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

No annotations are present, so the description carries the full burden. It discloses that the tool returns a catalog and a prompt, includes conditional partner playbooks, and states a re-call pattern. However, it does not explicitly state whether the tool is read-only or has side effects, and does not mention permissions or output format beyond high-level items.

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 front-loaded with a clear purpose, followed by strategic context and usage guidance. It is somewhat wordy with jargon ('profit-per-attention', 'FO') but each sentence contributes either to the tool's behavior, usage timing, or intended reasoning approach. Overall, it is structured and purposeful.

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 no output schema, the description adequately explains the return values (live MCP tool catalog + research prompt) and provides usage scenarios, strategic rationale, and conditional partner content. It could be more precise about the structure of the returned catalog/prompt, but it is sufficiently complete for an agent to decide when and how to invoke it.

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?

Schema description coverage is 100% for both parameters (host, companyId), so the baseline is 3. The description adds minor context by listing example host values ('Claude Code, Cursor, etc.') and referencing partner playbooks, but does not significantly expand on schema descriptions.

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's purpose: it returns a live MCP tool catalog and a research prompt to onboard a host coding assistant to FreedomOS. It uses a specific verb ('Onboard' but actually 'returns') and identifies a unique resource (host CoS, FreedomOS), distinguishing it from sibling get_* and onboarding-related 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?

Explicit usage conditions are provided: 'Use on first MCP connect, partner connect, or when the host asks how to use FreedomOS optimally.' Also mentions re-calling when FreedomOS ships tools. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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