cuemap_lexicon_graph

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

With no annotations provided, the description carries the full safety burden; 'Read' does convey that this is a non-mutating operation. However, it does not state what the returned graph looks like, whether it can fail for missing or uninitialized lexicons, or any other behavioral context.

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 a single, front-loaded sentence with no filler or repetition. Every word adds value, which is appropriate for a simple one-parameter read operation.

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 low complexity and full schema coverage, the description plus schema are enough to invoke the tool correctly. But because there is no output schema and no mention of how the graph relates to cuemap_lexicon_inspect or when the graph is unavailable, the definition is merely adequate rather than complete.

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 100%, and the only parameter, 'project', already has a clear description including its default behavior. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 names a specific verb ('Read'), a specific resource ('current Lexicon graph'), and the scope ('for a project'), so an agent can infer the basic operation. It does not, however, differentiate this from sibling tools like cuemap_lexicon_inspect or cuemap_lexicon_wire, so it is clear but not fully distinguishing.

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 call this tool instead of siblings such as cuemap_lexicon_inspect or cuemap_recall, and no conditions or exclusions are stated. The only context is the optional project parameter in the schema; the description itself provides no decision rules for selecting between tools.

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