Structomat

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds a hint about content shape ('what comes back') but says nothing about whether the response is static documentation, whether it can vary, or how large it is. Adequate but not additive.

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, front-loaded with the subject and its domain, then a compressed topic list that doubles as a table of contents. Nothing is repeated from the title and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only documentation tool with no output schema, the description covers what the agent needs to decide to call it. The one gap is that it does not characterize the returned content's form (prose doc, structured facts), which matters slightly since no output schema exists.

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 takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is required by framing the call as a pure information lookup.

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 the resource precisely ('Facts about Structomat, an AI engineering agent for structural steel') and enumerates the exact topics covered: capabilities, design codes, signing responsibility, inputs, outputs, and getting started. That enumeration makes it obviously distinct from the engineering siblings like analyze_frame and estimate_portal_frame_steel, which compute rather than explain.

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?

'Use when the user asks about Structomat or how to engage it' gives a clear trigger condition. It stops short of naming the adjacent alternatives — 'what to send' and 'how to start' overlap with draft_project_request, and the description never says to switch to that tool once the user is ready to actually submit work.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real context: it is elastic-only, not a code check, solved by an external page whose result includes a 3D link, and 'Nothing is stored.' These are behavioral facts the annotations cannot express.

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?

It is a single dense paragraph, but front-loaded with the payoff (what numbers come back) before the modeling detail and exclusions. Every sentence carries information; it could be broken into bullets for readability but is not padded.

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 30-parameter tool with a nested model object and no output schema, enumerating the return contents (equilibrium check, deflections, reactions, member forces/envelope, modal periods) is exactly what the description must supply, and it does so thoroughly, including limits and model formats.

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 30 parameters at 100% schema description coverage, the schema does the heavy lifting and baseline is 3. The description reinforces the two modeling modes (template vs full JSON) and the envelope/governing-combination behavior, but this largely restates structured information rather than adding new per-parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Runs a 3D finite-element frame analysis') and then enumerates exactly what comes back, so an agent knows precisely what this tool produces. It is clearly distinct from sibling tools like estimate_portal_frame_steel, since it returns numbers rather than an estimate.

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 explicit positive guidance ('check a frame, compare sections or see how loads flow, and run it again with changed sections or loads') and explicit exclusions ('Elastic analysis only, not a code check: member buckling, connection design and code load combinations are not covered'). The only gap is that it never names a sibling to route to when the agent actually wants a code check or a quick estimate.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the bar is lower, yet the description still adds the decisive reassurance ('sends nothing and stores nothing') and, critically, discloses the return shape ('draft text and a mailto link') where no output schema exists. It also pins the fixed recipient address, which is behavior an agent could not infer from the schema.

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, no filler. The core action and audience come first, and the non-mutating guarantee plus return format follow as the one fact that most affects the agent's decision. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Five parameters with only one required, full schema coverage, and no output schema, so the description's job is to explain what comes back and whether side effects occur — both are covered explicitly. Nothing an agent needs in order to call this 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?

Schema description coverage is 100% and each of the five properties carries its own description with examples, so the schema does the heavy lifting. The description only says the e-mail describes 'a project', adding no format, length or content guidance for `need` or the optional fields. Baseline 3 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?

States a specific verb and artifact ('prepare an e-mail'), names the recipient (Structomat, info@structomat.com) and the output ('ready for the user to review and send'). This is unmistakably different from the analysis siblings (analyze_frame, estimate_portal_frame_steel, get_connection), which compute rather than compose outreach.

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 makes the intended scenario clear: the user wants to describe a project to Structomat and needs a reviewable draft. It also sets a boundary on behavior ('sends nothing and stores nothing'), which tells the agent this is a safe pre-send step. It does not explicitly say when to prefer this over, say, list_services or about_structomat, so no exclusion guidance is offered.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add method and limits — and it does: results are interpolated between complete finite-element designs and calibrated against published designs, and it is a pre-design estimate. That is real behavioral context an agent could not infer from the annotations. It stops short of stating accuracy bands or how the range is derived.

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, front-loaded with purpose and scope, then outputs, then method, then usage caveat. No filler and nothing buried.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly — it lists every component of the result including the per-part breakdown and typical member sizes. Combined with the fully documented input schema and read-only annotations, an agent has everything needed to call and interpret it.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including ranges, units and the roof-load relation (0.8 sk), so the schema already does the parameter work. The description only repeats the span range and adds no syntax or default guidance (e.g. when to choose rod vs tube bracing) beyond what the enum already conveys.

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 — steel tonnage estimate for a single-span pitched portal frame, span 15-30 m — and enumerates exactly what is returned (total tonnes, kg/m2, range, weight by part, member sizes). The only gap is that it does not distinguish itself from the sibling analyze_frame, which an agent might reasonably consider for a frame-related task.

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 says to use it for budgets, tenders and feasibility, and explicitly says when not to rely on it: 'a real design needs the actual loads and code.' That is a clear when/when-not framing, though it never names an alternative tool for the design case.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no repeating. The description adds genuinely new information beyond them: the return shape ('titles, links and short summaries'), which matters because there is no output schema.

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, but the body is one very long sentence whose enumerated list maps nearly 1:1 to the schema enum (project, case_study, connection, benchmark, sample, tool), so much of it repeats structured data. The parenthetical examples are the only part that earns its 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 zero-required-parameter search tool with no output schema, the description supplies the searchable domain, the result format, and sample query targets — enough to invoke correctly. It lacks only routing guidance against sibling tools that touch adjacent content.

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 100% — all three parameters, including the seven-value enum, are documented in the schema. The description's examples ('point cloud', 'shop drawing submittal') loosely illustrate query phrasing but add no constraint, format, or interaction detail beyond the schema. Baseline 3 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?

Specific verb ('Search') plus a well-defined resource ('Structomat's published work') with the content corpus enumerated. An agent can immediately tell this is a discovery/lookup tool and distinguish it from siblings like get_connection or list_services.

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 makes clear what corpus is searchable and gives concrete example targets ('canopy', 'base plate', point cloud), which implies when to reach for it. It does not, however, name an alternative or state when NOT to use it — relevant since get_connection and list_services could overlap on 'checked steel connections' and 'free 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world access, so the safety profile is covered. The description adds real value beyond them by describing the payload contents, though it says nothing about failure behavior for an unknown slug or any limits.

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, zero waste: the payload summary is front-loaded and the prerequisite follows. Every clause carries information an agent needs.

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 one required parameter, no output schema, and annotations covering safety, the description is nearly complete — it even compensates for the missing output schema by listing returned fields. Only the behavior on a missing/invalid slug is left unstated.

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 100% and the single slug parameter is fully documented, so baseline would be 3. The description adds the specific acquisition path (find_examples with type "connection"), which tells the agent where a valid slug comes from without opening the sibling tool.

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 resource and scope: 'Details of one connection from the Structomat steel connection library', then enumerates what is returned (members, plates, bolts, welds, design code, utilisation). An agent can immediately distinguish this single-record lookup from the broader sibling tools such as analyze_frame or find_examples.

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 routes the agent to find_examples with type "connection" as the way to obtain the required slug, which is clear prerequisite guidance. It stops short of stating when-not to use it or naming an alternative for retrieving connection data, so it falls just short of full when/when-not coverage.

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?

Annotations already declare this as a read-only, idempotent, closed-world lookup, so safety is covered. The description adds that each entry includes both the client-provided inputs and the resulting outputs, which is genuine content beyond the annotations, but says nothing about ordering, count, or whether descriptions are exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, and the catalog enumeration comes first. The nested parentheticals make it slightly dense to parse but nothing is wasted.

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 carries the burden of explaining returns; 'what the client sends and what comes back' is directionally correct but imprecise about the actual shape of each entry. For a zero-required-parameter catalog tool this is adequate but leaves the agent guessing at the response structure.

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 100% and the enum is fully documented, so the schema does the heavy lifting. The description's parenthetical list enumerates the same six service values in prose, giving a human-readable gloss on each enum label (e.g. 'erectability check of a steel model before erection'), which is a modest value-add but not a baseline shift.

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 the exact resource (the six Structomat service lines) and what each record carries (client inputs and returned deliverables), so the agent knows this is a service catalog rather than a computation tool. It lacks an explicit verb ('list') and never contrasts itself with sibling about_structomat, which is also an informational 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 statement of when to call this versus about_structomat, draft_project_request, or find_examples, and no guidance on filtering by the optional `service` argument. The agent must infer usage 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.