> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mitu.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mitu.ai/_mcp/server.

# 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

| Field                   | Type                                                    | Required    | Description                                                                                         |
| ----------------------- | ------------------------------------------------------- | ----------- | --------------------------------------------------------------------------------------------------- |
| `path`                  | `string`                                                | Yes         | The path on your API, relative to the configured API base URL.                                      |
| `method`                | `GET` \| `POST` \| `PUT` \| `PATCH` \| `DELETE`         | Yes         | The HTTP method used when Mitu sends the request to your API.                                       |
| `name`                  | `string`                                                | Yes         | The tool name presented to AI clients, such as `create_order`.                                      |
| `description`           | `string`                                                | Yes         | Explains what the operation does and what result it produces.                                       |
| `when_to_use`           | `string`                                                | No          | Explains when the agent should choose this tool and what should already be known before calling it. |
| `pricing_type`          | `free` \| `fixed` \| `dynamic` \| `tiered` \| `session` | Yes         | Determines how the operation is priced.                                                             |
| `price`                 | `number`                                                | Conditional | The amount charged for a fixed-price operation.                                                     |
| `input_schema`          | `JSON Schema`                                           | No          | Describes the arguments the agent can provide.                                                      |
| `output_schema`         | `JSON Schema`                                           | No          | Describes the response the agent should expect.                                                     |
| `requires_auth`         | `boolean`                                               | No          | Determines whether the operation requires an identified customer.                                   |
| `rate_limit_per_minute` | `number`                                                | No          | Configures the allowed request rate for the endpoint.                                               |
| `is_public`             | `boolean`                                               | No          | Determines whether the endpoint is included in the published tool list.                             |

See [Pricing](/platform/payments/pricing) for the behaviour of each pricing model and [Authentication](/platform/mcp/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.

```text
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:

```text
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:

```text
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](/platform/mcp/open-api-import) for the import process.

## Related

#### [Tool schemas](/platform/mcp/tool-schemas)

Define the inputs and outputs an AI agent works with.

#### [Pricing](/platform/payments/pricing)

Configure free and paid operations.

#### [Authentication](/platform/mcp/authentication)

Decide which operations require an identified customer.

#### [OpenAPI import](/platform/mcp/open-api-import)

Create endpoint definitions from an existing API specification.