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

The description goes beyond the annotations (which correctly indicate readOnly, idempotent, and not destructive) by detailing exactly what data is included and, crucially, what is excluded. It warns that imported input is immutable evidence and not an AI proposal or live filesystem sync, which are important behavioral traits. The description is fully consistent with the annotations, no contradiction.

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 two sentences: the first explains what the tool does and lists the output components; the second clarifies key exclusions and data characteristics. Every sentence is purposeful and adds essential context without redundancy. It is front-loaded with the core action and resource, making it easy for an AI agent to quickly grasp the tool's role.

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 the tool's moderate complexity (3 parameters, no output schema, no nested objects), the description is complete. It fully documents what the tool returns, what it does not return, and the semantics of the optional parameters. The annotations provide additional behavioral safety cues. There are no obvious gaps in the information needed for correct invocation and understanding.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining that include_governance_text is deprecated and will always be ignored, and by clarifying that include_project_input_files will include 'sanitized observed file contents' while manifest facts and provenance are always returned. This clarifies the behavioral impact of each parameter beyond the schema's basic type and description.

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 starts with a clear verb ('Read') and specifies the resource ('source-free operating packet'). It then enumerates the components returned (e.g., version metadata, project input, review attention, artifact index), making the purpose concrete. Among many sibling tools like get_project, get_project_activity, and get_project_mission, this description effectively distinguishes this tool as the one for reading a comprehensive operational snapshot.

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 states what is not returned ('private 2ools skills, prompts, routing, governance text, and generated version source are not returned'), which preempts misuse. It clarifies that imported input is immutable evidence, not an AI proposal or live filesystem sync, guiding the agent on the tool's limitations and appropriate use cases. This provides clear context for when to use this tool versus alternatives that might supply additional or different data.

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