Session summary

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral value of disclosing that the response includes price and an access check, but says nothing about auth requirements, rate limits, or failure modes when the session is unknown.

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?

Two compact sentences with the purpose front-loaded and the source hint appended. Every clause carries information, though 'Describe one session before using it' is slightly awkward phrasing.

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 read-only tool with no output schema, the description usefully previews the summary contents (activity, outline, price, access), which is what an agent needs to decide whether to call acquire_session next. Minor gaps around the optional tenant parameter and error behavior keep it from a 5.

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 only 33% schema description coverage, the description must carry more weight. It clarifies the 'source' parameter ('marketplace (default) or library'), which is already implied by the enum and default in the schema, and says nothing about 'tenant' or the 'id' format. Partial compensation, baseline-level performance.

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?

States a specific verb+resource ('describe one session') and enumerates the returned facets (what it did, outline, price, access), which distinguishes it from fetch_session_context and acquire_session. It stops short of explicitly naming those siblings, so differentiation is inferable rather than stated.

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?

'Describe one session before using it' implies a pre-flight check that precedes acquire_session or actual use, which is useful implied guidance. However, no alternative is named and no exclusion or precondition (e.g., what to do if access is missing) is spelled out.

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