describe_context_model

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

No annotations are supplied, so the description carries the transparency burden entirely. Calling it 'how to use' and framing it as a starting instruction implies a read-only, non-mutating guidance call, and it discloses the topics covered, but it never states explicitly that it has no side effects, whether the payload is stable across calls, or whether it depends on tenant/source configuration. The single 'call once' constraint is the main behavioral signal.

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 compact sentences with no filler, and the substantive content list is front-loaded ahead of the invocation rule. Some phrases are dense internal jargon ('Confirmed map', 'capability-first landscape workflow') that a first-time agent cannot resolve from the text, which is the main cost in clarity.

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?

An output schema exists, so the description need not explain the returned structure, and with zero parameters and no annotations the surface to cover is small. For a pure guidance tool the description is adequate: it says what it contains and when to call it. It would be stronger if it unpacked the 'EA' context and clarified whether the returned guidance is authoritative over sibling schemas.

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?

The tool takes zero parameters and the schema is fully described (100% coverage, empty properties object), so there is nothing for the description to disambiguate. The description correctly implies no inputs are needed. Baseline 4 applies for a parameterless tool.

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 the specific content the tool returns: the context model ('Confirmed map vs evidence notes'), the 'capability-first landscape workflow', and the 'recommended tool call order'. That distinguishes it from the sibling data-access tools like get_entity or search_evidence, which fetch records rather than explain the framework. It lacks a crisp verb-and-resource phrasing ('Returns the context model...'), which keeps it from a 5.

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?

'Call once at the start of an EA Q&A session' gives an explicit trigger and an explicit frequency constraint, and the promise of a 'recommended tool call order' routes the agent to the other tools. It does not state when *not* to call it (e.g. mid-session re-reads) or what to do if the session context is already loaded, so it falls short of full when/when-not coverage.

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