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

Annotations (readOnlyHint=false, openWorldHint=true) only signal that this tool has write and open-world aspects; the description adds substantial behavioral context on top: invoke runs tools one-off without installing or bloating the tool list, writes require workspace owner/admin, search/describe flag installed_in_toolkit vs installed_in_workspace, and publish_prompt returns a login-free shareable link. It discloses side effects (install adds tools to future sessions, invoke does not), permission requirements, and retry behavior after payment/connect links. This is rich disclosure well beyond what the annotations carry.

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 (~300 words) but every sentence earns its place for a tool with 14 actions. It is front-loaded: the purpose statement, capability examples, and core flow come first, followed by the KEY behavioral disclaimer, conditional auth/payment handling, usage rules, permissions, and finally the prompt-library addendum. The 'KEY:' marker highlights the most decision-relevant fact, and the prompt-library section is necessary to explain why the schema contains 11 prompt_* parameters with otherwise zero documentation.

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 14-action, 23-parameter tool with no output schema, the description is remarkably complete: it explains the main flow, edge cases (not installed, missing credentials, empty wallet), permission requirements, and the secondary prompt-library domain. But gaps remain: the 'resume' action in the enum is never mentioned, and the immediate and conversation parameters' semantics are undocumented. Several action outputs are unspecified (search results shape, list_tools output, get_prompt return), and since there is no output schema to fill that gap, the description carries that burden partially but not fully.

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 and 23 parameters, the description carries the full burden and does compensate for the most critical parameter — it maps the action enum values to concrete workflows (search discovers, describe returns MCP profile with tool_id, invoke runs, subscribe/cancel handle billing). It also grounds mcp_id/tool_id (the describe→pick tool_id→invoke flow) and the prompt_* family as a cohesive library sub-domain. However, several parameters remain unexplained in both schema and description — immediate, conversation, tier_slug, cancel_reason semantics, report_context, request_details — so the compensation is strong but not complete.

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 states exactly what the tool is ('the in-platform catalog of every MCP/tool, AND the way to run them') and enumerates its 14 actions across two clear domains: MCP discovery/execution and the prompt library. It names each action with its role (search discovers, describe profiles, invoke runs, install persists), which fully disambiguates it from the stone_vendas_* sibling tools that are individual MCP endpoints rather than the platform catalog. The 'Core flow: action=search → describe → invoke' sentence anchors the multi-action tool around a single understandable 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?

Provides explicit when-to-use guidance: 'use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use,' and describes the conditional flow for auth and payment ('If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link... then you retry'). It also distinguishes the prompt-library actions from MCP actions and names list_tools as the way to see what is callable right now. The alternatives and their selection conditions are stated directly rather than left to inference.

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