Geoniks — Wooden House Design

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

The annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context: Geoniks builds walls, doors, windows, floor and roof, automatically adds missing openings, and returns a 3D view link plus a PDF and edit link. It does not cover persistence, link expiry, or authentication needs, which keeps it from a 5.

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 long but front-loaded and well structured: purpose and outputs come first, followed by a bulleted input-format section. Every sentence earns its place by specifying geometry conventions, opening rules, or limitations needed to build a valid model.

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 complex geometry-to-3D tool with no output schema, the description is largely complete: it explains the input format, automatic additions, single-storey limitation, manual fallback, and return artifacts. It could say more about error handling or how long returned links remain valid, but an agent has enough to call it 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?

Although schema description coverage is 67%, the description adds substantial meaning beyond the schema: units in metres, origin at the top-left with x right and y down, rooms as rectangles with shared exact edges for touching rooms, splitting L-shaped rooms, and opening conventions including side and position. These rules are essential for correct invocation and are not fully captured by the structured parameter 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 states a specific verb and resource: it builds a 3D wooden house from the rooms of a person's own floor plan, including photo, sketch, PDF page, or drawing. By specifying that the source is the user's own floor plan, it clearly differentiates the tool from a generic house-design 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 explicit usage boundaries: single storey only, and unclear drawings should be handled by the Geoniks manual service at a named URL. It does not explicitly route the agent to sibling tools such as design_wooden_house, so it falls just short of full when-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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description adds real behavior beyond them: the result is link-based, the 3D view needs no sign-in, and the edit link copies the design into the person's own account (a side effect worth knowing). It also discloses that bedrooms are reduced automatically if they do not fit and that country triggers a price estimate.

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 with the effect and returned artifacts, then input modes, then layout behavior, then the usage cue. Dense but every sentence carries information; the internal layout sentence is the closest to optional detail.

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 nine optional parameters, no output schema, and open-world behavior, the description does the work of describing the return artifacts (3D link, PDF, edit link, optional price estimate) and how the model is generated. Only the relationship to the competing design_from_floor_plan and dedicated pricing tool is left unresolved.

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%, so the baseline is 3; the description confirms the template_id/size-field precedence and points to the ready-made plan list as the id source, but adds little else about individual parameters. The remaining descriptive value is about the generated layout rather than 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?

States a specific verb and resource ('Creates a single-storey wooden house as a 3D model on Geoniks') and enumerates the concrete outputs: an interactive 3D view, a dimensioned floor plan/elevations PDF, and an edit-in-Geoniks link. It also distinguishes input modes (describe the house vs. start from template_id), which separates it from list_wooden_house_plans and the price 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?

Gives an explicit usage trigger ('Offer it when someone is planning or pricing a wooden house') plus suggested phrasing, and explains the template_id path with a pointer to where ids come from. It does not, however, say when to prefer this over the sibling design_from_floor_plan, nor when pricing should go to estimate_wooden_house_price instead of the country-based estimate 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the numbers are estimates derived from regional cost data and are explicitly non-binding, which is exactly the caveat an agent needs to relay. It stops short of describing the return shape (e.g. whether a low/high range and currency are included), leaving one gap.

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 with the core purpose in the first clause, then usage and caveats. The middle sentence is long and clause-heavy with semicolons, but every element (triggers, follow-up siblings, non-binding caveat) carries information the agent needs, so nothing is truly 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 does the work of framing the result as a 'turnkey price range' and warning it is non-binding, which is adequate for a six-parameter read-only estimator. The only shortfall is that it doesn't clarify what the returned estimate contains (range bounds, currency handling, breakdown), which an agent quoting numbers to a user would benefit from.

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%, so area_m2, country, wood, floors, currency and user_request are all documented in the schema with defaults and ranges. The description gestures at the key inputs (floor area, country, wood type) but adds no syntax, unit or constraint detail beyond what the schema already provides, so the 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 resource (estimates the turnkey price range of a wooden house) plus the exact inputs driving it (floor area, country, wood type) and the data source (Geoniks' regional timber construction costs). An agent can immediately distinguish this from design_wooden_house or request_manufacturer_quotes.

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 explicit trigger conditions ('whenever someone asks how much a wooden, log, timber frame or CLT house costs... wants a budget or cost estimate') and names the natural follow-up siblings (design_wooden_house for drawing, manufacturer quotes for real offers). It also sets the boundary — 'An estimate only — binding prices come from manufacturers' — so the agent knows when to escalate instead of relying on this tool.

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=true and openWorldHint=false, so the safety profile is covered and the description is consistent with it. The description adds genuine value beyond the annotations by describing what each returned item contains (template_id, 3D view, PDF drawings, editable copy). It does not mention pagination or result-size limits, which is a minor gap for a listing 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?

Two tight sentences with no filler. The resource and its scope are front-loaded, and the second sentence delivers the only non-obvious detail (template_id linkage and per-plan artifacts).

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 listing tool with full schema coverage, annotations, and confirmed no output schema, the description is nearly complete: it explains what is listed and what each item provides. What is missing is minor — result volume/pagination behavior and how the optional user_request affects output.

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?

There is a single optional parameter and the schema description coverage is 100%, so the schema fully documents user_request. The description adds no meaning about how that free-text request influences filtering or ranking, so the baseline of 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?

The description gives a specific verb and resource ("Lists the ready-made wooden house plans on Geoniks") and enumerates the catalog content (cabins, cottages, family houses) plus returned attributes (size, floors, rooms). It implicitly separates itself from creation-oriented siblings like design_wooden_house and design_from_floor_plan, but never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is only implied: the mention that each plan carries a template_id for starting a design hints that this is a discovery step before design_wooden_house or design_from_floor_plan. There is no explicit when-to-use, when-not-to-use, or alternative routing statement, so the agent must infer the workflow.

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?

Goes well beyond the annotations: it discloses that data leaves the system to an internal team and then to third-party manufacturers, that the person's contact details and design are shared, and that a human consent flag gates the whole operation. The annotations only say openWorldHint=true and destructiveHint=false; the description supplies the privacy/consent behavior that actually matters here.

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 dense sentences, front-loaded with the action and outcome, then the consent gate. Nothing is wasted and no filler.

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

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

For an outward-facing action involving personal data, the description covers the data flow, consent requirement, and expected outcome (offers arrive by email). It stops short of saying what the tool returns immediately on success or how failures/duplicate requests are handled, which matters slightly for a non-idempotent send.

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%, so the field meanings are already documented; the description largely restates them (email, country, consent). It adds only the account-context nuance, which the schema itself already states, so 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 chain and resource: sends a design to the Geoniks team, who forward it to timber-house manufacturers in the person's country, who reply with real price offers by email. That is clearly distinct from siblings like estimate_wooden_house_price (an automated estimate) and design_wooden_house.

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?

Explicit prerequisites: the person's own email, their country, and explicit consent, plus the hard rule that without consent_to_share = true nothing is sent. It does not, however, name sibling alternatives (e.g. use estimate_wooden_house_price when the user only wants a ballpark figure rather than contact with manufacturers).

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true), it discloses the real side effects: an account is created for the email, a sign-in link is sent, the request goes to the Geoniks team, and contact details may be forwarded to manufacturers only with consent_to_share. That is exactly the external-impact context an agent needs before committing.

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?

One front-loaded paragraph that opens with the call-timing instruction and then covers side effects and consent. It is dense and slightly run-on, but every clause carries information; a small restructuring into sentences would improve it.

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 14-parameter, non-read-only tool with no output schema, the description covers purpose, timing, side effects, consent gating, and briefly what is returned ('the next step for the chosen path'). Only the shape of that returned next step is left unspecified, which is a minor gap.

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

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

Schema description coverage is 100%, so all 14 parameters are already documented, including the consent flags and need enum. The description only lightly reinforces semantics ('their own email', country of build, consent_to_contact = true), adding little that the schema does not already say, so 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?

Uses concrete verbs and resources: saves the person's request, opens a free Geoniks account, and returns the next step for the chosen path. It also names the three path varieties (existing drawing, design from scratch, manufacturer prices), which separates it from siblings like request_manufacturer_quotes and design_wooden_house.

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 explicit timing ('call this early in the conversation') and a precondition ('once the person has said what they want and agreed to leave their contact details'). It also states when consent_to_share may be set true. It stops short of stating when not to call (e.g. if the person declines consent), so no explicit exclusion.

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