Skip to main content
Glama

Get canvas selection

get_selection
Read-only

Read what the user has selected on the project's canvas in Mapples Creator, by project UUID. context.selection names the screen or component (container: entity, id, uuid, name) and the selected elements (nodes: sid, type, label) — sid is the $sid the element carries in the synced code (null, or starting c_, while it is not saved in the Creator yet); an empty nodes list means the screen itself is selected. context is null when the Creator never shared a selection, and selection is null when nothing is selected or sharing is off. context.updatedAt says how old it is: the selection outlives a closed Creator tab, so confirm with the user before acting on an old one. Requires project:view (or the project's API key).

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": {
      "project_uuid": "<project_uuid>"
    },
    "name": "get_selection"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_uuidYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Consistent with readOnlyHint=true, and it goes well beyond the annotation by disclosing null semantics for context and selection, the meaning of an empty nodes list, the c_ prefix / null sid state for unsaved elements, and the key staleness caveat that selection outlives a closed Creator tab. This is exactly the kind of behavioral context an agent cannot infer from structured fields.

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?

Front-loaded with the verb and resource, then layered: return shape, null states, staleness, permissions. Dense but every clause carries information; it runs long only because the nested selection semantics are genuinely non-obvious.

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?

An output schema exists, yet the description still supplies the interpretation the schema cannot convey (what null means, what empty nodes means, what sid values imply, freshness via updatedAt). Combined with the auth requirement, nothing an agent needs to call this correctly and interpret the result is missing.

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 0% and the single parameter has no description in the schema, but the description compensates by saying the lookup is "by project UUID", making the parameter's role unambiguous (which project's canvas to read). Format details are already carried by the schema's uuid format, so little more is needed.

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?

States a specific verb and resource ("Read what the user has selected on the project's canvas in Mapples Creator") scoped "by project UUID". This is unmistakably different from the sibling tools get_project, get_project_style, and get_api_data_states, which read project metadata/styles/state rather than live selection.

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?

Gives real operational guidance: requires project:view (or the project's API key), and explicitly says to confirm with the user before acting on a selection that may be stale. It lacks an explicit when-not or sibling-routing sentence, but the conditions for safe use are clear.

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