Silvertongue: Write Like Anyone Famous

Get a voice packet

get_voice_packet

Read-onlyIdempotent

Get the instructions for writing in one voice with your own model, for one format, length, platform, intensity, edge, emoji and spelling setting. The packet carries the full VOICE.md, an exact length target fitted to the platform's limit, and the rules that keep the user's own facts and identity. It opens with a line that replaces any earlier voice, so switching voices mid-conversation is one call.

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": {
      "voice": "<voice>",
      "format": "<format>"
    },
    "name": "get_voice_packet"
  }
}

Input Schema

Name	Required	Description	Default
`edge`	No	clean removes swearing, sexual and drug references; full keeps the voice's edge, never slurs or racism.	full
`emoji`	No	on uses the voice's emoji at their real rate; off uses none.	on
`voice`	Yes	A voice slug such as elon-musk for the current edition, or an exact voice ID (slug@sha256:…) from search_voices.
`format`	Yes	post (one standalone post), reply (answers the post being replied to), explanation (connected prose) or thread (several posts).
`length`	No	one-liner, short, standard or long; each maps to a measured range for the format.	standard
`platform`	No	Where the draft will be posted: fits its character limit and whether it takes markdown.	generic
`spelling`	No	voice types the way they type; tidy keeps the way they talk and types it properly.	voice
`intensity`	No	light lets the user's own phrasing show; full writes completely in the voice.	full

Output Schema

Name	Required	Description	Default
`data`	Yes
`release_id`	Yes	The Provenry release every voice in this answer was read from.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

addedInput schema / properties / emoji

Added value: +{
+  "default": "on",
+  "description": "on uses the voice's emoji at their real rate; off uses none.",
+  "enum": [
+    "on",
+    "off"
+  ],
+  "type": "string"
+}

addedInput schema / properties / spelling

Added value: +{
+  "default": "voice",
+  "description": "voice types the way they type; tidy keeps the way they talk and types it properly.",
+  "enum": [
+    "voice",
+    "tidy"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / data / properties / emoji

Added value: +{
+  "enum": [
+    "on",
+    "off"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / data / properties / spelling

Added value: +{
+  "enum": [
+    "voice",
+    "tidy"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / data / required

Previous value: -[
-  "voice_id",
-  "name",
-  "format",
-  "length",
-  "platform",
-  "intensity",
-  "edge",
-  "target",
-  "instructions",
-  "notice"
-]New value: +[
+  "voice_id",
+  "name",
+  "format",
+  "length",
+  "platform",
+  "intensity",
+  "edge",
+  "emoji",
+  "spelling",
+  "target",
+  "instructions",
+  "notice"
+]

First observedNov 2, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety bar is lower. The description does add real behavioral context not visible in annotations: a packet contains the full VOICE.md, an exact length target, rules preserving the user's facts, and a leading line that overrides any earlier voice. It stops short of describing the response structure despite a structured output schema existing, so the extra value is moderate.

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

Conciseness4/5

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

Three sentences, front-loaded with the core action and the returned artifact. The middle sentence lists packet contents efficiently. The parameter enumeration in sentence one is slightly redundant given the schema, but the overall structure is tight and readable.

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?

This is an eight-parameter tool with an output schema, so the description needn't explain return values, and it correctly focuses on what the packet contains and how voice switching works. The main missing element is explicit guidance on selecting this tool over get_voice or search_voices and where the voice slug comes from, though the schema's voice parameter hints at search_voices.

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 coverage is 100% with enums and per-parameter descriptions already documenting every setting, including edge, emoji, length, spelling, and intensity semantics. The description merely echoes the parameter list ('one format, length, platform, intensity, edge, emoji and spelling setting') without adding format or constraint details. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb and resource: 'Get the instructions for writing in one voice with your own model,' and enumerates the settings that parameterize the packet. It is clearly distinguishable from sibling tools like get_voice or search_voices. It falls short of 5 only because the object returned ('the voice packet') is described in terms of its contents rather than a crisp one-line definition.

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?

The phrase 'for writing in one voice with your own model' implies the use case, and the closing sentence says switching voices mid-conversation is one call. But it never explicitly says when to use get_voice_packet versus get_voice or search_voices, nor does it state prerequisites like needing a slug from search_voices. Usage is inferable, not stated.

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

All Silvertongue: Write Like Anyone Famous tools Inspect

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.