get_workspace

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read-only retrieval operation ('Get details'), which is implied by the verb. However, it doesn't disclose what fields the returned details contain, whether team_id must reference an existing workspace or behavior on invalid ID, or any permission requirements. For a simple read/get tool with zero annotations, the description adds minimal behavioral context but doesn't fully explain.

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 sentence, zero waste, directly states what it does. Appropriately minimal for a simple single-parameter get tool.

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?

The tool has one parameter, full schema coverage, no output schema, and no annotations. For such a simple retrieval operation, the description covers the essential ground: what it gets and how it's scoped. There's no output schema to explain return values, so that burden isn't present. It's complete for the complexity of the tool.

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% with a single team_id parameter described as 'The workspace/team ID'. This description adds the minor detail that this specifies the workspace to retrieve. Given full schema coverage and only one parameter, the baseline of 3 is appropriate; there's little for the description to add.

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 states the tool gets details of a specific workspace, scoped by team ID. This is clear and specific (verb=get, resource=workspace, qualifier='by team ID'). It differentiates from siblings like get_workspaces (plural/listing) and get_workspace_members. However, it doesn't explicitly name the sibling for differentiation, so not a full 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?

The description implies the tool is for fetching a single workspace's details, contrasting with get_workspaces (list all). The context of 'specific workspace by team ID' implies a targeted retrieval use case, but there are no explicit when-to-use or exclusions stated. The absence of a when-not-to-use or alternative naming keeps this at a 3.

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