Skip to main content
Glama
Sign In

Soleil Clusters

by com.soleilpictures
OverviewDiscussionsAdmin

Create boards

create_boards

CREATES boards (clusters), one or a whole structure per call, in workspace_id (default: the personal workspace) and inside parent_board_id when given: pass it when the person says where (search finds the cluster). With none, a board becomes a top-level project and the answer's placement lists their clusters: ask where it belongs and move it with update_boards.

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": {
      "boards": "<boards>"
    },
    "name": "create_boards"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftNoThe draft key create_boards returned. Pass it on every call about that draft.
boardsYesThe boards to create
on_conflictNo"identifier" updates rather than duplicates
workspace_idNoDefault for the boards; left out, the personal workspace

Output Schema

NameRequiredDescriptionDefault
boardsNo
createdNo
updatedNo
placementNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / draft
      Added value: +{
+  "description": "The draft key create_boards returned. Pass it on every call about that draft.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the write/safety profile is covered. The description adds real context beyond that: the personal-workspace default, the top-level-project fallback, and the fact that the response's placement field lists the user's clusters. It stops short of covering the draft-key handshake and the identifier/on_conflict update path, which would have made it 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

All the content earns its place, but it is delivered as one long run-on sentence stitched together with colons and parentheticals, so an agent has to re-parse the conditional branches. Front-loading the verb helps, but splitting the placement/parent logic into its own sentence would read far better.

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?

Output schema exists, so return values need no explanation, and the description still flags the relevant response field. Batch limits, hierarchy placement, workspace defaulting, and the follow-up action are all covered for a create tool with one required parameter.

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, but the nested parent_board_id property carries no schema description and the description supplies its meaning plus a usage heuristic ('when the person says where'). workspace_id's default is restated rather than expanded, which keeps this from a 5.

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?

Opens with a specific verb and resource ('CREATES boards (clusters)') and immediately scopes it: one or a whole structure per call, inside workspace_id, optionally under parent_board_id. An agent can distinguish it from update_boards, move_cards, or list_boards without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit conditional routing: pass parent_board_id 'when the person says where (search finds the cluster)', and when no parent exists, ask where it belongs and hand off to update_boards. It names the alternative tool and the exact condition that selects it.

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