Skip to main content
Glama

Geoniks — Wooden House Design

Ask wooden house manufacturers for quotes

request_manufacturer_quotes

Sends a design to the Geoniks team, who forward it with the person's contact details to timber-house manufacturers that build in their country, so they receive real price offers by email. Requires the person's own email address and country and their explicit agreement that Geoniks may share their design and contact details with manufacturers (consent_to_share = true); without it nothing is sent.

Input Schema

NameRequiredDescriptionDefault
nameNoTheir name (optional).
emailNoThe person's email address, as they gave it. Not needed when signed in with Geoniks (taken from the account).
notesNoWishes: budget, timing, plot, wood type, anything the manufacturer should know.
phoneNoPhone number with country code (optional; manufacturers often reply by phone).
startNoWhen they want to build, if the person said.
budgetNoBudget range, if the person said.
area_m2NoFloor area in m², if there is no design_id.
countryNoCountry where they want to build. When signed in, the account's country is used if this is left out.
includesNoWhat the price should cover, if the person said (kit only … turnkey).
design_idNoId of a Geoniks design to send with the request.
user_requestNoWhat the person asked for, in one short sentence in their own words (no contact details).
consent_to_shareYestrue only if the person agreed that Geoniks shares their design and contact details with manufacturers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / budget
      Added value: +{
      +  "description": "Budget range, if the person said.",
      +  "enum": [
      +    "Under €100,000",
      +    "€100,000 – 200,000",
      +    "€200,000 – 400,000",
      +    "Over €400,000",
      +    "Not sure yet"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / includes
      Added value: +{
      +  "description": "What the price should cover, if the person said (kit only … turnkey).",
      +  "enum": [
      +    "House kit only (walls, floors, roof structure)",
      +    "Kit + windows, doors and roofing",
      +    "Weather-tight shell, assembled",
      +    "Turnkey (ready to move in)",
      +    "Not sure yet"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / start
      Added value: +{
      +  "description": "When they want to build, if the person said.",
      +  "enum": [
      +    "Within 6 months",
      +    "In 6–12 months",
      +    "In 1–2 years",
      +    "Just researching"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources