Skip to main content
Glama

opointo

by com.opointo
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 Designer 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

TableJSON 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

B3.4/5.0
Behavior3/5

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

Annotations already declare the safety profile (not read-only, not destructive, not idempotent), so the bar is lower, and the description does add real value: the result is a new *unsaved* design a person can change, plus a dryRun check mode. However, the 'into' behavior is left as a cryptic cross-reference rather than a disclosed trait, and there is no note on whether anything persists.

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

Conciseness2/5

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

The size is reasonable, but structure is poor: 'into: as propose_app's.' is a dangling fragment with no verb, and the run-on first sentence buries the return-value behavior (a link) mid-clause. Front-loading the purpose helps, but the shorthand-style gaps make it read as under-specified rather than concise.

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?

For a tool with a nested composition object, no output schema, and one badly described parameter (into), the description covers the essentials of what happens (unsaved design + link, dryRun) but leaves the 'into' semantics and any auth/permission expectations unaddressed. It is workable but not complete.

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%. The description supplies meaning for dryRun ('checks without making a link') and format ('true returns the format'), and the composition format is documented in the schema itself. The 'into' parameter is effectively undocumented beyond a pointer to propose_app's behavior, leaving a real gap.

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?

The description states a specific verb and resource: send one screen and get back a link that opens an unsaved design in the Designer. It also explicitly distinguishes itself from the sibling propose_app ('For a whole app, use propose_app'). The clarity is slightly eroded by the broken fragment 'into: as propose_app's.', which reads as leftover notes rather than a complete sentence.

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?

It gives a clear alternative and selection rule ('For a whole app, use propose_app') and explains that dryRun checks without producing a link, which is genuine when-to-use guidance. It stops short of contrasting against add_screen, even though it name-drops the relation indirectly.

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

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