AI capabilities overview
ApiGo organizes its AI capabilities into four main areas: AI data query (natural-language data lookup), AI assistant (multi-turn conversation with operation confirmation), MCP access (letting external agents call platform capabilities) and AI call logs (auditing and success rates). This page explains how they relate; see the dedicated pages for detailed procedures.
Capability map
| Capability | Audience | Details |
|---|---|---|
| AI data query | Platform users | AI data query and SQL analysis |
| AI assistant chat | Platform users | The "AI assistant" section of this page |
| App MCP | External AI clients | MCP access |
| Admin MCP / agents | AI agents managing the platform | MCP agents |
| Call logs and success rates | Administrators | AI call logs |
AI data query
Describe your data needs in natural language, and the system combines the semantic layer to generate SQL, execute the query and render charts:
- Select a project and data source, then enter a business question.
- The orchestrator parses the intent and matches the scenario plus semantic terms/metrics.
- SQL is generated and executed after read-only validation.
- Results are returned as tables or charts, and you can keep asking follow-up questions.
AI data query only allows read-only queries. Write operations, DDL and multiple statements are blocked; when SQL generation fails, the system attempts automatic repair, and if that still fails, it returns a readable error explanation. See AI data query and SQL analysis for the full flow and limitations.
AI assistant
The AI assistant is the conversational entry point in the platform. It uses SSE streaming responses and supports multi-turn context. Unlike ordinary Q&A, it can:
- Call platform tools to query resources such as APIs, data sources and logs;
- Generate a confirmation card when a write or high-risk operation is required, and execute only after the user confirms;
- Display the execution trace, including each tool call, SQL, latency and result summary;
- Route to different capability sets by scenario, such as data query, operations and API development scenarios.
Session state is stored in base_ai_agent_session_state, so a pending confirmation flow can continue after the page is refreshed or the reply is spread across multiple turns.
MCP access
The platform provides two MCP services, both using JSON-RPC 2.0 / MCP 2025-06-18:
| Entry | Address | Authentication | Tool source |
|---|---|---|---|
| App MCP | /mcp/{appCode} | X-AppKey | APIs that are published, use app_key authentication and include MCP in their release protocol |
| Admin MCP | /api/box/mcp/{agentCode} | X-Agent-Key | The admin tool set (querying and managing platform resources) |
Tool mapping rules
For an API to be visible to external MCP clients, all of the following must be satisfied:
- The release protocol includes
MCP; - The API is released to the
prodenvironment and is live; - The authentication method is
app_key; - The calling credential has been granted access to the API;
- The app has
mcpEnabled = 1.
The tool name is taken from the API definition's toolName first; when empty, skillCode is used, and when that is also empty, the name is generated from the path. The tool description comes from the API documentation and parameter definitions.
Supported methods
| Method | Handled by | Description |
|---|---|---|
initialize | Gateway | Returns the protocol version and server capabilities |
notifications/initialized | Gateway | Client initialization complete notification, with no response |
tools/list | Gateway | Returns the tool list available to the current credential |
tools/call | Execution chain | Converted into a REST runtime call, passing through authentication, rate limiting, IP, caching and logging |
MCP only accepts POST; GET returns 405. See MCP access for details.
Controlled access model
AI is not a bypass around governance; all capabilities go through the same boundaries:
- Data isolation: sessions, the semantic layer and data sources are all bound to projects and are not visible across projects.
- Read-only first: data query only executes queries; write operations require explicit confirmation or dedicated tool permissions.
- Tool whitelist: agents can call only the tools bound to them, and read and write tools are authorized separately.
- Full auditing: every question, tool call and SQL execution is written to the AI audit log, including latency, tokens and success status.
- Traceable failures: failure reasons are grouped by scenario, and the success-rate report aggregates by scenario and failure reason.