Skip to main content
Glama
Sign In

Chorus

by com.choruskeepsake
OverviewDiscussionsAdmin

Send the link to everyone, and get the tap that puts it in a group chat.

send_it_out
Idempotent

Emails the invitation once to every person added with an address, and returns a tap that opens WhatsApp, a text or a mail draft with the message and the link already written, for the family group and for anyone with no address. Nobody gets the invitation twice, and each caller has a daily limit on emails.

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": {
      "book": "<book>"
    },
    "name": "send_it_out"
  }
}

Input Schema

NameRequiredDescriptionDefault
bookYesThe book’s handle.
also_emailNofalse returns the taps and sends nothing. Without it, the invitation is emailed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / also_email / description
      Previous value: -"Leave it out to send the invitation. Set it false to get the taps only and send nothing."New value: +"false returns the taps and sends nothing. Without it, the invitation is emailed."
    • changedInput schema / properties / book / description
      Previous value: -"The handle start_book gave you."New value: +"The book’s handle."
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare non-read-only, idempotent, open-world, non-destructive, so the bar is lower; the description still adds real value by disclosing the per-caller daily email limit and the no-duplicate-send guarantee, plus the fact that the return value is a usable link/tap rather than a status. It stops short of saying what happens on failure or what the returned tap looks like.

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

Conciseness5/5

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

A single compact sentence that front-loads the two outcomes (email sent, tap returned) and then qualifies them. No filler, no repetition of the title.

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?

For a two-parameter tool with no output schema, the description covers the side effect, the idempotency guarantee, the rate limit, and what comes back. Only error/edge behavior and the shape of the returned tap are left unstated.

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?

Schema description coverage is 100%, so the baseline is 3; the description restates the suppress-email behavior that the also_email parameter description already carries and adds nothing about the book handle beyond what the schema says.

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?

States a concrete verb and resource: emails the invitation to every person with an address, and returns a tappable link for WhatsApp/text/mail. That distinguishes it from siblings like add_people or chase_the_missing, though the phrase 'the tap' is jargon-heavy and the sentence is long enough that the core action isn't as crisp as it could be.

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

Usage Guidelines3/5

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

Gives situational context — use it for the family group and for anyone with no address — and notes that suppress-email behavior exists, but it never names an alternative tool or spells out the condition that would send an agent to preview_pages or chase_the_missing instead. Usage is implied rather than stated.

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

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