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

The description discloses several behavioral traits beyond the annotations, including that 'invoke works even when the MCP is NOT installed — it runs the tool pontualmente,' returns connect/checkout links when credentials or payment are needed, and requires workspace owner/admin for writes. It also mentions the distinction between installed_in_toolkit vs installed_in_workspace, providing important context not available from the annotations.

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?

Despite being a long paragraph, every sentence adds meaningful information with no redundancy. It is front-loaded with the core definition and flows naturally through the main actions, key caveats, and the prompt library sub-feature. The density is justified given the tool's complexity and the need to cover 14 actions and multiple edge cases in a single description.

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 very complex meta-tool with 23 parameters and no output schema, the description provides a remarkably complete picture. It covers the core flows, special cases (uninstalled MCPs, payment/auth requirements), permission requirements, and sub-capabilities (prompt library). It goes beyond the structured data to explain exactly what the tool can do and how it behaves in different contexts, making it nearly self-sufficient.

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 description coverage, the description must compensate for explaining parameters. It effectively does so by describing the 'action' parameter's values (search, describe, invoke, etc.) and their semantics, and clarifies related parameters like mcp_id, tool_id, arguments, and prompt_vars. However, not all 23 parameters are explicitly mapped (e.g., limit, immediate, tier_slug, cancel_reason), so while it covers the core ones well, there is a slight gap in exhaustive parameter guidance.

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 tool is 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' giving a specific verb ('catalog' and 'run') and resource (MCPs/tools). It distinguishes itself from sibling tools like fipe_* by focusing on marketplace operations rather than domain-specific queries. The multi-action nature is explicitly outlined, removing ambiguity about its purpose.

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 explicit when-to-use guidance, such as 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT in the active toolkit.' It also contrasts with alternatives like list_tools ('lists what is callable right now') and describes the core search→describe→invoke flow. It covers when to use subscribe/cancel, report_bug, request_mcp, and prompt library functions, making it clear when this tool should be selected over siblings.

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