Skip to main content
Glama

ScriptGrain

Write a draft in a voice

generate_content

Generate a finished draft in the user's measured voice, with an automatic voice-match score (0-1) against the profile. Two modes: (a) one-shot — pass profile_id + brief + content_type; (b) from an approved outline — pass a generation_id with status 'outline' from create_outline instead (profile_id/brief/content_type are then ignored; the word_count_target set at outline time is honoured automatically, and passing word_count_target here overrides it). The response reports the length measurement — word_count, word_count_target, within_tolerance (±15%) — so check within_tolerance before presenting a draft as on-target, and the id's status becomes 'drafted'. Multiple variants are diversified server-side along declared axes, returned per variant as variant_axis: variant 1 'standard', variant 2 'alternative_opening' (question/concrete-detail opener, different structure), variant 3 'oblique_angle' (mid-scene or counterintuitive opening); variants 2-3 only up to 4,000 words. COSTS CREDITS by length: up to 5,000 words 1 credit, up to 10,000 words 2, up to 15,000 words 3 (the cap), per produced variant (failed variants are not charged). LONG DRAFTS: above 4,000 words the draft is written in the background, section by section, from an outline (a one-shot request gets one made first). The call returns at once with status 'generating', the generation id and a job; call get_job (or get_generation, whose content fills in as sections land) until the job's status is 'succeeded', about a minute per 2,000 words, then get_generation for the finished draft and its voice-match score. Credits are charged as the words are delivered, never above the tier asked for. Don't loop this tool speculatively — confirm with the user before generating many variants, long drafts or re-generating.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefNoWhat to write about, max 8,000 chars (one-shot mode).
registerNoOverride the profile's formality register for this piece.
variantsNoHow many alternative drafts to produce (1-3, default 1; 2-3 only up to 4,000 words). Each costs its own credit. Diversified server-side; each returns its variant_axis.
company_idNoWrite this FOR the user's product/company: a company profile id from list_companies. The draft is grounded in that company's facts, terminology and audience (never invented specifics). Omit company_id to use the voice's default company (set in the app under Voice Brain, when the voice has one); pass null for none.
continuityNoVoice Brain continuity. Default true once the memory knows 10+ pieces: the draft is told what the author has already established on the subject (build on it) and which prior arguments not to repeat. Pass false to write fresh, ignoring the memory.
profile_idNoVoice profile id (one-shot mode; required unless generation_id is set).
template_idNoOne-shot mode: start from a saved brief template (list_brief_templates); it fills every field this call leaves empty. Not with generation_id.
content_typeNoPiece type (one-shot mode). article = standalone long-form article; blog_intro = ONLY the opening section of a blog post, not a full piece; newsletter = an email newsletter issue; email = a single one-to-one or marketing email; short_story = fiction; linkedin = LinkedIn post; social_post = generic short social caption; twitter_thread = X/Twitter thread; instagram_caption = Instagram caption; press_release = press announcement; product_description = catalogue blurb for ONE product; ad_copy = very short advert copy; website_landing = campaign landing page driving one action; website_home = homepage introducing the whole brand; website_product = site page for one product/feature; website_about = about-us page.
generation_idNoA generation_id with status 'outline' (from create_outline) — drafts from that outline instead of one-shot.
english_variantNoEnglish spelling/idiom variant. Defaults to the profile's stored variant.
extra_directionNoOne-off styling guidance for this piece (max 2,000 chars).
idempotency_keyNoOptional retry-safety key: retrying with the same key replays the stored result instead of generating (and charging) again; for a long draft it returns the same job instead of starting a second.
word_count_targetNoTarget length in words (50-15,000, lands within ±15%; each content type has its own range: long-form articles, short stories and the four website page types go to 15,000, newsletters to 5,000, short formats such as linkedin keep short ranges). Credits by length: up to 5,000 words 1 credit, up to 10,000 words 2, up to 15,000 words 3. Above 4,000 words the draft is written in the background: generate_content returns at once with status 'generating'; call get_job or get_generation until the job has succeeded (about a minute per 2,000 words). Omit for the content type's default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false; the description goes well beyond that with credit costs by length tier, per-variant charging, background section-by-section writing above 4,000 words, the 'generating' status and get_job/get_generation polling loop, and the status transition to 'drafted'. It also discloses server-side variant diversification and the within_tolerance contract the caller must check.

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?

Purpose is front-loaded, then modes, response fields, costs, and long-draft behavior in a logical order. The dense stacked-parenthetical style risks overloading a single read, but nearly every sentence carries a distinct operational fact essential for a 13-parameter, dual-mode tool.

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?

There is no output schema, so the description correctly carries the return contract — voice-match score, word_count/word_count_target/within_tolerance, variant_axis, and status — and covers costs, background execution, and the polling alternative. Nothing an agent needs to invoke this 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 the baseline is 3, but the description adds mode-dependent semantics the schema cannot express: which parameters are ignored when generation_id is set, that the outline's word_count_target is honoured automatically but can be overridden here, and the meaning of the variant axes. It stops short of re-documenting fields the schema already covers thoroughly.

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?

The first clause states a specific verb and resource ('Generate a finished draft in the user's measured voice') plus the automatic voice-match scoring behavior. An agent can distinguish this from siblings like create_outline, polish, humanize, and mimic_brand purely from the description.

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?

It explicitly defines the two mutually exclusive modes — one-shot (profile_id + brief + content_type) versus from an approved outline (generation_id with status 'outline' from create_outline) — and states that the one-shot fields are ignored in outline mode. It also adds an explicit when-not ('Don't loop this tool speculatively — confirm with the user before generating many variants, long drafts or re-generating').

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.

Resources