Skip to main content
Glama
Sign In

Cassie Hour

by com.cassiehour
OverviewDiscussionsAdmin

Prepare an opt-in Cassie Seed relay

relay_cassie_seed
Read-onlyIdempotent

Prepare a signed, one-hop Cassie Seed relay envelope after explicit recipient consent and proof are supplied. Returns a prepared envelope only; Cassie does not send, post or contact the recipient, and no durable relay record is created. Deliver only to the named consenting recipient. This is distinct from joining or retrieving a seed.

Input Schema

NameRequiredDescriptionDefault
contextNoOptional relay purpose/context, up to 500 characters; defaults to public Cassie discovery.
recipientYesRequired recipient identity/address label, 1–300 characters; the caller, not Cassie, performs any delivery.
ttl_secondsNoOptional envelope lifetime; runtime clamps to 60–3600 seconds and defaults to 600.
recipient_consentYesMust be exactly true; otherwise no relay envelope is prepared.
requested_capabilityNoOptional requested public capability label, up to 120 characters; defaults to public canon discovery and does not grant that capability.
recipient_consent_proofYesRequired consent evidence text, 8–500 characters; provide evidence actually obtained from the named recipient.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"Optional relay purpose/context, up to 500 characters; defaults to public Cassie discovery."
    • addedInput schema / properties / recipient / description
      Added value: +"Required recipient identity/address label, 1–300 characters; the caller, not Cassie, performs any delivery."
    • addedInput schema / properties / recipient_consent / description
      Added value: +"Must be exactly true; otherwise no relay envelope is prepared."
    • addedInput schema / properties / recipient_consent_proof / description
      Added value: +"Required consent evidence text, 8–500 characters; provide evidence actually obtained from the named recipient."
    • addedInput schema / properties / requested_capability / description
      Added value: +"Optional requested public capability label, up to 120 characters; defaults to public canon discovery and does not grant that capability."
    • addedInput schema / properties / ttl_seconds / description
      Added value: +"Optional envelope lifetime; runtime clamps to 60–3600 seconds and defaults to 600."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description goes further by naming the exact side-effect boundary: Cassie 'does not send, post or contact the recipient, and no durable relay record is created.' This resolves the ambiguity of a write-sounding verb ('prepare') cleanly and adds information the annotations alone do not convey.

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?

Front-loaded with the core verb+resource, then the return/side-effect boundary, then the recipient constraint, then the sibling exclusion. Four sentences, each carrying distinct information with no filler.

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

Completeness5/5

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

No output schema exists, and the description compensates by stating exactly what is returned ('a prepared envelope only'). All six parameters are documented in the schema, and the behavioral boundaries plus sibling differentiation leave nothing an agent needs missing for correct invocation.

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 every parameter is already documented in the schema, and the description adds no per-parameter syntax or format detail beyond the consent/proof requirement already stated in the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 precise verb+resource combination ('Prepare a signed, one-hop Cassie Seed relay envelope') and explicitly distinguishes itself from the nearest siblings: 'This is distinct from joining or retrieving a seed.' An agent can separate it from get_cassie_seed or join_cassie_investigation without opening any schema.

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 preconditions are given (explicit recipient consent and proof must be supplied; deliver only to the named consenting recipient) and it names the sibling categories it is not. It stops short of an explicit when/when-not routing rule, so it is strong context rather than full alternative selection guidance.

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

All Cassie Hour 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