Skip to main content
Glama

Move cards

move_cards

Move one or more cards to new positions on a board. The server places new cards itself; this is for the board view's drag. Costs no credits. SIGN-IN REQUIRED: connect this server with OAuth (the host prompts for it), or add an API key header "Authorization: Bearer acd_live_…" created at https://aicontentdrop.com/settings/integrations.

Input Schema

NameRequiredDescriptionDefault
movesYesCards and their new positions.
revisionNoThe board revision this change is based on (from the last board you saw). Optional: when omitted the tool reads the current one first.
canvas_idYesThe board id, from list_canvases or create_canvas.

Output Schema

NameRequiredDescriptionDefault
canvasYes
next_stepYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / properties / canvas / properties / updated_at
      Removed value: -{
      -  "type": [
      -    "string",
      -    "null"
      -  ]
      -}
    • changedOutput schema / properties / canvas / required
      Previous value: -[
      -  "id",
      -  "name",
      -  "revision",
      -  "card_count",
      -  "updated_at",
      -  "link",
      -  "cards",
      -  "edges"
      -]New value: +[
      +  "id",
      +  "name",
      +  "revision",
      +  "card_count",
      +  "link",
      +  "cards",
      +  "edges"
      +]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / canvas / properties / edges / items / description
      Added value: +"A connection drawn from one card to the next: { id, source, target, label? }. data.role start_image means the source card's finished image is the target card's start frame."
    • addedOutput schema / properties / canvas / properties / edges / items / properties
      Added value: +{
      +  "id": {
      +    "type": "string"
      +  },
      +  "label": {
      +    "description": "Text drawn on the line, when it has one."
      +  },
      +  "source": {
      +    "description": "The card the connection starts from.",
      +    "type": "string"
      +  },
      +  "target": {
      +    "description": "The card it leads to.",
      +    "type": "string"
      +  }
      +}
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly=false, destructive=false, non-idempotent, closed-world), so the description needn't repeat that. It adds genuinely new behavioral facts: the operation costs no credits and requires OAuth or a Bearer API key, including where to obtain the key — details absent from all 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?

Purpose is front-loaded in one sentence, followed by the disambiguating note and the auth requirement. The auth block is long (URL plus header format) but is load-bearing information that prevents a failed call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and all three parameters are documented in the schema. The description completes the picture with cost and authentication, leaving only the arrange_cards boundary unresolved.

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 description coverage is 100%, including the optional x/y and revision semantics, so the schema carries the parameter burden. The description adds no extra meaning beyond noting the server handles placement of new cards, which is already stated in the position property description.

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 ('Move one or more cards to new positions on a board') and clarifies the scope by contrasting with server-side card placement. It does not name the overlapping sibling arrange_cards, so the boundary is only partially drawn.

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?

'The server places new cards itself; this is for the board view's drag' implies when to use it (manual repositioning rather than creation). However, it never mentions arrange_cards, which is the obvious alternative for bulk repositioning, so the agent must guess which to pick.

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.