Endpoints

An MCP endpoint connects an operation on your existing API to a tool that an AI agent can understand. The endpoint tells Mitu where the operation lives, what it does, when an agent should use it, what request and response shapes it expects and whether the operation requires authentication or payment.

Register the operations that are useful to an AI agent rather than publishing every route your backend serves. Your API remains unchanged and continues to handle the actual request using the business logic, account rules and data you already maintain.

Endpoint fields

See Pricing for the behaviour of each pricing model and Authentication for customer access.

Name tools by what they do

Tool names should be short, specific and action-oriented. A consistent verb_noun pattern makes a tool list easier for both developers and AI models to understand.

list_locations
search_availability
create_booking
get_booking
cancel_booking

The name should identify the operation, while the description provides the meaning and context the name cannot carry by itself.

Write useful descriptions

A description should explain the behaviour of the operation rather than simply repeat its name or HTTP route.

For example:

Poor:
Creates order
Better:
Creates an order for the signed-in customer using the confirmed items,
delivery address and order details.

A good description tells the model what will happen if it calls the tool. This becomes particularly important for operations that create, modify, cancel or purchase something because the model needs to distinguish informational actions from actions that have consequences.

Tell the agent when to use a tool

Use when_to_use to describe the conditions that should already be true before the agent calls the operation. This gives the model sequencing information that is difficult to infer from the tool name alone.

For example:

Use after the customer has confirmed the items, quantities,
delivery address and final order details.

This is especially useful when several tools could appear relevant at the same point in a conversation. Clear usage guidance reduces the chance that an agent calls a transaction operation before it has gathered the information required to perform it correctly.

Design a coherent tool set

A useful tool set normally gives the agent enough capabilities to discover information, perform an action and retrieve the result afterwards. For an ordering product, that might mean tools for retrieving available items, checking whether delivery is possible, creating an order and checking its status.

A booking product might instead provide search_availability, create_booking and get_booking. The exact operations depend on your product, but the principle is the same. The agent should be able to gather the information it needs before committing to an action and later retrieve the state of anything it created.

Do not publish internal administration routes or operations an agent should never call. A smaller set of well-described capabilities is generally more useful than a large tool list filled with operations that are irrelevant to customer workflows.

Keep changing information in your API

Prices, inventory, availability, delivery times and other changing information should come from your API rather than being embedded into tool descriptions. Tool metadata helps an agent understand how to interact with your product, while your API should remain authoritative for the current state of your product.

When the underlying information changes, the agent can retrieve the new value through the appropriate tool instead of depending on stale metadata loaded when the connection was established.

Import existing operations

If you already maintain an OpenAPI document, you can use it to create endpoint definitions and schemas instead of configuring every operation manually. Imported definitions should still be reviewed before they are published because an API reference and an AI tool description serve different purposes.

See OpenAPI import for the import process.

Related