企业级 AI 控制平面 — ThinkNEO 的远程 MCP 服务器。
使 Claude、ChatGPT、Copilot、Gemini 以及任何兼容 MCP 的客户端能够直接与 ThinkNEO 的治理功能进行交互：支出跟踪、护栏评估、策略执行、预算监控、合规状态和提供商健康状况。
注册表： ai.thinkneo/control-plane
端点： https://mcp.thinkneo.ai/mcp
传输： streamable-http
认证： Bearer 令牌（ThinkNEO API 密钥），用于受保护的工具
工具 | 描述 | 认证 |
| 读取 Claude Code 项目内存文件 | 公开 |
| 按提供商/模型/团队划分的 AI 成本明细 | 需要 |
| 预检提示词安全评估 | 需要 |
| 验证模型/提供商/操作是否被允许 | 需要 |
| 预算使用情况和执行情况 | 需要 |
| 活动警报和事件 | 需要 |
| SOC2/GDPR/HIPAA 就绪状态 | 需要 |
| 实时 AI 提供商健康状况 | 公开 |
| 预约 ThinkNEO 演示 | 公开 |
Related MCP server: Compliance Scanner MCP
添加到 ~/.claude/claude_desktop_config.json (macOS/Linux) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：
{
"mcpServers": {
"thinkneo": {
"url": "https://mcp.thinkneo.ai/mcp",
"headers": {
"Authorization": "Bearer <YOUR_THINKNEO_API_KEY>"
}
}
}
}{
"mcpServers": {
"thinkneo": {
"url": "https://mcp.thinkneo.ai/mcp"
}
}
}要获取您的 ThinkNEO API 密钥，请在 thinkneo.ai/talk-sales 申请访问权限或发送电子邮件至 hello@thinkneo.ai。
添加到工作区或用户设置中的 .vscode/mcp.json：
{
"servers": {
"thinkneo": {
"type": "http",
"url": "https://mcp.thinkneo.ai/mcp",
"headers": {
"Authorization": "Bearer <YOUR_THINKNEO_API_KEY>"
}
}
}
}curl -X POST https://mcp.thinkneo.ai/mcp \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "tools/list",
"id": 1,
"params": {}
}'curl -X POST https://mcp.thinkneo.ai/mcp \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "tools/call",
"id": 2,
"params": {
"name": "thinkneo_provider_status",
"arguments": {"provider": "openai"}
}
}'curl -X POST https://mcp.thinkneo.ai/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <YOUR_API_KEY>" \
-d '{
"jsonrpc": "2.0",
"method": "tools/call",
"id": 3,
"params": {
"name": "thinkneo_check_spend",
"arguments": {
"workspace": "prod-engineering",
"period": "this-month",
"group_by": "provider"
}
}
}'curl -X POST https://mcp.thinkneo.ai/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <YOUR_API_KEY>" \
-d '{
"jsonrpc": "2.0",
"method": "tools/call",
"id": 4,
"params": {
"name": "thinkneo_evaluate_guardrail",
"arguments": {
"text": "Summarize this document for me",
"workspace": "prod-engineering",
"guardrail_mode": "enforce"
}
}
}'Docker + Docker Compose
Nginx 反向代理（用于 HTTPS）
git clone https://github.com/thinkneo-ai/mcp-server.git
cd mcp-server
# Configure environment
cp .env.example .env
# Edit .env: set THINKNEO_MCP_API_KEYS and THINKNEO_API_KEY
# Build and start
docker compose up -d
# Verify
curl -X POST http://localhost:8081/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/list","id":1,"params":{}}'server {
listen 443 ssl;
server_name mcp.thinkneo.ai;
ssl_certificate /etc/letsencrypt/live/mcp.thinkneo.ai/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mcp.thinkneo.ai/privkey.pem;
location /mcp {
proxy_pass http://127.0.0.1:8081/mcp;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Required for streamable-http (keep connection open)
proxy_buffering off;
proxy_read_timeout 300s;
proxy_send_timeout 300s;
}
}ai.thinkneo/control-plane 命名空间）# 1. Generate Ed25519 key pair
openssl genpkey -algorithm Ed25519 -out /tmp/thinkneo-mcp-key.pem
# 2. Get the public key value for the DNS TXT record
PUB=$(openssl pkey -in /tmp/thinkneo-mcp-key.pem -pubout -outform DER | tail -c 32 | base64)
echo "Add DNS TXT record to thinkneo.ai:"
echo " Host: _mcp"
echo " Type: TXT"
echo " Value: v=MCPv1; k=ed25519; p=${PUB}"
# 3. Wait for DNS propagation (usually 5-30 minutes), then publish
mcp-publisher publish \
--registry-url "https://registry.modelcontextprotocol.io" \
--mcp-file "./server.json" \
--auth-method dns \
--dns-domain thinkneo.ai \
--dns-private-key /tmp/thinkneo-mcp-key.pemio.github.thinkneo-ai/control-plane 命名空间）mcp-publisher login github
mcp-publisher publish \
--registry-url "https://registry.modelcontextprotocol.io" \
--mcp-file "./server.json"请参阅 .github/workflows/publish-mcp.yml 以获取完整的 CI/CD 工作流。
# Search
curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=thinkneo" | jq .
# Direct lookup
curl -s "https://registry.modelcontextprotocol.io/v0/servers/ai.thinkneo%2Fcontrol-plane" | jq .本项目采用 MIT 许可证 授权。
ThinkNEO 平台： thinkneo.ai
A2A 代理： https://agent.thinkneo.ai/a2a (用于代理间交互的 A2A 协议)
MCP 注册表： registry.modelcontextprotocol.io
MCP 规范： modelcontextprotocol.io
联系方式： hello@thinkneo.ai
Check if a specific model, provider, or action is allowed by the governance policies configured for a workspace. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Workspace name or ID whose governance policies to check against | |
| model | No | AI model name to check (e.g., gpt-4o, claude-sonnet-4-6, gemini-2.0-flash) | |
| provider | No | AI provider to check (e.g., openai, anthropic, google, mistral) | |
| action | No | Specific action to check (e.g., create-completion, use-tool, fine-tune) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the authentication requirement, which is valuable behavioral context not present in the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence front-loads the core purpose and scope; the second states the auth requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (4 simple parameters), 100% schema coverage, existing annotations, and presence of an output schema, the description is complete. It does not need to detail return values since the output schema exists, and the auth requirement is noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description references the parameter concepts (model, provider, action) but does not add semantic details beyond the schema's examples (e.g., gpt-4o, openai) or explain parameter interaction logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Check) and the specific resource (governance policy allowance for models/providers/actions). It implicitly distinguishes from siblings like check_spend or get_budget_status through specificity, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires authentication' as a prerequisite, but provides no guidance on when to use this tool versus siblings like thinkneo_get_compliance_status or thinkneo_evaluate_guardrail, nor when to check specific parameter combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check AI spend summary for a workspace, team, or project. Returns cost breakdown by provider, model, and time period. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Workspace name or ID (e.g., 'prod-engineering', 'finance-team') | |
| period | No | Time period for the report: today, this-week, this-month, last-month, or custom | this-month |
| group_by | No | Dimension to group costs by: provider, model, team, or project | provider |
| start_date | No | Start date for a custom period in ISO format (YYYY-MM-DD). Only used when period='custom' | |
| end_date | No | End date for a custom period in ISO format (YYYY-MM-DD). Only used when period='custom' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety traits. It adds value by disclosing the authentication requirement and summarizing the return structure (cost breakdown by provider/model/period). However, it omits rate limits, caching behavior, or error conditions (e.g., invalid workspace).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero waste. It front-loads the core action ('Check AI spend summary'), follows with return value description, and ends with the auth requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated) and 100% input schema coverage, the description appropriately provides a high-level summary rather than detailed field documentation. However, it lacks differentiation from financial siblings (particularly thinkneo_get_budget_status) and doesn't clarify the operational scope limitations (workspace-only filtering).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema itself documents all five parameters comprehensively (including the conditional logic for start_date/end_date). The description mentions 'workspace, team, or project' which loosely maps to the workspace parameter and group_by options, but doesn't add syntax details, format examples, or clarify the relationship between period and date parameters beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Check[s] AI spend summary' with specific breakdown dimensions (provider, model, time period). However, it slightly conflates filtering scope by mentioning 'team, or project' as targets when the schema only supports workspace-level filtering with team/project as grouping dimensions (group_by parameter), and doesn't differentiate from the similar sibling thinkneo_get_budget_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Requires authentication' as a prerequisite but provides no guidance on when to use this tool versus alternatives like thinkneo_get_budget_status (which also deals with financial data) or when to use custom date ranges versus preset periods. No exclusions or prerequisites beyond auth are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a prompt or text against ThinkNEO guardrail policies before sending it to an AI provider. Returns risk assessment, violations found, and recommendations. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The prompt or text content to evaluate for policy violations (max 32,000 characters) | |
| workspace | Yes | Workspace whose guardrail policies to apply for this evaluation | |
| guardrail_mode | No | Evaluation mode: 'monitor' (log violations only) or 'enforce' (block the request on violation) | monitor |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent safety. The description adds valuable behavioral context not in annotations: the authentication requirement and a summary of return values (risk assessment, violations, recommendations). It appropriately doesn't contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly constructed sentences with zero waste. Front-loaded with the core action, followed by return value description, and ending with the authentication requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a complete input schema (100% coverage), output schema, and annotations, the description provides sufficient additional context (authentication needs, return summary, workflow timing) without needing to duplicate schema details. Adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is appropriately met. The description implicitly clarifies the 'text' parameter by calling it a 'prompt or text' and provides workflow context ('before sending to AI provider') that adds semantic meaning to the evaluation process without redundantly listing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (evaluate), resource (prompt/text against ThinkNEO guardrail policies), and scope. It distinguishes from siblings by specifying 'guardrail policies' versus general 'policy' checks or other operations, though it doesn't explicitly contrast with thinkneo_check_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important temporal context ('before sending it to an AI provider') implying when to invoke it in a workflow. However, it lacks explicit guidance on when to use this versus thinkneo_check_policy or other policy-related siblings, and doesn't mention prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current budget utilization and enforcement status for a workspace. Shows spend vs limit, alert thresholds, and projected overage. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Workspace name or ID to retrieve current budget status for |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds 'Requires authentication' which is critical behavioral context not in annotations, and previews returned data concepts (spend vs limit, thresholds). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. Front-loaded with main action ('Get current budget...'), followed by specific capabilities ('Shows spend vs limit...') and requirements ('Requires authentication'). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a read-only status tool with existing output schema and annotations. Description covers authentication requirement and nature of returned data without needing to replicate output schema details. Sufficient for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'workspace' parameter fully documented in schema ('Workspace name or ID to retrieve current budget status for'). Description does not add parameter-specific semantics beyond schema, which meets baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and specific resource 'budget utilization and enforcement status'. Lists specific data points (spend vs limit, thresholds, overage) that implicitly distinguish from simple spend checking, though does not explicitly differentiate from sibling thinkneo_check_spend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives like thinkneo_check_spend. While the specific capabilities listed (enforcement status, projections) imply appropriate use cases, there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get compliance and audit readiness status for a workspace. Shows governance score, pending actions, and compliance gaps. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Workspace name or ID to evaluate compliance readiness for | |
| framework | No | Compliance framework to assess: soc2 (SOC 2 Type II), gdpr (GDPR), hipaa (HIPAA), or general (ThinkNEO AI governance) | general |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only/idempotent behavior, and the description is consistent with 'Get' and 'Shows'. It adds valuable context beyond annotations by noting the authentication requirement and previewing specific output content (governance score, pending actions, compliance gaps), helping the agent understand what data will be returned even though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently structured: purpose statement first, followed by output preview, then authentication requirement. Every sentence provides distinct value without redundancy or unnecessary elaboration. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of complete schema annotations (100% coverage), output schema, and safety hints (readOnly/idempotent), the description provides sufficient high-level context. It appropriately focuses on purpose and prerequisites rather than duplicating structured data, though it could slightly improve by hinting at relationship to sibling governance tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not explicitly discuss the parameters (workspace, framework) or their semantics, relying entirely on the schema's detailed descriptions. No additional parameter guidance (e.g., format hints, examples) is provided in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'compliance and audit readiness status' and specifies the target resource (workspace). It distinguishes itself from siblings like check_policy or check_spend by specifying outputs unique to compliance (governance score, compliance gaps), though it doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Requires authentication' as a prerequisite but provides no guidance on when to use this tool versus siblings like thinkneo_check_policy or thinkneo_evaluate_guardrail. There are no explicit when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active alerts and incidents for a workspace. Includes budget alerts, policy violations, guardrail triggers, and provider issues. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | Workspace name or ID to list active alerts for | |
| severity | No | Filter alerts by severity level: critical, warning, info, or all | all |
| limit | No | Maximum number of alerts to return (1–100) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint: true, and the description aligns with this ('List'). The description adds valuable behavioral context beyond the annotation: it specifies 'active' status (scope/temporal filtering), lists content categories to expect, and notes authentication requirements. It does not contradict the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences with zero waste: sentence one establishes core purpose, sentence two specifies content types (high value add), and sentence three states authentication requirements. Information is front-loaded appropriately with the primary action stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (covering return values), 100% parameter schema coverage, and readOnly annotations, the description provides sufficient context. It adequately explains what the tool returns (the four alert types) without needing to detail return structure. It meets completeness requirements for a standard list operation with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed descriptions for workspace, severity, and limit parameters. The description mentions 'workspace' in the first sentence, reinforcing the required parameter's role, but does not elaborate further on parameter semantics. With full schema coverage, the baseline score of 3 is appropriate as the description does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with clear resource ('active alerts and incidents') and scope ('for a workspace'). It effectively distinguishes from siblings (check_policy, check_spend, evaluate_guardrail, etc.) by positioning this as an aggregation endpoint that covers 'budget alerts, policy violations, guardrail triggers, and provider issues'—implicitly contrasting with the specific deep-check operations of sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by enumerating the specific alert types included (budget, policy, guardrail, provider), which helps identify when to use this tool versus specific check/evaluate siblings. However, it lacks explicit guidance such as 'use this for overview, use check_policy for specific policy validation' or explicit when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time health and performance status of AI providers routed through the ThinkNEO gateway. Shows latency, error rates, and availability. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Specific provider to check: openai, anthropic, google, mistral, xai, cohere, or together. Omit to get status for all providers. | |
| workspace | No | Workspace context for provider routing configuration (optional) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true, the description adds valuable behavioral context: it specifies the authentication requirements ('No authentication required') and details what metrics are returned (latency, error rates, availability). This goes beyond the binary read-only flag to explain what data the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: first establishes purpose, second details output metrics, third states authentication requirements. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and readOnly annotations, the description provides sufficient context without redundancy. It adequately covers the tool's purpose, return value categories, and invocation prerequisites for a simple monitoring tool with two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents both parameters including specific provider enum values (openai, anthropic, etc.) and the optional workspace context. The description relies on the schema for parameter semantics, which is appropriate given the comprehensive schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Get', 'Shows') and clearly identifies the resource (health and performance status of AI providers) and scope (routed through ThinkNEO gateway). It effectively distinguishes from siblings like check_spend, check_policy, and get_compliance_status by focusing on provider infrastructure rather than financial or policy domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage constraint ('No authentication required'), which is helpful for invocation prerequisites. However, it lacks explicit guidance on when to use this tool versus sibling status-checking tools like thinkneo_get_budget_status or thinkneo_check_spend, leaving the selection criteria implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a demo or discovery call with the ThinkNEO team. Collects contact information and preferences. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_name | Yes | Full name of the person requesting the demo | |
| company | Yes | Company or organization name | |
| Yes | Business email address to receive follow-up from the ThinkNEO team | ||
| role | No | Contact's role: cto, cfo, security, engineering, or other | |
| interest | No | Primary area of interest: guardrails, finops, observability, governance, or full platform | |
| preferred_dates | No | Preferred meeting dates, times, and timezone (e.g., 'Tuesdays or Thursdays, 9-11am EST') | |
| context | No | Additional context such as current AI providers used, request volume, or specific use case |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-idempotent operation (write). The description adds valuable behavioral context that no authentication is required, which is critical for a write operation. It also clarifies the data collection nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: the first states the core action, the second describes the data collection behavior, and the third provides the auth requirement. Every sentence earns its place with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, existing output schema, and annotations covering the safety profile, the description provides complete contextual value by adding the authentication requirement (not in annotations) without needing to repeat parameter or return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all seven parameters. The description broadly mentions 'contact information and preferences' but does not add semantic details, formats, or relationships beyond what the structured schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Schedule') with a clear resource ('demo or discovery call with the ThinkNEO team'), and effectively distinguishes from operational siblings (check_policy, check_spend, etc.) by indicating this is for booking meetings rather than querying system state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for scheduling demos and includes the important usage constraint 'No authentication required.' However, it lacks explicit when-to-use guidance contrasting with the seven sibling monitoring tools, though the functional distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
thinkneo_check_policythinkneo_check_spendthinkneo_evaluate_guardrailthinkneo_get_budget_statusthinkneo_get_compliance_statusthinkneo_list_alertsthinkneo_provider_statusthinkneo_schedule_demoScored across 8 tools
Tools are generally distinct with clear domains: policy (permissions), guardrail (content safety), spend (analytics), budget (limits), compliance (audit), alerts (incidents), and provider health. Minor semantic overlap exists between check_spend and get_budget_status (both financial), and between check_policy and evaluate_guardrail (both validation), but descriptions clarify their distinct scopes.
Consistent snake_case prefixing (thinkneo_) and mostly verb_noun structure (check, evaluate, get, list, schedule). Minor deviation with provider_status which lacks a verb prefix, breaking the pattern established by get_budget_status and get_compliance_status. Verbs vary (check/evaluate/get) but remain readable.
Eight tools is a reasonable count for an AI governance control plane, covering policy, cost, compliance, and operational monitoring. The inclusion of schedule_demo (a sales/marketing function) is slightly incongruous with the operational focus of the other seven tools, but doesn't bloat the set.
Strong observability coverage (read-only status checks, spend analysis, alert listing) but lacks expected control plane capabilities: no tools to create/update policies, set budgets, configure guardrails, or manage/acknowledge alerts. The surface is adequate for monitoring but incomplete for 'control' operations implied by the server name.
Enterprise AI Control Plane: governance, guardrails, spend tracking, compliance & smart routing.
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
