MCP tool

The Model Context Protocol is a standard for connecting agent runtimes to external capabilities. An MCP server publishes a set of tools; a client discovers them, reads their descriptions and input schemas, and calls them during a session. The point of the standard is that a tool written once works across any runtime that speaks the protocol, rather than being wired to one product.

A tool definition is mostly three things: a name, a description in plain language, and a JSON schema for its inputs. That description is not documentation for a human reader, it is the entire basis on which a model decides whether this tool is the right one. This is the part that most implementations under-invest in.

What separates a tool that gets called correctly from one that does not:

• Narrow purpose. search_hospitals_by_province is easier to select correctly than query, which can mean anything.
• A description that states when not to use it. Boundaries prevent wrong selections more effectively than more detail about the happy path.
• Constrained inputs. Enums and explicit formats beat free text, because they remove guesses.
• Errors written for a reader. A tool result saying province not recognised, expected one of the 38 province names lets the agent correct itself. A bare 400 does not.

Wrapping an existing API is not the same as designing tools. A REST API with 40 endpoints does not become 40 good tools automatically. Endpoints are organised around resources; tools should be organised around intents.

API Indonesia is a live example of the pattern, exposing 77 MCP tools alongside its 23 REST API groups over the same underlying data. The same authentication and quota rules apply through either surface, which is the sane arrangement: an agent calling a tool is still a client, and it still needs an API key, a quota, and a rate limit.