Generate platform-native social posts that are humanized, AI-detection scored and illustrated.
Scored across 3 tools
Each tool has a clearly distinct purpose: generate_social_post creates a job, check_social_job polls it, and list_social_platforms enumerates options. There is no overlap—generation, status lookup, and metadata listing are unambiguous.
All three tools use consistent snake_case with a verb_noun pattern (generate_social_post, check_social_job, list_social_platforms). The convention is predictable and readable throughout.
Three tools is on the thin side but each earns its place in the async job lifecycle (create, poll, list options). The scope is narrow, so a small count is justified rather than a mismatch.
The core generate-then-poll workflow is fully covered, plus platform discovery. Minor gaps exist—no job cancellation or listing of past jobs—but agents can work around these for the stated purpose.
Look up a social post generation job by id. Returns the finished posts once the job completes, or its current progress while it runs. Costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id returned by generate_social_post. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior, so the bar is lowered. The description still adds value beyond them: the polling/return semantics (progress while running, posts when complete) and the 'Costs nothing' billing note, which is not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the core action and followed by the return-value behavior. Every clause earns its place, including the cost note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does describe the two outcomes (in-progress vs. completed). It does not cover failure or not-found behavior, but for a simple idempotent polling tool this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already explains that job_id comes from generate_social_post. The description adds no additional parameter detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('look up a social post generation job by id') with clear scope, and is trivially distinguishable from the sibling generate_social_post (which creates rather than inspects a job). An agent knows exactly what it retrieves without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the intended lifecycle use — poll this while a job runs, and call it to get the finished posts once the job completes — and the param doc ties it to generate_social_post. It gives clear context but does not explicitly state when-not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a social media post for a given platform and topic. The post is written to that platform's conventions, rewritten to read as human-authored, optionally scored against AI detection, and optionally illustrated with a generated image. Returns a job id immediately — poll it with check_social_job, which usually completes in 20-90 seconds. Costs credits.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Defaults to friendly. | |
| emoji | No | Add emoji to the post. Omit for automatic: off on LinkedIn and YouTube, on elsewhere. Set false for a clean post on any platform. | |
| topic | Yes | What the post should be about. | |
| language | No | Output language by name. Defaults to English. | |
| platform | Yes | Target platform. Each has its own style guide and default length. | |
| preserve | No | Exact lines that must appear verbatim in the finished post — a closing question, a call to action, a tagline. The humanizer rewrites sentences, so anything whose exact wording matters belongs here rather than only in the topic. | |
| quantity | No | How many distinct variations to generate. Defaults to 1. | |
| detect_ai | No | Score the post against AI detection and retry if it reads as machine-written. Adds 8 credits per post. Omit for automatic: runs only at 150+ words, because short posts score unreliably. | |
| brand_name | No | Brand to mention where it reads naturally. | |
| brand_tone | No | Voice guidance, e.g. 'Direct, no jargon'. | |
| word_count | No | Target length per post. Omit to use the platform default (LinkedIn 100, YouTube 150, Facebook/Pinterest 75, Instagram/TikTok 50, X 40). | |
| brand_audience | No | Who the post should speak to. | |
| brand_keywords | No | Comma-separated terms to work in. | |
| generate_image | No | Generate a matching image for the post. Defaults to false over MCP; pass true to request one. Adds 10 credits per post. | |
| brand_description | No | What the business does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly=false, openWorld=true, idempotent=false) by disclosing that the call is asynchronous, returns a job id rather than content, takes 20-90 seconds, and consumes credits. These are the details an agent most needs and none are derivable from the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the core purpose and terminating with the two facts an agent must act on (async job id + polling, credit cost). No redundant restatement of name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter async generation tool with no output schema, the description supplies the missing pieces: the return contract (job id), the follow-up tool, expected latency, and cost signaling. Combined with a fully documented schema, an agent has everything needed to invoke and follow through.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (tone, emoji, detect_ai, generate_image, word_count, preserve, etc.) is already documented in the schema, including defaults and credit costs. The description only gestures at the optional AI-scoring and image features, adding no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Write a social media post') scoped by platform and topic, then enumerates the pipeline steps (platform conventions, humanizer rewrite, optional AI scoring, optional image). It also names the sibling it hands off to (check_social_job), so an agent can place it in the workflow without inspecting other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational context: it returns a job id immediately and must be polled via check_social_job, with a 20-90 second expectation. It does not state exclusions or when to prefer a sibling over this tool, but for a generation entry point the routing guidance is essentially complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the platforms generate_social_post supports, with each one's default post length and emoji policy. Costs nothing and makes no network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new operational context: zero cost and no network call, which tells the agent this is a safe, local, cacheable lookup worth calling freely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The value proposition (what it returns) comes first and the behavioral reassurance (free, no network) is second, so nothing needs to be skimmed for.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and no output schema, the description must characterize the returned data, and it does: the supported platform list with each platform's default post length and emoji policy. Nothing an agent needs to decide to call this is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4 and there is no parameter semantics to document. The description helpfully characterizes the response content even though the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (platforms supported by generate_social_post), plus the exact payload fields (default post length, emoji policy). This clearly separates it from the sibling generate_social_post, which produces posts rather than enumerating supported targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a cheap pre-flight lookup ('costs nothing and makes no network call'), which hints at when to call it, but it never explicitly says to use this before generate_social_post or why one would prefer it over alternatives. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_social_post3 fields changedInput schema / properties / emojiAdded value: +{
+ "description": "Add emoji to the post. Omit for automatic: off on LinkedIn and YouTube, on elsewhere. Set false for a clean post on any platform.",
+ "type": "boolean"
+}Input schema / properties / generate_image / descriptionPrevious value: -"Generate a matching image. Defaults to true. Adds 10 credits per post."New value: +"Generate a matching image for the post. Defaults to false over MCP; pass true to request one. Adds 10 credits per post."Input schema / properties / preserveAdded value: +{
+ "description": "Exact lines that must appear verbatim in the finished post — a closing question, a call to action, a tagline. The humanizer rewrites sentences, so anything whose exact wording matters belongs here rather than only in the topic.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}check_social_jobgenerate_social_postlist_social_platformsSchedule, generate and publish social posts to X, LinkedIn, Instagram, Threads and YouTube
Create, schedule, and publish on-brand social posts to Instagram, LinkedIn, TikTok, and more.
Writes a native post per network from one idea and publishes it: TikTok, Instagram, YouTube & more
AI social autopilot: plan, write, design and publish posts, blog/SEO, news radar and leads.
Add one secure layer between your agents and this server.
