goldseam

Coach Say

coach_say

Speak through the open coach: the words, queued for the coach and spoken in the voice the person chose on the coach once the coach view holds the coach; and optional cues (GoldAvatar's show_frame, action, head, set_caption, speaking, mouth_shapes, blink, idle, auto_revert) at sentence or beat boundaries. Words sent while the coach is still speaking wait their turn, so a short acknowledgment can go first and the answer after it. While a GoldSeam service is being called, keep the coach talking: chat with the person about the process and about how their answers are affirming, in a motivational voice. The coach view shows the words beside the coach as it speaks them: do not repeat them in the chat; while the view is showing the coach, your chat reply is one short line naming what you looked up. Speaking as yourself, Claude, rather than as the coach (your lines in a script the person plays, or when they ask for you), send speaker claude: the view shows Claude's own picture and speaks in the voice the person chose for Claude. view switches the picture now (avatar, claude, or camera: the person's own camera, which their browser asks them to allow); whoever speaks next takes it back. Use the coach_id open_coach returned. The answer says what was queued; a queued line is not evidence the person heard it.

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": {
      "coach_id": "<coach_id>"
    },
    "name": "coach_say"
  }
}

Input Schema

Name	Required	Description
`cues`	No
`text`	No	What the coach says, as you would say it
`view`	No	Optional: the picture to show now: avatar, claude (the Claude bot) or camera (the person's own camera)
`speaker`	No	Who says it: avatar (the coach; the default) or claude (you, in Claude's own picture and voice)
`coach_id`	Yes	The coach.coach_id open_coach returned
`reply_to`	No	Optional: the message this answers, when it came through the coach

Output Schema

Name	Required	Description	Default
`sent`	No
`limits`	No
`status`	No
`problem`	No
`contract`	Yes
`not_sent`	No
`statement`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / speaker

Added value: +{
+  "description": "Who says it: avatar (the coach; the default) or claude (you, in Claude's own picture and voice)",
+  "enum": [
+    "avatar",
+    "claude"
+  ],
+  "type": "string"
+}

addedInput schema / properties / view

Added value: +{
+  "description": "Optional: the picture to show now: avatar, claude (the Claude bot) or camera (the person's own camera)",
+  "enum": [
+    "avatar",
+    "claude",
+    "camera"
+  ],
+  "type": "string"
+}

AddedNov 3, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: words queue while the coach is still speaking, a short acknowledgment can precede a longer answer, and a queued line is explicitly not evidence the person heard it. It also documents view ownership ('whoever speaks next takes it back') and that the camera view triggers a browser permission prompt. Annotations (readOnlyHint=false, openWorldHint=true) are consistent with a side-effecting speech tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The opening sentence is a run-on that repeats 'the coach' four times and is hard to parse ('queued for the coach and spoken in the voice the person chose on the coach once the coach view holds the coach'). Useful content is present but not front-loaded cleanly, and agent chat-behavior instructions are interleaved with tool mechanics, forcing a re-read to extract the callable facts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-param tool with an output schema, the definition covers ordering, view switching, speaker modes, cue timing, and coach_id provenance, so an agent can call it correctly. Edge cases (nothing open, invalid coach_id, cue failures) are unaddressed but are arguably out of scope given the output 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 already high (83%), and the description still adds meaning: text is phrased as the agent would say it, speaker claude implies Claude's own picture and voice, camera means the person's own camera with a browser prompt, and cues fire at sentence or beat boundaries rather than arbitrarily. The cue arguments are delegated to GoldAvatar's own tool rather than explained, a minor gap.

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 verb+resource is specific: speak words through the open coach, with an optional speaker override and view switch. It distinguishes the avatar (the coach) from the claude speaker mode explicitly, so an agent knows this is the speech-output tool rather than coach_listen or open_coach. It stops short of naming coach_listen as the counterpart, so it is clear but not fully sibling-differentiated.

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?

Strong contextual guidance: keep the coach talking while a GoldSeam service runs, do not repeat the spoken words in chat, and give a one-line chat reply naming what was looked up. It also tells the agent when to send speaker claude (speaking as yourself, not as the coach) and how view switching interacts with who speaks next. No explicit 'do not use when' or named alternative tool, which keeps it below a 5.

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

All goldseam tools Inspect

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.