get_error_file

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

With no annotations, the description carries full behavioral burden. It does disclose the read-only nature ('Retrieve') and the return format ('Plain text output of EPlus error file'), which is helpful. It does not mention behavior for missing IDs, empty files, or any required initialization steps (e.g., initialize_model_map), leaving some gaps.

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 compact, front-loaded, and organized with clear Args and Returns sections. 'Useful in debugging' adds minor context without bloating the text, and no schema details are redundantly repeated.

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 simple one-parameter retrieval tool, the description covers the essential information: the parameter's meaning/source and the output type. It lacks edge-case details like error handling or empty-file behavior, but those are not critical for making a correct invocation.

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 schema only says id is a string, but the description clarifies that id is 'the model_id of the EnergyPlus model' and directs the agent to get it from get_available_models. This provides crucial semantic context and fully compensates for the 0% schema description coverage.

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 'Retrieve' and a specific resource: 'a specific Error file from an EnergyPlus model using ID.' This makes the tool's purpose clear without needing the schema. It does not explicitly differentiate itself from sibling retrieval tools like get_rdd_file, so it does not earn 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?

The description provides a usage context ('Useful in debugging') and an explicit prerequisite for obtaining the id from get_available_models. However, it does not state when to prefer this tool over alternatives or mention any exclusion criteria or when NOT to use it.

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