Which Marketplaces Are Loaded

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context beyond these: defensive importing behavior, that failed imports are recorded in ``skipped`` rather than raised, and that it never raises ToolError. This explains the observable behavior and error semantics.

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?

Although the description is longer than average, it is well-structured with clear sections ("Why this exists", "Return Format", "Error Format") and every paragraph adds value. The length is justified by the need to explain the invisible failure mode and the return format.

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?

Given zero parameters and the presence of an output schema, the description fully covers the tool's purpose, usage context, return semantics, and error behavior. It addresses the complex diagnostic case where a missing source looks like an empty one, which is essential for an agent to use the tool correctly.

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?

The tool has 0 parameters, so the baseline for this dimension is 4. The description appropriately focuses on the return format and error behavior, adding meaning beyond the parameterless schema. No parameter documentation is needed.

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 verb+resource: "List which connectors this unified server actually mounted." It distinguishes itself from sibling tools by explaining the diagnostic purpose: distinguishing missing marketplaces from empty ones, which is unique among the available tools.

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: "Call this before concluding a marketplace has no results — if it is in ``skipped``, it was never queried at all." This tells the agent exactly when to invoke this tool versus assuming a marketplace is empty, effectively differentiating it from comparison tools like compare_sources.

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