BetterPost

Generate content

betterpost_generate_content

Generate a new piece of content for a project from its timely, relevant stories. Fast in steady state. Charges credits on success only. If you pass a topic the project has no stories about, this returns a topic_unavailable error (no charge) carrying an inScope flag and next steps — it never silently writes an off-topic piece.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	Yes	Output format. 'x' and 'bluesky' are generated as a single post or, more often, a short numbered thread of connected posts (multiple tweets) when there is enough to say — this is the default for those channels. 'blog', 'newsletter', and 'linkedin' are one piece.
`reuse`	No	Reuse the most recent topic.
`tieIn`	No	A product/service to weave in.
`topic`	No	Steer the piece to a specific topic. Generation only writes from stories actually about it. If none exist yet, it returns topic_unavailable (no charge) with an inScope flag: inScope:true means the topic fits the project and betterpost_expand_coverage can gather it, while inScope:false means it is outside the project scope so expanding to it requires the user's confirmation.
`projectId`	Yes
`wordLimit`	No

Output Schema

TableJSON Schema

Name	Required	Description
`type`	Yes
`topic`	Yes
`content`	Yes	The generated content. Fields present depend on `type`.
`summary`	Yes
`contentId`	Yes
`publicUrl`	Yes
`storyCount`	Yes
`imagesHosted`	Yes
`creditsCharged`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

The description adds significant behavioral details beyond annotations: fast performance, credit charging on success only, and error behavior (topic_unavailable with inScope flag, never silent off-topic generation). Annotations only indicate read/write, idempotence, and destructiveness, which are consistent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences), front-loads the primary purpose, and includes only necessary behavioral and billing details without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, billing, and error handling adequately. It lacks explicit prerequisites (e.g., need stories in project) and does not differentiate from sibling tools, but the presence of an output schema reduces the need to describe return values.

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?

The input schema already provides rich descriptions for all parameters, including error handling for the topic parameter. The tool description repeats this information without adding new parameter-specific insights. With high schema coverage, the description adds minimal value to parameter understanding.

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 explicitly states 'Generate a new piece of content for a project from its timely, relevant stories,' which is a specific verb+resource combination. It distinguishes from siblings like 'derive_content' (likely for refining) and 'expand_coverage' (for gathering stories).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clarifies when to use the tool (to generate content from stories) and explains error handling for missing topics. However, it does not explicitly compare to sibling tools or state when not to use it, missing some guidance for alternative selection.

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

All BetterPost 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

A4/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose—project management, source and story handling, content generation, settings, and usage—with no overlapping functionality. The descriptions clearly delineate when to use each tool.

Naming Consistency5/5

All tools follow the consistent pattern 'betterpost_<verb>_<noun>', making the set predictable and easy to navigate. The naming convention is uniform throughout.

Tool Count5/5

With 23 tools, the server covers a comprehensive content generation workflow without being overwhelming. Each tool serves a necessary function, and the count feels well-scoped for the domain.

Completeness5/5

The tool surface covers the full lifecycle of project management, source acquisition, story curation, content generation/derivation, and settings configuration. There are no obvious gaps that would cause an agent to fail in typical use cases.

Generate content

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources