Schedule posts to 10 social platforms and check drafts against hook rules learned from your audience
Scored across 8 tools
Each tool has a distinct purpose in the content workflow: connection listing, post listing, evergreen listing, rule listing, draft checking, hook testing, scheduling, and performance. The only potential overlap is create_hook_test vs schedule_post, but the descriptions clearly separate test scheduling from normal post scheduling.
All tools use snake_case with a consistent verb_noun pattern (list_*, get_*, check_*, create_*, schedule_*). There are no deviations or mixed conventions.
8 tools is well-scoped for a social media scheduling and analytics server. Each tool covers a distinct part of the workflow without excessive breadth or thin coverage.
Core workflows are present: list connections/posts/evergreen/rules, check drafts, schedule posts, measure performance, and run hook tests. However, the post lifecycle lacks update, delete/cancel, and single-post retrieval operations, so agents cannot modify or remove an existing scheduled post through this server.
Check a draft caption against the rules learned for a specific account, before publishing. Returns which rules it follows and which it breaks, with the measured effect of each. This is the tool to call after writing a caption and before scheduling it.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | The caption to check. | |
| accountId | Yes | Account id from list_connections. | |
| mediaKinds | No | Kinds of media attached, e.g. ["video"] or ["image"]. Omit for a text post. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real value by stating what the call returns: which rules are followed/broken with the measured effect of each. It stops short of documenting auth requirements or rate limits, but for a read-only check the added disclosure is solid.
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 tight sentences, front-loaded with the action, then the return value, then the workflow position. Every sentence earns its place with no filler.
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 burden of explaining results and does so (rules followed/broken plus measured effect). Combined with the workflow guidance, an agent has everything needed to call and interpret it.
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 parameters are already documented. The description reinforces that the rules are account-specific (tying meaning to accountId) but says nothing about mediaKinds or caption format, so it only marginally exceeds the schema baseline.
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+scope: it checks a draft caption against account-specific learned rules. This distinguishes it cleanly from siblings like create_hook_test and list_hook_rules, so an agent can pick it without opening a 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?
Explicitly places the tool in a workflow: 'call after writing a caption and before scheduling it,' which contrasts it against schedule_post. It gives clear when-to-use context but no explicit when-not-to-use or named alternative, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a hook test: publish several openings for the same idea and measure which one holds attention on this account. THIS SCHEDULES REAL POSTS — one per variant per round, spaced out over days — so confirm with the person before calling it. Results become the rules that list_hook_rules and check_draft read, which stay empty until a test concludes.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | The single idea every variant expresses. Only the opening should differ. | |
| title | Yes | Short name for the test, e.g. 'Hook style — scheduling posts'. | |
| rounds | No | How many times each variant is posted. Defaults to 3. Fewer than 2 cannot conclude. | |
| variants | Yes | 2-4 opening lines to compare. Same idea, genuinely different openings. | |
| accountId | Yes | Account id from list_connections to run the test on. | |
| archetypes | Yes | One archetype per variant, in the same order: question, contrarian, number, story or direct. This is not a label — it decides the rule the test can produce, and the opening must actually match it (question ends with '?', number starts with a figure, contrarian starts with stop/nobody/everyone/most/forget/unpopular/the reason, story starts with I/we/last/yesterday/when I/my client). | |
| slotHourUtc | No | Hour of day (UTC) to post at. Defaults to 18. | |
| spacingDays | No | Days between posts. Defaults to 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it non-read-only, open-world, non-idempotent and non-destructive; the description goes much further by disclosing that it schedules REAL posts across multiple days, the posting cadence (one per variant per round), and the side effect that list_hook_rules/check_draft stay empty until the test concludes. That is precisely the context a mutation tool needs.
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, front-loaded with the action, then the critical warning in caps, then the downstream consequence. Every clause carries information and nothing is padding.
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 an 8-param scheduling mutation with no output schema, the description covers the action, the side effects, the human-in-the-loop requirement, and where results surface. Combined with the fully documented schema, an agent has everything needed to call it 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?
Schema coverage is 100%, so the schema already documents all 8 parameters in detail, including the archetype-to-opening-matching rules. The description adds only the high-level shape ('several openings for the same idea') without new syntax or constraint 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 (start a hook test) plus the mechanism (publish several openings for the same idea, measure which holds attention) and names the downstream consumers (list_hook_rules, check_draft). Clearly separable from siblings like schedule_post or list_posts.
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?
Explicitly requires human confirmation before calling ('confirm with the person before calling it') and explains that results only materialize after the test concludes. It does not, however, name the alternative tool (schedule_post) for the case where a single ordinary post is wanted, so routing vs. that sibling 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.
Cross-platform performance for recent posts — what actually landed. Use it to answer 'did it work' rather than guessing from a single post.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds the behavioral note that results are aggregated across platforms rather than per-post, which is useful context, but it omits the time window of 'recent' and any cost/rate-limit behavior.
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, front-loaded with the purpose and followed by the usage framing. No filler, though the second sentence is more rhetorical than informative.
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?
This is a zero-parameter tool with no output schema, so the description must carry the burden of saying what data comes back. It never names the metrics (impressions, engagement, etc.) or the time window, leaving 'performance' undefined for the agent.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds the implication that results are aggregated cross-platform for a recent window, which is the only semantic the empty schema cannot convey.
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 the resource (post performance) with a cross-platform framing, but the verb is soft ('performance ... what actually landed') and the scope term 'recent posts' is never defined. It does not distinguish itself from siblings such as list_posts or list_evergreen, so an agent cannot tell exactly which retrieval this replaces.
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 phrase "Use it to answer 'did it work'" implies a usage context, which is better than nothing. However, there are no explicit when/when-not conditions and no named alternative, so the agent must infer when to reach for this over list_posts or check_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the social accounts connected to this workspace. Call this first: every other tool identifies an account by the id returned here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: this is a discovery/prerequisite call whose output feeds all other tools. It stops short of describing the return payload structure, but the essential behavioral role is 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?
Two short sentences with zero waste; the action is stated first and the critical 'call this first' dependency is front-loaded. Every clause 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 simple zero-param listing tool with no output schema, the description supplies everything needed: what it lists and why it must be called before other tools. Nothing an agent needs to invoke it correctly 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 the schema imposes no semantic burden and there is nothing for the description to clarify. Baseline of 4 applies for a no-param operation.
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 ('List the social accounts connected to this workspace'), clearly distinguishing it from sibling list tools that target posts, evergreen content, or hook rules. An agent knows exactly what this returns.
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?
Explicitly instructs 'Call this first' and explains the dependency: every other tool identifies an account by the id returned here. This is a textbook when-to-use directive that routes the agent before it attempts sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts in the evergreen library — content that already performed and is being recycled. Good source material when asked what to post next.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered externally. The description adds useful domain meaning (what 'evergreen' content is) but says nothing about ordering, volume or pagination of the returned list.
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, the resource and its scope front-loaded, followed by the use case. No filler or redundancy.
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 parameterless read-only list with no output schema, the description covers what the tool returns at a conceptual level. It omits any note about list size or return ordering, which would matter for a listing tool.
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 the baseline is 4. There is nothing for the description to clarify beyond confirming it is a no-argument listing operation.
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 (list posts in the evergreen library) and defines the scope ('content that already performed and is being recycled'), which separates it conceptually from the sibling list_posts. It stops short of explicitly naming that sibling as the alternative, so it is clear but not maximally differentiated.
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?
'Good source material when asked what to post next' gives a concrete triggering scenario for use. It provides positive context but no exclusions or explicit contrast with list_posts, so it is clear rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the rules KreatorMesh has learned about what works for THIS account, derived from hook tests run against its real audience rather than generic advice. Use these when writing a draft.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, closed-world behavior, so the safety profile is covered. The description adds genuinely non-redundant context: that the data is account-specific and empirically derived from hook tests against a real audience rather than generic advice.
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 tight sentences with no filler. The account-specific nature of the rules is front-loaded and the usage directive follows immediately.
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 zero-parameter read tool with annotations covering the safety profile, the description supplies purpose and usage. There is no output schema, so a brief note on what the returned rules look like would fully close the gap.
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 the schema has no semantics to explain and the baseline is 4. Nothing in the description contradicts or needs to compensate for the empty schema.
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?
Specific verb (List) plus a precisely scoped resource: rules KreatorMesh has learned about what works for THIS account. The contrast with 'generic advice' and the origin from hook tests distinguishes it from siblings like create_hook_test or list_posts.
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?
States a clear activation context ('Use these when writing a draft'), which routes an agent to consult it during draft writing. It does not name an explicit alternative or a when-not condition, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts in this workspace — drafts, scheduled, published and failed. Call this to see what already exists before writing something new, to check whether a draft was saved, or to answer 'what is scheduled this week'. Filter by status and keep the limit small; a busy workspace has hundreds of posts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum posts to return, newest first. Defaults to 20, capped at 100. | |
| status | No | Optional status filter: draft, scheduled, posted or failed. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds practical behavioral context not in the annotations: results are workspace-wide and can number in the hundreds, so the limit should stay small. It omits pagination behavior, but that gap is minor against the annotation coverage.
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 what the tool returns, then the call scenarios, then the practical size caveat. No filler or restatement of the name/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 read-only, fully-schema-documented list tool with annotations covering safety, the description supplies everything needed to decide when to call it. The only omission is any hint at the shape/ordering of returned items, which is a minor gap with no output schema present.
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 both parameters are fully documented in the schema itself (limit default/cap, status enum values). The description only restates the intent to filter by status and keep limit small, adding little syntax or format detail beyond the schema. 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 (list posts) scoped to 'this workspace' and enumerates the statuses covered (drafts, scheduled, published, failed). It does not explicitly distinguish itself from close siblings like list_evergreen or check_draft, which is the only thing keeping it from a 5.
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 three concrete 'call this when' scenarios: checking what exists before writing, verifying a draft was saved, and answering 'what is scheduled this week'. Clear context, but it names no alternative tool or explicit when-not condition (e.g. versus check_draft for a single draft).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a post to one or more connected accounts, with or without media. Instagram, TikTok, YouTube and Pinterest REQUIRE at least one media URL; X, LinkedIn, Facebook, Threads, Bluesky and Google Business accept text alone. Media is passed as a public https URL that the platform fetches when the post publishes — so it must still be reachable then, not just now. Per-platform validation is the same the app uses, so an over-length caption is refused rather than silently truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | The caption text. Optional when media is supplied. | |
| mediaUrls | No | Public https URLs of images or video to attach. Required for Instagram, TikTok, YouTube and Pinterest. Kind is inferred from the file extension; append #video or #image to a URL that has none. | |
| accountIds | Yes | Account ids from list_connections to publish to. | |
| scheduledAtUtc | No | When to publish, as an ISO-8601 UTC timestamp. Omit to save as a draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior: media is fetched by the platform at publish time and must remain reachable then, and per-platform validation rejects over-length captions rather than truncating. It does not cover auth requirements, failure modes, or return values.
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 core action, then requirements, then media semantics. Every sentence carries distinct information with no filler.
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 non-idempotent scheduling mutation with no output schema, the definition covers platform requirements, media handling, and validation strictness well. It omits scheduling edge cases (past timestamps, per-account partial failure) and any notion of the return value, but nothing essential for a first correct call 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?
Schema description coverage is 100%, so the schema already documents all four parameters, including the media URL requirement, extension-based kind inference, and draft behavior. The description mostly reinforces the same material, adding only the publish-time reachability framing. Baseline 3 is appropriate.
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?
Opens with a specific verb+resource ('Schedule a post to one or more connected accounts') and immediately names the media dimension of the operation. An agent knows exactly what this does and how it differs from read-oriented siblings like list_posts or check_draft.
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 concrete platform-level conditions: Instagram/TikTok/YouTube/Pinterest require media, others accept text alone, and omitting a schedule time produces a draft (echoed in the schema). It stops short of naming alternatives or stating when to prefer a draft workflow versus another tool, so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule social media posts to 10 platforms: Instagram, TikTok, X, YouTube, LinkedIn, and more
Schedule and publish social content across nine destinations with human guardrails.
Schedule and publish social media posts to 10 platforms from your AI agent
Schedule and publish social posts to 11 platforms with media, campaigns, analytics and AI captions
Add one secure layer between your agents and this server.
