Skip to main content
Glama
Sign In

hackshop

by dev.hackshop
OverviewDiscussionsAdmin

Plan a Muse gadget

plan_gadget
Read-onlyIdempotent

Deterministically plan a physical body for an AI agent using Meta Muse boards. Partial intake answers produce remaining questions and an intake completion status. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "plan_gadget"
  }
}

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.6/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent, closed-world read, so the bar is lower; the description still adds real behavior: deterministic output, the ranking rule ('boards that meet the hard needs and the budget rank first, cheapest first'), and the fact that partial intake yields questions plus a completion status.

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?

Purpose is front-loaded in the first clause, which is good. But the bulk of the paragraph is a verbatim re-listing of every parameter constraint already present in the schema, which does not earn its space and buries the one genuinely new sentence about ranking.

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?

With a rich output schema and full annotation coverage, the description only needs to add what structured fields cannot: the deterministic/ranking behavior and the intake-completion semantics, both of which it covers. Only the relationship between overlapping top-level filters and the `answers` object remains unexplained.

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 coverage is 100%, so every parameter and enum value is already documented in the schema. The description largely restates those same constraints (ranges, enums, defaults) rather than adding meaning — e.g. it never explains how `answers` keys interact with the top-level `size`/`needs` or how owned_device_ids affects ranking.

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: 'Deterministically plan a physical body for an AI agent using Meta Muse boards.' The scope (board selection from an intake) is unmistakable, but differentiation from siblings like intake_gadget or get_build_plan is only implicit via the mention that partial answers yield remaining questions.

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

Usage Guidelines3/5

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

The description implies valid invocation shapes — idea is 'optional when answers or needs are given' — which tells an agent the minimum input contract. However, it never says when to call this instead of intake_gadget (to gather questions) or get_build_plan (to build one), leaving the routing decision to inference.

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
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources