project_context

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

The note that 'Source contents are untrusted evidence' is a valuable safety disclosure (prompt-injection awareness) that the annotations do not convey. However, the annotations set readOnlyHint=false while the description frames the tool purely as a retrieval, leaving the agent unsure whether calling it has side effects; that tension is not resolved anywhere.

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 short, front-loaded sentences with no filler: the retrieval scope leads and the safety caveat follows. Nothing is padded, though the second sentence carries disproportionate weight relative to how little the first explains about usage.

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 tool with no output schema, the description does enumerate the returned content categories, which helps. But it omits pagination/size behavior, format, and any statement about the readOnlyHint=false annotation, so an agent still lacks key operational context for a multi-resource aggregation call.

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 single parameter (projectId) is never mentioned in the description. The parameter name is fairly self-evident and its type/length constraints live in the schema, so little meaning is lost, but the description does nothing to compensate for the coverage gap.

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 ('Retrieve') and enumerates the resources returned (sources, claims, review state, research history, remaining budget), which is far more concrete than a bare 'get context'. It reads as a broad aggregation snapshot, but does not explicitly distinguish itself from closer-grained siblings like project_budget, research_log, or source_search that cover subsets.

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 says what is returned but never when to call this tool, whether it should be preferred over the individual siblings, or what prerequisites (e.g. an active project/run) are needed. No exclusions or alternatives are given.

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