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

The description adds substantial behavioral context beyond annotations (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false). Key disclosures: invoke 'runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list'; auth/payment fallbacks ('returns a connect link', 'returns a checkout/top-up link... then you retry'); permission requirements ('Writes... require workspace owner/admin'); installed-state flags; and the login-free prompt link behavior. No contradiction with annotations — readOnlyHint: false is consistent with documented install/uninstall/subscribe writes.

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?

Front-loaded well with the core search→describe→invoke flow, and every sentence earns its place given the tool's enormous 14-action scope. However, the entire text is one dense, unbroken paragraph with no bullet points, section breaks, or action-grouping — a parsing burden for an agent. The content is efficient, but the format could be significantly improved for a tool with this many subsections and sub-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?

For an unusually complex dispatcher (23 params, 14 actions, 2 sub-systems, no output schema, no param descriptions), the description is remarkably complete: it covers the one-off invoke semantics, connect/checkout retry flows, permission tiers, installed-state flags, and the prompt library. Gaps remain: `resume`/`immediate`/`limit`/`tier_slug` semantics, return-format expectations (no output schema), and full detail of several prompt_* params. Since there is no output schema, the description might have done more to describe return shapes, but overall it is strong for the complexity level.

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 carries the full burden and does most of the work: it explains the crucial `action` enum (all 14 values either named or implied — only `resume` is unmentioned), plus mcp_id ('describe returns one MCP's full profile'), tool_id ('so you pick the right tool_id'), arguments (implied via 'invoke RUNS that tool'), query, request_*, cancel_*, and the prompt_* family (prompt_body/prompt_slug/prompt_vars). It still leaves gaps: `limit`, `immediate`, `tier_slug`, `message`, `conversation`, `prompt_tool`, `prompt_targets`, `prompt_category`, `prompt_description`, and the `arguments` JSON format are not addressed.

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 precisely defines the tool's role: 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It enumerates every sub-action (search, describe, install, invoke, etc.) and outlines the core flow 'action=search discovers MCPs by intent → describe returns one MCP's full profile → invoke RUNS that tool.' This goes well beyond the generic name 'marketplace' to establish a specific dispatch tool with multiple verbs and resources.

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?

Excellent internal guidance: 'Use install only to make an MCP PERMANENT in the active toolkit... prefer invoke for a single/occasional use' sets explicit when-to-use rules between two overlapping actions. It explains list_tools ('lists what is callable right now'), request_mcp ('build a NEW MCP when nothing fits'), the full search→describe→invoke workflow, and the distinct prompt-library sub-flow (search_prompts/get_prompt/publish_prompt). The only gap is not contrasting with sibling tools like authenticate/connect, but within its own 14-action surface the guidance is thorough.

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