What is the Atoti MCP Server?

• It acts as a bridge between an Atoti data model and AI tools
• It enables dynamic, context-aware interactions

​

What does the MCP Server provide?

• Query Atoti cubes, hierarchies, and measures through an LLM client
• Call custom tools that encapsulate business-specific logic
• Connect to any MCP-compatible LLM client, such as Claude Desktop
• Use the tools of other MCP Servers as Atoti’s own

​

Why use the Atoti MCP Server?

• Use Atoti’s analytical capabilities from external AI tools without modifying the Atoti application
• No vendor lock-in: works with any MCP-compatible LLM client
• Standardized protocol eliminates the need for custom integration code

​

Can Atoti connect to other MCP Servers?

• Each server exposes its own cube.
• Each cube uses their tools as its own, in chat and on its own MCP endpoint.
• Every call runs under the identity of the user who triggered it. This means that the other cube’s role-based restrictions stay in force.

​

What are the best practices for MCP configuration?

1. Serve chat from one application
2. Connect every other server to that application over MCP

• Holds the only LLM configuration for the deployment.
• Answers every cube in one conversation.

​

How to configure chat across a deployment

1. Pick the application that users send their prompts to, called the main application below.
2. Turn chat off on every other application of the deployment.
3. Declare, on the main application, one MCP connection per other application.

atoti:
  ai:
    chat:
      enabled: false

import atoti as tt
from atoti_ai import AiConfig

session_config = tt.SessionConfig(ai=AiConfig(chat_enabled=False))

• The /chat endpoint is not registered.
• The /versions endpoint stops advertising the activeviam/ai/chat namespace.
• Auto-Explain and the MCP Server are unaffected
• The cube tools stay available to the main application.

​

How to connect to an external MCP Server

• Connect to every server directly. Tools do not chain from one connection to the next: a server asked by another aggregating server answers with its own tools alone. Connecting to a peer never brings in the servers that peer is itself connected to.
• Use Streamable HTTP. Declare every connection under spring.ai.mcp.client.streamable-http.connections. It is the only transport supported for an outbound connection.
• Match the authentication mode to the remote server. Use atoti-jwt for another application of the same deployment, sharing the same atoti.jwt.key signing key. Use pass-through for a server validating tokens against an external identity provider. Leave the default none only for a genuinely unauthenticated server, such as a local development server.
• Name the connection after the server. The name prefixes every tool taken from it, and the model reads it. Keep it to 53 characters or fewer, and keep names distinct after normalization: pnl-server and pnl_server collide, and the application refuses to start.
• Vet a server run as a local process. Such a server runs on the machine hosting the application, with that process’s rights. Declare only commands the deployment controls.
• Plan no failover. An unreachable server costs only its own tools, and the failure is not cached. Every other server keeps answering, and the tools reappear on the next answered request.