Famous writing voices for your agent. Find a voice, read how it was studied, and write in it with your own model.
Scored across 4 tools
The four tools have mostly distinct roles: search for discovery, get_voice for profiles, get_voice_packet for generation instructions, and get_changes for cache synchronization. However, search_voices with no query and get_changes with an empty list both enumerate all voices, and get_voice versus get_voice_packet could be confused at a glance.
All names use consistent snake_case with a clear verb_noun pattern: get_changes, get_voice, get_voice_packet, search_voices. The use of get versus search is semantically predictable.
Four tools is well-scoped for a read-only voice-writing service: discovery, profile retrieval, packet generation, and update synchronization. Each tool has a clear reason to exist and no obvious redundancy.
The surface covers the core lifecycle: finding voices, inspecting them, generating writing packets, and syncing changes. A minor gap is the lack of a dedicated way to discover valid packet parameters such as formats, platforms, intensity levels, and edge options before calling get_voice_packet.
Compare the voice IDs your agent has cached with the current release: voices added, voices re-studied as a new edition, and voices removed. Pass an empty list to receive every voice as added.
| Name | Required | Description | Default |
|---|---|---|---|
| known | Yes | The exact voice IDs your agent has cached. |
| Name | Required | Description |
|---|---|---|
| added | Yes | |
| removed | Yes | |
| restudied | Yes | |
| unchanged | Yes | |
| release_id | Yes | The Provenry release every voice in this answer was read from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety burden is covered. The description adds real behavioral value by defining the three result categories (added / re-studied as a new edition / removed) and the empty-input shortcut, though it says nothing about result size or what happens to malformed or unknown IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the comparison operation and followed by the one edge-case rule an agent needs. Nothing is redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one fully documented parameter, an output schema, and rich annotations; the description fills the remaining conceptual gap — what the diff categories mean and how to request a full listing. An agent can call this correctly without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the slug@sha256 digest form, so the baseline is 3. The description goes beyond it by giving the empty-list semantics, which the schema does not state and which is the key non-obvious usage of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it compares the caller's cached voice IDs against the current release and reports added, re-studied, and removed voices. This is clearly distinct from the fetch-one (get_voice), packet (get_voice_packet), and lookup (search_voices) siblings, which do not describe a diff operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear — syncing a local cache with the current release — and states the bootstrap case (empty list returns everything as added). It does not explicitly name siblings or say when not to use it (e.g., fetching a single voice by ID), so a small routing gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one voice's full profile: its VOICE.md, every source studied with a note on what it shows, the observations drawn from them, a handwritten example, the licence and the attribution line. Profiles are unofficial studies of public writing technique; the people named did not write or endorse them.
| Name | Required | Description | Default |
|---|---|---|---|
| voice | Yes | A voice slug such as elon-musk for the current edition, or an exact voice ID (slug@sha256:…) from search_voices. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| release_id | Yes | The Provenry release every voice in this answer was read from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds non-obvious context the annotations cannot: the profile's editorial nature ('unofficial studies of public writing technique; the people named did not write or endorse them'), which shapes how an agent should present the content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: contents first, caveat second. The long enumeration in sentence one is dense but each listed item is informative rather than filler; no redundancy with annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, rich annotations, and a fully documented single parameter, the description needs only to frame purpose and caveats, which it does. The one gap is sibling disambiguation (get_voice vs get_voice_packet), which would be the finishing touch for a retrieval tool with a near-namesake.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter already documents both slug and exact-ID forms, so the description adds nothing about the `voice` argument. Baseline 3 applies since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one voice's full profile') and then enumerates the actual contents — VOICE.md, sources, observations, handwritten example, licence, attribution — so an agent knows exactly what comes back. It is clearly distinct from search_voices (which returns IDs) and get_voice_packet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Using it after a search is implied by the schema's mention of an ID 'from search_voices', but the description itself gives no when-to-use/when-not guidance and never contrasts itself with get_voice_packet, its closest sibling. The agent must infer the choice between the two packet/profile tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the instructions for writing in one voice with your own model, for one format, length, platform, intensity and edge. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| edge | No | clean removes swearing, sexual and drug references; full keeps the voice's edge, never slurs or racism. | full |
| 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 |
| intensity | No | light lets the user's own phrasing show; full writes completely in the voice. | full |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| release_id | Yes | The Provenry release every voice in this answer was read from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the lower bar applies, yet the description still adds real behavioral context: the packet contains the full VOICE.md, a platform-fitted length target, and rules preserving the user's facts and identity. Most valuable is the disclosure that the packet 'opens with a line that replaces any earlier voice' — a conversational side effect an agent could not infer from readOnlyHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and the packet's contents, closing with the voice-switching affordance. Dense and largely waste-free, though 'with your own model' and the inventory phrasing lean slightly toward promotional rather than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, rich annotations, and full schema coverage, the description need only explain intent and behavior — and it does, including what the packet contains and the voice-replacement effect. The one gap is the unstated relationship to get_voice, leaving the agent to guess which of the two to call for a given need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and five of six parameters are enums with documented values, so the schema carries the semantics. The description only restates the parameter names and adds one useful relational hint — that length is fitted to the platform's limit — which is a modest increment over the schema rather than a compensation for a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource — it returns writing instructions for one voice, parameterized by format, length, platform, intensity and edge — and enumerates the packet's contents (VOICE.md, length target, fact/identity rules). It never names the siblings get_voice or search_voices, so the agent must infer on its own why it would want a 'packet' rather than the voice itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the parameter list and by the closing note that 'switching voices mid-conversation is one call', which is a genuine use case. However, there is no explicit when-not guidance and no mention of when to call get_voice or search_voices instead, which matters given three sibling tools in this namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Silvertongue's famous writing voices by name, by lane (tech, celebrity, comedy, classics, politicians), or by what the writing should do: a roast, a launch post, a plain explanation, a speech. Each result gives the voice ID, its lane, what the voice does, what was studied, its strengths and limits, and its status. Omit the query to list every voice, featured voices first.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | Only voices in this lane. | |
| limit | No | Maximum results to return; defaults to 25. | |
| query | No | A person's name, a lane, or what you want the writing to do. Omit to list every voice. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| total | Yes | |
| truncated | Yes | |
| release_id | Yes | The Provenry release every voice in this answer was read from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavior beyond those hints by specifying result ordering (featured voices first) and what each result contains, though it does not discuss pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly structured sentences with no wasted text. Search scope is front-loaded, followed by concrete examples and a concise summary of return fields and default listing behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage, read-only annotations, and an output schema, the description supplies everything needed for correct invocation: searchable dimensions, lane names, query omission behavior, and result ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents lane, limit, and query semantics. The description reinforces the searchable concepts and omission behavior but does not add syntax or constraints beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Search Silvertongue's famous writing voices") and immediately clarifies the searchable dimensions: name, lane, or writing purpose. It also distinguishes the result type from apparent siblings like get_voice, which retrieves a single voice rather than searching across them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: search by name, lane, or intended writing function, and explicitly states that omitting the query lists every voice with featured voices first. It does not explicitly compare against sibling tools such as get_voice, but the usage scenario is still easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_voice2 fields changedOutput schema / properties / data / properties / evaluationRemoved value: -{
- "const": "unbenchmarked",
- "description": "unbenchmarked: not yet blind-tested against a name-only prompt.",
- "type": "string"
-}Output schema / properties / data / requiredPrevious value: -[
- "voice_id",
- "slug",
- "name",
- "lane",
- "featured",
- "move",
- "description",
- "scope",
- "studied",
- "strengths",
- "limitations",
- "status",
- "evaluation",
- "page_url",
- "voice_md_url",
- "voice_md",
- "voice_md_digest",
- "sources",
- "observations",
- "illustration",
- "licence",
- "licence_url",
- "attribution",
- "notice"
-]New value: +[
+ "voice_id",
+ "slug",
+ "name",
+ "lane",
+ "featured",
+ "move",
+ "description",
+ "scope",
+ "studied",
+ "strengths",
+ "limitations",
+ "status",
+ "page_url",
+ "voice_md_url",
+ "voice_md",
+ "voice_md_digest",
+ "sources",
+ "observations",
+ "illustration",
+ "licence",
+ "licence_url",
+ "attribution",
+ "notice"
+]search_voices2 fields changedOutput schema / properties / data / items / properties / evaluationRemoved value: -{
- "const": "unbenchmarked",
- "description": "unbenchmarked: not yet blind-tested against a name-only prompt.",
- "type": "string"
-}Output schema / properties / data / items / requiredPrevious value: -[
- "voice_id",
- "slug",
- "name",
- "lane",
- "featured",
- "move",
- "description",
- "scope",
- "studied",
- "strengths",
- "limitations",
- "status",
- "evaluation",
- "page_url",
- "voice_md_url"
-]New value: +[
+ "voice_id",
+ "slug",
+ "name",
+ "lane",
+ "featured",
+ "move",
+ "description",
+ "scope",
+ "studied",
+ "strengths",
+ "limitations",
+ "status",
+ "page_url",
+ "voice_md_url"
+]get_changesget_voiceget_voice_packetsearch_voices
Add one secure layer between your agents and this server.