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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: no subscription or listing fee, and no customer credentials accepted or returned, which is meaningful privacy/compliance information for an agent. It omits deeper behavior such as how often the enabled/disabled state changes or whether results are cached, keeping it from a 5.

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?

Three short sentences, front-loaded with the cost qualifier 'FREE' and then the return content and the credential guarantee. It is appropriately sized for a zero-parameter informational tool; the only waste is mild redundancy between 'FREE' and 'No subscription or listing fee'.

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?

With no parameters, no output schema, and full annotation coverage, the description carries the remaining burden of telling the agent what it will learn. It names the two content categories (enabled paths, disabled marketplace capabilities) and the credential boundary, which is enough to call it correctly. A brief note on what 'participation information' contains would make it fully complete.

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 takes zero parameters and the schema coverage is 100%, so there is no parameter meaning to convey. The description correctly says nothing about inputs, which is the right call for a no-argument tool.

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 a concrete verb ('Returns') and specifies the payload: 'connection and participation information for customer and authorised provider agents, including currently enabled paths and disabled marketplace capabilities.' That distinguishes it from the sibling tools, which are all about finding providers, job requests, or submitting inquiries. It stops short of 5 because 'connection and participation information' is abstract and does not say in concrete terms what the caller will actually read.

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?

Usage is only implied: the name and the cost statements suggest calling this before joining or when checking participation status. There is no explicit 'use this when…' or 'do not use this for…', and no sibling is named as an alternative even though find_service_providers and service_trade_catalog exist for adjacent intents. The 'FREE / no fee' framing does help an agent choose it over paid paths, which lifts it above a pure 2.

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