Skip to main content
Glama

hackshop

by dev.hackshop
OverviewDiscussionsAdmin

Plan a Muse gadget

plan_gadget

Deterministically plan a physical body for an AI agent using Meta Muse boards. Ask the intake questions first (intake_gadget, or the questions this returns until intake.complete is true), then pass the human's choices as answers. Inputs: idea 3-2000 chars (optional when answers or needs are given); answers {size, interaction, sensing, budget} using the intake option values; platform one of muse-esp32, muse-linux, any (default any); budget_usd number greater than 0, up to 100000; owned_device_ids up to 50 catalog ids; needs values: voice, screen, images, touch, camera, air-sensors, e-ink, battery, round, home-tunnel, big-screen, compute, linux; size one of pocket, desk, wall, hidden, any (default any); limit 1-5 (default 3). Boards that meet the hard needs and the budget rank first, cheapest first. Returns fit, notes, warnings, intake status, questions, picks with difficulty, terms and next steps.

Input Schema

NameRequiredDescriptionDefault
ideaNoGadget idea or use case, 3-2000 characters. Optional when `answers` or `needs` are given.
sizeNoPreferred size or placement: pocket, desk, wall, hidden, any. Default any.any
limitNoNumber of picks to return: 1-5, default 3.
needsNoOptional explicit needs. Allowed: voice, screen, images, touch, camera, air-sensors, e-ink, battery, round, home-tunnel, big-screen, compute, linux.
answersNoThe human's intake answers, by question id, using the option values from intake_gadget.
platformNoPlatform filter: muse-esp32, muse-linux, or any. Default any.any
budget_usdNoOptional hardware budget in USD. Must be greater than 0, max 100000.
owned_device_idsNoCatalog device ids the user already owns. Max 50.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / answers
      Added value: +{
+  "additionalProperties": false,
+  "description": "The human's intake answers, by question id, using the option values from intake_gadget.",
+  "properties": {
+    "budget": {
+      "description": "What budget should I plan around? under-25 = Under $25; under-50 = Under $50; under-100 = Under $100; no-limit = No limit.",
+      "enum": [
+        "under-25",
+        "under-50",
+        "under-100",
+        "no-limit"
+      ],
+      "type": "string"
+    },
+    "interaction": {
+      "description": "How should you interact with it? voice = Talk to it; touch = Touch screen; light-button = Light and button.",
+      "enum": [
+        "voice",
+        "touch",
+        "light-button"
+      ],
+      "type": "string"
+    },
+    "sensing": {
+      "description": "Should it sense the room? camera = Camera; air-quality = Air quality; none = None.",
+      "enum": [
+        "camera",
+        "air-quality",
+        "none"
+      ],
+      "type": "string"
+    },
+    "size": {
+      "description": "Where should this body live? pocket = Pocket; desk = Desk; wall = Wall or fridge; hidden = Hidden, no screen.",
+      "enum": [
+        "pocket",
+        "desk",
+        "wall",
+        "hidden"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • changedInput schema / properties / idea / description
      Previous value: -"Gadget idea or use case, 3-2000 characters."New value: +"Gadget idea or use case, 3-2000 characters. Optional when `answers` or `needs` are given."
    • removedInput schema / required
      Removed value: -[
-  "idea"
-]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose ranking behavior ('Boards that meet the hard needs and the budget rank first, cheapest first') and the ranked output categories. It omits permission/auth needs, whether planning is idempotent, and any rate limits, but the determinism and ranking claims are genuinely useful 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.

Conciseness3/5

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

The purpose and workflow lead are front-loaded and useful, but the bulk of the text is a run-on re-enumeration of values (needs list, sizes, platforms) already fully specified in the schema, which bloats the definition without adding decision value.

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 8-parameter tool with a nested `answers` object, an output schema, and no annotations, the description covers prerequisites, cross-parameter optionality, ranking logic, and a summary of returns. It is close to complete, with only auth/permission context 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 coverage is 100%, so the schema already documents every parameter; the description nonetheless adds cross-parameter meaning, notably that `idea` is optional when `answers` or `needs` are given and that `answers` must use intake_gadget option values. That cross-tool linkage justifies going above the 3 baseline.

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

Purpose4/5

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

States a specific verb and resource ('plan a physical body ... using Meta Muse boards') and even characterizes the algorithm as deterministic. It distinguishes itself from intake_gadget by positioning that tool as a prerequisite, but leaves its relationship to get_build_plan and assess_hackability unaddressed.

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?

Gives a clear sequencing rule: ask the intake questions first (via intake_gadget or the returned `questions` until `intake.complete` is true), then pass the human's choices as `answers`. That is actionable context, though it offers no explicit when-not-to-use or comparison against the other planning siblings.

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

All hackshop toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources