Narrareach

Create generated notes

create_generated_notes

Generate short notes in the writer's voice with Narrareach's note generator, from their own writing (source "profile") or from an article or post you pass in. Each note comes with a suggested time that avoids what is already on their calendar. This saves and schedules nothing: show the notes to the writer, then schedule each one they approve with schedule_note, passing the note as content, the platforms, its suggestedTime unchanged as scheduledFor (it is an absolute time) unless the writer picks another, the same workspace you used here, and this result's requestId as generationId. To schedule several approved notes at once, use schedule_notes with the same fields per note and a clientRequestId for each. Use create_draft only to keep a note unscheduled in the personal account (no workspace); it cannot save into a team workspace. Up to 10 notes per call and 20 calls per day; a call can take a minute or two.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	How many days ahead to spread the suggested times over. Defaults to 7.
`tone`	No	Optional tone. Defaults to PEER_TO_PEER.
`count`	No	How many notes to generate. Defaults to 5. Some may be left out if they fail quality checks.
`source`	No	What to generate from. "profile" (default) uses the writer's own writing and voice; the others need postContent and postTitle.
`postUrl`	No	Optional link to that article or post, so notes can point to it.
`timezone`	No	Optional IANA time zone used when the writer has no saved posting schedule, such as America/Toronto.
`platforms`	No	Optional platforms the notes are for, so they fit each platform's length limit.
`postTitle`	No	The title of that article or post. Required unless source is "profile".
`workspace`	No	Optional authorized team workspace name or id. Absence selects the authenticated user's personal account.
`postContent`	No	The article or post text to draw notes from. Required unless source is "profile".
`cadenceResolution`	No	What to do when the count does not fit the writer's usual posting rhythm: "extend_window" (default) spreads notes over more days; "increase_daily" posts more each day.
`customInstructions`	No	Optional instructions from the writer for this batch, in their words.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tone`	Yes
`notes`	Yes
`source`	Yes
`cadence`	No
`persona`	Yes
`quality`	Yes
`requestId`	Yes
`connectedAccount`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real behavioral context beyond annotations: it persists nothing, enforces up to 10 notes per call and 20 calls per day, and a call can take a minute or two. It also explains the chaining contract (pass note as content, suggestedTime unchanged as scheduledFor, requestId as generationId). Doesn't contradict the readOnlyHint=false/destructiveHint=false profile.

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 purpose, then the scheduling workflow, then limits. It's a dense single paragraph but every clause earns its place; a slightly tighter structure with the limits broken out would be the only improvement.

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?

For a 12-parameter, non-mutating generation tool with an output schema, it covers purpose, downstream workflow, rate limits, latency, and workspace-scoping caveats. Nothing an agent needs to invoke and chain it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, and the description adds value by tying parameters to the downstream call (workspace, platforms, suggestedTime as an absolute time). It meaningfully clarifies how the schema fields carry into scheduling rather than restating them.

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+resource ('Generate short notes in the writer's voice') plus the two source modes (own writing/profile vs. a passed-in article or post). It also distinguishes itself from siblings by explicitly noting it 'saves and schedules nothing,' separating it from schedule_note and create_draft.

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 routes the agent: show notes to the writer, then schedule approved ones with schedule_note (or schedule_notes for batches), and use create_draft only to keep an unscheduled note in the personal account since it cannot save into a team workspace. When/when-not and alternatives are all named.

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?