CueAPI 的官方 Model Context Protocol 服务器，CueAPI 是 AI 代理系统的开源协调层。
让您支持 MCP 的助手（Claude Desktop、Cursor、Zed 或任何其他 MCP 主机）能够在对话中调度代理工作、获取执行历史记录，并使用基于证据的结果报告来闭环。
代理无法通过一次调用完成任务。它们需要在时间、工具、环境、代理和人类之间进行协调。每一次交接都是隐藏静默失败的地方。CueAPI 通过结构化证据（外部 ID、结果 URL 或工件）来结束每一次交接。此 MCP 服务器为代理提供了对该表面的直接访问，因此代理既可以调度自己的后续工作，也可以提供带有证明的结果报告。
Related MCP server: LLM Bus
npm install -g @cueapi/mcp
# or use via npx (no install):
npx -y @cueapi/mcp将其添加到您的 Claude Desktop 配置中（macOS 上为 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"cueapi": {
"command": "npx",
"args": ["-y", "@cueapi/mcp"],
"env": {
"CUEAPI_API_KEY": "cue_sk_..."
}
}
}
}在 cueapi.ai 生成您的 API 密钥。自托管？请设置 CUEAPI_BASE_URL 以及 CUEAPI_API_KEY。
任何支持 stdio 服务器的 MCP 主机都可以运行此程序。将主机指向 cueapi-mcp 二进制文件，并在环境中传递 CUEAPI_API_KEY。
工具 | 功能 |
| 创建循环 (cron) 或一次性 ( |
| 列出提示，按状态过滤 |
| 获取单个提示的详细信息 |
| 立即触发现有提示，可选负载覆盖 |
| 更新提示的可变字段（名称、调度、回调、负载等） |
| 暂停提示，使其停止触发 |
| 恢复已暂停的提示 |
| 永久删除提示 |
| 列出历史执行记录，按提示/状态过滤 |
| 通过 ID 获取单个执行记录，包含状态 + 结果 |
| 列出可领取的执行记录，按任务/代理在服务器端过滤 |
| 原子化领取特定执行记录以进行处理 |
| 领取下一个可用执行记录（可选任务过滤器） |
| 延长正在进行的执行记录的领取租约 |
| 报告带有证据（外部 ID / URL）的一次性结果 |
您： 安排一个每天上午 9 点的工作，将摘要发布到我的 webhook。
助手（使用
cueapi_create_cue）： 已创建提示cue_abc123，首次触发时间为明天 UTC 时间 9:00。您： 向我展示它最后五次的运行记录。
助手（使用
cueapi_list_executions）： ...
npm install
npm test # vitest smoke tests for the tool surface
npm run build # compile TypeScript to dist/
npm run dev # run the server locally with tsxCueAPI 主页： https://cueapi.ai
Model Context Protocol： https://modelcontextprotocol.io
0.4.1. 添加 cueapi_update_cue 工具：更新提示的可变字段（名称、调度、回调 URL、时区、负载、描述）。封装 PATCH /v1/cues/{id}。稀疏更新 — 仅发送提供的字段。弥补了跨包装器的对等差距（其他所有客户端包装器都公开了更新；MCP 之前没有）。
0.4.0. 添加五个执行生命周期工具 — cueapi_get_execution、cueapi_list_claimable_executions、cueapi_claim_execution、cueapi_claim_next_execution、cueapi_execution_heartbeat。为希望在会话内（例如 Claude Desktop、Cursor、Zed）使用工作者传输执行记录的 MCP 主机代理关闭了接收-领取-处理-完成循环。亮点：list_claimable_executions 通过 task / agent 查询参数在服务器端进行过滤（客户端过滤会遇到已知的 LIMIT-50 饥饿错误）；claim_next_execution 接受可选的 task_name 并在内部进行扇出（过滤列表 → 选择最旧的 → 按 ID 领取），因为服务器尚不支持在原始领取端点上进行任务过滤；execution_heartbeat 通过 X-Worker-Id 请求头发送 worker_id（服务器用于该字段的传输），并要求在模式中包含它，以便配置错误的调用者在包装器处失败，而不是静默绕过竞争保护。内部：CueAPIClient.request() 获得了一个可选的 extraHeaders 参数，以支持每次调用的自定义标头。
0.3.0. 添加 cueapi_fire_cue 工具：使用可选的 payload_override（以及 merge_strategy: 'merge' | 'replace'，默认为 'merge'）立即触发现有提示。封装 POST /v1/cues/{id}/fire。让代理无需创建一次性提示即可触发临时执行，并让每次触发的动态数据流向 webhook 分发 + 工作者领取响应，而无需更改存储的提示。
0.1.4. 修复 cueapi_pause_cue / cueapi_resume_cue 以使用 PATCH /v1/cues/{id} 和 {"status": "paused" | "active"}（之前调用了不存在的 /pause 和 /resume 端点，返回运行时 404）。PR #1。这是实际包含修复的版本；0.1.3 在发布时带有此说明，但未合并代码。
0.1.3. 过早发布，被 0.1.4 取代。与 0.1.2 相比没有功能变化。
0.1.2. 在官方 MCP 注册表中注册。
0.1.0. 初始版本：8 个用于创建/列出/获取/暂停/恢复/删除提示、列出执行记录、报告结果的工具。
MIT © Vector Apps Inc.
Create a new CueAPI cue — a scheduled job that fires a callback (or enqueues worker work) on a cron or one-time trigger.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable cue name | |
| cron | No | Cron expression for a recurring cue (e.g. '0 9 * * *') | |
| at | No | ISO-8601 timestamp for a one-time cue | |
| callback_url | No | Webhook URL fired when the cue triggers (omit for worker mode) | |
| worker | No | If true, use worker transport — no callback URL needed | |
| timezone | No | IANA timezone, default 'UTC' | |
| payload | No | Arbitrary JSON payload delivered with the cue | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the cue 'fires a callback (or enqueues worker work)' and is 'scheduled,' but it does not disclose critical traits like authentication requirements, rate limits, error handling, or whether creation is idempotent. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core purpose ('Create a new CueAPI cue') and then elaborates concisely on its nature and triggers. Every phrase adds value without redundancy, making it easy to parse and understand quickly. There is no wasted text or unnecessary elaboration.
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 tool's complexity (8 parameters, mutation operation) and lack of annotations and output schema, the description is somewhat incomplete. It covers the basic purpose and trigger types but misses details on behavioral aspects, error cases, and return values. While it provides a foundation, it does not fully compensate for the missing structured data, leaving gaps for an AI agent to infer usage.
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 high at 88%, so the schema already documents most parameters well (e.g., 'cron' as 'Cron expression for a recurring cue'). The description adds minimal value beyond the schema by hinting at the cron/at dichotomy and callback/worker modes, but it does not explain parameter interactions (e.g., mutual exclusivity of cron and at) or provide additional semantics. This meets the 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?
The description clearly states the action ('Create a new CueAPI cue') and specifies the resource type ('scheduled job'). It distinguishes this from sibling tools like cueapi_delete_cue, cueapi_get_cue, and cueapi_list_cues by focusing on creation rather than retrieval or deletion. The phrase 'fires a callback (or enqueues worker work) on a cron or one-time trigger' adds specificity about the cue's behavior.
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 implies usage by mentioning 'cron or one-time trigger' and the choice between callback and worker modes, but it does not explicitly state when to use this tool versus alternatives like cueapi_pause_cue or cueapi_resume_cue. It provides some context (e.g., 'omit for worker mode') but lacks clear guidance on prerequisites or exclusions, such as when a cue might not be creatable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a cue permanently. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| cue_id | Yes | CueAPI cue ID (e.g. 'cue_...') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical traits: the operation is destructive ('Delete'), permanent, and irreversible. This covers safety concerns, though it lacks details on permissions, error handling, or side effects like cascading deletions.
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 extremely concise and front-loaded, consisting of only two sentences that directly convey the core action and its critical implication. Every word earns its place, with no redundancy or unnecessary elaboration.
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?
For a destructive tool with no annotations and no output schema, the description provides essential context on permanence and irreversibility, which is crucial for safe usage. However, it lacks information on return values or error conditions, leaving some gaps in operational understanding.
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?
The schema description coverage is 100%, with the parameter 'cue_id' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema 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?
The description clearly states the specific action ('Delete') and target resource ('a cue'), with the adverb 'permanently' emphasizing the nature of the operation. It directly distinguishes from sibling tools like 'cueapi_pause_cue' or 'cueapi_resume_cue' by indicating a destructive removal rather than a state change.
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 implies usage context through 'permanently' and 'Irreversible,' suggesting this tool should be used for final removal rather than temporary actions. However, it does not explicitly name alternatives (e.g., 'cueapi_pause_cue' for temporary suspension) or state when not to use it, such as for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single cue by ID, including current schedule and most recent execution.
| Name | Required | Description | Default |
|---|---|---|---|
| cue_id | Yes | CueAPI cue ID (e.g. 'cue_...') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a read operation ('Fetch') and specifies what data is included (schedule and execution), which helps the agent understand the tool's behavior. However, it doesn't mention potential errors (e.g., invalid ID), performance characteristics, or authentication needs.
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 a single, well-structured sentence that efficiently conveys the tool's purpose and scope without unnecessary words. It's front-loaded with the core action and resource.
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 tool's low complexity (single parameter, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and what data it returns, though it could benefit from mentioning error cases or output format to fully compensate for the lack of annotations and output schema.
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%, so the schema already documents the single parameter cue_id with its type and format. The description doesn't add any additional parameter details beyond what's in the schema, such as validation rules or examples beyond the schema's 'e.g.'.
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 ('Fetch'), resource ('a single cue by ID'), and scope ('including current schedule and most recent execution'). It distinguishes from siblings like cueapi_list_cues (which lists multiple cues) and cueapi_list_executions (which focuses on executions).
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 implies usage context by specifying 'by ID' and mentioning schedule/execution details, suggesting it's for retrieving detailed information about a specific cue. However, it doesn't explicitly state when to use this versus alternatives like cueapi_list_cues for overviews or cueapi_list_executions for execution history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cues on the authenticated account, optionally filtered by status.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status | |
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions filtering by status but doesn't disclose behavioral traits like pagination behavior (implied by limit/offset but not explained), rate limits, authentication requirements, or what 'cues' represent. For a list operation with 3 parameters and no annotation coverage, this leaves critical operational context unspecified.
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 a single, efficient sentence that front-loads the core purpose ('List cues') and adds the key optional feature ('filtered by status'). There's no wasted wording or redundant information, making it appropriately concise for a straightforward list operation.
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 tool's complexity (3 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what 'cues' are, how results are structured, pagination behavior, or error conditions. Without annotations or output schema, the description should provide more operational context to be complete for agent use.
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 33% (only 'status' has a description), so the description must compensate. It mentions optional filtering by status, which aligns with the schema's enum values, but doesn't explain 'limit' or 'offset' parameters. The description adds minimal value beyond the schema, resulting in a baseline 3 score given the partial 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?
The description clearly states the verb ('List') and resource ('cues on the authenticated account'), making the purpose unambiguous. It distinguishes from siblings like 'cueapi_get_cue' (singular retrieval) and 'cueapi_list_executions' (different resource). However, it doesn't explicitly differentiate from other list operations beyond the resource name, keeping it at 4 rather than 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when filtering by status is appropriate, how it differs from 'cueapi_list_executions', or any prerequisites like authentication context. With multiple sibling tools available, this lack of comparative guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List executions — the historical record of times a cue actually fired. Optionally filter by cue, status, or paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| cue_id | No | Filter to a specific cue | |
| status | No | Filter by execution status | |
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that executions are a 'historical record,' implying read-only behavior, and hints at filtering and pagination capabilities. However, it lacks details on permissions required, rate limits, response format, or whether this is a safe operation. For a list tool with no annotations, this leaves significant behavioral gaps uncovered.
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 a single, efficient sentence that front-loads the core purpose ('List executions') and adds necessary context without waste. Every word earns its place, making it highly concise and well-structured for quick understanding.
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 4 parameters with 50% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the tool's purpose and hints at parameter usage but lacks details on behavioral traits, response format, and full parameter documentation. For a list tool with filtering, this is adequate but has clear gaps, especially in output expectations and safety assurances.
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 50% (two parameters have descriptions, two do not). The description adds value by explaining that parameters allow filtering 'by cue, status, or paginate,' which maps to cue_id, status, and limit/offset. However, it doesn't provide additional semantics beyond what the schema already covers for cue_id and status, and it doesn't clarify the undocumented limit and offset parameters fully. Baseline 3 is appropriate as the description compensates somewhat but not completely.
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 ('List') and resource ('executions') with specific clarification that these are 'historical record of times a cue actually fired.' It distinguishes from siblings like cueapi_list_cues by focusing on execution records rather than cue definitions. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 implies usage through the phrase 'Optionally filter by cue, status, or paginate,' suggesting when to use filtering parameters. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like cueapi_list_cues or cueapi_report_outcome, nor does it mention prerequisites or exclusions. The guidance is present but limited to parameter usage rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a cue. Paused cues do not fire until resumed.
| Name | Required | Description | Default |
|---|---|---|---|
| cue_id | Yes | CueAPI cue ID (e.g. 'cue_...') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that paused cues do not fire until resumed, which is a key behavioral trait. However, it lacks details on permissions needed, error conditions, or whether the action is reversible, leaving gaps for a mutation 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?
The description is two sentences, front-loaded with the core action and followed by a clarifying outcome. Every word earns its place, with no redundancy or unnecessary details, making it highly efficient and well-structured.
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 tool's complexity (simple mutation with one parameter) and lack of annotations or output schema, the description is minimally adequate. It explains what the tool does but does not cover return values or error handling, leaving some context gaps that could hinder agent usage.
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%, so the schema already documents the 'cue_id' parameter fully. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, but this is acceptable given the high schema coverage, resulting in a 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 clearly states the specific action ('Pause a cue') and the resource ('cue'), distinguishing it from siblings like 'resume_cue' by specifying that paused cues do not fire until resumed. It uses a precise verb and defines the outcome, making the purpose unambiguous.
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 implies usage when a cue needs to be paused, but does not explicitly state when to use this tool versus alternatives like 'resume_cue' or 'delete_cue'. It provides some context by mentioning the effect of pausing, but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the outcome of an execution. CueAPI's core accountability primitive: attach evidence (external_id, result_url, summary) that proves the work actually happened. Write-once — the outcome record is immutable.
| Name | Required | Description | Default |
|---|---|---|---|
| execution_id | Yes | ||
| success | Yes | ||
| external_id | No | ID from the downstream system | |
| result_url | No | Public URL proving the work happened (tweet, PR, etc.) | |
| summary | No | Short human summary of what the agent did |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it describes the tool as a 'core accountability primitive,' specifies immutability ('Write-once — the outcome record is immutable'), and implies it's for finalizing executions. It doesn't cover permissions, rate limits, or error handling, but provides key operational traits beyond basic function.
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 front-loaded with the core purpose in the first sentence, followed by key behavioral details in a second sentence. Every sentence earns its place by adding value (accountability primitive, evidence attachment, immutability), with no wasted words or redundancy.
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 no annotations and no output schema, the description provides good context for a mutation tool: it explains the purpose, key behavioral trait (immutability), and parameter semantics. It could improve by mentioning response format or error cases, but it's largely complete for guiding usage in this accountability context.
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 60% (3 of 5 parameters have descriptions), and the description adds meaning by explaining the purpose of parameters: 'attach evidence (external_id, result_url, summary) that proves the work actually happened.' This clarifies the role of these evidence fields beyond schema descriptions, compensating for the 40% coverage gap (execution_id and success lack schema descriptions).
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 ('Report') and resource ('outcome of an execution'), specifying it's CueAPI's 'core accountability primitive' for attaching evidence to prove work happened. It distinguishes from siblings like cueapi_create_cue or cueapi_list_executions by focusing on outcome reporting rather than cue management or listing.
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 implies usage context ('attach evidence that proves the work actually happened') and mentions 'Write-once — the outcome record is immutable,' suggesting when to use it for final reporting. However, it lacks explicit guidance on when not to use it or alternatives among siblings (e.g., vs cueapi_list_executions for checking status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a previously-paused cue.
| Name | Required | Description | Default |
|---|---|---|---|
| cue_id | Yes | CueAPI cue ID (e.g. 'cue_...') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Resume') but doesn't explain what resuming entails (e.g., does it restart execution, change status, require specific permissions, or have side effects?). This lack of detail is a significant gap for a mutation tool with zero annotation coverage.
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 a single, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently communicates the core action, making it highly concise and well-structured.
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 tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., what happens when resumed, error conditions, or response format), which are crucial for an AI agent to use it correctly. The high schema coverage doesn't compensate for these gaps.
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?
The description doesn't add any parameter information beyond what the input schema provides. Since schema description coverage is 100% (the 'cue_id' parameter is well-documented in the schema), the baseline score of 3 is appropriate. No extra value is contributed by the description regarding 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 action ('Resume') and the target resource ('a previously-paused cue'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'cueapi_pause_cue' or 'cueapi_get_cue' beyond the obvious action contrast, so it falls short of a perfect score.
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 implies usage context by specifying 'previously-paused cue', suggesting it should be used only on cues that are in a paused state. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'cueapi_create_cue' or 'cueapi_delete_cue', nor does it mention prerequisites or exclusions, leaving some ambiguity.
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.
v0.1.2cueapi_create_cuecueapi_delete_cuecueapi_get_cuecueapi_list_cuescueapi_list_executionscueapi_pause_cuecueapi_report_outcomecueapi_resume_cueScored across 8 tools
Each tool has a clearly distinct purpose targeting specific operations on cues or executions. There is no overlap: create, delete, get, list, pause, resume, list_executions, and report_outcome are all unique actions with well-defined boundaries.
All tools follow a consistent 'cueapi_verb_noun' pattern with snake_case throughout. The naming is predictable and uniform, making it easy to understand each tool's function at a glance.
With 8 tools, the server is well-scoped for managing cues and executions. Each tool earns its place, covering core CRUD operations, lifecycle management (pause/resume), and accountability features without being overwhelming.
The toolset provides complete coverage for the CueAPI domain: full CRUD for cues (create, get, list, delete), lifecycle control (pause/resume), execution tracking (list_executions), and accountability (report_outcome). There are no obvious gaps, enabling agents to handle all typical workflows.
Hosted MCP server for task-first delegation to remote workstations and workers.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Official Airtable MCP server — database and operations layer for agents.
MCP Server for an Agent Task Marketplace
