This server connects MCP-enabled AI assistants to CueAPI, allowing them to schedule, manage, and track agent tasks with structured evidence of outcomes.
Create cues (cueapi_create_cue): Schedule recurring (cron) or one-time (at) jobs with optional webhook callbacks, worker transport mode, custom JSON payloads, timezone, and description.
List cues (cueapi_list_cues): Retrieve all cues, with optional filtering by status (active/paused) and pagination.
Get cue details (cueapi_get_cue): Fetch a single cue's full configuration and most recent execution info by ID.
Fire on demand: Trigger a cue immediately with an optional payload override.
Update cues: Modify mutable fields such as name, schedule, callback URL, and payload.
Pause/resume cues (cueapi_pause_cue / cueapi_resume_cue): Temporarily stop or restart a cue without deleting it.
Delete cues (cueapi_delete_cue): Permanently remove a cue.
List executions (cueapi_list_executions): View historical execution records, filterable by cue ID or status, with pagination.
Get execution details: Fetch a specific execution's state and outcome.
Claim executions: Atomically claim outstanding worker executions for processing (list claimable, claim by ID, or claim the next available).
Heartbeat: Extend the claim lease on an in-flight execution.
Report outcomes (cueapi_report_outcome): Attach immutable, evidence-backed records to executions (success/failure, summary, external ID, result URL) to prove work actually happened.
Official Model Context Protocol server for CueAPI, the open-source coordination layer for AI agent systems.
Give your MCP-enabled assistant (Claude Desktop, Cursor, Zed, or any other MCP host) the ability to schedule agent work, fetch execution history, and close the loop with evidence-backed outcome reports, all from inside a conversation.
Agents don't finish in one call. They coordinate across time, tools, environments, agents, and humans. Every handoff is a place where silent failure hides. CueAPI closes each handoff with structured evidence: an external ID, a result URL, or an artifact. This MCP server gives the agent direct access to that surface, so the agent can both schedule its own follow-up work and report outcomes with proof.
Related MCP server: LLM Bus
npm install -g @cueapi/mcp
# or use via npx (no install):
npx -y @cueapi/mcpAdd this to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"cueapi": {
"command": "npx",
"args": ["-y", "@cueapi/mcp"],
"env": {
"CUEAPI_API_KEY": "cue_sk_..."
}
}
}
}Generate your API key at cueapi.ai. Self-hosting? Set CUEAPI_BASE_URL alongside CUEAPI_API_KEY.
Any MCP host that supports stdio servers can run this. Point the host at the cueapi-mcp binary and pass CUEAPI_API_KEY in the environment.
Tool | What it does |
| Create a recurring (cron) or one-time ( |
| List cues, filter by status |
| Fetch details for a single cue |
| Fire an existing cue immediately, optional payload override |
| Update a cue's mutable fields (name, schedule, callback, payload, etc.) |
| Pause a cue so it stops firing |
| Resume a paused cue |
| Delete a cue permanently |
| List historical executions, filter by cue/status |
| Fetch a single execution by ID, with state + outcome |
| List unclaimed worker executions, filter server-side by task/agent |
| Atomically claim a specific execution for processing |
| Claim the next available execution (optional task filter) |
| Extend the claim lease on an in-flight execution |
| Report write-once outcome with evidence (external ID / URL) |
You: Schedule a daily 9am job that posts a digest to my webhook.
Assistant (uses
cueapi_create_cue): Created cuecue_abc123, first fire tomorrow at 9:00 UTC.You: Show me the last five times it ran.
Assistant (uses
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 homepage: https://cueapi.ai
Docs: https://docs.cueapi.ai
Core (open source): https://github.com/cueapi/cueapi-core
Model Context Protocol: https://modelcontextprotocol.io
0.4.1. Add cueapi_update_cue tool: update a cue's mutable fields (name, schedule, callback URL, timezone, payload, description). Wraps PATCH /v1/cues/{id}. Sparse update — only provided fields are sent. Closes the cross-wrapper parity gap (every other client wrapper exposed update; MCP didn't until now).
0.4.0. Add five execution-lifecycle tools — cueapi_get_execution, cueapi_list_claimable_executions, cueapi_claim_execution, cueapi_claim_next_execution, cueapi_execution_heartbeat. Closes the receive-claim-process-complete loop for MCP-host agents that want to consume worker-transport executions from in-session (e.g. Claude Desktop, Cursor, Zed). Highlights: list_claimable_executions filters server-side via task / agent query params (client-side filtering hits a known LIMIT-50 starvation bug); claim_next_execution accepts an optional task_name and internally fans out (filtered list → pick oldest → claim by ID) since the server doesn't yet support a task filter on the bare claim endpoint; execution_heartbeat sends worker_id via the X-Worker-Id request header (the server's transport for that field) and requires it in the schema so misconfigured callers fail at the wrapper instead of silently bypassing race protection. Internal: CueAPIClient.request() gains an optional extraHeaders parameter to support per-call custom headers.
0.3.0. Add cueapi_fire_cue tool: fire an existing cue immediately with an optional payload_override (and merge_strategy: 'merge' | 'replace', default 'merge'). Wraps POST /v1/cues/{id}/fire. Lets agents trigger ad-hoc one-shot executions without creating throwaway cues, and lets per-fire dynamic data flow through to webhook dispatch + worker-claim responses without mutating the stored cue.
0.1.4. Fix cueapi_pause_cue / cueapi_resume_cue to use PATCH /v1/cues/{id} with {"status": "paused" | "active"} (previously called non-existent /pause and /resume endpoints, returning a runtime 404). PR #1. This is the release that actually contains the fix; 0.1.3 was published prematurely with this note but without the merged code.
0.1.3. Premature publish, superseded by 0.1.4. No functional changes from 0.1.2.
0.1.2. Register with the Official MCP Registry.
0.1.0. Initial release: 8 tools for create / list / get / pause / resume / delete cues, list executions, report outcome.
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. Dates show when Glama detected each change.
v0.1.2cueapi_create_cuecueapi_delete_cuecueapi_get_cuecueapi_list_cuescueapi_list_executionscueapi_pause_cuecueapi_report_outcomecueapi_resume_cueEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cueapi/cueapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
