Connect your product to AI agents

Connect your existing API

Start by connecting the API that already powers your product. In the dashboard, open your MCP configuration and provide the base URL that Mitu should use when calling your API.

https://api.example.com

You do not need to create separate endpoints for AI agents. The same API that serves your existing application can also handle requests initiated through MCP.

When you connect your API, Mitu provides a signing secret that your backend uses to verify requests sent by Mitu. Keep this secret secure and use it only from your server.

Learn more about Request verification.

Choose the operations agents can use

Select the parts of your product that are useful to an AI agent rather than making every API operation available. A booking product, for example, might let agents find locations, check availability, create bookings and retrieve existing bookings.

GET  /locations
GET  /availability
POST /bookings
GET  /bookings/{id}

Each operation becomes a tool the AI client can discover and call. You define the tool name, description, when it should be used and the request and response schemas that describe the operation.

For example:

name: create_booking
method: POST
path: /bookings
description: Creates a booking at a location for a given date, time and party size
when_to_use: Use after the customer has confirmed the location, date, time and party size
requires_auth: true
pricing_type: free

Start with the operations that represent useful actions in your product. A smaller set of clearly defined tools is easier for an AI agent to understand and use correctly than a large collection of operations with overlapping purposes.

Learn more about MCP endpoints.

Describe each tool clearly

The tool definition tells the AI agent what an operation does, when it should use it and what information it needs to provide. Use names that describe the action clearly and descriptions that explain the result the operation produces.

For example, create_booking is more useful when its description explains that it creates a booking for a specific location, date, time and party size. Its when_to_use can then tell the agent that the customer should already have confirmed those details before the operation is called.

Your input schema should match what your API actually accepts. Use clear field names, mark genuinely required values as required and use enums where only a fixed set of values is valid. The response schema should describe the information your API returns so the agent can use that result in the next part of the customer’s task.

{
  "type": "object",
  "properties": {
    "location_id": {
      "type": "string",
      "description": "Location identifier"
    },
    "date": {
      "type": "string",
      "format": "date"
    },
    "time": {
      "type": "string",
      "description": "24-hour local time, HH:MM"
    },
    "party_size": {
      "type": "integer",
      "minimum": 1
    }
  },
  "required": ["location_id", "date", "time", "party_size"]
}

Keep these schemas aligned with the validation rules already used by your backend. The goal is to describe your existing API accurately rather than create a second contract specifically for agents.

Learn more about Tool schemas.

Import your OpenAPI document

If you already maintain an OpenAPI document, you can import it instead of configuring every operation manually. Mitu can use the document to create the corresponding operations and schemas, which you can then review before making them available to AI agents.

Review the generated names and descriptions after importing. Documentation written for developers does not always give an AI agent enough context to decide when one operation should be used instead of another.

Learn more about OpenAPI import.

Choose how customers connect

Decide which operations require a signed-in customer and how Mitu should identify that customer. Public operations such as product catalogues, menus or general availability can remain available without customer authentication, while account-specific operations can require it.

Customers can connect using a customer key or your existing OAuth sign in flow. With a customer key, you provide the customer with their mcpk_... credential. With OAuth, the customer signs in using the account they already have with your product.

When OAuth is used, the signed-in customer’s access token can be forwarded with requests to your API so your existing authorisation, account and entitlement rules continue to apply.

Learn more in Connect customer accounts and MCP authentication.

Connect from an AI client

Once your tools are configured, customers can add your MCP connection to a compatible AI client such as ChatGPT, Claude, Claude Code, Cursor, Windsurf or another client that supports MCP.

They connect using your MCP URL and authenticate using the method you configured. Once connected, the AI client can discover the tools you made available and use them when they are relevant to the customer’s request.

If you use a custom domain, customers can connect through your own MCP URL rather than a Mitu-hosted address.

Learn more about Domains.

Verify requests from Mitu

When an AI agent uses one of your tools, Mitu sends the corresponding request to your API. Before processing the request, your backend should verify that the request came from Mitu.

When you connect your API, you receive a signing secret that your backend uses to verify requests sent by Mitu. Keep this secret secure and only use it from your server.

Request verification is separate from your customer authentication. It confirms that the request was sent through Mitu before your application trusts the request and processes it.

If you use OAuth for customer authentication, the signed-in customer’s access token is also forwarded with the request so your existing authorisation and account rules can continue to apply.

See Request verification for the verification process and implementation examples.

Return your normal API response

After verification, process the request using the same business logic your application already uses and return your normal API response.

For example, a booking operation can return the same booking object your website or application already receives:

{
  "id": "bk_77213",
  "status": "confirmed",
  "location_id": "lagos-01",
  "date": "2026-09-20",
  "time": "19:30",
  "party_size": 4
}

Mitu returns the result to the AI client so the agent can continue the customer’s task. You do not need to create agent-specific response objects, conversation transcripts or additional AI fields unless they are genuinely part of your own API contract.

Errors should also remain useful and descriptive. If a booking cannot be completed, for example, returning the reason and any available alternatives gives the agent enough information to help the customer choose what to do next.

Test the integration

Connect a test customer from an AI client and confirm that the client can discover the tools you configured. Test both read and write operations, confirm that your backend successfully verifies requests from Mitu and check that your normal API responses are returned correctly to the agent.

Also test the failure cases that matter to your product, such as invalid input, unavailable inventory or an unauthorised customer. The agent should receive enough information from your existing API response to understand what happened and determine the appropriate next action.

Once the core flow works, add more operations gradually rather than making your entire API available at once.