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

With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool adds a box to a geometry sequence, but does not say whether the operation is destructive, whether it requires an existing geometry sequence, whether it is idempotent, or what side effects it has. The agent is left to infer the mutating behavior.

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, compact sentence with no filler, and the parenthetical '(box)' adds useful clarity. It is front-loaded with the action and resource, though it lacks any additional structural elements such as usage cues; conciseness is not the weakness here.

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 tool with five parameters, zero annotations, and zero schema descriptions, this one-sentence description is not enough for an agent to invoke it confidently. The presence of an output schema may cover return values, but the description leaves key operational details such as required geometry context, parameter semantics, and side effects unexplained. It is only slightly more informative than a bare tool name.

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 0%, and the description adds no meaning for any of the five parameters. It does not clarify how geom_tag, dims, size, and pos relate, what units or coordinate conventions are expected, or what the optional tag parameter means. The description provides no parameter semantics beyond the bare field names.

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 begins with a specific verb ('Add'), names the exact resource ('a block (box)'), and locates it in a geometry sequence. This clearly distinguishes it from sibling tools like add_sphere and add_cylinder, which target other primitive types.

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 no guidance on when to use add_block versus alternatives such as add_sphere, add_cylinder, or import_geometry. There is no explicit when-to-use statement, no exclusion, and no mention of the conditions under which adding a block is the right operation.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add a cylinder to a geometry sequence' and does not explain whether the cylinder is appended, merged, transformed, or what side effects occur on the sequence. This is a minimal statement of effect but lacks behavioral depth.

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 clear sentence with no filler or repetition. It is front-loaded with the core action and object, though it is so minimal that conciseness comes at the cost of completeness.

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 annotations, 0% schema description coverage, and 7 parameters including several opaque ones, a one-sentence description leaves the agent without enough context to call the tool correctly. The output schema exists but does not explain parameter semantics or geometry-sequence behavior.

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 0%, so the description must compensate, but it does not explain geom_tag, dims, pos format, axis, or tag. The word 'cylinder' gives some semantic context for r and h, but the most ambiguous required parameters remain unexplained.

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 states a specific action ('Add') and resource ('a cylinder to a geometry sequence'), making the basic purpose clear. It is distinguishable from siblings like add_sphere and add_block by naming the geometry type, though it does not explicitly differentiate itself from those alternatives.

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 about when to use this tool versus add_sphere, add_block, or import_geometry. The only implicit guidance is the shape name itself, which is not enough to help an agent decide between geometry-creation tools.

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

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

Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It only states an add operation without clarifying whether existing materials are replaced, whether a selection is required, whether the operation is idempotent, or what side effects occur. Permission needs and failure behavior are also unaddressed.

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 extraneous content, making it concise and scannable. However, the brevity appears to stem from under-specification rather than deliberate inclusion of all necessary details, so it earns high marks for structure but not for completeness.

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 tool with three parameters, no annotations, and no explanatory description, this definition is insufficient for an agent to invoke it correctly. The purposes of 'tag' and 'selection' and the expected content of 'material' remain unknown; while an output schema exists, it cannot compensate for missing input semantics.

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 0%, so the description must compensate. It offers only a weak hint that the 'material' parameter is the entity being added, while 'tag' and 'selection' are completely unexplained. An agent cannot determine the expected material format, how the tag is used, or what the selection string refers to.

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 uses a specific verb and resource ('Add a material to the model'), which clearly distinguishes it from sibling tools like add_sphere or add_block by the unique resource type. It does not explicitly call out differentiation from related tools such as add_physics, but the resource is specific enough for basic identification.

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 no guidance on when to use add_material versus alternatives such as add_physics or import_geometry. It does not mention prerequisites, ordering, or scenarios where this tool should be avoided, leaving the agent to infer usage 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.

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

No annotations exist, so the description carries the full burden. It only restates the primary add operation and does not disclose side effects, idempotency, dependencies on an existing model, or error behavior.

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 efficient sentence with no filler. The parenthetical examples are useful and compact, though the overall terseness limits its completeness.

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 no annotations, low schema coverage, nested settings, and several sibling tools, the description is too sparse to fully support correct invocation. It identifies the operation but leaves important invocation details and usage context unspecified.

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 coverage is 0%, and the description only adds meaning to the 'interface' parameter by listing example values like ht, spf, and tds. The 'tag' and 'settings' parameters remain unexplained, and settings is a nested object that could benefit from clarification.

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 states a specific verb and resource: 'Add a physics interface', with concrete examples of interface types. This clearly distinguishes it from siblings like add_sphere, add_material, and add_study.

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 intended usage is implied by the resource type: use this tool when adding a physics interface rather than a geometry, material, or study. However, it provides no explicit when-to-use guidance, exclusions, or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a sphere is added but says nothing about side effects (e.g., whether existing geometry is modified), return behavior, or required conditions. This is entirely inadequate for a mutation tool.

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, short sentence with no wasted words, which is technically concise. However, it is so under-specified that it does not serve as an adequate tool description. The sentence earns its place but leaves critical information uncovered.

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?

The tool has 5 parameters (4 required), no schema coverage, no annotations, and an output schema that is not referenced. The one-line description is grossly insufficient for an agent to understand what inputs mean, what the operation does beyond a vague action, or what to expect. This is far from 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 0%, and the description does not mention any of the five parameters (r, pos, tag, dims, geom_tag). It adds no meaning beyond the bare schema field names. The tool has required parameters that remain completely unexplained.

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 states a clear verb ('Add') and resource ('a sphere to a geometry sequence'), which establishes the fundamental purpose. However, it does not differentiate from sibling tools like add_block or add_cylinder, so it lacks the explicit scope that would merit a 5. It is still unambiguous about what the tool does.

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 zero guidance on when to use this tool versus the many sibling tools (add_block, add_cylinder, etc.). It mentions no prerequisites, no context, and no exclusions. An agent has no basis to select this tool over alternatives.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the intended operation. It does not mention side effects on the model, return behavior, whether adding a study replaces an existing one, or any permissions or prerequisites.

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. It conveys the core purpose and the most important value constraint efficiently.

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 tool has three parameters, a free-form nested settings object, and no annotations, the description is too thin. It does not explain tag or settings semantics, when to call it, or what behavioral effects to expect, leaving important invocation decisions to the agent.

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 description coverage is 0%, and the description only clarifies the allowed values for study_type. The required tag parameter and the settings object remain unexplained, and since settings allows arbitrary additional properties, the agent gets no guidance on what keys or values are expected.

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 concrete action and resource ('Add a study') and enumerates the valid study types (Stationary|TimeDependent|Parametric|Eigenfrequency), so the agent knows exactly what this tool does. It is clearly distinguishable from sibling tools like add_physics or add_material.

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 gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no context such as needing a loaded model before adding a study. Usage is only weakly implied by the tool name and resource type.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the union/intersect/difference operations. It does not reveal whether the operation mutates the original geometry, creates new features, requires existing geometry, or how results are returned. The description also does not mention side effects or destructive potential.

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, direct sentence with no filler, and the operation list is usefully front-loaded. It is concise, though it arguably sacrifices important behavioral and parameter detail for brevity.

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?

The tool has three required parameters, zero schema descriptions, no annotations, and no usage guidance; the one-line description leaves substantial gaps about input semantics, side effects, and prerequisites. While an output schema exists, that does not help an agent decide how to invoke this tool correctly or whether it is the right tool for a given CAD/geometry task.

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 0%, so the description must compensate for undocumented parameters. It partially clarifies 'operation' by listing the three allowed values, but geom_tag and inputs remain unmeaningful: there is no explanation of whether inputs are feature names, tags, or geometry selections, nor of how geom_tag relates to them.

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 action ('combine geometry features') and enumerates the allowed operation modes ('union|intersect|difference'), making the tool's purpose clear. It also distinguishes it from sibling geometry-creation tools like add_sphere, import_geometry, add_block, and add_cylinder, though 'geometry features' is not precisely defined.

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?

Usage context is only implied: the verb 'combine' suggests it acts on existing geometry rather than creating primitives like the add_* siblings. There is no explicit statement of when to choose this tool over alternatives, no prerequisites, and no mention of what should populate geom_tag or inputs.

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

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

With no annotations provided, the description carries the full burden of disclosing effects and preconditions. It discloses nothing about whether existing geometry is required, what state changes occur, or what the operation returns or modifies.

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 extremely short, but this is under-specification rather than effective conciseness. The sentence restates the tool name and contains no distinct information that earns its place.

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 mesh-related siblings and an output schema, the description provides no context about model prerequisites, whether a geometry must exist first, or how this step fits into a larger workflow. An agent cannot determine the appropriate circumstances for invoking this tool.

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 parameter mesh_tag has 0% schema description coverage, and the description does not compensate by explaining its meaning or effect. The schema only provides a title and default value; the description adds no semantic value.

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 'Build the mesh.' simply restates the tool name and provides no additional specification of what building the mesh entails. It is a tautology rather than a substantive definition.

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 about when to call this tool versus siblings like import_geometry, generate_model_java, or run_solver. No prerequisites, conditions, or alternative recommendations are provided, though the text is not misleading.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only says 'Connect to an already-running COMSOL GUI bridge' without mentioning whether connection is state-changing, requires authentication, is idempotent, or what happens on failure. It adds no behavioral context beyond the bare action.

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?

A single sentence that is front-loaded with the core purpose. It is not verbose, but it is too sparse, omitting parameter and usage details. It earns its place but could be slightly expanded without losing conciseness.

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 tool with two optional parameters and an output schema, the description is inadequate. It does not mention connection prerequisites, success/failure behavior, or what the output represents. Given the absence of annotations, the description should provide more operational context.

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?

With 0% schema description coverage, the description must explain the parameters, but it does not mention host or port at all. It fails to compensate for the schema's lack of descriptions, leaving the agent clueless about parameter purpose, defaults, or valid values beyond the schema's type hints.

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?

States a specific verb ('Connect') and a specific resource ('an already-running COMSOL GUI bridge'). The phrase 'already-running' distinguishes it from sibling launch_gui, which presumably starts a new GUI. It is clearly not a tautology and unambiguously identifies the tool's function.

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 it is used when a GUI bridge is already running, but does not explicitly contrast with alternatives like launch_gui or gui_status. There is no guidance on when not to use it or what to do if no bridge is running. The usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool returns data, but does not state whether evaluation has side effects, whether it requires a loaded model, what 'global evaluation' means, or what kind of expression syntax is expected.

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 sentence and front-loads the primary action. It is appropriately brief, though the parenthetical 'or global evaluation' introduces ambiguity without explanation, slightly reducing structural 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?

Although an output schema exists, the description remains incomplete for a two-parameter tool with no annotations. It fails to clarify the evaluatee, the dataset semantics, or how this tool fits into the broader API workflow alongside siblings. An agent would need to inspect schemas or guess to invoke it correctly in non-trivial contexts.

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 0%, so the description must compensate. It echoes the 'expression' concept for expr but adds no detail about the dataset parameter, expression syntax, or the relationship between 'global evaluation' and the inputs. This is minimal added meaning over the raw schema field names.

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 states a clear verb and resource: 'Evaluate an expression (or global evaluation) and return data.' It identifies the tool's core action and output. However, it does not differentiate it from sibling tools like exec_model_api, and the meaning of 'global evaluation' is left vague.

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 this tool should be used instead of its siblings, nor any mention of prerequisites or exclusions. 'Evaluate an expression' implies a use case, but the description does not clarify when this is preferable to other evaluation or API-execution tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does well: it states that snippets are automatically wrapped, execution happens in the COMSOL JVM, and live vs. batch mode behave differently. It does not mention side effects, error behavior, or environment restrictions, but it is reasonably transparent for an arbitrary-code execution tool.

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 and well-structured: a one-sentence purpose, followed by the two accepted input forms and execution-mode caveat. Every sentence earns its place; there is no redundancy or filler.

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 an arbitrary-code tool, it covers the essential input formats, the expected method signature, and compile/run behavior. An output schema is present, so return-value documentation is structurally covered. It omits details about imports, available classes, timeouts, or failure modes, but is otherwise sufficient for advanced usage.

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 defines 'code' with 0% description coverage, so the description must add meaning. It does substantially: it specifies the required method signature `public static String run(Model model)`, distinguishes full-class vs. snippet input, and explains automatic wrapping. This is essential semantics beyond the bare schema.

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: 'Run arbitrary COMSOL Java API code.' It clearly distinguishes this tool from the sibling tools, which are high-level operations like add_sphere or run_solver, by positioning exec_model_api as the generic escape hatch for custom Java API calls.

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 explains how to supply code (full class vs. snippet) and how it will be wrapped, but it does not explicitly state when to prefer this tool over the provided sibling tools. 'Arbitrary' implies it is for custom operations not covered by the other tools, but no explicit alternatives or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that results are exported to a file; it does not mention file creation/overwrite behavior, supported formats, side effects, or whether success is indicated in any particular way. The statement is not misleading, but it is minimal.

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 short sentence with no filler words and front-loads the core action. It is structurally efficient, though its brevity contributes to the lack of behavioral and parameter context.

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 three parameters including a free-form settings object and zero schema descriptions, the description is not complete enough for correct invocation. The presence of an output schema reduces the need to explain return values, but an agent still cannot determine required export_type values, settings keys, or file format behavior.

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 0%, and the description does not explain the meaning of 'export_type' or 'settings'. 'plot/data' loosely hints at what might be exported and 'to a file' clarifies 'filename', but an agent still cannot infer valid export_type values or the structure of the settings object.

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 uses a specific verb ('Export'), a clear object ('results (plot/data)'), and a destination ('to a file'), so an agent can tell this is the file-output tool among model-building and simulation siblings. It loses one point because it does not elaborate on what 'plot/data' encompasses or how it differs from any non-export alternatives.

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 about when to use this tool, when not to use it, or which alternatives to prefer. An agent can infer that exporting happens when a file is needed, but the description provides no explicit context or exclusions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that COMSOL is not required for generation, that the output is only source code, and that compilation to an .mph still requires COMSOL. It could mention file-overwrite behavior, but the core operational constraints are clearly stated.

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 concise and well-structured: a clear first sentence, a self-contained usage workflow, and supporting commands. Every sentence contributes useful information, though the two references to COMSOL being needed for compilation are slightly repetitive.

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 code-generation tool with no annotations and a low-coverage schema, the description covers the essential operational context: where to use it, what it creates, what the next steps are, and what the `spec` parameter controls. With an output schema already present, the lack of return-value detail is acceptable, though model_version remains a gap.

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 0%, so the description must compensate. It adds meaning for the `spec` parameter by listing what it may carry, and the compile commands imply the roles of `filepath` and `class_name`. However, `model_version` is not mentioned at all, and filepath/class_name are only implied rather than explicitly described.

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 states a specific verb and deliverable: generate a standalone, compilable COMSOL Java model source file. It also distinguishes itself from sibling tools by emphasizing that it works without COMSOL and produces source code rather than an .mph file.

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 explains when to use the tool: on a COMSOL-less machine to prepare a Java model, then compile it on a COMSOL machine. It even includes concrete commands. It does not explicitly name alternatives or state when not to use it, but the intended workflow is unambiguous.

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

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

With no annotations provided, the description carries the burden, and the verb 'Report' reasonably implies a read-only, non-mutating operation. However, it does not explicitly state that no session changes are made or disclose behavior when no session exists.

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?

A single eight-word sentence that is front-loaded with the operation and scope. Every word contributes meaning, and there is no redundant filler.

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 zero-parameter status tool with an output schema, the description is largely sufficient: the agent knows what to query. It loses one point because it does not clarify how a missing or disconnected GUI session is represented or how this differs from related state tools.

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 defines zero parameters with 100% coverage, so the baseline is 4. The description adds no parameter details beyond the schema, but none are needed here.

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 ('Report') and a specific resource ('current GUI/bridge session state'), which clearly identifies this as a status retrieval tool. This is distinct from siblings like solver_status, model_info, and connect_gui/shutdown_gui.

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 gives no guidance on when to call this tool versus alternatives such as connect_gui, launch_gui, or solver_status. It does not state prerequisites, such as whether a GUI session must already exist, nor any exclusions.

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

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

With no annotations, the description is the only source of behavior. 'Import a geometry' implies adding geometry, but it does not say whether it overwrites existing geometry, whether it requires an active model, or what error behavior occurs for unsupported formats. Important side effects and requirements are undisclosed.

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 sentence is short and front-loaded, with no filler words, so it is concise. However, its brevity sacrifices the substance needed to structure parameter and usage details.

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 that import_geometry is a non-trivial operation with three undocumented parameters, no annotations, and an unseen output schema, the single-sentence description omits critical context about supported file types, required model state, and side effects. An agent cannot reliably invoke it without additional information.

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 0%, and the description only loosely hints at the file format. It does not explain the purpose of 'geom_tag' (likely an identifier but ambiguous), what values 'type' accepts, or what 'filename' refers to relative to the server. This is insufficient for correct parameter construction.

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 states a clear verb ('Import'), object ('a geometry'), and source ('from a CAD/file format'). This differentiates it from sibling primitives like add_sphere and add_block, but 'CAD/file format' is left unspecified, and the exact outcome (e.g., new geometry tag vs replacing a model) is unclear.

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?

No guidance is given for when to use import_geometry over sibling tools such as add_sphere or generate_model_java, nor any mention of prerequisites like having a model loaded or a valid file path. The description is purely functional, leaving selection to inference.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does convey the key side effect: launching a visible GUI and keeping it driven by subsequent operations. But it omits other behavioral traits an agent may need, such as whether it blocks, whether repeated launches are allowed, or what cleanup/shutdown implications exist.

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 crisp sentences with no filler. The primary action is front-loaded, and the consequential behavioral detail (GUI remains live-driven) follows immediately. Every word earns its place.

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?

The description is complete for the bare act of launching, and an output schema is present, so return values need not be described. However, with no annotations and zero parameter documentation, an agent cannot fully understand how to control the launch via port or model_path, nor what conditions must hold for the bridge to be 'loaded'. This leaves a meaningful gap.

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 0%, so the description needed to explain what 'port' and 'model_path' mean and how they affect the launch. It does not mention either parameter at all. While the parameter names are somewhat self-explanatory, the description adds no semantic value beyond the bare names and defaults.

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 uses a specific verb ('Launch') and names the resource ('COMSOL desktop GUI') with a distinguishing qualifier ('with the live bridge loaded'). This clearly differentiates it from siblings like connect_gui and shutdown_gui without needing their schemas.

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 use-before-follow-up-operations ('Operations issued afterwards drive the visible GUI in real time'), which gives useful context. However, it does not explicitly state when to prefer this over connect_gui or whether launch_gui is only for first-time startup, leaving the routing partially inferred.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether loading replaces the current model, whether there are side effects on existing data, or what occurs on an invalid path. 'Load a .mph model from disk' names the operation but omits its consequences.

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 sentence with no filler or redundant phrasing. It is efficiently front-loaded with the action and resource, though its brevity sacrifices useful context that could be added at minimal length cost.

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 state-changing tool with one parameter and no annotations, this description is too sparse. It lacks any mention of expected output, side effects, preconditions, or error behavior, so an agent cannot fully anticipate the impact of calling it.

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 0%, yet the description does not explain the 'path' parameter's expected format, whether relative paths are accepted, or how the extension is handled. It merely implies the path points to a .mph file, adding marginal value beyond the schema's 'Path' title.

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 uses a specific verb ('Load') and a clear resource ('.mph model from disk'), making the core action unmistakable. It operationally differs from siblings like save_model or new_model, though it stops short of explicitly naming them.

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?

No guidance is provided on when to use this tool versus alternatives such as new_model, generate_model_java, or import_geometry. The description states only the action, not the circumstances that should trigger its use or when it is not appropriate.

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

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

There are no annotations, so the description must carry the behavioral disclosure burden. 'Return' implies a read-only operation with no side effects, and 'current model' indicates state dependence, which is useful. However, it does not explicitly say whether it modifies state, requires the model to be loaded first, or what happens if no model exists.

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. Every word contributes meaning, and it is appropriately sized for a zero-parameter introspection tool.

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 zero parameters and an output schema, the description is largely sufficient for an agent to call this tool. The main missing context is an explicit statement that this is a safe, read-only introspection call and whether a model must already be loaded.

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 accepts zero parameters, so parameter semantics are trivially clear. Per the baseline for zero-parameter tools, the description need not explain inputs. The schema already confirms there are no arguments.

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 uses a specific verb ('Return') and identifies the resource ('structure of the current model'), clearly distinguishing it from the many model-manipulation siblings like add_sphere, run_solver, or save_model. However, it does not clarify what kind of structure is returned (e.g., geometry hierarchy, API schema, or mesh topology), leaving some room for interpretation.

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?

No guidance is given about when to use this tool versus alternatives such as evaluate, solver_status, or load_model. The name implies an introspection utility, but the description does not state a recommended use case or mention that it can be used to inspect the current model before performing operations.

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

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

With no annotations provided, the description does not disclose side effects such as whether creating a new model replaces the current one, requires confirmation, or affects unsaved work. It only says 'create', giving no safety or behavioral context for a mutation operation.

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 short sentence with no wasted words. It is front-loaded with the core action and resource, and every word contributes to the meaning.

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 creation tool with no annotations, the description is too sparse. It does not explain what 'model' means in this context, what the version parameter affects, when to use this tool instead of related siblings, or what happens after creation. The presence of an output schema helps but does not compensate for the lack of usage and side-effect information.

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 describes a single optional 'version' parameter with default '6.2', but the description does not mention it at all. With 0% schema description coverage, the description should explain the parameter's purpose or valid values, but it adds nothing beyond the schema.

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 clearly states a specific action ('Create') and resource ('a new empty model'). It also distinguishes itself from siblings like load_model and generate_model_java by emphasizing 'new' and 'empty', which makes the tool's purpose unambiguous.

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 no guidance about when to use this tool versus alternatives such as load_model, generate_model_java, or model_info. It simply states what it does without any context, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the solver run is blocking or long-running, whether it modifies model state, what side effects occur, or how results become available. This is a significant gap for a solver-invocation tool.

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 extremely concise, front-loading the essential action immediately in a single short sentence with no filler. It is appropriately minimal for a simple one-parameter tool.

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?

While an output schema exists and may document return values, the description omits key contextual details: prerequisites, whether the call is synchronous or asynchronous, how to monitor progress, and any relationship to solver_status or evaluate. For a tool with no annotations, this is under-specified.

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 0%, and the description adds no meaning beyond the parameter name 'study_tag' and the phrase 'for a study.' It does not explain how to obtain a valid study tag, what format it should take, or how it relates to add_study or study-related tools.

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 states a specific action ('Run the solver') and a specific target ('for a study'), making the tool's basic function clear. It is distinguishable from siblings like add_study and solver_status by this direct phrasing, though it does not explicitly name alternatives.

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 about when to use this tool relative to siblings, nor any stated preconditions such as the study needing to exist before running. The phrase 'for a study' only implies that a study must already be created, but no explicit usage context or exclusion is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic save action but does not disclose whether existing files are overwritten, whether directories are created, what happens if the path is empty, or any side effects beyond saving the file.

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 sentence with no redundant words. The core action and target format are front-loaded, making it easy for an agent to parse quickly.

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?

The tool is simple, with one optional parameter and an output schema available, so the description is largely sufficient for basic selection and invocation. However, the empty default path and lack of overwrite/error details create a small gap in operational clarity.

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 0%, so the description must compensate for missing parameter meaning. It implies 'path' refers to the destination file path by mentioning '.mph', but it does not clarify whether the extension is auto-appended, whether the path is required, or what the default empty string means behaviorally.

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 uses a specific verb ('Save') with a clear resource ('the current model') and target format ('.mph file'). This clearly distinguishes it from siblings like load_model, new_model, and export_results, which involve different operations or output formats.

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?

No guidance is provided about when to use this tool versus alternatives such as export_results or load_model. The description does not mention prerequisites, typical workflow placement, or scenarios where another sibling would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Stop' without detailing consequences: whether it terminates the GUI process, discards unsaved work, requires an active session, or is idempotent. This leaves the agent with significant uncertainty about side effects.

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?

A single, front-loaded sentence with zero waste. It efficiently conveys the core action without extraneous words, which is ideal for a simple stop command.

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?

The tool is simple, and an output schema exists, so return values need not be described. However, key context is missing: whether a session must be active, what happens to the GUI state, and if any cleanup is involved. The description is adequate but not fully complete for an agent that needs to call it safely.

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, and the schema is empty. Per the baseline, a score of 4 is appropriate since no parameter explanation is needed, and the description adds no irrelevant info.

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 states a specific action ('Stop') and resource ('COMSOL GUI bridge session'), distinguishing it from siblings like launch_gui, connect_gui, and gui_status. It is clear and unambiguous about what the tool does.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., gui_status, connect_gui). There is no mention of prerequisites, conditions for calling, 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.

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

No annotations are provided, so the description carries the behavioral burden. The word 'Report' implies a read-only, non-mutating query, but the description does not disclose behavior for unknown study tags, whether the status is cached, or whether it can return in-progress states.

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 redundant information. Every word contributes to the core purpose.

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?

The tool is simple and has an output schema, so the return contract is covered elsewhere. However, the description omits any guidance on valid study_tag values, prerequisites, or relationship to solver lifecycle steps, leaving some inference required.

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 0%, and the description never mentions study_tag or explains how to specify the study. The only meaning comes from the parameter name and title, which is minimal compensation for the lack of explicit documentation.

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 uses a specific verb ('Report') and a specific question ('whether a study has been solved'), making the tool's purpose immediately clear. It is distinct in intent from siblings like run_solver and evaluate, though it does not explicitly name those alternatives.

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?

No explicit guidance is given about when to use this tool versus alternatives like run_solver or evaluate. The context implies it is for checking solver status after running a study, but this is left to inference rather than stated.

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