Skip to main content
Glama

recipebooq

by com.recipebooq
OverviewDiscussionsAdmin

Build an app from a design

emit_app
Read-onlyIdempotent

Needs a subscription. Turns a design from the Architect into a working Expo app: navigation, providers, tab bar, screens and the components they use. Returns a recipe for the current project: every file with its target path, one install line and ordered steps with a check each. Pass step for one step in full, which does not count against the daily allowance.

Input Schema

NameRequiredDescriptionDefault
pageNofor step write or review; each page names the next
stepNoa step id from the recipe, or "review" for the screen list
appIdYesthe Architect's "Send app to agent" share code, e.g. "34ca4babb2"
overrideNoemit even with screens flagged not ready; ask the customer first

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / appId / description
      Previous value: -"the share code from the Designer's \"Send app to agent\", e.g. \"34ca4babb2\""New value: +"the Architect's \"Send app to agent\" share code, e.g. \"34ca4babb2\""
  2. Changed1 schema field changed
    • changedInput schema / properties / appId / description
      Previous value: -"the share code from the App Designer's \"Send app to agent\", e.g. \"34ca4babb2\""New value: +"the share code from the Designer's \"Send app to agent\", e.g. \"34ca4babb2\""
  3. Changed1 schema field changed
    • changedInput schema / properties / appId / description
      Previous value: -"the share code from the App Builder's \"Send app to agent\", e.g. \"34ca4babb2\""New value: +"the share code from the App Designer's \"Send app to agent\", e.g. \"34ca4babb2\""
  4. Changed4 schema fields changed
    • changedInput schema / properties / appId / description
      Previous value: -"the share code, e.g. \"34ca4babb2\""New value: +"the share code from the App Builder's \"Send app to agent\", e.g. \"34ca4babb2\""
    • changedInput schema / properties / override / description
      Previous value: -"emit even when screens are flagged as not ready. Ask the customer first; the flags exist for a reason."New value: +"emit even with screens flagged not ready; ask the customer first"
    • addedInput schema / properties / page
      Added value: +{
+  "description": "for step write or review; each page names the next",
+  "type": "number"
+}
    • addedInput schema / properties / step
      Added value: +{
+  "description": "a step id from the recipe, or \"review\" for the screen list",
+  "type": "string"
+}
  5. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: an entitlement requirement, a daily allowance quota, and the notable fact that single-step fetches don't count against that quota. It also discloses the return shape (files with target paths, one install line, ordered steps with a check each), which is exactly what an agent needs given no output schema.

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?

Three tight sentences, front-loaded with the prerequisite and the core action, then the return format, then the parameter tip. No filler.

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?

With no output schema, the description carries the return-value burden and does so precisely, and it covers the quota and prerequisite behavior an agent needs before calling. Nothing material is missing for a read-only recipe generator.

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 baseline is 3, but the description adds real meaning: it explains that `step` fetches one step in full and is quota-exempt, which the schema does not say. `page` and `override` semantics are left to the schema.

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: turns an Architect design into a working Expo app (navigation, providers, tab bar, screens, components) and returns a per-project recipe. This clearly separates it from siblings like propose_app, add_screen and verify_app, though it 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.

Usage Guidelines3/5

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

Gives a prerequisite ('Needs a subscription') and one concrete usage mode ('Pass `step` for one step in full'), but never says when to choose this over propose_app/verify_app or when emission is inappropriate. Usage is implied by the flow rather than spelled out.

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

All recipebooq 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