To connect an AI assistant to MCP ROOTE, add the remote server https://mcp.roote.ai/mcp in an application compatible with MCP Streamable HTTP. The server exposes reading tools for addresses, mobility, and nearby services.
This tutorial follows the configuration published by ROOTE and a connection check to the server. Menu titles vary depending on the client; the URL, transport, and tool scheme are the elements to verify. The server's tools/list may change ahead of documentation: use the capabilities actually announced.
Verify client compatibility
Your application must accept a remote MCP server via Streamable HTTP. A client limited to local stdio servers cannot use this URL as an executable command. Also check if your account permits adding custom servers.
If the application offers a form, enter ROOTE as the name and the server URL as the address. If it accepts a file in mcpServers format, ROOTE documentation provides this minimal configuration:
{
"mcpServers": {
"roote": { "url": "https://mcp.roote.ai/mcp" }
}
}Official ROOTE connection configuration
Choose anonymous or authenticated access
Documentation provides for anonymous access without an Authorization header, subject to the Free projection and active API limits. For authenticated access, use the client’s secure mechanism to pass your token in a Bearer header.
Authorization: Bearer YOUR_API_TOKENYOUR_API_TOKEN is a placeholder to replace in the client’s secure configuration. Do not paste the token in conversations, public URLs, or articles. An invalid or revoked token is not automatically replaced by anonymous access.
Confirm tools are available
After connecting, open the server’s tools list in your client. ROOTE documentation describes the initialize, tools/list, then tools/call sequence; compatible clients normally perform these exchanges for you. Use the version and capabilities advertised by the server.
The server exposes geocode, place_search, reverse_geocode, nearby, mobility_nearby, transit_nearby, transit_disruptions, and services_nearby. The absence of these tools indicates a connection, discovery issue, or a service change. Always check the list announced by the server. Journey and Departures are not yet exposed there.
Perform a first reproducible search
Start with an explicit address: “Use ROOTE to search 10 rue de Rivoli, Paris, France. List the candidates found and their coordinates.” Examine the tool’s result, not just the model’s written response.
{
"name": "geocode",
"arguments": {
"q": "10 rue de Rivoli, Paris",
"language": "fr",
"country": "FR"
}
}This block illustrates the name and arguments of a call; it is not a complete HTTP request. Your client encapsulates the MCP call. If multiple plausible candidates return, pick the correct one before searching around the point.
You can then test transport around a reference point in Bordeaux. The coordinates below are for testing and do not claim to come from the previous Paris address.
{
"name": "transit_nearby",
"arguments": {
"lat": 44.8416106,
"lon": -0.5810938,
"radius": 600,
"modes": ["bus", "tram"],
"limit": 10
}
}Read the result before concluding
Check status, returned entities, coverage, warnings, and applied limits. A partial response may contain useful information. An empty search does not prove the physical absence of transports in the city.
The expected test result is a structured response or explicit error, not a predefined number of stops. Sources and coverage may evolve. Stop searches do not return their upcoming departures.
Troubleshoot connection errors
| Symptom | Helpful check |
|---|---|
| No tools discovered | Exact URL, remote transport, and client authorization |
| Argument error | Types, allowed values, and fields in the declared schema |
| Authentication error | Bearer validity and header configuration |
| Limit reached | Active limits, retry delay, and call frequency |
| Empty or partial result | Coordinates, filters, radius, coverage, and warnings |
Distinguish an empty result from an API error
Create a complete assistant from an address
Understand the role of an MCP server
Coming soon: next departures and route calculation
ROOTE plans to extend its MCP to upcoming departures and route calculation. These functions are forthcoming and are not yet part of the tools currently exposed by the MCP server. When available, check the tools announced by the server, their arguments, and the information actually returned before announcing a passage or journey.
Frequently asked questions
Is a token mandatory?
Documentation provides for Free anonymous access. Limits and capacities remain those applied by the service.
Why does my assistant announce a schedule after a stop search?
A transit_nearby search does not provide next departures. Ask the assistant to cite the actual returned data and note this absence.
Can I test without creating an application?
Yes, with a compatible client that allows adding a remote server and executing its tools.