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

No annotations are provided, so the description must disclose behavior. It states connection and return of info/error, but lacks details on side effects, session management, blocking behavior, or authentication requirements.

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 front-loaded with the purpose. The docstring format with Args/Returns is efficient, and every sentence adds value without redundancy.

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 output schema, the return description is adequate but minimal. Missing context about prerequisites (e.g., server must be running) and relation to sibling tools. Could note that this is typically used before other COMSOL operations.

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%, but the description adds meaning by explaining 'port' and 'host' (including default). This compensates for the missing schema descriptions, though port range or format could be more specific.

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 the action ('Connect') and the resource ('remote COMSOL server'), distinguishing it from sibling tools like 'comsol_disconnect' and 'comsol_start'.

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 on when to use this tool versus alternatives, nor prerequisites like server availability. The implied usage is to connect before other operations, but no exclusions are 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?

Discloses destructive action (clearing models) without annotations. However, could mention side effects like unsaved work loss. Still, good transparency.

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 concise sentences with front-loaded purpose. No redundant 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?

Given no parameters and no output schema, description adequately covers purpose and return. Could elaborate on return format.

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?

No parameters; schema coverage is 100% trivially. Baseline 4 applies.

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?

Description clearly states 'Disconnect from COMSOL and clear all models from memory', using specific verb and resource. It distinguishes itself from siblings like comsol_connect and comsol_start.

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?

Implied usage context (disconnect after connecting), but no explicit when-not or alternatives guidance.

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 load. It does disclose the return shape ('Session info including version and core count, or error message') and the effective defaults for each argument, which is useful. It says nothing about latency (starting a COMSOL session is slow), whether an existing session is replaced, or resource/permission requirements.

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 purpose is front-loaded in one line, followed by compact Args/Returns blocks. Every sentence earns its place; there is no redundancy with the schema.

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 3-param entry-point tool with no output schema and no annotations, the definition covers parameters and return shape adequately. It omits the operational context an agent would want — relationship to comsol_connect/comsol_disconnect and session lifecycle — leaving it only marginally 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%, so the description must compensate, and it does: each of the three parameters gets meaning plus an example ('6.0', ["ACDC", "CADImport"]) and the semantic default ('all available', 'latest installed'), which the schema's null defaults do not convey.

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+resource: 'Start a local COMSOL client session.' That is clearly distinct from most modeling siblings. However, it does not differentiate itself from close siblings such as comsol_connect or comsol_status, so an agent must infer the boundary.

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 is only implied — the tool is an entry point that logically precedes modeling calls. There is no explicit when-to-use statement and no guidance on choosing between comsol_start and the near-neighbor comsol_connect, which is the main selection risk here.

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 provided, so the description must fully disclose behavioral traits. It states the tool 'gets' status and 'returns' information, implying no side effects, but does not confirm read-only behavior, whether it requires an active session, or any potential impacts. Minimal transparency.

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 with two sentences that directly convey purpose and return value. No unnecessary 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?

For a simple status tool with no parameters and no output schema, the description gives a reasonable overview of what is returned. However, it lacks specifics about the format or structure of the return value, and could clarify if it works only when COMSOL is connected.

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?

No parameters in the input schema, so schema description coverage is 100% by default. The description does not need to add parameter details; baseline score of 4 is appropriate.

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 the tool gets the current COMSOL session status and returns session information including connection status, version, and loaded models. This distinguishes it from sibling tools like comsol_connect (connect to COMSOL) or comsol_start (start session).

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 the tool is used to check session status, but does not explicitly state when to use it versus alternatives or provide prerequisites (e.g., requires an active session). No exclusions or when-not-to-use guidance.

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 states the tool lists datasets but does not discuss scope (e.g., all models vs. current model), error behavior, pagination, performance, or side effects. The agent has limited insight into the tool's operational traits.

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 and well-structured. It opens with a clear purpose statement, then briefly defines the term 'datasets,' followed by parameter documentation. Every sentence provides value with no extraneous text.

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's simplicity (one optional parameter, no output schema), the description is reasonably complete. It explains the return value ('list of dataset names') and the parameter. However, it omits details like authentication requirements, potential errors, or whether the list is exhaustive. For a simple read tool, this is acceptable but not exceptional.

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 input schema has 0% description coverage, so the description compensates by explaining the model_name parameter's purpose and default value ('Model name (default: current model)'). This adds meaningful context beyond the schema, which only shows the type and default null. The description is adequate for the single parameter.

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 that the tool lists all datasets in a model, specifying the action (list) and resource (datasets). It also provides a brief explanation of what datasets are, aiding understanding. However, it does not explicitly distinguish from sibling tools, though no other tool appears to directly compete.

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 lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it compares to other tools like model_list or solutions_list. The agent must infer usage context from the tool name alone.

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?

Without annotations, the description carries the burden of behavioral disclosure. It only states that it 'returns documentation content' but does not mention whether the operation is purely read-only, if any authentication is needed, or how errors (e.g., invalid topic) are handled. This is insufficient for a tool with no 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 exceptionally concise: two sentences plus a bulleted list of topics. It front-loads the main action and presents the parameter options clearly without any superfluous text.

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 retrieval tool with one parameter and no output schema, the description adequately covers what the tool does and what inputs are valid. However, it omits details like error handling, response format, or whether the documentation content is raw text or structured, which could be helpful but are not critical.

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 has 0% description coverage for the 'topic' parameter, but the description compensates by listing three specific valid topics with brief explanations. This adds significant meaning beyond the bare schema, though it could be improved by including format constraints or error handling notes.

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 'Get documentation on a specific topic' and enumerates the available topics, making the tool's purpose unambiguous. It distinguishes itself from siblings like docs_list (which lists topics) and physics_get_guide (which is physics-specific).

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 the tool should be used when a user needs documentation on a known topic, but it provides no explicit guidance on when to prefer this tool over alternatives like physics_get_guide or docs_list. No exclusions or conditions are 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?

Describes return value as list of topics with descriptions. No annotations exist, so burden is on description. It is adequate but lacks details on output format or side effects (none 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?

Two sentences with no wasted words. Structure is simple but effective for a zero-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?

Given no output schema, description should specify return format. It says 'list of topics with descriptions' but not whether it's an array of strings or objects. Adequate but minimal.

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?

No parameters, so baseline 4. No additional parameter info needed beyond 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?

Description clearly states it lists documentation topics. Differentiates from sibling 'docs_get' which likely retrieves a specific topic, though not explicit.

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 on when to use this tool versus alternatives like docs_get. Does not specify prerequisites or context.

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 must fully disclose behavior. It mentions auto-generation of feature_name but does not describe side effects (e.g., whether it modifies existing geometry, error handling, or what 'Created block info' entails). Critical behavioral traits are missing.

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: one sentence for purpose, then a list of parameters with one-line explanations, and a return note. It is front-loaded and each sentence earns its place with no redundancy.

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 adequately documents all parameters but lacks behavioral context such as what happens if geometry_name is null or invalid, error conditions, and the format of the return value. For a tool with 6 optional parameters and no output schema, more completeness is needed.

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 compensates excellently. Each parameter is explained with meaningful context: units for position and size, defaults, and optionality for geometry_name, feature_name, model_name. This adds value beyond the sparse 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 the tool adds a block (rectangular cuboid) to the geometry. The verb 'Add' and resource 'block' are specific, and the shape name distinguishes it from sibling geometry_add_circle, cylinder, etc. However, it does not explicitly contrast with alternatives, missing a chance to differentiate.

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 this tool versus other geometry_add_* tools or when to avoid it. There is no mention of prerequisites, context, or comparison, leaving the agent without decision support.

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. While it states 'Add a circle,' implying mutation, it does not describe side effects, required state (e.g., geometry must exist), or what happens if parameters are omitted beyond defaults. No information about rate limits or destructive 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 relatively brief and includes a structured Args and Returns section. It is not verbose, but the return value is minimally described ('Created circle info'), which could be expanded. Overall, it is appropriately sized.

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 among many geometry_add_* siblings and without an output schema, the description adequately explains parameters but lacks context on when to choose this shape and how it interacts with existing geometry. It does not specify whether geometry_name must refer to an existing geometry or work plane, leaving ambiguity.

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?

Despite 0% schema coverage, the description adds meaningful semantics for all four parameters: position as center [x, y] in meters, radius in meters, geometry_name as geometry sequence name, model_name with default current model. This clarifies usage beyond the schema's defaults and types.

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 identifies the tool as adding a circle to a 2D geometry or work plane. It distinguishes itself from sibling tools like geometry_add_block, geometry_add_cylinder, geometry_add_rectangle, and geometry_add_sphere by specifying the shape.

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 this tool versus other geometry_add_* tools. It does not mention prerequisites, such as the need for an existing geometry or work plane, nor does it suggest 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 full burden. It only states it adds a cylinder, but does not disclose side effects, whether it modifies existing geometry, what 'add' means in terms of geometry sequences, or the format of return info.

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?

Structured with Args and Returns, brief and to the point. No redundant 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 7 parameters, no annotations, and no output schema, the description is insufficient. It does not explain parameter behavior or return format, making it incomplete for effective tool 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?

Schema coverage is 0%, so description compensates with parameter descriptions (position, radius, height, etc.). However, lacks details on geometry_name (which geometry?), component_name, and feature_name semantics.

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?

Description clearly states the tool adds a cylinder to the geometry. The verb 'add' and resource 'cylinder' are specific, but it does not differentiate from sibling tools like geometry_add_block or geometry_add_sphere.

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 on when to use this tool vs alternatives like adding other shapes or using geometry_add_feature. No mention of prerequisites 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?

With no annotations, the description carries full burden. It mentions adding a feature and returning info, but lacks details on side effects (e.g., whether the geometry is built or needs rebuilding), permissions, or constraints. Behavioral traits are partially disclosed.

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 well-structured with a clear action sentence, a list of feature types, and an 'Args' section. It is concise but informative, with no redundant information. Front-loaded with the main 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?

Given 5 parameters, no output schema, and many sibling tools, the description is moderately complete. It explains parameters and returns but lacks examples and behavioral details. Familiar users might find it sufficient, but novices may need more 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?

Schema coverage is 0%, so description must compensate. It explains the purpose of each parameter (feature_type, geometry_name, etc.) and mentions kwargs as feature-specific properties. However, it does not provide examples or format for kwargs, nor allowed values for feature_type beyond the list. Adds some meaning but not comprehensive.

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 'Add a geometry feature to a geometry sequence' and lists common feature types, which distinguishes it from sibling tools. However, it does not explicitly differentiate from specific geometry_add_* tools (e.g., geometry_add_block).

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 lists feature types implying when to use this tool, but does not provide explicit guidance on when to use this generic version versus the specific shape tools (siblings). No when-not-to-use or alternative recommendations.

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?

Describes only the action of adding a rectangle without disclosing behavioral traits like side effects, dependency on geometry existence, or performance implications. No annotations exist to compensate.

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?

Concise docstring format with Args and Returns sections. The first sentence clearly states purpose. Every sentence serves a purpose, though the Returns section is minimal.

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?

Covers the basics for a simple add tool but lacks details on return value format and prerequisites like needing an open geometry or work plane. Output schema is absent, so description carries additional burden.

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?

Provides brief descriptions for each parameter (e.g., 'position: Base position [x, y] in meters') and default values, adding some meaning beyond the schema. However, with 0% schema coverage, more detail would be beneficial.

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?

Clearly states 'Add a rectangle to a 2D geometry or work plane' with specific verb and resource, distinguishing it from siblings like geometry_add_block or geometry_add_circle.

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 on when to use this tool vs alternatives (e.g., circle, block). Does not specify prerequisites or context such as requiring an existing geometry.

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. The description only states the action and returns 'Created sphere info' but does not disclose side effects, model requirements, or whether the operation is reversible. Minimal behavioral context beyond the basic 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?

The description is structured as a clear docstring with Args and Returns. It is concise, with no unnecessary words, and front-loades the primary 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?

Given 6 parameters and no output schema or annotations, the description covers all parameters and mentions return info. However, it omits context like the need for an active model or coordinate system, which would aid completeness.

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 fully compensates. It explains every parameter: position as center [x,y,z], radius with default 0.5, geometry_name, component_name, feature_name, model_name. This adds meaning that the schema titles alone lack.

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 'Add a sphere to the geometry,' which is a specific verb-resource pair. It distinguishes from sibling tools like geometry_add_block or geometry_add_circle that add other shapes.

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 usage for adding a sphere shape but offers no explicit guidance on when to use this tool versus alternatives like geometry_add_block. No when-not or prerequisites are mentioned.

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 must fully describe behavior. It only says 'create a boolean difference' and returns 'operation info', but does not disclose whether the operation is destructive, modifies existing objects, or creates new ones. No side effects or permissions are mentioned.

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: one purpose line followed by a structured Args list and a return line. It is front-loaded with the main operation. Minor waste: the 'Returns' line is vague but acceptable.

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, the description should provide more detail about the return value. 'Created difference operation info' is too generic. Covers parameter definitions but lacks usage context, error handling, or examples. Adequate but not 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%, so description must compensate. The description provides brief role explanations for parameters (e.g., 'Object to subtract from'), and default values for some. This adds meaning beyond the schema's title-only fields, but explanations are still high-level and lack details like allowed formats or constraints.

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 explicitly states 'Create a boolean difference (subtract objects from another)' with a specific verb and resource. It clearly distinguishes from the sibling tool geometry_boolean_union by naming the operation.

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 on when to use this tool or when to prefer alternatives. Does not mention that geometry_boolean_union exists for union operations or provide any context about prerequisites or common use cases.

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 provided, so description carries full burden. It only says 'Creates' and 'Returns info', but does not disclose if it modifies existing geometry, how overlaps are handled, or any 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?

The description is short and includes Args/Returns in a structured format. No wasted words, but could be more informative without extra length.

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 boolean union tool with no output schema and no annotations, the description is incomplete. It lacks details on required state, error conditions, and behavior of the union operation.

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 has 0% description coverage, so the description must add meaning. It adds brief explanations for each parameter (e.g., 'Names of objects to unite'), which is helpful but still vague for geometry_name and model_name.

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 'Create a boolean union of geometry objects' which is a specific verb-resource pair. It distinguishes from sibling geometry_boolean_difference by name and description.

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 on when to use union versus alternatives like difference or add operations. No context about prerequisites or typical use cases.

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 provided; description mentions it is a build operation (likely mutable) and requires prior modifications. However, it does not detail destructiveness, permission needs, or reversible nature.

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 short, efficient sentences. The first clearly states purpose and prerequisite, the second lists parameters. No wasted text.

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?

No output schema; returns are only 'Build status' without detail. No mention of possible failures or side effects. Adequate for a simple tool but lacks completeness for a production setting.

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 has 0% coverage (no descriptions), but the description adds meaning for each parameter: defaults for geometry_name (build all), component_name ('comp1'), model_name (current model).

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?

Clearly states the tool builds the geometry sequence to generate the actual geometry, and distinguishes from sibling tools that add/modify features (e.g., geometry_add_block).

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?

Explicitly states 'must be called after adding/modifying geometry features', providing clear context. Does not mention alternatives, but the sister list of geometry modification tools implies when to use others.

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. It lists parameter defaults and returns 'Created geometry info,' but does not disclose side effects, error conditions, or whether the operation is destructive. This is acceptable but lacks 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 very concise: a clear purpose statement, an important note, and a bulleted parameter list. Every sentence serves a purpose, no fluff.

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 sibling tools, the description adequately identifies this as the step to create a geometry container before adding primitives. It includes a prerequisite note and parameter defaults, but lacks details on how to set the current model or what 'geometry sequence' entails.

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 explains each parameter with defaults and special notes (e.g., space_dimension: '2 for 2D, 3 for 3D'). This adds useful meaning beyond the schema, though more detail on allowed values or constraints would improve it.

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 'Create a new geometry sequence in the model's component,' using a specific verb and resource. This distinguishes it from sibling tools like geometry_add_block which add primitives to an existing geometry sequence.

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 explicitly warns that a component must exist first and suggests model_create_component if needed. This provides a clear prerequisite, though it does not explicitly contrast with alternatives like geometry_add_*.

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 behavioral burden. It discloses defaults for optional parameters and notes the return ('Created named selection and matched entity numbers when available'), which helps. It still omits whether the selection persists, permission/model-state prerequisites, or failure behavior for a mutation tool, keeping it at a modest 3.

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 purpose is front-loaded, followed by a well-organized Args list and a Returns note. Each line contributes, though listing parameters as a separate block is somewhat verbose for what the schema could have carried.

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 12-parameter tool with 0% schema coverage and no output schema, the description covers parameter meaning and the return value adequately. The gaps are tool-selection guidance and mutation/error semantics rather than missing parameter documentation.

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% - only bare titles exist - so the description must compensate, and it does: the Args block documents all 12 parameters, including coordinate-expression semantics, 'Box condition, usually "intersects" or "inside"', and defaults for geometry_name, component_name, and model_name. This adds substantial meaning 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 states a specific verb and resource: 'Create a named Box selection for geometry entities by position.' This is clear and distinguishable from siblings like geometry_create_side_selections. It stops short of explicitly contrasting itself with those alternatives, so it earns a 4 rather than 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?

It supplies conditional guidance for entity_dimension (use 1 for 2D boundaries, 2 for 3D boundary faces), which is genuinely useful usage context. However, it never says when to choose this tool over alternatives such as geometry_create_side_selections or geometry_boundary_selection, so guidance is only implied at the tool-selection level.

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 the full burden. It discloses a useful behavior beyond the schema: the four generated tags and their <prefix>_... naming convention. It does not say whether existing selections are overwritten, what permissions or model state are required, or that this mutates geometry state.

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 short paragraphs, front-loaded with the action and followed by the domain and tag naming. No filler sentences. Slightly under-specified rather than bloated, but structurally sound.

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 10-parameter geometry-mutation tool with no annotations, no output schema, and zero param documentation, the description covers only the output tag naming. Semantics of tolerance, entity_dimension, and model/geometry/component scoping are absent, so the agent cannot call it confidently.

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 all 10 parameters are undocumented in the schema. The description only illuminates the 'prefix' parameter (through the tag naming) and indirectly the bounding-box coordinates; tolerance, entity_dimension, model_name, geometry_name, and component_name get no explanation anywhere.

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 and resource ('Create named left, right, bottom, and top Box selections') and even enumerates the resulting tag names, which is unusually concrete. However, it never differentiates itself from the near-identical sibling geometry_create_box_selection, so the agent can't tell the two apart from the text alone.

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 names the intended domain ('rectangular 2D domains such as waveguides and water-wave tanks'), which is real usage context. But there is no when-not guidance and no mention of the alternative box-selection tool, leaving the agent to infer which sibling to pick.

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 discloses the return content ('boundaries with their numbers and areas') and frames the operation as a preparatory read, but says nothing about permissions, side effects, or whether it requires a built geometry. Adequate but incomplete for an un-annotated 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?

Front-loads the purpose, then adds usage, then Args/Returns sections. Efficient and well-organized, though the docstring-style Args/Returns blocks are slightly formulaic for a 3-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?

For a simple read-only geometry inspection tool with no output schema, the description covers purpose, usage context, parameter defaults, and the shape of the returned data. Nothing critical an agent needs to call it correctly 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?

With 0% schema description coverage, the description compensates by explaining all three parameters, including the non-obvious default semantics: geometry_name defaults to the first geometry and model_name defaults to the current model. This adds meaning the bare schema titles do not convey.

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 and resource: 'Get all boundaries from a geometry with their properties.' An agent can distinguish this from siblings like geometry_list or geometry_list_features without opening the schema. It stops short of explicitly contrasting those siblings, 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?

Gives a concrete when-to-use: 'Use this to identify which boundary numbers correspond to which faces before setting boundary conditions.' That is a clear sequencing/context hint that ties it to the physics boundary-condition setup tools. No when-not-to-use or named alternative is offered, so not a 5.

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?

Without annotations, the description must fully disclose behavior. It only states the basic import action and supported formats, but fails to mention whether the tool overwrites existing geometry, requires a current model, or how it handles errors (e.g., invalid file path). The return value is vaguely described as 'Import operation info', offering no concrete behavioral detail.

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 (4 lines excluding header) and front-loaded with the main action. The parameter list is readable but uses plain text without bullet formatting, which could be improved for clarity. Every sentence adds value, with no redundancy.

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, no output schema, and 4 parameters with 0% schema coverage, the description is incomplete. It lacks details on prerequisites (e.g., must a model exist?), error handling, and return value structure. The tool interacts with files and likely has side effects (e.g., modifying the current model), but these are not mentioned.

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 adds some value by labeling each parameter: file_path, geometry_name, import_type, model_name, and noting defaults (e.g., model_name defaults to 'current model'). However, it does not provide valid value examples for import_type (e.g., 'CAD', 'mesh') or clarify geometry_name's format, leaving gaps for the agent to infer.

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 'Import geometry from a CAD file' and lists supported formats, distinguishing it from sibling tools that create primitives (e.g., geometry_add_block) or manipulate geometry. The verb 'import' and resource 'geometry from a CAD file' are specific and 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 implies use when a CAD file is available and lists supported formats (STEP, IGES, STL, NASTRAN, etc.), providing usage context. However, it lacks explicit exclusions or comparisons to alternative geometry creation tools, such as geometry_create or geometry_add_*. This leaves the agent to infer when to import versus build from scratch.

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 burden. It specifies the return type (list of names) and implies a read operation, but does not disclose safety, side effects, or permissions. Adequate but 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 extremely concise with two sentences plus an Args/Returns block. Every sentence adds value, no wasted words.

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 output schema, the description adequately explains the return value. It covers the single parameter well. For a simple list tool, this is sufficient, though it could mention if the list is empty or behavior with invalid model names.

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 description adds meaning to the single parameter 'model_name' by stating it defaults to the current model (schema only shows anyOf string/null with default null). This clarifies the default behavior, compensating for 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 clearly states 'List all geometry sequences in a model,' using a specific verb and resource. It distinguishes from sibling tools like geometry_list_features (lists features within a sequence) and geometry_add_* (adds geometry).

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 usage (listing geometry sequences) but does not explicitly state when to use it versus alternatives or provide conditions for use. No guidance on when not to use 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?

No annotations are provided, and the description only says 'list', implying read-only but not explicitly. It lacks details about side effects or any behavioral traits.

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 with a clear purpose, Args, and Returns sections. Every sentence adds value without redundancy.

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 list tool, the description is fairly complete, specifying the return type (list of geometry features with types). Given no output schema, this is adequate, though it could elaborate on what constitutes a 'feature'.

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%, but the description adds meaningful parameter explanations: geometry_name defaults to first geometry, model_name defaults to current model. This goes beyond the schema's titles 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 clearly states the tool lists all features in a geometry sequence. It distinguishes from siblings like geometry_list (lists geometries) and geometry_add_feature (adds features).

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 on when to use this tool versus alternatives. The description does not mention prerequisites 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?

With no annotations, the description must carry the behavioral burden, and it does disclose one non-obvious side effect: a mesh sequence may be auto-created (auto_create defaults to True), plus it returns a generation status. It omits whether the operation is safe/idempotent, whether meshing is long-running or blocking, and what happens to existing sequences.

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?

Front-loaded one-line summary followed by a compact Args block and a return note; nothing is padded. The Args list largely restates schema keys, but each line adds a default or behavioral nuance, so it earns its space.

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?

Five parameters with zero schema coverage are all explained, and the return is at least named, so an agent can call this. Gaps remain: 'Mesh generation status' is never defined despite there being no output schema, blocking/latency behavior is unstated, and the relationship to mesh_create_sequence is unclear.

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, and it documents all five parameters with their default semantics (mesh_name defaults to all or 'mesh1' on creation, component_name defaults to the first component, model_name defaults to the current model). This meaningfully exceeds the schema, which supplies only titles and null 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 states a concrete verb and resource: 'Run one or all mesh sequences, creating a default sequence when needed.' That is clearer than the bare name mesh_create and conveys the both-broad-and-narrow scope. It does not, however, distinguish itself from the sibling mesh_create_sequence, leaving the agent to infer the difference.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named even though mesh_create_sequence and mesh_info sit right next to it. The defaults imply casual usage but the agent gets no routing signal for choosing this over its siblings.

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 provided, so the description carries full burden. It does not say whether this mutates the model, requires an existing built geometry, what happens if the geometry doesn't exist, or whether creation is idempotent. Only the defaults are noted, which the schema already contains.

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?

Front-loaded one-line summary followed by a compact Args/Returns block. Every line is functional, though 'Returns: Created mesh sequence info' is vague boilerplate.

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 4-param, no-annotation, no-output-schema creation tool, the description covers parameters and defaults but omits the crucial behavioral context: preconditions (geometry must exist), model-mutation effect, and what the return value actually contains. Adequate but with clear gaps.

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 explains each parameter's role and defaults, which is genuinely useful since the schema has no descriptions. However, it merely restates the schema's own defaults and does not clarify name-resolution behavior for the optional, nullable parameters.

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?

Clear specific verb (create) and resource (mesh sequence) bound to a geometry. Does not name siblings like mesh_create to distinguish when to use this over that tool.

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 on when to use this versus mesh_create or mesh_list, nor prerequisites (does a geometry need to be built first?). The 'bound to a geometry' phrase implies a precondition but does not state 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?

With no annotations, the description carries the full behavioral burden. 'Get' implies a read-only operation and the description discloses default fallback behavior for omitted arguments and the kinds of information returned, but it does not state permissions, side effects, or whether it can alter the current model/selection.

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 short and front-loaded with the core purpose, then cleanly separated into Args and Returns sections. There is no filler or redundancy.

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 read tool with no annotations and no output schema, the description covers parameter meanings, defaults, and return categories. It leaves some context implicit, such as how to obtain valid mesh/component/model names and how it relates to mesh_list, but remains adequate for 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?

Schema description coverage is 0%, so the prose Args block is the only source of parameter meaning. It documents all three parameters with their roles and defaults, though it does not specify the expected tag format or how to discover valid 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?

States a specific verb ('Get') and resource ('mesh information'), and mentions the stable Java tag, so the basic operation is understandable. It does not distinguish itself from sibling mesh_list or clarify what specific mesh information is returned beyond the general phrase, so it is not 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?

Provides only parameter defaults and no guidance on when to use this tool versus mesh_list or other mesh-related siblings. It does not state prerequisites, alternatives, or conditions under which this tool should be preferred.

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 behavioral burden. It discloses the return content (tags, components, usable labels), but says nothing about permissions, pagination, scope limits, or what happens when no mesh exists. For a list tool this is minimal but under-specified.

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?

Very tight and front-loaded: a one-line purpose followed by clean Args/Returns blocks. No wasted sentences, though the Returns block is arguably redundant given its 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?

No output schema or annotations exist, so the description must stand alone; it names the return fields but does not describe their structure. Adequate for a simple two-parameter read tool, but leaves behavioral and format gaps unaddressed.

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, and it does explain both parameters plus defaults ('default: all components', 'default: current model'). This adds meaning the bare schema lacks, though the default values slightly differ in spirit from the schema's null defaults and no format details are given.

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 and resource ('List mesh sequences') with the added scoping detail 'by stable COMSOL Java tag', which signals the identifier style. It is reasonably distinct from siblings like mesh_create_sequence and mesh_info, though it does not explicitly contrast with mesh_info, the other mesh read tool.

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 listing use but gives no explicit when-to-use guidance and no indication of when to prefer it over mesh_info or mesh_create_sequence. No prerequisites, context, or exclusions are 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?

No annotations are provided, and the description does not disclose side effects, prerequisites (e.g., model must exist), or whether the operation is safe. It only states the basic cloning action without behavioral context.

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 with a clear structure: purpose sentence, then Args list, then Returns. Every sentence provides necessary information without redundancy.

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 clone tool, the description covers parameters and return type. However, it lacks prerequisites (e.g., model must exist) and potential side effects (e.g., does it save to disk?), so completeness is adequate but not full.

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%, but the description adds meaning for all three parameters, explaining their purpose, defaults, and behavior (e.g., 'auto-generated if not provided'). This compensates well for the schema's lack of descriptions.

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 'Clone a model to create a copy for comparison or modification.' It uses a specific verb ('clone') and resource ('model'), and distinguishes from sibling tools like model_create or model_save_version by indicating a copy operation.

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 usage for creating a copy for comparison or modification, but does not explicitly state when not to use or mention alternatives. Some guidance is present, but lacks exclusions or context vs. other model 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?

No annotations are provided, so the description must bear the full burden of behavioral disclosure. However, it only states the action and arguments without detailing side effects, prerequisites, or resource impacts. For a tool that likely requires an active COMSOL connection, this omission is significant.

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 efficient: one main sentence then a compact list for arguments. Every element serves a purpose with no fluff.

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 the description covers the creation action and arguments, it omits prerequisite context (e.g., need for an active connection). The return value is vaguely described as 'Model info' without structure details, but that is acceptable for a simple create 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 Args section adds meaningful context beyond the schema, explaining the auto-generation of name and the default of set_current. Despite the schema having 0% property descriptions, the description compensates well.

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 explicitly states it creates a new empty COMSOL model, which is a specific verb+resource combination. This clearly distinguishes it from sibling tools like model_clone or model_load.

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 on when to use this tool versus alternatives like model_clone or model_load. Usage is only implied by the name and description, lacking when-not-to-use context.

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 behavioral burden; it discloses that components are containers for geometry/physics/materials/mesh and that creation is a prerequisite, which is useful semantic context. It is silent on failure modes (duplicate component name), whether the new component becomes current/active, and persistence, leaving meaningful gaps 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 Args/Returns layout is easy to scan and front-loaded, but the ordering constraint is stated twice — '(required before adding geometry/physics)' and then 'Must be created before adding geometry or physics' — so one sentence does not earn 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?

For a simple three-parameter creation tool with no output schema, the description covers purpose, precondition, and every parameter, and summarizes the return ('Created component info'). It is only mildly short of complete given the absence of any statement about duplicate-name behavior or error responses.

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, and it does: it documents all three parameters with defaults and, critically, decodes the non-obvious space_dimension integer codes (0/1/2/3/20/30 = 0D..3D axisymmetric) that the bare integer schema cannot convey.

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+resource ('Create a component in the model') and immediately scopes it with the precondition that it must precede geometry/physics. This distinguishes it from siblings like model_create, geometry_create, and model_list_components without opening any schema.

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?

Gives an explicit ordering rule ('Must be created before adding geometry or physics'), which is genuine when-to-use guidance for an agent sequencing a modeling workflow. It does not name an alternative tool or state when-not to use it, but the precondition covers the primary decision point.

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 provided; description does not disclose any behavioral traits such as read-only nature, prerequisites, or side effects. Minimal disclosure beyond the obvious knowledge retrieval purpose.

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?

Description is well-structured with a title, bullet list, and Args/Returns sections. It is concise and front-loaded, though the Args/Returns section is somewhat redundant.

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?

Missing output schema and description of return format (e.g., string, structure). Does not mention prerequisites like COMSOL connection or error cases. Adequate for a simple lookup but incomplete for a production 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?

Schema has 0% description coverage, but description explicitly lists allowed category values (geometry, mesh, physics, solver, results), compensating for the lack of enum. This adds significant meaning beyond the raw 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?

Description clearly states it gets best practices for different modeling categories, with a specific verb and resource. Lists five concrete categories, distinguishing it from sibling operational tools like geometry_add_block or physics_add.

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 on when to use this tool versus alternatives like docs_get or troubleshoot. The description only lists categories but does not provide context for decision-making.

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 must disclose all behavioral traits. It mentions what is returned (parameters, physics, studies) but does not state that the tool is read-only or safe to call without side effects. This omission is a gap for a tool that likely does not modify state.

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, uses a standard docstring format with Args and Returns, and front-loads the core purpose. Every sentence contributes value with no wasted words.

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's simplicity (1 optional parameter) and no output schema, the description provides sufficient context about input and return values. It covers the essential behavioral aspects, though it could explicitly state the read-only nature.

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%, but the description adds meaning by stating the default value ('current model') and explaining the parameter's role ('Name of the model to inspect'). This compensates well for the lack of schema detail.

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 the tool's purpose with a specific verb ('Get') and resource ('detailed information about a model's structure and contents'), which distinguishes it from sibling tools like model_create, model_list, or model_load.

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 usage for inspection tasks but lacks explicit guidance on when to use this tool versus alternatives (e.g., model_list for listing models, physics_list for physics info). No 'when not to use' or alternative names are 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?

No annotations are provided, so the description must cover behavioral aspects. It mentions the return type (list of models with names, file paths, status), which is helpful, but does not disclose any side effects, authorization needs, or limitations. For a simple read-only list, this is acceptable but not fully transparent.

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: a single sentence stating the purpose followed by a clear list of return fields. No wasted words.

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 parameterless listing tool with no output schema, the description adequately covers the behavior and return values. It is fully sufficient for an agent to understand and invoke the tool correctly.

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 input schema covers 100% with no additional information needed. The description adds no parameter details, which is appropriate. Baseline is 3 per rubric due to high schema 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 clearly states 'List all models currently loaded in the COMSOL session,' specifying a concrete action and resource. This distinguishes it from siblings like model_create or model_load, which perform different operations.

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 this tool versus alternatives (e.g., model_inspect for details, model_list_components for components). It lacks context on prerequisites or scenarios where it's 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?

With no annotations, the description fully discloses the tool's behavior: it lists components and returns their names. No side effects or hidden behaviors are relevant for a read-only list 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 extremely concise with two sentences for purpose and one line each for args and returns, containing no extraneous 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?

Given the tool's simplicity, the description adequately covers what it does and what it returns. It lacks error handling or format details, but for a straightforward list operation this is sufficient.

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 description adds value to the schema by explaining that model_name refers to the model to query and defaults to the current model. This clarifies usage beyond the schema's type information.

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 'List all components in a model' with specific verb and resource, and it is distinct from sibling tools which focus on other aspects like creating, cloning, or inspecting models.

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 does not mention when to use this tool versus alternatives, nor does it provide context for selection. Usage is implied but not explicitly guided.

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 provides basic behavioral info: it loads a file and returns model info including name, path, version, or error. However, it does not disclose failure modes (e.g., file not found, invalid format) or side effects (e.g., overriding current model).

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, with 4 lines total. The key purpose comes first ('Load a COMSOL model from a .mph file'), followed by structured argument details and return info. No redundant or irrelevant sentences.

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 simple nature of the tool (2 parameters, no output schema), the description covers the main operation, arguments, and return format. Minor gaps include error handling and dependencies (e.g., requires COMSOL connection), but overall it is sufficient for selection and 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?

Schema coverage is 0%, so the description compensates by explaining file_path as 'Absolute or relative path to the .mph model file' and set_current as 'Whether to set this as the current active model (default: True)'. This adds meaningful context beyond the schema's type and 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 clearly states 'Load a COMSOL model from a .mph file' with a specific verb and resource. It distinguishes from sibling tools like model_create (new) and model_clone (clone existing) by focusing on loading an existing 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?

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites like needing a running COMSOL session or connected instance, nor does it advise against use in certain scenarios.

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 provided, so description should disclose behavioral traits. It only says 'remove from memory' but does not specify side effects, whether unsaved data is lost, or if removal is reversible.

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?

Description is short and front-loaded with purpose. However, the Args/Returns section is boilerplate and could be more informative. It earns its place but lacks depth.

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 output schema and no annotations, the description is too minimal. It does not explain return values, error conditions, or prerequisites for successful removal.

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%, so description must compensate. It adds a single line for model_name ('Name of the model to remove'), which adds little beyond the schema title. No details on format, lookup, or constraints.

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?

Description clearly states the action: remove a model from memory. It distinguishes from sibling tools like model_create, model_load, etc., which have different purposes.

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 on when to use this tool versus alternatives or prerequisites. The description does not mention when removal is appropriate, e.g., after saving or when model is no longer needed.

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 must carry the full burden. It does not disclose potential side effects such as overwriting existing files, state changes, or permission requirements. The return value is vaguely described as 'Save confirmation with file path, or error message'.

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 with a clear header, bullet-pointed parameters, and a returns section. Every sentence provides necessary information without redundancy.

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 covers basic usage and return format but misses context such as prerequisites (e.g., model must be loaded), error conditions in detail, and behavior when file_path is omitted. Given the simple tool, it is minimally adequate.

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 adds significant value by explaining each parameter's purpose and default value. It enumerates valid format options, which the schema lacks.

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 the action ('Save') and the resource ('a COMSOL model to file'), distinguishing it from sibling tools like model_load or model_save_version effectively.

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., model_save_version). The description does not specify prerequisites or conditions for use.

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 provided, so description fully discloses behavior: creates timestamped file and a 'latest' copy, stores optional description in metadata. No contradictions.

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?

Well-structured: summary, path details, usage, arguments, returns. No fluff, every sentence adds value.

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?

Comprehensive for a versioned save tool: explains what it does, its parameters, and return value. No missing details.

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 coverage, description adds meaning: explains 'model_name' defaults to current model, 'description' is optional and stored in metadata. Could mention acceptable formats but suffices.

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?

Clearly states 'Save a model with a timestamp version suffix', indicating a specific verb and resource. Distinguishes from sibling 'model_save' by emphasizing versioning and file path structure.

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?

Implies usage for version control and design iterations, and contrasts with 'model_save' (sibling) which likely does simple saving without versioning. However, lacks explicit when-not-to-use guidance.

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 must carry the full burden. It states it sets the current active model but does not disclose side effects, whether the operation is destructive, error handling for non-existent models, or state changes. The Returns section mentions 'confirmation or error message' but lacks detail.

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 with a main sentence and structured Args/Returns sections. It avoids unnecessary words, though it could be more informative without sacrificing 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?

Given the lack of output schema and annotations, the description is minimally adequate for a simple setter. However, it omits key contextual details like when to use it, prerequisites, and error handling, making it incomplete for an agent to reliably invoke without additional 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 adds meaning by stating 'Name of the model to set as current' for the model_name parameter. However, it does not specify if it's a name, ID, or any constraints like case sensitivity or existence. The baseline is higher due to low coverage, but the description only partially compensates.

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 the verb 'Set' and the resource 'current active model', and explains the purpose 'for subsequent operations'. It distinguishes this tool from sibling tools like model_list, model_create, etc., which have different actions.

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 this tool versus alternatives. It does not mention prerequisites (e.g., model must exist) or when not to use it. No comparison to sibling tools is 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 provided, so description has full burden. It discloses the action (adds coupling) and return type but omits side effects, error behavior, or what happens if coupling already 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?

Description is short, front-loaded with purpose, and well-structured with Args/Returns sections. No redundant sentences; every sentence adds value.

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?

Adequately covers parameters and purpose but is incomplete on return value details ('Created coupling info' is vague) and parameter relationships (e.g., coupling_type implies required physics). Given no output schema, more detail is expected.

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%, but the description lists all three parameters with examples for coupling_type, adding significant meaning beyond the schema. However, it lacks constraints on physics_list (e.g., required number of interfaces) and model_name format.

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?

Clearly states the verb 'Add a multiphysics coupling between physics interfaces,' identifies the resource (multiphysics coupling), and lists common coupling types, distinguishing it from sibling tools that add single physics interfaces.

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?

Provides examples of coupling types and their combinations, hinting at usage context, but does not explicitly state when to use this tool versus alternatives like physics_add_* or any 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?

No annotations are provided, so the description carries full burden. It discloses that the tool can get or set based on the 'text' parameter and returns either description or confirmation, but lacks detail on side effects (e.g., overwriting) or confirmation format.

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 with a clear top-level statement, structured Args, and Returns. Every sentence adds value, and there is no unnecessary text.

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 get/set tool, the description covers the main purpose and parameters. The return value is stated ('Parameter description, or confirmation of update'), though more specific format details could improve completeness. Given no output schema, this is adequate.

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%, but the description clearly explains each parameter: 'name' (parameter name), 'text' (new description, returns current if None), and 'model_name' (model name, default current). This adds meaning 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 'Get or set the description of a parameter,' specifying the action (get/set) and the resource (parameter description). It distinguishes from sibling tools like param_get and param_set, which deal with parameter values.

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 usage for getting or setting parameter descriptions but lacks explicit guidance on when to use this tool versus alternatives like param_get or param_set. No exclusions or alternative references are 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?

Without annotations, the description carries the full burden. It transparently states it returns a value/description or error, and explains the evaluate parameter's effect. No side effects are mentioned, but for a getter this is sufficient.

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, front-loads the purpose, and uses clear docstring format. No redundant sentences, but could be slightly more streamlined.

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?

No output schema exists, so description should detail return format. It states 'Parameter value and description, or error message' but lacks specifics on structure. Prerequisites (model exist) not mentioned, but adequate for a simple getter.

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 description adds meaning beyond the schema by explaining each parameter's purpose (name, model_name with default, evaluate toggle between numeric and string). Schema coverage is low (0%) but description compensates well.

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 the action 'Get the value of a model parameter' and distinguishes it from siblings like param_list (list all) and param_description (description only) by focusing on value retrieval.

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 when to use via parameter explanations but does not explicitly state when to use param_get versus alternatives like param_list or param_description. No when-not or alternative guidance 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?

No annotations provided. Description declares return type but lacks disclosure on side effects, permissions, or safety. 'List' implies read-only but is not explicit.

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?

Very concise: one-line summary, Args/Returns section. No redundant information. Well-structured for quick parsing.

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?

Explains parameters and return value sufficiently for a simple list tool. Lacks context on usage relative to siblings, but overall adequate.

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?

Description adds meaning beyond the schema, explaining 'model_name' default and 'evaluate' behavior. Schema coverage 0% so description carries full parameter explanation burden.

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?

Clearly states 'List all parameters in a model' with specific verb and resource. Distinguishes from parameter-specific tools (param_get, param_set) but does not explicitly differentiate.

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 on when to use this tool versus alternatives like param_get or param_description. Does not provide 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?

No annotations are provided, so the description carries the full burden. It mentions return value (confirmation or error) and the ability to include units in the value. However, it does not specify whether the parameter is created if it doesn't exist, or any 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?

The description is highly concise, using a single introductory sentence followed by structured parameter and returns sections. Every sentence adds value, with no redundancy.

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 set operation with 4 parameters and no output schema, the description covers the basics but lacks details on error handling, behavior for non-existent parameters, and any prerequisites. It is adequate but not exhaustive.

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 adds significant meaning: it explains each parameter's purpose, including the units format for value and the default for model_name. This compensates for the sparse 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 the verb 'Set' and the resource 'model parameter', making the tool's function unambiguous. It distinguishes from sibling tools like param_get or param_list by its action.

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 does not provide explicit guidance on when to use this tool versus alternatives. While the context implies it's for setting parameters, it lacks any 'when to use' or 'when not to use' direction.

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. It mentions return values (configuration or error) but does not disclose side effects, required permissions, or whether it modifies existing state. Critical details about behavior are missing.

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 reasonably concise but includes unnecessary sections like 'Args:' and 'Returns:' that add no value. The core information is dense but could be more streamlined without the docstring format.

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 output schema and the complexity of a parametric sweep, the description fails to explain prerequisites, error conditions, or the overall process. It lacks crucial context for correct 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?

Schema coverage is 0%, so the description adds some meaning beyond the schema by noting defaults (e.g., 'model_name: Model name (default: current model)'). However, explanations for 'values' and 'study_name' are minimal, not fully compensating for the lack of schema descriptions.

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 it sets up a parametric sweep for a parameter, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like param_set or param_list, which could cause ambiguity.

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. The description lacks context for prerequisites (e.g., model/study must exist) 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 provided. Description notes it returns a list of module names with file counts, implying a read-only operation, but does not mention any other behavioral traits such as permissions, side effects, or limitations.

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 clear sentences with no unnecessary words. Front-loaded with verb and resource, then details return value.

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 no output schema, the description adequately explains the return value (list of module names with file counts). It is minimally complete for a simple listing 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?

Tool has no parameters; schema coverage is 100% (vacuous). Baseline score of 4 applies as description adds no parameter information beyond what is already captured.

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?

Description clearly states verb 'list' and resource 'COMSOL documentation modules'. It is specific but does not distinguish from sibling tools like 'docs_list' which might serve a similar purpose.

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 on when to use this tool vs alternatives. Sibling tools include 'docs_list', 'docs_get', and 'pdf_search' which could be used for related purposes, but no comparison 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?

Describes it as a semantic search returning snippets. No annotations provided, so description carries full burden. Does not disclose potential side effects, rate limits, or specific behavioral traits beyond the basic read 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?

Concise and well-structured: brief intro, then clear Args and Returns sections. No redundant information. Front-loaded with 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?

Covers purpose, all parameters with defaults and examples, and return type. Missing details on return format/structure, but acceptable for a search tool given no output schema. Siblings provide related 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?

Despite 0% schema coverage, the description adds useful context for all parameters: query (search query description), n_results (default and max), module (example values). Enhances understanding beyond 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?

Clearly states it searches COMSOL PDF documentation using semantic search. Specifies scope (60+ modules) and purpose (find info on physics, modeling, API usage). Distinguishes from sibling tools like docs_get and pdf_list_modules.

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?

Implied usage for searching documentation by query and optional module filter. No explicit guidance on when to use this vs alternatives like docs_get or pdf_list_modules. Lacks when-not or context-specific recommendations.

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?

Discloses return values including status info, indexed documents, and available modules. No annotations provided, so description carries the burden, which it does adequately.

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 concise sentences with no wasted words. Efficiently communicates purpose and return 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?

No output schema, but description covers the key return elements. Adequate for a simple status tool, though could mention response format.

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?

No parameters; baseline score of 4. Description adds context about return values that complements 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 the tool gets the status of the PDF documentation search system, distinguishing it from sibling tools like pdf_search and pdf_list_modules.

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 on when to use this tool vs alternatives like pdf_search or pdf_list_modules. The usage context is implied but not explicit.

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 full burden. It does not disclose that adding physics modifies the model, whether a model must be loaded, or any side effects. For a mutation tool, this is insufficient.

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?

Well-organized with header, common types list, and parameter descriptions. The list of types is helpful but slightly verbose; otherwise 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?

Adequately covers the main purpose and parameters, but lacks context about model prerequisites, return value details, and mutability. For a tool with no output schema and no annotations, more context is needed.

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 coverage, the description adds meaning beyond the schema: explains physics_type with examples and defaults for component_name and model_name. However, it could be more detailed (e.g., valid values for component_name).

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?

Clearly states 'Add a physics interface to the model' and lists common physics types with examples, distinguishing it from sibling tools that add specific physics 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?

Provides common physics types and aliases but does not explicitly guide when to use this generic version versus specific sibling tools like physics_add_electrostatics. No when-not-to-use or alternatives mentioned.

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 burden. It discloses default behavior for every argument (tag generated from type, all domains, first component/geometry/current model), which is genuinely useful. It does not describe side effects on the model, error behavior for unrecognized physics types, or what the returned 'Created physics info' contains beyond a generic phrase.

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?

Front-loads the action in one sentence with no waste, then adds the version-specific hint and a clean Args/Returns block. Given zero schema coverage, the enumerated parameters are earning their place rather than padding.

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 six-parameter mutation tool with no annotations and no output schema, the description covers the callable inputs and defaults thoroughly and notes a return value exists. The main gap is that the 'Created physics info' return and the consequences on the model are not elaborated, but nothing essential to correct invocation 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?

Schema description coverage is 0%, so the description must compensate, and the Args block documents all six parameters including defaults and the meaning of domain_selection ('Domain numbers'). It adds real meaning beyond bare property names, though it doesn't specify formats expected for tags or 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?

States a specific verb and resource ('Add a geometry-based Acoustics Module physics interface') and clarifies its distinguishing scope: it accepts any COMSSOL acoustic physics type rather than a fixed list, unlike the narrower sibling physics_add_pressure_acoustics. It is clear what the tool does, though it doesn't explicitly contrast itself with that sibling.

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 gives context on how to pick a value ('Use the exact COMSOL physics type for the installed version', with confirmed 6.3 examples), which implies usage. However it never states when to prefer this generic tool over physics_add_pressure_acoustics or physics_add_laminar_flow, nor any prerequisites or when-not-to-use conditions.

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 must carry the full behavioral burden. It mentions that properties can be scalar/vector/matrix and that rejected properties are returned, which is some useful detail, but it does not disclose permission requirements, side effects, or what happens on invalid input beyond the rejection notice.

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 short and front-loaded with the core action. The second and third sentences add relevant detail without excessive verbosity, though they could be more tightly integrated.

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 6-parameter tool with no annotations and no output schema, the description is incomplete. It does not explain parameter semantics, usage context, or return behavior, leaving significant gaps for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.