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.