Skip to main content
Glama

Cherami

by to.cherami
OverviewDiscussionsAdmin

Get sending rules

get_sending_policy
Read-onlyIdempotent

Check which recipients this inbox may send to, before preparing a send. Only the human can change these rules, in Account > Sending rules; do not send through another inbox to get around them.

Input Schema

NameRequiredDescriptionDefault
inbox_idYes

Output Schema

NameRequiredDescriptionDefault
domainsYesAllowed domains, ASCII and lowercased, matched exactly; a subdomain needs its own entry.
enabledYesfalse: any recipient is allowed. true with no addresses or domains: all sending is blocked.
inbox_idYes
revisionYesVersion of the saved rules.
addressesYesAllowed addresses, matched exactly: in the local part, case, plus tags and dots all count; domain case does not. Every To, Cc and Bcc recipient must match an allowed address or domain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedOutput schema / properties / addresses / description
      Previous value: -"Exact allowed addresses. Local-part case matters; domain case does not. Plus tags and dots remain distinct. Every To/Cc/Bcc recipient must match an allowed address or domain."New value: +"Allowed addresses, matched exactly: in the local part, case, plus tags and dots all count; domain case does not. Every To, Cc and Bcc recipient must match an allowed address or domain."
    • changedOutput schema / properties / domains / description
      Previous value: -"Exact allowed ASCII domains, lowercased. Subdomains are not included unless listed separately."New value: +"Allowed domains, ASCII and lowercased, matched exactly; a subdomain needs its own entry."
    • changedOutput schema / properties / enabled / description
      Previous value: -"False means unrestricted by this control; true with no addresses or domains blocks all sending."New value: +"false: any recipient is allowed. true with no addresses or domains: all sending is blocked."
    • changedOutput schema / properties / revision / description
      Previous value: -"Saved policy version at inspection."New value: +"Version of the saved rules."
  2. Changed1 schema field changed
    • changedOutput schema / properties / revision / description
      Previous value: -"Policy version at inspection, not authorization for a later send."New value: +"Saved policy version at inspection."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive. The description adds real context beyond them: the rules are human-controlled and cannot be modified via the API, and circumventing them via another inbox is forbidden. It doesn't describe what the policy response contains, but with an output schema present that is acceptable.

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?

Two tight sentences, front-loaded with the action and its timing, then the constraint. No wasted words.

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 simple one-param read tool with an output schema and full annotations, this covers what an agent needs: when to call it and the hard constraint on bypassing rules. Slightly short on what the returned policy means, but the output schema carries that.

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?

One required parameter (inbox_id) with 0% schema description coverage; the description implies the policy is scoped to a specific inbox but gives no format or lookup guidance. Baseline 3 for a single-param tool.

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 specific verb and resource ('Check which recipients this inbox may send to') and ties it to the send workflow. It is clearly distinct from the sibling get_receiving_policy and from the send_* tools.

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?

Explicitly says when to use it ('before preparing a send') and adds a when-not/alternative constraint: only the human can change rules, and the agent must not route through another inbox to bypass them. That routing prohibition is genuine, non-obvious guidance.

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

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