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

With no annotations provided, the description carries the behavioral disclosure burden. It does well by disclosing side-effect-free behavior ('Does not switch orgs') and a meaningful access limitation ('tsk_ keys see only their seat org'). While it does not exhaustively describe authentication or formatting behavior, it covers the most important semantic traits for safe invocation.

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 tight and front-loaded: the first sentence immediately answers what the tool returns, and the following two sentences add only high-value caveats and routing guidance. Every sentence earns its place, with no filler or redundant elaboration.

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 low-complexity list tool with one fully documented optional parameter and an output schema, the description is complete. It covers the operation's scope, the key side-effect boundary, the alternative tool, and an important access restriction. An agent has enough context to invoke org_list correctly without further inference.

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 schema already documents the single optional workspace parameter at 100% coverage, so the description does not need to add parameter-level detail. The description's mention of 'bind layers' aligns with the schema's 'include that workspace bind in the snapshot,' but it does not go beyond what the schema already states. This is the appropriate baseline when schema coverage is complete.

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 function with a specific verb and resource: 'List memberships, current org, and bind layers for this MCP session.' It distinguishes itself from sibling tools like org_bind and org_unbind by immediately noting 'Does not switch orgs,' so an agent knows exactly what org_list does and does not do.

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?

The description explicitly tells the agent when to use an alternative: 'Use org_bind to bind this conversation or a workspace.' It also sets a clear boundary with 'Does not switch orgs' and provides a useful scoping constraint for certain key types: 'tsk_ keys see only their seat org.' This gives the agent actionable routing guidance beyond the tool name.

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