Skip to main content
Glama
Sign In

ShapelessAI

by com.shapelessai
OverviewDiscussionsAdmin

Open a panel tab

panel_open

The panel is the document beside the chat on the ShapelessAI Ask page (shapelessai.com/studio): tabs the person looks at while you talk, and the place they answer a question with a press or edit a plan's node by hand. The browser, the chat's own agent and you (from a terminal) share one panel per conversation. The page draws it for the founder's account today (it is being rolled out); every account holds and can read its panel through these tools and the API. Opens one tab and brings it to the front; the same id replaces that tab in place, so re-open to refresh it rather than piling up copies. Kinds and their fields: node: a graph node (person, account, organization, post) with its connections: node (a node id like person:). people: the account's people graph: no fields. plan: a chat turn's plan cards: messageId, blockIds. calendar: the post queue as a calendar: ids? (post ids, none = whole queue), highlight? (post ids to point at), from?, to?, mode? (week | month | list). performance: how posts performed: post? (one post id), days?. agent: a standing agent and its runs: strategyId?. choices: a question the person answers with one press: question, options [{id, label, sub?, media? {kind: image|video, src}}]; use panel_ask, which also waits for the pick. prompter: a teleprompter for recording: sections [{text, kind?, seconds?, cue?, wpm? (this section's pace, 60..260), tone? (warm, urgent, dry...)}], wordsPerMinute?; text may carry delivery marks: words land harder, / a breath, // a full stop, ^word lifts. search: search results the person can group and sort: query, hits [{id, title, sub?, kind?, node?, url?, thumb?, group? {facet: value}, metrics? {name: number}}], groupBy?, orderBy?. brain: the account's Brand Memory: no fields. media: images, videos or audio to look at: items [{kind: image|video|audio, src, title?}]. custom: your own HTML in a sandboxed frame, when no kind fits: html (at most 200 KB), height?. flow: a plan as a graph, one node per choice made for the person: nodes [{id, kind, title, sub?, status? (planned | new | changed | running | done | failed | waiting), costUsd?, text?, refs? [{title, url?, node?, why?}], media? {kind: image|video|audio, src, title?}, options? [string], was?}] (1 to 40, unique ids), edges [{from, to, label?}], estimateUsd?, approve? (the sentence the Approve press sends to the chat). Returns {conversation_id, id, panel, text}; text is one plain line per tab. Needs the write scope.

Input Schema

NameRequiredDescriptionDefault
idNoStable id for this tab. Omit it and one is made from kind and title.
toNocalendar: last day, YYYY-MM-DD.
idsNocalendar: post ids to show; none shows the whole queue.
daysNoperformance: how many days back.
fromNocalendar: first day, YYYY-MM-DD.
hitsNosearch: the results.
htmlNocustom: the HTML, drawn in a sandboxed frame with our design tokens; at most 200 KB.
kindYesWhat the tab shows (see the kinds above).
modeNocalendar: the view.
nodeNonode: a graph node id (person:<uuid>, account:<uuid>, organization:<uuid>, asset:<platform>:<postId>).
postNoperformance: one post id.
edgesNoflow: how the nodes connect; an edge naming no node is dropped.
focusNoBring it to the front (default true). false opens it behind the current tab.
itemsNomedia: what to show.
nodesNoflow: the plan's steps, 1 to 40, unique ids.
queryNosearch: the words searched.
titleYesA short name for the tab.
heightNocustom: frame height in pixels.
approveNoflow: the sentence the Approve press sends to the chat; absent means no button. Never run a paid node before it arrives.
groupByNosearch: a facet name from the hits' group.
optionsNochoices: two or more options.
orderByNosearch: a metric name from the hits' metrics.
blockIdsNoplan: the plan blocks to show.
questionNochoices: what the person decides. Prefer panel_ask, which also waits for the pick.
sectionsNoprompter: the script, in order.
highlightNocalendar: post ids to draw attention to (the ones you just proposed).
messageIdNoplan: the chat message whose plan to show.
strategyIdNoagent: the standing agent's id (agents_list).
estimateUsdNoflow: the total the run bills, shown before Approve.
wordsPerMinuteNoprompter: scroll speed.
conversation_idNoThe conversation (job) id whose panel to use. Omit it to use the conversation the person opened last in the browser, which is the one they are most likely looking at.

Output Schema

NameRequiredDescriptionDefault
idYes
textYes
panelYes
conversation_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: the panel is shared across the browser, chat agent, and terminal; there is one panel per conversation; accounts can read their panel through the API; opening brings the tab to the front; the same id replaces the tab in place; and the call needs the write scope. It also states the return shape and that text is one plain line per tab. The annotations already declare non-read-only, non-destructive, non-open-world behavior, and the description is consistent with them.

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

Conciseness4/5

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

The description is long, but the tool is genuinely complex: 13 kinds and 31 parameters. It front-loads the panel concept and the opening behavior before listing kind-specific fields, which is the right structure. Some of the kind/field listing duplicates the schema, but it remains useful as a compact selection guide.

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?

Given the tool's complexity, the description is complete enough for correct invocation. It covers sharing semantics, id-based replacement, required write scope, return values, and kind-specific behavior. An output schema exists, and the description still explains the return shape and text summary, so an agent has what it needs.

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 each parameter. The description still adds meaningful cross-parameter semantics by mapping each kind to the fields it uses and giving kind-specific constraints, such as 1 to 40 unique flow node ids, 200 KB custom HTML, and prompter pace of 60 to 260 wpm. It also clarifies that custom is for cases where no kind fits and that choices should generally be handled through panel_ask.

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

Purpose5/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: it opens one panel tab and brings it to the front. It also explains the panel itself as the document beside the chat and distinguishes opening from replacing an existing tab by id. This is enough for an agent to understand exactly what the tool does without opening the schema.

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?

Usage guidance is clear in several places: re-open with the same id to refresh rather than piling up copies, and use panel_ask instead of the choices kind because panel_ask also waits for the pick. However, it does not explicitly compare panel_open with sibling tools such as panel_update or panel_close, so the when-not-to-use boundary is only partially covered.

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

All ShapelessAI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources