lira_model_summary

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

The readOnlyHint already establishes safety, and the description adds useful behavioral context: the default is the active model, whether analysis results are retained, when they were written, and warnings when results belong to another version or same-named model. This is meaningful beyond the 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 dense but front-loaded and every clause contributes useful content about the summary's scope and caveats. The phrasing is slightly run-on, especially around the quoted 'results' section, but it remains readable and efficient.

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 an output schema exists and the tool is read-only, the description is nearly complete for correct selection and invocation. The main remaining gap is how to specify the optional model argument, but the default behavior and result-provenance caveats are well covered.

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 single optional model parameter has 0% schema description coverage, so the description must compensate. It clarifies that the default is the active model, but does not explain how the model should be identified, such as by name, path, or index.

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 gives a specific verb-like resource overview and enumerates exactly what the summary contains: model type, units, node/element counts, FE types, stiffnesses, load cases, and results status. It also distinguishes this as an orientation tool with 'Start here before reading or changing a model.'

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 clearly says to start here before reading or changing a model, which gives a strong usage context. It does not explicitly name alternatives or exclusions, but the prerequisite-like guidance is clear.

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