MCP, APIs, and function calling

An HTTP API defines how software talks to a service. Function calling lets a model produce arguments for a declared function. MCP connects these ideas across hosts and servers.

An MCP server can call an API you already have. It can turn a broad API into a smaller interface with names, descriptions, schemas, results, and permission boundaries that make sense to an AI application.

For example, a billing API may expose dozens of endpoints. An MCP server could expose one find_invoice tool that accepts an invoice number and returns only the fields needed for support. The server handles API authentication and translates upstream failures into a useful result. The model never needs the raw API token.

The host still decides whether and when to present a capability to a model. The server executes only the operations it exposes.

Do not mirror every API endpoint automatically. Start from a real user task and expose the smallest operation that completes it.

The layers have different responsibilities:

• the API defines the service’s native operations and authorization
• the MCP server adapts selected operations into focused capabilities
• the protocol handles discovery and messages
• model tool calling proposes structured arguments
• the host decides what reaches the model and what requires approval

Schemas improve structure, not truth. A string that matches an invoiceId schema may still name an invoice the current user cannot access. The server must authenticate, authorize, validate, rate-limit, and log sensitive actions just like any other application boundary.

Take one existing API endpoint and design a smaller task-level tool around it. List what the tool deliberately omits, which identity it acts as, and which upstream errors callers need to distinguish.

MCP complements APIs and function calling. It does not erase their security or product-design work.