Официальный сервер Model Context Protocol для CueAPI, уровня координации с открытым исходным кодом для систем ИИ-агентов.
Предоставьте своему помощнику с поддержкой 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 (~/Library/Application Support/Claude/claude_desktop_config.json в macOS):
{
"mcpServers": {
"cueapi": {
"command": "npx",
"args": ["-y", "@cueapi/mcp"],
"env": {
"CUEAPI_API_KEY": "cue_sk_..."
}
}
}
}Сгенерируйте свой API-ключ на cueapi.ai. Используете self-hosting? Установите CUEAPI_BASE_URL вместе с CUEAPI_API_KEY.
Любой MCP-хост, поддерживающий stdio-серверы, может запустить это. Укажите хосту путь к бинарному файлу cueapi-mcp и передайте CUEAPI_API_KEY в переменные окружения.
Инструмент | Что он делает |
| Создание повторяющегося (cron) или однократного ( |
| Список сигналов, фильтрация по статусу |
| Получение деталей конкретного сигнала |
| Немедленный запуск существующего сигнала, опциональная замена полезной нагрузки |
| Обновление изменяемых полей сигнала (имя, расписание, callback, полезная нагрузка и т.д.) |
| Приостановка сигнала, чтобы он перестал срабатывать |
| Возобновление приостановленного сигнала |
| Безвозвратное удаление сигнала |
| Список исторических выполнений, фильтрация по сигналу/статусу |
| Получение одного выполнения по ID, с состоянием + результатом |
| Список невостребованных выполнений воркеров, фильтрация на стороне сервера по задаче/агенту |
| Атомарное получение конкретного выполнения для обработки |
| Получение следующего доступного выполнения (опциональный фильтр задачи) |
| Продление аренды выполнения для запущенной задачи |
| Отчет об однократном результате с доказательством (внешний ID / URL) |
Вы: Запланируй ежедневную задачу на 9 утра, которая отправляет дайджест на мой вебхук.
Помощник (использует
cueapi_create_cue): Сигналcue_abc123создан, первое срабатывание завтра в 9:00 UTC.Вы: Покажи мне последние пять раз, когда он запускался.
Помощник (использует
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 tsxДомашняя страница CueAPI: https://cueapi.ai
Документация: https://docs.cueapi.ai
Ядро (open source): https://github.com/cueapi/cueapi-core
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. Замыкает цикл получения-заявки-обработки-завершения для агентов MCP-хостов, которые хотят потреблять выполнения из транспортного уровня воркеров прямо во время сессии (например, Claude Desktop, Cursor, Zed). Основные моменты: list_claimable_executions фильтрует на стороне сервера через параметры запроса task / agent (клиентская фильтрация натыкается на известную ошибку ограничения LIMIT-50); claim_next_execution принимает опциональный task_name и внутренне распределяет запрос (отфильтрованный список → выбор самого старого → заявка по ID), так как сервер пока не поддерживает фильтр задач в базовой конечной точке заявки; execution_heartbeat отправляет worker_id через заголовок запроса X-Worker-Id (транспорт сервера для этого поля) и требует его в схеме, чтобы неправильно настроенные вызывающие стороны получали ошибку на уровне обертки, а не молча обходили защиту от состояний гонки. Внутреннее: CueAPIClient.request() получил опциональный параметр extraHeaders для поддержки пользовательских заголовков для каждого вызова.
0.3.0. Добавлен инструмент cueapi_fire_cue: немедленный запуск существующего сигнала с опциональным payload_override (и merge_strategy: 'merge' | 'replace', по умолчанию 'merge'). Обертка для POST /v1/cues/{id}/fire. Позволяет агентам запускать разовые выполнения без создания временных сигналов и позволяет динамическим данным каждого запуска проходить до отправки вебхука и ответов на заявки воркеров без изменения сохраненного сигнала.
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. 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
