Skip to main content
Glama
tristanlawrenceguy

Sameway

by tristanlawrenceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Add a block

add_component

Add a component to the current canvas by supplying its name and schema-matching props. Returns the new block id and current display state, or an error explaining why it was not added.

Instructions

Add a component to the canvas the person is looking at. Props must match the component's props schema; a refusal gives the schema and an example. Returns the new block id and what it shows; read it: "nothing yet" means it shows no records now. A block that could not be shown (a type, field, date field, condition or tag the workspace does not have, one field asked for two values, a chart by a date with no period) is not added, and the error says why and what to do instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNofull is the whole thing (the default). compact fits more on a page. icon is a glyph with its name for screen readers that opens the full thing; for people who know what it is.
spanNoWidth in columns of twelve. 12 is full width, 6 half, 4 a third. Defaults to 6.
toneNoTints the block's surface. Defaults to none.
frameNocard gives the block a surface, bare sits flush on the page. Defaults to card.
propsYesProps matching the component's schema.
canvasNoWhich tab the block goes on, as a canvas id from the list of tabs; empty string is Home. Defaults to the tab the person is looking at.
regionNomain is the body of the page. left and right are full height panes beside it: left for history and navigation, right for what the person glances at. header is the bar at the top, for what they reach for on every page; footer the bar at the bottom. Defaults to main.
componentYesComponent name, as the prompt lists it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses atomic failure semantics: an invalid block type/field/date/range is 'not added' rather than partially applied, and the error explains what to do instead. It also explains how to read the return payload, including the 'nothing yet' sentinel meaning no records are currently shown.

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 core action and the props constraint are front-loaded, and every sentence carries information about failures or return values. It is a single dense paragraph with some long clauses, but there is little 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 must carry the return contract, and it does: new block id, what the block shows, and the meaning of the 'nothing yet' case. Failure modes and their remediation are also covered, so an agent has enough to call this correctly.

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 description coverage is 100%, so the baseline is 3, and the description adds real value on the trickiest parameter by specifying that props must match the component's props schema and that a refusal returns the schema plus an example. It does not, however, add anything beyond the schema for size, span, tone, frame, region, or canvas.

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 opens with a specific verb and resource ('Add a component to the canvas the person is looking at'), which immediately separates it from update_component, remove_component, and arrange_canvas. Scope (the currently viewed canvas) is stated rather than left to inference.

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?

It makes clear this is the creation path and implies props must match a component schema, but it never names an alternative (e.g. update_component for modifying an existing block) or states prerequisites such as needing the workspace to already define referenced types, fields, or tags. Usage is implied rather than directed.

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

Deploy Server

Other Tools