Skip to main content
Glama

recipebooq

by com.recipebooq
OverviewDiscussionsAdmin

Propose a screen design

propose_screen

Your agent can design a single screen with you: send one screen in opointo's design format (the Composition add_screen builds from) and get back a link that opens it in the Architect as a new, unsaved design the person can change. into: as propose_app's. dryRun checks without making a link; format: true returns the format. For a whole app, use propose_app.

Input Schema

NameRequiredDescriptionDefault
intoNo
dryRunNocheck the screen and report, without making a link
formatNo
compositionNoOne screen: { name, screen: { content: { children: [node] }, chrome: { header?, headerItems?, floating: [] }, overlays: [] } }. A node is { id, slug, props }: slug is "wireframe:<block>" or a component from find_component.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / into
      Added value: +{
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / composition / description
      Previous value: -"One screen: { name, screen: { content: { children: [node] }, chrome: { header?, headerItems?, floating: [] }, overlays: [] } }. A node is { id, slug, props }: slug is a component from list_components or \"wireframe:<block>\"."New value: +"One screen: { name, screen: { content: { children: [node] }, chrome: { header?, headerItems?, floating: [] }, overlays: [] } }. A node is { id, slug, props }: slug is \"wireframe:<block>\" or a component from find_component."
    • addedInput schema / properties / format
      Added value: +{
+  "type": "boolean"
+}
    • removedInput schema / required
      Removed value: -[
-  "composition"
-]
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Adds real context beyond annotations: the result is a new, unsaved design the person can edit, which tells the agent nothing is persisted or destroyed (consistent with destructiveHint=false). It also discloses the dryRun non-effect, though it says nothing about permissions or failure behavior.

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 the propose_app alternative are front-loaded, but sentences are long run-ons and the 'into: as propose_app's.' fragment adds noise rather than information. Short overall, but not every clause earns its place.

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

Completeness3/5

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

Given four params, nested composition objects, and no output schema, the description covers the essentials: what to send, what comes back (a link), and how to preview without a link. It leaves gaps on 'into', the exact shape of the dryRun report, and error behavior.

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 50%, so the description must compensate for undocumented params. It does add meaning for 'format' ('true returns the format') and echoes dryRun, but 'into' is reduced to the unusable fragment 'as propose_app's,' leaving one of four params effectively unexplained in both places.

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 ('design a single screen'), explains the input format and the return value (a link opening a new, unsaved design in the Architect). It explicitly distinguishes itself from propose_app for whole apps, so an agent can route correctly despite the garbled 'into: as propose_app's' fragment.

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?

'For a whole app, use propose_app' is an explicit alternative with the selecting condition. The dryRun and format flags are also framed as usage choices ('checks without making a link', 'returns the format'), though 'into' gets no usable guidance at all.

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