Skip to main content
Glama

Mute authors

mute_authors
Idempotent

Adds authors to an alert's muted list and keeps the rest of the filter. Entries can be profile or post links, @handles, u/names, Bluesky DIDs or display names. Links are stored as the author's profile. Authors already on the list are skipped, and entries that don't name a person are refused.

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": {
      "authors": "<authors>",
      "id": "<id>"
    },
    "name": "mute_authors"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe alert's id
authorsYesA profile link (x.com/name, linkedin.com/in/name, reddit.com/user/name), post link, handle (@name, u/name), Bluesky DID or display name. Links are stored as the author's profile. A bare name or handle covers every platform.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the mutation/idempotency/safety profile, and the description usefully corroborates and extends it: duplicates are skipped (matches idempotentHint=true), the rest of the filter is preserved (matches non-destructive), and non-person entries are refused. Refusal and link-normalization behavior ('links are stored as the author's profile') is genuinely additive context not present in the annotations.

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 tight sentences, each carrying distinct information: the mutation and its scope, accepted input formats and normalization, then the skip/refuse edge cases. Front-loaded with the operation and no filler.

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 mutation with no output schema, the description covers formats, dedup behavior, refusal behavior, and non-destructive scoping. Only the return/effect of the call (e.g., what the updated muted list looks like) is unaddressed, a minor gap given the annotations.

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%, and the authors parameter's schema description already lists profile/post links, handles, Bluesky DIDs and display names — the description largely restates this. It adds only marginal value (the refusal condition), so the baseline 3 for full schema coverage is appropriate.

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 specific verb and resource with scope: 'Adds authors to an alert's muted list.' The mute/unmute distinction from the sibling unmute_authors is obvious from the verb, but the description never explicitly names or contrasts any sibling, so it stops short of a 5.

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?

Usage is only implied — the agent can infer you call this when you want authors silenced on an alert. There is no explicit when-to-use, no pointer to unmute_authors for the inverse operation, and no stated prerequisite (e.g., that the alert must already exist).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.