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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behavioral traits: invoke runs tools one-off without installing them; invoke returns a connect link when credentials are needed and a checkout/top-up link when payment is required; install makes MCPs permanent; writes require workspace owner/admin; and publishing a prompt returns a shareable link. These details significantly extend the annotation information without contradiction.

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 long but dense and front-loaded: the first sentence states the tool's purpose, followed by the core flow, edge cases, and prompt library. Every sentence contributes meaningful guidance, and the length is justified by the tool's complexity (14 actions, 23 parameters). No filler or redundant phrases.

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 tool with 14 actions, 23 parameters, and no output schema, the description is remarkably complete. It covers workflows, permission requirements (owner/admin), payment/auth redirects, installed status flags, permanent vs one-off usage, prompt library publishing, and return link formats. There is enough context for an agent to select and invoke the correct action with confidence.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description takes on the burden of explaining parameters. It maps actions to their parameters well (action=search, action=describe, tool_id for invoke, prompt variables for get_prompt, etc.) and clarifies the flow of arguments. However, some parameters like immediate, resume, tier_slug, conversation, and report_context are never mentioned, and it does not state that arguments/prompt_vars are JSON strings. It compensates strongly for the main actions but not exhaustively for all 23 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 identifies the tool as the official mcp.ai marketplace catalog and execution engine, with a specific verb+resource structure: it 'discovers MCPs by intent', 'describes' profiles, and 'invokes' tools. It also distinguishes itself from sibling tools by covering the marketplace actions (search/describe/invoke/install) and prompt library, which siblings like authenticate, connect, and show_version do not.

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 gives explicit when-to-use guidance: 'Use install only to make an MCP PERMANENT in the active toolkit; prefer invoke for a single/occasional use.' It also lays out the core flow (search → describe → invoke), and clarifies when to use list_tools, subscribe/cancel, report_bug, request_mcp, and the prompt library actions. It even describes fallback behavior: 'If nothing fits, request_mcp asks us to build a NEW MCP.'

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