Skip to main content
Glama
Sign In

Soleil Clusters

by com.soleilpictures
OverviewDiscussionsAdmin

Tag cards

tag_cards
DestructiveIdempotent

Puts tags on cards of one board and takes them off. A tag is a name or an id from list_tags; a name with no tag in the workspace makes a new one. A tag taken off stays off: automatic tagging never puts it back. Tag only what the person asked for.

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": {
      "board_id": "<board_id>",
      "card_ids": "<card_ids>"
    },
    "name": "tag_cards"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoTags to put on: names or tag ids
removeNoTags to take off: names or tag ids
board_idYesThe board the cards are on
card_idsYesCard ids (from read_board)

Output Schema

NameRequiredDescriptionDefault
urlNo
addedNo
removedNo
board_idNo
not_foundNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations (destructive/idempotent, not read-only), the description discloses two behaviors an agent could not infer: an unknown name silently creates a new workspace tag, and a removal is durable because automatic tagging never re-adds it. It does not mention rate limits or what happens on partial failure when some names are invalid, which keeps it from a 5.

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?

Four short sentences, front-loaded with the operation, then tag identity, then the side effect, then the scope constraint. Every sentence carries information, though the final sentence reads more as a policy directive than tool behavior and could be tightened.

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 annotations covering the safety profile and an output schema covering return values, the description only needs to explain the add/remove duality and side effects, which it does. The one residual gap is failure semantics when a mix of valid and invalid tags is supplied.

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 baseline is 3, and the description earns above that by explaining that both add and remove accept either a tag name or an id from list_tags, and by clarifying the create-on-miss semantics of a name that has no matching tag. It adds no detail on the 10/200 item caps, which the schema already states.

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?

"Puts tags on cards of one board and takes them off" is a specific verb+resource statement that makes the dual add/remove nature clear at a glance. It does not name a sibling tool or contrast itself with e.g. update_cards or list_tags, so it stops short of full differentiation.

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 description usefully points at list_tags as the source of valid tag identifiers and adds the guardrail "Tag only what the person asked for," which implies when to be conservative. It never states when to choose this tool over update_cards or add_cards, nor does it mention prerequisites such as board access.

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

All Soleil Clusters 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