Narrareach

Update voice profile

update_voice_profile

Idempotent

Set sections of the writer's voice profile when the writer asks you to: how they sound, their niche, their audience, their instructions for drafts, or their topics. Pass only the sections to change; each replaces what is there (topics replaces the whole list). Use the writer's own words and never fill a section in on your own. Style only: it cannot allow invented facts, stories, quotes, or numbers. One call is one change the writer can undo.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_voice_profile"
  }
}

Input Schema

Name	Required	Description
`niche`	No	What the writer writes about. Empty or null clears it.
`topics`	No	The full list of topics the writer covers. Replaces the current list.
`writer`	No	Optional team writer name, handle, or id within the workspace. "me" selects your linked voice. Requires workspace.
`audience`	No	Who the writer writes for. Empty or null clears it.
`workspace`	No	Optional authorized team workspace name or id. Absence selects the authenticated user's personal account.
`howYouSound`	No	How the writer sounds, in their words. An empty string clears it.
`instructions`	No	Standing instructions for drafts, in the writer's words. An empty string clears them.

Output Schema

Name	Required	Description	Default
`undo`	Yes
`changed`	Yes
`profile`	Yes
`connectedAccount`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description goes beyond them by disclosing replacement semantics ('each replaces what is there', 'topics replaces the whole list') and reversibility ('One call is one change the writer can undo'), which links it to undo_voice_change. It is also candid about the style-only limit (no invented facts, stories, quotes, or numbers). It does not explicitly state permission/workspace requirements for mutation, though the schema hints at them.

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?

Front-loaded with the action and the section list, then the operational rules, then the constraint. Every sentence carries a distinct rule; the style-only caveat is slightly compressed but not wasteful.

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?

With annotations, full schema descriptions, and an output schema present, the description supplies exactly the missing pieces: trigger context, partial-update semantics, replacement behavior, and undo-ability. An agent has enough to call it correctly without further inference.

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 the schema already documents every parameter including the empty/null clearing behavior and the topics-replaces-list rule. The description reinforces replace semantics but adds no syntax, format, or length guidance beyond the structured data, so the baseline 3 applies.

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 (Set) and resource (sections of the writer's voice profile) and enumerates exactly which sections are editable (how they sound, niche, audience, instructions, topics). This lets an agent distinguish it from siblings like update_voice_rule, update_voice_stances, and update_voice_examples without opening their schemas.

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?

Explicit trigger condition ('when the writer asks you to'), explicit partial-update instruction ('Pass only the sections to change'), and an explicit prohibition ('never fill a section in on your own'). It also distinguishes scope from related tools by naming the section set it owns.

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

All Narrareach 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.

Resources

Need Help?