Generate platform-native social posts that are humanized, AI-detection scored and illustrated.
Scored across 5 tools
Each tool has a clearly distinct role: generate_social_post creates from scratch, score_text measures AI-ness, humanize_text rewrites, check_social_job polls async jobs, and list_social_platforms enumerates options. The descriptions even cross-reference each other to steer selection (e.g. prefer score/humanize if you already have a draft), leaving no real ambiguity.
All names use a consistent snake_case verb_noun pattern (generate_social_post, check_social_job, score_text, humanize_text, list_social_platforms). The convention is uniform and predictable across the whole set.
Five tools form a tight, well-scoped set covering the generation/measurement/humanization workflow plus job polling and platform discovery. Every tool earns its place with no redundancy.
The surface covers the core loop of generating, scoring, and humanizing content, with async job lookup and platform listing to support it. Minor gaps exist (no way to cancel or list jobs, no scheduling/publishing), but these fall outside the apparent scope and are easy to work around.
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 from scratch for a given platform and topic. Use this when you do not already have a draft — for example to produce several variations at once, or for platforms whose conventions you are unsure of. If you have already written the post yourself, prefer score_text and humanize_text, which check and fix your own wording instead of replacing it. 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. | |
| humanize | No | Rewrite the post to read as human-authored. Omit for automatic: the draft is scored first and humanized only if it reads as machine-written. Skipping it keeps the exact wording and saves credits, since a well-written post often already passes. | |
| 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?
Annotations already mark this as a non-read-only, open-world operation, and the description adds substantial context beyond them: it returns a job id immediately and must be polled via check_social_job with a 20-90 second expected duration, and it consumes credits. It stops short of covering edge cases such as credit behavior on failure, but the async contract and cost model are clearly disclosed.
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?
Four sentences, each earning its place: purpose, routing condition, sibling alternative, and the async/cost contract. The most decision-relevant content (what it does plus when not to use it) is front-loaded before the operational details.
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?
Although there is no output schema, the description covers what an agent needs to call and follow up on this tool: it returns a job id and must be polled with check_social_job. Combined with cost signals and full schema-level parameter documentation, there is no material gap for a 16-parameter generator.
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 all 16 parameters — including defaults, enums, ranges, and the 'omit for automatic' behavior — are already fully documented in the schema. The description adds no per-parameter meaning beyond what is structured, which is the expected baseline when the schema does the heavy lifting.
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 ('Write a social media post from scratch') and immediately scopes it by platform and topic. It explicitly names what it is not — a checker/fixer — and routes to the sibling tools score_text and humanize_text, so an agent can distinguish it from all four siblings without opening any 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?
Gives an explicit when-to-use condition ('when you do not already have a draft'), concrete examples (multiple variations, unfamiliar platform conventions), and an explicit when-not with the preferred alternatives ('If you have already written the post yourself, prefer score_text and humanize_text'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text so it no longer reads as machine-written, using an external humanizing service. Use this on your own writing when score_text says it would be flagged. Brand names, domains and any lines listed in preserve are restored verbatim afterwards, because the humanizer rewrites whole sentences and splits names. Costs 1 credit per 20 words.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to rewrite. At least 10 characters. | |
| preserve | No | Exact lines that must survive verbatim — a tagline, a call to action, a closing question. | |
| brand_terms | No | Names that must not be altered, e.g. a product name the humanizer would otherwise split into two words. | |
| score_after | No | Score the rewritten text and return it. Adds 8 credits. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description goes well beyond them: it discloses the external service dependency, the post-hoc verbatim restoration of brand names/domains/preserve lines and the reason for it (sentence-level rewriting splits names), and a concrete cost of 1 credit per 20 words.
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 sentences, zero filler. The core action and the gating condition come first, the restoration caveat second, and the cost last — appropriately front-loaded and every sentence earns its place.
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 4-param mutation tool with no output schema, it covers usage, side effects, restoration behavior, and cost. The one gap is that it never says what is returned (rewritten text, and whether score_after's score is included), which an agent must infer from the schema.
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 coverage is 100%, so the schema already documents all four parameters. The description nonetheless adds genuine meaning by explaining the rationale behind `preserve` (the humanizer splits names, so these lines are restored verbatim afterwards), which is more than the schema's own wording conveys.
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 ('rewrite text so it no longer reads as machine-written') and names the mechanism (external humanizing service), which clearly distinguishes it from siblings like generate_social_post or check_social_job.
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 an explicit trigger: 'Use this on your own writing when score_text says it would be flagged,' naming the sibling tool that gates its use. It stops short of stating when NOT to use it (e.g. freshest drafts, non-prose content), so it falls just short of the top band.
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.
Check how machine-written a piece of text reads, using an external AI detector. Returns a score from 0 to 65 where 0 reads as human and anything above 30 is likely to be flagged. Use this on text you have already written to find out whether it will pass before it is published — it is a measurement you cannot make yourself. Costs 8 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to score. At least 10 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), but the description adds materially more: an external third-party dependency, a per-call cost of 8 credits, and an interpretation guide for the numeric result including the flag threshold of 30. Cost and external-service dependency are behavioral traits annotations cannot express.
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 sentences, front-loaded with the purpose, then the result semantics, then the usage condition and cost. No sentence is redundant and nothing is buried.
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 compensates by explaining the return scale and threshold, and it discloses cost and external dependency. For a single-parameter read-only tool, an agent has everything needed to decide and invoke correctly.
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, including the minLength of 10, so the schema fully documents it. The description adds no syntax or format detail beyond that, making the baseline 3 correct.
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 — check how machine-written text reads via an external AI detector — and names the exact output shape (0–65 scale with a 30 threshold). This is clearly distinguishable from siblings like humanize_text (which rewrites) and generate_social_post (which creates).
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 a clear when-to-use: on text already written, before publishing, as a self-measurement the agent cannot perform itself. It does not, however, point to the natural follow-up sibling (humanize_text) for text that fails, nor state any exclusion, so it falls short of the explicit-alternatives bar.
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.
humanize_textscore_textgenerate_social_post1 field changedInput schema / properties / humanizeAdded value: +{
+ "description": "Rewrite the post to read as human-authored. Omit for automatic: the draft is scored first and humanized only if it reads as machine-written. Skipping it keeps the exact wording and saves credits, since a well-written post often already passes.",
+ "type": "boolean"
+}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
Social media for small businesses: write, illustrate, schedule and publish posts from your AI.
Write, schedule and publish on-brand social posts to nine networks from your AI assistant.
Draft, schedule and review social posts on X, LinkedIn, Instagram, TikTok, YouTube and more.
Add one secure layer between your agents and this server.