VarynForge

Generate article brief

generate_article_brief

Forge a writer-ready brief from an article suggestion. channel picks the brief template: article (default, SEO article outline), reels (hook/beats/shot list), youtube (retention beats/chapters), x (thread posts), linkedin (carousel slide deck: cover hook, one-idea slides, recap, CTA). A suggestion holds one brief per channel — generating a second channel adds a brief without touching the others. When the suggestion already has an article brief, channel briefs DERIVE from it (its key points, hook, and keyStats flow into the channel shape) and are free — they do not consume a daily brief slot. Idempotent per channel: if that channel already has a brief, returns it without consuming a slot; pass force: true to regenerate it. When regenerating, pass guidance — corrective direction the forge must follow (e.g. the angle the operator actually wants, a section to drop, an audience correction) — instead of re-rolling blind and hoping. Free tier: 10/day for article briefs and non-derived channel briefs. Returns { entitlement } when the daily cap is reached.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`force`	No
`channel`	No
`guidance`	No
`projectId`	Yes
`articleSuggestionId`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

The description goes beyond the annotations (which only say readOnlyHint=false, destructiveHint=false) to disclose crucial behavioral traits: idempotency per channel, derivation from existing article briefs, the effect on daily slot consumption, and the return of '{ entitlement }' when the daily cap is reached. This transparency is essential for an agent to understand side effects and constraints, and it is accurately aligned with the annotations (it is a generative, non-destructive operation).

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?

The description is moderately long but each sentence is purposeful, covering the core functionality, channel templates, derivation logic, idempotency, guidance usage, and free tier limits. It is front-loaded with the primary action, then details. It is dense but not verbose; it could be slightly shortened by removing some redundant qualifiers, but overall it earns a high score for structure.

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?

Given the tool's moderate complexity (5 parameters, multiple channels, derivation logic, idempotency, entitlement), the description is remarkably complete. It covers all key behavioral aspects an agent needs to know: what channels exist, how they affect cost, when to use force and guidance, and what to expect on quota exhaustion. Since there is no output schema, the description explains the '{ entitlement }' return case. Nothing essential is missing for correct invocation.

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?

In the absence of schema descriptions (0% coverage), the description compensates by explicitly explaining the 'channel' enum's possible values and their meaning. It also explains the semantics of 'force' and 'guidance' in context. However, it does not explicitly describe 'articleSuggestionId' and 'projectId' beyond their names, but their purpose is inferable from the tool's name and context. This is strong compensation, but a slight gap remains for the id parameters.

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 description clearly states the tool's purpose: generating a writer-ready brief from an article suggestion, with a specific verb 'forge' and resource. It distinguishes itself from siblings by detailing how different channels produce different brief types (article, reels, youtube, x, linkedin), and by explaining the derivation logic and idempotency. This makes it unambiguous what the tool does and how it differs from, for example, get_article_brief or update_article_status.

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?

The description provides explicit guidance on when to use this tool: to generate a brief for a specific channel, with clear instructions on when to pass 'force' (to regenerate) and when to pass 'guidance' (when regenerating). It also explains the free tier limits and the behavior when the cap is reached. It implies when not to use it (e.g., when just fetching a brief, use get_article_brief) by describing generation vs retrieval. This is comprehensive usage guidance.

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

All VarynForge tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation4/5

Most tools have distinct purposes, but a few pairs could confuse an agent: add_article_suggestion vs create_article_suggestion_with_input, and get_article_brief vs download_brief_markdown vs get_write_handoff all deal with brief content. The detailed descriptions help disambiguate, but the overlap is real.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case (create_project, list_opportunities, generate_article_brief, lint_draft). There is no mixing of camelCase, acronyms, or vague verbs, making the naming predictable and readable.

Tool Count2/5

50 tools is excessive for an MCP server, even for a broad platform like content operations. While the scope is large, this many tools will overwhelm agents and increase latency and context cost. Most practical servers are well under 25.

Completeness4/5

The tool surface covers the full content lifecycle: project creation, research, opportunity clustering, content planning, briefs, drafting, linting, publishing, and reporting. Minor gaps exist (e.g., no delete_project, no remove_destination, no direct analytics beyond distributions), but they are workarounds or handled in the web UI.

Resources

Need Help?