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

Given the annotations are minimal (readOnlyHint:false, openWorldHint:true, no details on destruction or idempotency), the description carries full weight and delivers: it explains what happens when credentials are missing (connect link), what happens with a zero wallet (checkout link, user opens, then retry), which operations are writes requiring owner/admin, and clarifies that invoke runs the tool one-off 'without adding the MCP to the toolkit and without bloating the tool list'.

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?

It's a single dense wall of text, but every 3-10 word chunk earns its place: 'pontualmente (one-off)', 'the user opens it, then you retry', 'which is about ready-made prompt TEXT rather than MCPs'. Some structure (bullets, dashes) would improve quick scanning, and 'pontualmente' could confuse non-Portuguese readers (though it's arguably intentional given the 'consulta um CPF' example hints at a PT-BR user base). That said, the density is information-rich rather than bloated — hard for a description covering 14+ actions.

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?

This is a fair assessment — the schema is massive (23 params, no required params, no enum hints beyond action), there's no output schema, and no nested objects. The description covers the full lifecycle while remaining actionable about what the agent must NOT know: how to handle non-install edge cases, retry semantics, which actions need mcp_id being contextualized into core ('describe returns one MCP's full profile'), and permission scoping (installed vs owner/admin). It's a complete operational manual for an unusually complex tool.

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 schema description coverage at 0%, the description is the sole interpreter of the 23-parameter schema, and it more than compensates. It introduces the `action` property semantics that aren't self-evident from the schema alone (list of 14 actions, each with its own required fields: mcp_id for search/describe/invoke, tool_id+arguments for invoke, prompt_* fields for the prompt library, cancel_reason/comment for cancel). The description explains the actual error-handling flow (invoke without install tricks the static schema would never reveal). The agent can meaningfully map parameters to workflows from the description alone.

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 uses specific verb-action pairs ('search discovers MCPs by intent', 'invoke RUNS that tool', 'install only to make an MCP PERMANENT') and grounds them with concrete examples ('find an MCP that does X', 'consulta um CPF'). It clearly distinguishes the two ecosystems (marketplace actions vs prompt library) and differentiates the main flows from siblings via explicit naming (`report_bug`, `toolkit_info`). It would earn a 5 except the overloaded 'marketplace' name is never directly defined in a single clause, and the tool is so broad it's more of a hub than a single-purpose tool.

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 usage guidance is exemplary: it explicitly contrasts 'prefer invoke for a single/occasional use' with 'Use install only to make an MCP PERMANENT', explains when NOT to use it ('only if the MCP needs a credential... invoke returns a connect link'), and covers the auth/payment retry flow. It also tells the agent when to fall back to `request_mcp` ('asks us to build a NEW MCP when nothing fits'). This is when-to-use vs alternative guidance done at the highest standard.

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