ea_get_model_info

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

The readOnlyHint annotation already marks this as safe, and the description adds meaningful behavior beyond that: it explains that `resolvedPath` is environment detail rather than citable, that `resolvedPathNote` clarifies this, and that configuration sources can include skipped or shadowed entries with reasons. This gives the agent realistic expectations about sensitive or non-portable output.

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 dense, run-on sentence that front-loads the core purpose and then packs in many field-level details. Every detail is relevant, but the wall of text is harder to parse than it needs to be; breaking it into a short overview plus field list would improve scannability without losing information.

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?

With no output schema and minimal annotations, the description carries the burden of explaining return values, and it does so thoroughly: it covers the identity fields, server version, resolved path and its note, configuration source and provenance, and skipped/shadowed settings. For a zero-argument read-only status tool, nothing essential is missing.

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 has zero parameters, so the input schema fully covers the parameter surface. Per the baseline for no-parameter tools, 4 is appropriate; there is no parameter information to provide, and the description instead focuses on the output schema, which is the more important gap given no output schema exists.

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 opens with a specific verb and resource: 'Report which .qea export file the server has open.' It then enumerates the exact information returned, making its identity and scope unmistakable and clearly distinct from sibling tools that query elements, packages, or diagrams.

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 implies a use case—when you need to know which file the server has open or how configuration was resolved—but it never states when to use this tool versus alternatives or when not to use it. No sibling tool is named or contrasted, leaving the agent to infer placement entirely from the tool name.

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