Skip to main content
Glama
Sign In

Sienna, Knobs.co hardware advisor

by co.knobs
OverviewDiscussionsAdmin

Build a Hardware Plan (Knobs.co)

build_plan

Build the shopper's whole-kitchen (or bath) Hardware Plan: one line per zone (doors, drawers by width, island, tall, appliance panels) with the exact Knobs.co product, finish, size, count and list price, totals, the pieces that qualify as samples, and what is still unconfirmed. Use it once the shopper has given counts, drilling (existing holes or fresh), finish, style and a budget; include products they liked from search_catalog as candidates. The plan is saved for 90 days at the returned plan_url, where the shopper can see it and add its samples or the whole plan to their cart. To change counts, finish or products, call build_plan again with the corrected answers; for Kayla's review, request_consultation with the plan_url. No email or account needed. Costs real money on our side, so call it once per shopper, after the facts are gathered.

Input Schema

NameRequiredDescriptionDefault
answersYesWhat the shopper has told the agent about the project. Every field is optional, but the plan needs at least the counts, the drilling situation and the finish.
summaryNotwo to six sentences of what the shopper told you, in their words where possible (shown to Kayla if they later ask for a review)
candidatesNoproducts the shopper liked or the agent found with search_catalog (handle + variant_id in the right finish), optionally with the zone and count they are for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / answers / description
      Added value: +"What the shopper has told the agent about the project. Every field is optional, but the plan needs at least the counts, the drilling situation and the finish."
    • addedInput schema / properties / answers / properties / appliance_panels / description
      Added value: +"panel-front appliances (dishwasher, refrigerator) that get a pull"
    • addedInput schema / properties / answers / properties / doors / description
      Added value: +"cabinet doors that get a knob or pull (not drawers, not tall/pantry doors)"
    • addedInput schema / properties / answers / properties / timing / description
      Added value: +"when they need the hardware, in their words (\"this week\", \"cabinets arrive in March\", \"no rush\")"
    • addedInput schema / properties / candidates / items / properties / count / description
      Added value: +"how many pieces this candidate covers, if known"
    • addedInput schema / properties / candidates / items / properties / handle / description
      Added value: +"the product handle from search_catalog or get_product"
    • addedInput schema / properties / candidates / items / properties / variant_id / description
      Added value: +"numeric Shopify variant id of the finish they want (from get_product); omit to let the plan pick the finish"
    • addedInput schema / properties / candidates / items / properties / zone / description
      Added value: +"where it goes: \"doors\", \"drawers\", \"island\", \"tall\", \"appliance_panels\", or \"any\""
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing persistence ("saved for 90 days at the returned plan_url"), downstream effects (shopper can add samples or the whole plan to their cart), no auth requirement ("No email or account needed"), and a real cost constraint ("Costs real money on our side, so call it once per shopper"). The once-per-shopper warning also reinforces the non-idempotent behavior the annotations flag.

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

Conciseness4/5

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

Front-loaded with the plan's contents, then usage conditions, then the cost caveat. Dense and mostly waste-free, though the cart/sample sentence and the 90-day detail could be slightly tightened without losing information.

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

Completeness5/5

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

For a nested-object, non-idempotent build tool with no output schema, the description covers what is produced (plan_url, line items, totals, unconfirmed items), how long it lives, and what the agent must gather first. Nothing essential for a correct single invocation is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so parameter documentation is already strong and the baseline is 3. The description adds genuine meaning by stating the minimum viable answer set (counts, drilling, finish) and by explaining where candidates come from (search_catalog handles plus variant_id in the right finish), which the schema alone does not convey.

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 and resource ("Build the shopper's whole-kitchen (or bath) Hardware Plan") and enumerates exactly what the output contains: one line per zone, product, finish, size, count, list price, totals, samples, unconfirmed items. This is clearly distinguishable from siblings like search_catalog or sizing_guide.

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

Usage Guidelines5/5

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

Explicitly names the preconditions (counts, drilling, finish, style, budget) and how to feed in search results ("include products they liked from search_catalog as candidates"). It also routes alternatives: re-call build_plan to correct answers, and use request_consultation with the plan_url for Kayla's review.

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

All Sienna, Knobs.co hardware advisor toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources