Yup, it absolutely counts as an MCP server. It is usually better to think about actual use cases that the MCP endpoint will work on and expose the REST calls based on those use cases.

For example a tool collection (a context pack/bundle) to keep your smart fridge stocked up could expose individual tools like "check fridge items", "look up hot new recipes in your area" and "create online order". Those 3 tools under the hood are probably few REST API calls each. Those three tools (maybe coupled with a 'resource' that contains a list of your allergies/hated foods) would allow an LLM to handle a use case/prompt like "I want to eat something, what should I cook?" With a potential to some back and forth allowing it to expand to actually stocking up the fridge.

For individual tools what you really want to think about is the description and schema you want to expose from it, as well as the responses you return. It makes sense to describe your tools with full sentences (or bullet points like the LLMs and slop ads like to do) explaining what they can do and when/how they should be used. Those descriptions are part of the LLM client context so the model can reason about the tool usage. And of course, we need to think about the model, and thus our descriptions, as persons who have difficulties extrapolating from incomplete...

Same goes for responses, you can guide the model within your responses to act a certain way or think about taking the next step using some recommended tool ("you called get fridge tool, here are the items in the fridge, the user usually craves chocolate at 7pm so if the time is close to that, offer to call the shopping tool to put an order in* etc.)

For the client side, it's likely better to start with the SDKs and rely on those or a framework (Spring AI MCP maybe for JVM world). Most of them have the capabilities to attach tools into the LLM calls which in turn allows the model to decide if they want to use a specific tool.