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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by detailing the internal structure of the templates (node definitions, relationship configs) and noting they can be used as-is or adapted for create_graph_project. No contradictions with annotations.

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 slightly long but front-loaded with the most critical instruction (USE THIS FIRST). Each sentence contributes: template list, structure explanation, and usage tip. The TIP and explicit template examples justify the length for a tool that needs to convey format details.

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 zero-parameter tool with no output schema, the description fully covers what is returned (list of templates and their structure), when to use it, and how to apply the output. Nothing essential is missing for an agent to invoke it correctly.

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?

There are zero parameters, so the baseline is 4. The description appropriately compensates by explaining what the tool returns and how to interpret the template data, even though no input parameters need documentation.

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 a specific verb ('Get') and resource ('pre-built graph template schemas'), lists concrete templates, and explicitly marks it as the first step for creating a new graph project. This clearly differentiates it from sibling tools like get_template_schemas (non-graph) and get_graph_schema (retrieves existing schemas).

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?

It gives explicit when-to-use guidance ('USE THIS FIRST when creating a new graph project') and explains how the output feeds into create_graph_project. However, it does not explicitly contrast with alternatives such as get_template_schemas or other schema-related tools, leaving some inference to the agent.

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