Skip to main content
Glama
Sign In

Courier

by io.github.trycourier
OverviewDiscussionsAdmin

release_user_digest

Release one recipient's held digest for a topic now, instead of waiting for its schedule. Use it to preview a digest, or to let a user flush their own, without releasing everyone else on the schedule. There is no release-everyone form of this call; use release_digest with a schedule id for that.

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": {
      "section_id": "<section_id>",
      "topic_id": "<topic_id>",
      "user_id": "<user_id>"
    },
    "name": "release_user_digest"
  }
}

Input Schema

NameRequiredDescriptionDefault
user_idYesThe recipient whose digest to release
topic_idYesId of the digest topic
tenant_idNoThe recipient's tenant, when they were sent to as part of one
section_idYesId of the preference section the topic belongs to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations give some safety context (readOnly=false, idempotent=false, destructive=false). The description adds meaningful behavioral context beyond that: the operation is immediate, scoped to one user, and does not affect other schedule recipients. It does not explicitly state whether the schedule for that user is altered or whether the release is permanent, but the core side effect is clear.

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?

Three tightly-written sentences: the first states the action, the second gives use cases, and the third explicitly routes to the sibling tool. Every sentence earns its place, and the most important information is front-loaded.

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 low-complexity mutation with complete schema and basic annotations, the description is nearly complete. It explains the 'held digest' concept, the single-recipient scope, and the distinction from the sibling. The only minor gap is that no return value or success indication is described, but that is easily inferred for a release action. Overall, nothing critical is missing.

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 each parameter is already documented. The description refers to 'recipient,' 'topic,' and 'schedule,' which maps loosely to user_id, topic_id, and section_id, but it does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.

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?

The description opens with a specific verb-resource pair: 'Release one recipient's held digest for a topic now.' It immediately distinguishes from the sibling release_digest by emphasizing the single-recipient scope and the 'now' action. The first sentence alone uniquely identifies the operation.

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?

Provides explicit use cases: 'preview a digest' and 'let a user flush their own.' It also states an exclusion: 'without releasing everyone else on the schedule.' Finally, it names the exact alternative for the broader operation: 'use release_digest with a schedule id for that.' This is model guidance.

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

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