Skip to main content
Glama
Sign In

Testsy

by dev.testsy
OverviewDiscussionsAdmin

Create a watch link

create_watch_link

A view-only link to watch a run live and read its result, with no sign-in, valid while it runs and for some hours after. Runs started here get one automatically; this makes another, or one for a run started from the web app. The link shows the live screen, the steps and checks so far, then the read-only result. membersOnly is true when the workspace limits watch links to signed-in members (or the run came from a public repository). 403 when the workspace turned watch links off.

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": {
      "runId": "<runId>"
    },
    "name": "create_watch_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
runIdYesRun id (j_…)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Well beyond what the annotations provide: the description discloses link lifetime ('valid while it runs and for some hours after'), access model (view-only, no sign-in), what the recipient sees at each stage, the membersOnly condition, and the 403 failure mode when watch links are disabled. Those are exactly the operational details an agent needs before creating an externally reachable URL.

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 artifact and its properties, then the when-to-use clause, then output/error semantics — a sensible order. The prose is dense but every sentence carries information; only the membersOnly sentence is slightly clipped in a way that reads like response-field documentation in the wrong place.

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 no output schema, the description correctly compensates by explaining the membersOnly flag and the 403 condition, and by describing what the link surfaces. It does not say what the successful response itself contains (presumably a URL) or whether repeat calls yield distinct links, which is the remaining gap for a creation tool.

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?

The single runId parameter is fully documented in the schema (100% coverage), and the description only refers to it obliquely as 'a run'. No added meaning about format, source workspace, or resolution is offered beyond the schema's 'j_…' example.

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?

The opening sentence gives a specific verb and resource ('A view-only link to watch a run live and read its result') and immediately describes the artifact's properties (no sign-in, time-limited). It distinguishes the tool from the implicit automatic creation path, but never names the obvious siblings create_share_link or revoke_watch_link, so an agent must infer which link type to use for what.

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

Usage Guidelines4/5

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

Clear when-to-use guidance: runs started here already get one automatically, so call this to make an additional link or one for a run started from the web app. That answers the main 'why would I call this' question. It stops short of naming alternatives (e.g., share links) or stating when-not to use it.

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

All Testsy toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources