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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the safety profile is free. The description adds non-obvious behavioral content: the response is simultaneously a permission probe, telling you what this connection may change in the workspace, which an agent would not infer from the schema alone.

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?

A single front-loaded sentence with no filler. It is efficient, though 'what this connection may change in it' is slightly oblique phrasing that takes a second read to parse as permission scope.

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?

This is a simple read tool with rich annotations and a fully documented parameter, so requirements are low. However, with no output schema the description must carry return-value disclosure, and it only names three fields without indicating structure or whether anything else (billing, settings, stats) lives on the workspace object and requires the sibling getters.

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 coverage is 100% and project_id is documented as 'from list_projects' with a default-when-omitted rule. The description adds nothing about the parameter, so the schema does all the work and the baseline 3 applies.

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 identifies the resource and scope precisely ('One workspace') and enumerates what it surfaces: name, your role, and this connection's write permissions. There is no explicit verb ('retrieves'/'fetches'), and it doesn't distinguish itself from siblings like list_projects or switch_project, which keeps it below a 5.

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?

No statement of when to call this versus list_projects (enumerate all) or switch_project (change active workspace). The only usage hint is buried in the schema ('Leave out for the default one'), not in the description, so the agent gets no routing guidance from the prose.

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