Skip to main content
Glama
Sign In

RelayLink

by ai.relaylink
OverviewDiscussionsAdmin

Find shared work

project_work_find
Read-onlyIdempotent

Search shared work items across every RelayLink project the user is on, or narrow to one. Answers "what's assigned to me", "what's blocked", "what's due this week" — across the whole account, not one project at a time. project_work_open reads one in full. Reads only. 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "project_work_find"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNodecision | constraint | question | task | note.
textNoWords to search the title and body for.
limitNoRows per page (default 20, max 50).
stateNoopen | doing | review | done | blocked | cancelled | needs_me | waiting_on_others | due_soon.
offsetNoSkip this many rows (default 0).
projectNoA project name or id to narrow to. Omit to search every project the user is on.
dueBeforeNoOnly things due on or before this date (2026-09-20).
assignedToNo"me", or an accepted contact's email address. A bare name cannot be resolved across projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the added value is the visibility disclosure: everything here is readable by every project member, and the description warns to use it only for work the user intends to be visible. That is a non-obvious data-exposure trait not captured by any structured field.

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 core verb and scope before the sibling routing and privacy caveats; sentences are dense but each carries routing or safety information. The closing cross-app ambiguity note is slightly tangential for a search tool but still actionable.

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?

Covers the decisions an agent must make for an eight-parameter, zero-required search tool with no output schema: scope, visibility, alternatives, and intent-to-filter mapping. It omits return shape and pagination behavior, though limit/offset are documented in the schema.

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 description maps user intent phrases onto parameters implicitly — "assigned to me" to assignedTo, "blocked" to state, "due this week" to dueBefore — which helps an agent choose values. It does not add syntax detail beyond the schema, so it stops short of 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?

States a specific verb (search) plus resource (shared work items) with explicit scope: every RelayLink project the user is on, or narrowed to one. It distinguishes itself from project_work_open (reads one in full) and notebook_* (private notes) so an agent can route without opening a 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 concrete when-to-use triggers ("what's assigned to me", "what's blocked", "what's due this week") and names the alternatives: project_work_open for a single item in full, notebook_* for private material, and another connected app for ambiguous "add a task" requests. It even specifies the fallback behavior (ask once, stay with the answer) when destinations are ambiguous.

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