Skip to main content
Glama

Set Component Data

set_component_data
Destructive

Pushes live observations without regenerating source. Same-source React reuses the compiled module. Default replaces data; merge:true shallow-merges keys (32KB bound). Optional slot targets a nested sub-component on a fullscreen board. Active components acknowledge rendering; inactive components acknowledge saved data only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operationID": "<operationID>",
      "expectedRevision": "<expectedRevision>",
      "componentID": "<componentID>",
      "data": "<data>",
      "controlToken": "<controlToken>"
    },
    "name": "set_component_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYes
slotNo
mergeNo
componentIDYes
operationIDYes
controlTokenYes
expectedRevisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / slot
      Added value: +{
      +  "maxLength": 64,
      +  "pattern": "^[a-z][a-z0-9_-]{0,63}$",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / merge
      Added value: +{
      +  "type": "boolean"
      +}
  3. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare destructive=true, readOnly=false, openWorld=true, so the safety profile is covered. The description adds genuinely non-structured behavior: the 32KB merge bound, module reuse for same-source React, and the split acknowledgement semantics (active components ack rendering, inactive ack saved data only).

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?

Five tight sentences, front-loaded with the core action before parameter details. Dense but no filler; the React module-reuse sentence is niche but arguably informative.

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 7-param mutation with no output schema and no param descriptions, the description covers the acknowledgment behavior and merge bound well, but omits revision-conflict handling and controlToken requirements. An agent can call it, but not fully anticipate conflict/authorization failures.

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?

With 0% schema description coverage the description must carry the load, and it does explain merge, slot (nested sub-component on a fullscreen board), and the data replace/merge behavior. However expectedRevision, controlToken, operationID, and componentID are left undecoded, and expectedRevision in particular implies optimistic-concurrency semantics the agent cannot infer.

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 ('Pushes live observations', 'set component data') and clarifies it works 'without regenerating source'. It is clearly distinct from read_component/update_component by nature of pushing live data, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

It explains the two data modes (default replace vs merge:true), which guides parameter choice, but never says when to prefer this tool over update_component, create_component, or render, nor any exclusions. No tool-selection guidance is present.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources