Skip to main content
Glama

report_missing_capability

Report missing capabilities or insufficient tools to the platform team. Use when no MCP tool fulfills a user request or an existing tool limits your response.

Instructions

Reports a missing capability or an insufficient tool to the platform team. Use it when you cannot fulfil a user request because no MCP tool offers what is needed, OR when an existing tool limits you (incomplete return, missing parameter, unhelpful error, ...).

Typical example: the user asks for a link to a file; you search the returns of list_files / read_file, there is no webUrl field; you report the missing capability. The platform team prioritizes and ships the field in a next release.

Principle: your ticket is a SIGNAL, not an implementation order. Several converging tickets = a priority. Do not hesitate to report even when unsure — noise is filtered at triage. Do NOT report an obvious bug (the API returns 500) — let the error surface naturally instead.

Auto-dedup: an identical ticket (same description + same tool + same agent) within 24h just refreshes the timestamp instead of creating a duplicate.

Before reporting, consider calling list_cortex_tickets to check you have not already filed a similar ticket — avoids re-filing in a loop.

Returns: { ticketId, deduplicated, ackMessage }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
severityYesblocking = you cannot answer the user. inconvenient = workaround exists but with friction. nice_to_have = ergonomic improvement.
contextAppNoBackend concerned (a backend id, or 'cortex' for the gateway itself). Optional but very useful for triage.
userIntentYesWhy the user needed this capability. Helps understand the business value.
contextToolNoName of the MCP tool you tried / wanted to use (e.g. 'list_files'). Optional.
whatIWantedYesThe missing capability, in natural language. E.g. 'Give the user a clickable link to a file'.
suggestedShapeNoIf you have an idea of the tool signature or returned field, suggest it. E.g. 'Add `webUrl: string` to the list_files return'. Optional.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: the tool is a signaling mechanism, not an implementation order; auto-dedup with 24h window; return fields. It clearly sets expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but well-structured with paragraphs and bullet points. It is front-loaded with purpose and each section adds value, though some redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a reporting tool: covers purpose, usage, dedup, return structure, and pre-reporting checks. No output schema exists, but the description explains returns in text, making it self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all parameters clearly. The description adds no extra meaning beyond the schema, thus baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting a missing capability or insufficient tool. It distinguishes itself from siblings by providing explicit use cases and examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives detailed guidance on when to use (unfulfillable requests, tool limitations) and when not to (obvious bugs). It suggests checking existing tickets and explains auto-dedup, providing comprehensive usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wellknownmcp/cortex-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server