get_project_status

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

With no annotations, the description must carry the full behavioral disclosure burden. It states the return type (a summary of branches, changes, workspaces) but does not disclose side effects (presumably read-only), permission requirements, potential errors (e.g., invalid project_id), or any performance or rate-limit considerations. This is minimal coverage.

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 with no redundancy. It front-loads the core purpose and lists the status components compactly. Every word earns its place; there is no fluff or unnecessary detail.

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?

Given no output schema, no annotations, and only one parameter, the description must provide enough context for correct invocation. It clarifies the high-level return content but omits details like the exact response format, potential error scenarios, and any preconditions (e.g., project existence). This is incomplete for a tool with no other documentation.

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 description coverage is 0%, and the description makes no mention of the single parameter project_id. It does not explain what a project_id is, how to obtain it, or any constraints (e.g., must exist). The parameter name is self-evident in isolation, but the description adds zero semantic value.

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 a specific verb ('Get') and resource ('summary status for a project'), and enumerates the three components of that status (branches, open changes, active workspaces). This distinguishes it from siblings like get_change or list_workspaces by focusing on a project-level aggregate.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or refer to sibling tools that might serve a similar purpose for more granular data. The agent is left to infer when a summary is preferable to individual list tools.

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