Skip to main content
Glama
Sign In

RelayLink

by ai.relaylink
OverviewDiscussionsAdmin

Prepare changes members will see

project_draft

Prepare up to twenty changes to a RelayLink project — new work, revisions, assignments, decisions — as one change set. NOTHING IS WRITTEN by this call: it validates everything and returns a CONFIRM NEEDED preview naming exactly what every member will then be able to see; only confirm_intent after the user's own explicit approval applies it, all at once. operations is a JSON array, each item an object with "op" and whichever fields it needs: create_project (title, outcome?, definitionOfDone?, targetDate?) — must be the ONLY operation, and project must be omitted; set_project (outcome?, definitionOfDone?); set_state (state: active|on_hold|completed); create_work (kind: decision|constraint|question|task|note, body, title?, definitionOfDone?); update_work (workItem, expectedRevision, title?, body?, definitionOfDone?); assign_work (workItem, assignTo, due?); set_work_state (workItem, state: done|cancelled|open — a manager override; the assignee's own progress is project_work_update); publish_entry (fromEntry, kind); adopt_decision (workItem); supersede_decision (workItem, body? — omit to withdraw instead). workItem may be a real work_id, or "$N" naming the Nth operation in THIS same array when it created the item. Inviting, removing, changing a role, transferring ownership, archiving, cancelling or deleting a project are refused here by name — those are decided in the browser. This is shared with everybody on the project: every member can read it, so use these tools only for work the user means to be visible to the people they have put on this project. A private note, task or preference that is only the user's own is the notebook's (notebook_*) instead, and a bare "add a task" may be meant for another connected app — if more than one destination is plausible and the user has not said which, ask once and stay with the answer.

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": {
      "operations": "<operations>"
    },
    "name": "project_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectNoThe project's name or id. Omit only when the first (and only) operation is create_project.
operationsYesA JSON array of operations, e.g. [{"op":"create_work","kind":"task","body":"Write the brief"}].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior1/5

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

The description discloses many important behaviors: no writes, a CONFIRM NEEDED preview, validation, a twenty-operation limit, refusals, and shared visibility. However, annotations set readOnlyHint=false while the description explicitly says 'NOTHING IS WRITTEN by this call' and that only confirm_intent applies the changes, creating an annotation contradiction about whether this call mutates state.

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?

It front-loads the purpose and no-write guarantee, then packs the operation grammar, refusals, privacy boundary, and ambiguity handling into a dense paragraph. It is long but nearly every clause earns its place; better formatting could improve scanability.

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?

For a complex multi-operation tool with no output schema, it explains the preview/confirmation boundary, the operation grammar, validation behavior, refusals, shared visibility, and alternatives such as notebook_* tools. An agent has enough context to call it correctly and route ambiguous cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is technically 100%, but the schema only documents operations as a JSON string and project as a name/id. The description adds substantial meaning: operation types, required and optional fields, enum values such as active|on_hold|completed, the create_project sole-operation rule, and the $N reference to earlier operations in the same array.

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: prepare up to twenty project changes as one change set, with concrete operation families (new work, revisions, assignments, decisions). It clearly distinguishes itself from confirm_intent, which applies the change set, and from project_work_update, which handles the assignee's own progress.

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?

Explicitly says this call only validates and previews, and that confirm_intent is used only after the user's explicit approval. It also refuses browser-only actions by name, routes private items to notebook_*, and tells the agent to ask once when 'add a task' could target another connected app.

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

All RelayLink 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