Schedule posts to 10 social platforms and check drafts against hook rules learned from your audience
Scored across 12 tools
Every tool targets a distinct resource and action, and the descriptions actively cross-reference each other (get_post vs list_posts vs get_performance vs list_evergreen; check_draft vs list_hook_rules), leaving no realistic overlap. The closest pair, check_draft and list_hook_rules, is explicitly separated by 'score one caption' versus 'list what exists'.
All 12 names follow a strict verb_noun snake_case pattern (cancel_post, check_draft, create_hook_test, get_*, list_*, schedule_post, update_post) with no style mixing. Verbs are used consistently for their intent: list/get for reads, schedule/update/cancel for mutations.
12 tools is well within the ideal range and each one earns its place: post lifecycle, analytics, connections, evergreen library, hook rules/tests, and link-in-bio. No redundant or filler tools are present.
Full post lifecycle is covered (schedule_post/create, list_posts+get_post/read, update_post/update, cancel_post/delete) plus analytics, connections and hook tooling. Minor gaps remain — a hook test cannot be stopped and evergreen entries cannot be managed from this server, both of which the descriptions acknowledge must be done in the app, and media/accounts are intentionally external.
Cancel a post that has not gone out yet (scheduled, draft or failed) and delete it, so nothing is published. THIS DELETES THE POST — confirm with the person first. To change a post's text, media or time instead, use update_post. It refuses a post that is published or publishing, because those are already live on the platforms and deleting the record here would not take them down. It also refuses a post that belongs to a running hook test, because Lab would schedule a replacement; stop the test in the app instead.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post id from list_posts or schedule_post. With or without dashes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description goes well beyond them: it warns THIS DELETES THE POST and to confirm with the person, and it documents two specific refusal conditions (published/publishing posts are already live; posts in a running hook test would trigger a Lab replacement). That is rich behavioral context that the annotations alone do not convey.
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?
The critical delete warning is front-loaded in the first two sentences, followed by the alternative and the refusal conditions. Every sentence carries distinct, non-redundant 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 single-required-param destructive tool with no output schema and full annotation coverage, the description supplies the confirmation requirement, refusal cases, and sibling routing. Nothing an agent needs to call it safely 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 coverage is 100% and postId is fully documented in the schema, including the 'with or without dashes' detail. The description adds no parameter-level meaning beyond that, 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 precise verb+resource+scope: cancel and delete a post that has not gone out yet, enumerated as scheduled, draft or failed. It explicitly distinguishes itself from update_post, which handles text/media/time changes, so an agent can separate the two siblings without opening schemas.
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 explicit when-to-use, when-not-to-use, and the alternative: use update_post to edit a post, and stop a running hook test in the app rather than canceling here. Nothing about routing 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.
Check a draft caption against the rules learned for one account, before it is scheduled. Returns which rules the caption follows and which it breaks, with the measured effect of each, so you can rewrite the opening before posting. Call it after writing a caption and before schedule_post or update_post. With no rules learned yet for the account it says so rather than inventing advice; list_hook_rules shows what exists.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | The full caption exactly as it would be posted. The opening line matters most, because that is what the rules are about. | |
| accountId | Yes | Id of the account the post will go to, from list_connections. Rules are learned per account, so this decides which rules apply. | |
| mediaKinds | No | What is attached: ["video"], ["image"], or both. Omit for a text-only post. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description goes further by disclosing the return semantics (which rules are followed vs broken, with measured effect) and the graceful failure mode when no rules are learned yet — behavior an agent could not infer from 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?
Four sentences, each earning its place: purpose, return shape and payoff, call-site ordering, and the no-data edge case. Front-loaded with the core action and free of 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?
No output schema exists, and the description compensates by describing what is returned and how to use it. Combined with full schema coverage of the three parameters and annotations covering the safety profile, nothing an agent needs to invoke this 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?
Schema description coverage is 100%, so the schema already documents accountId, caption, and mediaKinds in detail. The description adds only the per-account rule scoping rationale, which the schema already implies, so the 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?
States a specific verb and resource — check a draft caption against rules learned for one account — and clarifies scope (per-account rules, opening-line focus). It is clearly distinguishable from list_hook_rules, which it explicitly names.
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 explicit timing and routing: call it after writing a caption and before schedule_post or update_post, and points to list_hook_rules to see what rules exist. When-to-use and the relevant alternative are both spelled out.
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, and tell them how many posts it scheduled (postsScheduled). Each post's views are recorded seven days after it goes out and a winner is only declared when it clearly beats the others and the account's usual range; "no winner" is a common, real result. Results become the rules that list_hook_rules and check_draft read. The posts appear in list_posts, but cancel_post and update_post refuse them while the test runs, because changing one would spoil the measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | The one idea every variant expresses, e.g. 'Batch-editing a week of videos in one sitting saves hours'. Only the opening should differ between variants. | |
| title | Yes | A short name the person will recognise in the app, e.g. 'Question vs story — editing tips'. | |
| rounds | No | How many times each variant is posted, from 2 up. Defaults to 3; with 3 variants that is 9 posts. Fewer than 2 can never conclude. | |
| variants | Yes | Two to four opening lines to compare, each a genuinely different way into the same idea, e.g. ["Why do your edits take all week?", "I edit a week of videos in one afternoon."]. | |
| accountId | Yes | Id of the account to run the test on, from list_connections. The platform must report views: TikTok, Instagram, YouTube, X, Facebook, Threads or Pinterest — not LinkedIn or Bluesky. | |
| 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 to post at, 0 to 23, in UTC — convert from the person's time zone first. Defaults to 18. Every variant uses the same hour so time of day cannot decide the result. | |
| spacingDays | No | Days between consecutive posts. Defaults to 3, which spreads the variants across different days of the week. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: it schedules real posts spaced over days, results are recorded seven days later, a winner requires beating both peers and the account's usual range, 'no winner' is common, and it locks the posts against cancel_post/update_post while running. This is exactly the kind of downstream-effect disclosure annotations (readOnlyHint=false, openWorldHint=true) cannot provide.
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?
Front-loaded with the core action, then the critical scheduling warning, then measurement/lockout details. It is somewhat long, but every sentence carries a distinct operational fact (scheduling, timing, winner logic, downstream effects, lockout) so little feels wasted.
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-parameter mutation tool with no output schema, it covers the full lifecycle: what gets created, when results arrive, how a winner is decided, what the results feed into, and how conflicts are handled. An agent has enough to call it safely pending human confirmation.
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 every parameter richly. The description nonetheless maps behavioral meaning onto parameters (posts scheduled per variant per round, results become list_hook_rules input), adding context the schema does not carry. Baseline 3 is exceeded because it ties parameters to the experiment's semantics.
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 ('Start a hook test') and immediately defines the mechanism ('publish several openings for the same idea and measure which one holds attention'). It is clearly distinguishable from sibling write tools like schedule_post because it describes a multi-variant measurement experiment.
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 strong usage context: confirm with the person before calling, this is for measuring hook variants on accounts whose platform reports views. It implicitly routes away from LinkedIn/Bluesky but does not name an explicit alternative tool for single-post scheduling (schedule_post), so the when-to-use is clear but the when-not is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The workspace's link-in-bio page (kreatormesh.com/@name) and its numbers for the last 30 days: page views, taps on each link (clicks30d), total taps, the top apps or websites visitors came from (topSources) and the top countries (topCountries, ISO codes). Use it to answer which platform sends people to the creator's offer, and which link they want. Source keys are app names (tiktok, instagram, threads, facebook, linkedin, youtube, x, bluesky), a referring website's host name, or "direct" when the visit carried neither, which includes apps that hide where a visit came from. Link-preview robots are never counted. page is null when no page has been set up yet: it is created in the app at kreatormesh.com/bio, not through this tool. published=false means visitors currently see "page not found". For how the posts themselves did, use get_performance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, not open-world), and the description adds behavior they cannot express: link-preview robots are never counted, source keys enumerate valid app names, and 'direct' includes apps that deliberately hide the referrer. It also discloses that the page cannot be created through this tool.
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?
Front-loaded with the resource and metric list, then edge cases, then the sibling hand-off — a sensible order with no filler sentences. It is on the long side, and the 'which platform sends people / which link they want' framing mildly restates the metric list, but for a tool with no output schema the length is largely earned.
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?
There is no output schema, so the description carries the return-value burden and does so completely: named fields, units (last 30 days), ISO country codes, source-key vocabulary, and the two null/false edge states. An agent has everything needed to call it and interpret the result.
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 no parameters, so the baseline is 4. The description instead spends its budget on return-field semantics (clicks30d, topSources, topCountries as ISO codes, source key formats), which is useful but not parameter guidance.
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 resource (the workspace's link-in-bio page) and a specific payload (views, clicks30d, total taps, topSources, topCountries for the last 30 days). It explicitly separates itself from get_performance ('For how the posts themselves did, use get_performance'), so an agent can route 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?
Gives an explicit use case ('answer which platform sends people to the creator's offer, and which link they want') and names the alternative tool for the adjacent question (get_performance). It also pre-empts two failure modes: page is null when nothing is set up, and published=false means visitors see 'page not found'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metrics for this workspace's published posts. Returns a summary totalled across every published post (post count, overall totals, totals per platform), plus the newest posts in detail, each with one entry per platform it went to: impressions, reach, views, likes, comments, shares and saves. A metric is null when that platform does not report it; supported=false means nothing can be read for that target (no analytics for the platform, or no post id yet). Values are the last stored reading, not a live fetch, and fetchedAt says when it was taken. Use this to answer whether posts worked. It covers published posts only: use list_posts for drafts and scheduled posts, get_post for one post's details, and get_link_in_bio for visits to the link-in-bio page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many of the newest published posts to include in detail, from 1 to 100. Defaults to 20. The summary always covers every published post, whatever this is. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses several non-obvious behaviors: metrics are the last stored reading rather than a live fetch, fetchedAt timestamps it, null means the platform does not report that metric, and supported=false means the target is unreadable (no analytics or no post id). These are exactly the gotchas an agent needs to avoid misreading results.
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?
It is long, but front-loaded with the summary-vs-detail structure and then the caveats (null, supported=false, stored vs live), followed by routing. The metric enumeration is listy but each item earns its place by defining the payload shape; 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?
With no output schema, the description carries the full burden of explaining the return shape, and it does: summary fields, per-platform detail fields, null/supported semantics, and freshness via fetchedAt. An agent can consume the response correctly without further documentation.
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 single parameter is fully documented in the schema (range 1-100, default 20, summary unaffected), so the baseline is 3. The description adds the semantic distinction the schema can't: the summary always covers every published post while only the newest posts are returned in detail, which is what makes 'limit' meaningful.
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?
The opening sentence names the resource precisely ('Metrics for this workspace's published posts') and the body enumerates exactly what is returned: a cross-post summary plus per-platform detail entries. It is immediately distinguishable from list_posts, get_post, and get_link_in_bio, which it names explicitly.
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?
It states the intended question ('Use this to answer whether posts worked') and then gives explicit routing: drafts/scheduled go to list_posts, single-post detail to get_post, link-in-bio visits to get_link_in_bio. This is a textbook when-to-use / when-not-to-use block.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one post by id: caption, per-platform caption overrides, media, target accounts, schedule, status (draft, scheduled, publishing, posted or failed) and, once published, the result for each platform including its link or its error. Use it to confirm what schedule_post or update_post saved, to see why a post failed, or to check a post before cancel_post. For many posts at once use list_posts; for its metrics use get_performance.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post id from list_posts, schedule_post, update_post or list_evergreen. With or without dashes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, not open-world), so the bar is lower, and the description still adds real context: the full status lifecycle (draft, scheduled, publishing, posted, failed) and the fact that once published each platform result carries either a link or an error. It does not mention pagination, auth, or rate limits, so it stops short of a 5.
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?
Purpose is front-loaded and the field enumeration and routing guidance are packed into two dense sentences with little waste. The field list is long, but each item earns its place because there is no output schema to carry that information.
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-shape burden and does so: payload fields, per-platform caption overrides, status enumeration, and the published-result link-or-error shape. Combined with the routing guidance and annotation-covered safety, the 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 description coverage is 100% and the single postId parameter is already fully documented in the schema, including its source tools and dash tolerance. The description only restates 'by id' and adds 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 and resource ('Fetch one post by id') and immediately enumerates what that post contains, so the agent knows the payload before opening the schema. It is clearly distinguishable from list_posts (many) and get_performance (metrics), both of which it names.
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 when-to-use triggers – confirming what schedule_post/update_post saved, diagnosing a failure, and pre-checking before cancel_post – each tied to a sibling tool. It also routes the agent to list_posts for bulk retrieval and get_performance for metrics, so alternatives are explicit rather than inferred.
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: for each, its id, platform, handle and display name. Call this first — schedule_post, update_post, check_draft and create_hook_test all identify accounts by the id returned here. expiresAt is when the current access token expires, not the connection: where autoRenews is true KreatorMesh renews it automatically, so a date in the past is normal and needs no action. Only a past expiresAt with autoRenews false means the person must reconnect that account in the app. Accounts are connected in the app, not through this server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safe-read profile (readOnly, idempotent, closed-world). The description adds substantive behavioral context the annotations cannot: expiresAt refers to the access token not the connection, autoRenews=true means a past date is normal and requires no action, and only past expiresAt with autoRenews=false signals a needed reconnection. It also discloses that accounts are connected in the app, not through this server.
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?
Purpose and the 'call this first' directive are front-loaded, and every sentence carries actionable information about token expiry. The expiry explanation restates itself slightly ('a date in the past is normal and needs no action' followed by the autoRenews=false exception), a minor redundancy in an otherwise tight block.
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?
There is no output schema, so the description carries the burden of describing return values — it does so field by field. Combined with the dependency ordering and expiry semantics, an agent has everything needed to call this correctly and act on the response.
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 and there is nothing schema-side to add meaning to. The description usefully documents the shape of the returned records instead, which is the closest analogue to parameter semantics here.
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 ('List the social accounts connected to this workspace') and enumerates the returned fields (id, platform, handle, display name), so the agent knows exactly what it gets. No sibling tool lists accounts, so this is unambiguously distinct.
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 states 'Call this first' and names the four siblings (schedule_post, update_post, check_draft, create_hook_test) that consume the id returned here, establishing a hard dependency ordering. It also gives when-to-act guidance for reconnection, so the agent knows both when to call and how to interpret the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the evergreen library: published posts that performed well and that KreatorMesh re-posts on a schedule. Each entry gives the original post's id, whether it is still active, how many times it has been recycled, when it last was, and the metrics that earned its place. Good source material when asked what to post next. To read an entry's caption and media, pass its postId to get_post. For every post rather than only the library, use list_posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. With no output schema, the description usefully enumerates the per-entry fields returned (original post id, active flag, recycle count, last-recycled time, earning metrics), which is real behavioral context. It stops short of stating ordering, pagination, or freshness guarantees for the recycling schedule.
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 carrying distinct load: definition, return fields, use case, and sibling routing. The core identity of the tool is front-loaded before any detail.
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?
There is no output schema, so the description carries the return-value burden and discharges it by naming the fields each entry contains. Combined with the routing to get_post for deeper content, an agent has everything needed to call this and interpret the result.
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 4 is the baseline. The mention of passing a postId to get_post is guidance for a different tool rather than a parameter of this one, so it does not add schema-level meaning here.
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 evergreen library') and then defines that resource operationally as 'published posts that performed well and that KreatorMesh re-posts on a schedule.' It explicitly distinguishes itself from the closest sibling by naming list_posts for the unfiltered case, so an agent can route without opening either 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 both a positive trigger ('Good source material when asked what to post next') and two explicit alternatives: get_post for caption/media of a specific entry, list_posts for every post rather than only the library. When-to-use, when-not-to-use, and the routing mechanism are all present.
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 each account, from hook tests run on its real audience rather than generic advice. Each rule has its text, the account and platform it applies to, the measured effect (effectRatio: 1.6 means the winning style got 1.6× the result), how many posts it rests on, a confidence from 1 to 5, and when it is due to be re-checked. Read these before writing a draft. The list is empty until a hook test has concluded — create_hook_test starts one. To score one particular caption against the rules, use check_draft instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds behavior annotations cannot express — the empty-until-test state, the meaning of effectRatio (1.6 = 1.6× result), the 1–5 confidence scale, the post-count basis, and the re-check due date. With no output schema, this return-shape disclosure is exactly the missing behavioral context.
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?
Front-loaded with the purpose, then the returned fields, then usage routing — a sensible order. The field enumeration sentence is long, but given there is no output schema each clause carries information an agent needs to interpret results, so only minor trimming is possible.
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?
Covers everything needed for a zero-parameter read with no output schema: what the data is, how to read each field, the empty-state precondition, which sibling creates the data, and which sibling handles the adjacent scoring task. Nothing required to call or interpret it 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 no parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly spends its words on the returned fields instead.
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 learned hook rules per account) and immediately differentiates the artifact from generic advice by naming its provenance: real-audience hook tests. It also names what it is not (check_draft scores a caption; create_hook_test produces the data), so an agent can place it among siblings 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?
Gives explicit when-to-use ("Read these before writing a draft"), an explicit precondition ("The list is empty until a hook test has concluded — create_hook_test starts one"), and an explicit alternative for the adjacent use case ("To score one particular caption against the rules, use check_draft instead"). Both routing decisions are stated, not inferred.
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, publishing, published and failed — newest first. Call it to see what already exists before writing something new, to find the id of a post to change with update_post or remove with cancel_post, or to answer 'what is scheduled this week'. Filter by status and keep the limit small; a busy workspace has hundreds of posts. For one post in full use get_post, for metrics use get_performance, and for the re-posted library of top performers use list_evergreen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many posts to return, newest first, from 1 to 100. Defaults to 20. | |
| status | No | Only posts with this status: draft, scheduled, publishing, posted or failed. Omit to list every status. |
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 value beyond that with the newest-first ordering guarantee and the warning that busy workspaces hold hundreds of posts (implying cost/latency and the need to filter). It stops short of describing pagination or a cursor, so it is not a 5.
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, all load-bearing: scope/ordering, use cases, filtering advice, and sibling routing. The primary purpose is front-loaded. Slightly dense in the second sentence, where three use cases are packed into one clause chain.
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 two-parameter read tool with no output schema, the description covers ordering, volume expectations, and how to locate a post's id for follow-up mutations. It does not sketch the returned fields, but the annotations carry the safety profile and the schema carries the inputs, so nothing critical 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 coverage is 100%, so both parameters are already documented; baseline 3 applies. The description's 'filter by status and keep the limit small' adds mild practical guidance, but it also lists 'published' where the schema enum says 'posted', a small terminology mismatch that could confuse an agent.
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) plus scope (this workspace), ordering (newest first), and the full set of statuses covered. It explicitly distinguishes itself from get_post, get_performance, and list_evergreen, so an agent can route without opening another 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 concrete when-to-use triggers: check what exists before writing, find an id to pass to update_post or cancel_post, or answer a scheduling question. It also names the alternatives for the adjacent needs (single post, metrics, evergreen library), which is exactly the routing information an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a post for one or more connected accounts and schedule it, or save it as a draft. Instagram, TikTok, YouTube and Pinterest REQUIRE media; X, LinkedIn, Facebook, Threads, Bluesky and Google Business accept text alone. Media is passed as a public https link that the platform fetches when the post publishes — so it must still work then, not just now. The caption is checked against each platform's limit and refused if too long, never cut short. Posting to TikTok also needs tiktokPrivacy, chosen by the person — ask them; TikTok does not allow a default. Use check_draft first to test the caption against the account's hook rules. Afterwards, get_post confirms what was saved, update_post changes it and cancel_post removes it.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | The caption as it should appear. Optional when media is supplied. Limits: X 280, Bluesky 300, Threads 500, Pinterest 500, Google Business 1,500, Instagram 2,200, TikTok 2,200, LinkedIn 3,000, YouTube 5,000, Facebook 63,206. | |
| mediaUrls | No | Public https links to the images or video to attach. Required for Instagram, TikTok, YouTube and Pinterest. Kind comes from the file extension; append #video or #image to a link without one. A file attached to the chat is not a link and cannot be used. | |
| accountIds | Yes | One or more account ids from list_connections, e.g. ["3f2a9c..."]. The post goes to every account listed. | |
| tiktokPrivacy | No | Required when any target is TikTok: who can see the post — public, friends, or private (only the account owner). Ask the person; TikTok requires them to choose and allows no default. Only public posts can be measured, so performance and hook tests need public. | |
| scheduledAtUtc | No | When to publish, as an ISO-8601 UTC timestamp such as 2026-10-20T17:00:00Z — convert from the person's time zone first. Must be in the future. Omit to save a draft for the person to review. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare this is a non-read-only, non-idempotent, open-world write, but the description adds substantial context beyond that: which platforms require media, that media is fetched by the platform at publish time and must remain live, that captions are refused rather than truncated, and that TikTok privacy has no default. These are real operational constraints an agent must know before calling.
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?
The core action and mode are front-loaded, and nearly every sentence carries platform-specific information rather than filler. It is dense and runs long, with some overlap against the schema descriptions, but no sentence is purely redundant boilerplate.
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 five-parameter write tool with no output schema, the description covers the full lifecycle: prerequisite validation via check_draft, platform constraints, the draft-vs-schedule switch, and the follow-up tools for confirming, editing, or removing the result.
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 baseline is 3, but the description adds cross-parameter meaning: media is required for specific platforms, caption is optional when media is supplied, and omitting scheduledAtUtc turns the call into a draft. It largely mirrors the schema's per-field text, so it does not exceed a 4.
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 ('Create a post for one or more connected accounts') plus the two modes it supports: schedule or save as draft. This clearly distinguishes it from the sibling mutation tools update_post and cancel_post, which act on existing 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 routes the agent: use check_draft first to test captions against hook rules, and afterwards use get_post, update_post, or cancel_post. It also states the conditional requirement that TikTok targets need tiktokPrivacy chosen by the user, with no default allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a draft or scheduled post before it goes out: its caption, media, TikTok visibility or time, or take it off the schedule as a draft. Only what you pass changes; the rest stays. THE NEW VALUES REPLACE THE OLD ONES — confirm the change with the person. The edited post is checked against each platform's limits just like a new one. It refuses a post that is published or publishing (it is already live — edit it on the platform), a failed post (some platforms may have succeeded, so re-sending could post twice — create a new one with schedule_post instead), and a post in a running hook test. To delete a post use cancel_post; to create one use schedule_post.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post id from list_posts, schedule_post or get_post. With or without dashes. | |
| caption | No | New caption, replacing the old one. Checked against each platform's limit: X 280, Bluesky 300, Threads 500, Pinterest 500, Google Business 1,500, Instagram 2,200, TikTok 2,200, LinkedIn 3,000, YouTube 5,000, Facebook 63,206. Omit to keep the current caption. | |
| mediaUrls | No | New media as public https links, replacing all current media; [] removes it (not allowed for Instagram, TikTok, YouTube or Pinterest, which need media). Kind comes from the file extension; append #video or #image to a link without one. Omit to keep the current media. | |
| saveAsDraft | No | Set to true to take a scheduled post off the schedule and keep it as a draft. Cannot be combined with scheduledAtUtc. | |
| tiktokPrivacy | No | For a post that goes to TikTok: public, friends or private. The person must choose it; ask them. Omit to keep the current setting. | |
| scheduledAtUtc | No | Move the post to this time, as an ISO-8601 UTC timestamp such as 2026-10-20T17:00:00Z — convert from the person's time zone first. Must be in the future. Schedules a draft. Omit to keep the current time. | |
| replacePlatformCaptions | No | Set to true to also drop the per-platform captions the person set in the app, so the new caption is used everywhere. Needed only when changing the caption of a post that has them; the tool says so if it does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this destructive, idempotent and open-world; the description goes well beyond them by explaining that only passed fields mutate, that new values fully replace old ones, that edits are re-validated against per-platform limits, that a human must confirm, and why create-new beats re-sending a failed post. This is exactly the mutation-risk context an agent needs before invoking.
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?
Front-loads what the tool changes, then the replace-and-confirm rule in caps, then validation, then the refusal list and alternatives. No sentence is filler; each carries either a rule or a routing decision.
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 7-parameter mutation tool with no output schema, the description covers the preconditions, the non-obvious mutation semantics, human-confirmation needs, and the sibling escape hatches. Nothing an agent needs to invoke this correctly appears to be 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 coverage is 100%, so the schema carries the parameter detail and baseline 3 would be acceptable. The description still adds cross-parameter reasoning the schema does not: tiktokPrivacy must be chosen by the person, the caption/media replacements are wholesale, and replacePlatformCaptions is only needed in a specific case. That is a modest but real value-add over the 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?
States a specific verb (change/edit) and resource (a draft or scheduled post) plus the editable facets: caption, media, TikTok visibility or time, and unscheduling. It also names the sibling tools it is not (cancel_post for delete, schedule_post for create), so an agent can discriminate without reading sibling schemas.
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 declares the refusal conditions that redirect the agent elsewhere: published/publishing posts (edit on the platform), failed posts (create a new one via schedule_post, because re-sending could double-post), and posts in a running hook test. It also states the delete and create alternatives by name.
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.
cancel_post1 field changedInput schema / properties / postId / descriptionPrevious value: -"The post id, as returned by list_posts or schedule_post."New value: +"The post id from list_posts or schedule_post. With or without dashes."check_draft3 fields changedInput schema / properties / accountId / descriptionPrevious value: -"Account id from list_connections."New value: +"Id of the account the post will go to, from list_connections. Rules are learned per account, so this decides which rules apply."Input schema / properties / caption / descriptionPrevious value: -"The caption to check."New value: +"The full caption exactly as it would be posted. The opening line matters most, because that is what the rules are about."Input schema / properties / mediaKinds / descriptionPrevious value: -"Kinds of media attached, e.g. [\"video\"] or [\"image\"]. Omit for a text post."New value: +"What is attached: [\"video\"], [\"image\"], or both. Omit for a text-only post."create_hook_test7 fields changedInput schema / properties / accountId / descriptionPrevious value: -"Account id from list_connections to run the test on."New value: +"Id of the account to run the test on, from list_connections. The platform must report views: TikTok, Instagram, YouTube, X, Facebook, Threads or Pinterest — not LinkedIn or Bluesky."Input schema / properties / idea / descriptionPrevious value: -"The single idea every variant expresses. Only the opening should differ."New value: +"The one idea every variant expresses, e.g. 'Batch-editing a week of videos in one sitting saves hours'. Only the opening should differ between variants."Input schema / properties / rounds / descriptionPrevious value: -"How many times each variant is posted. Defaults to 3. Fewer than 2 cannot conclude."New value: +"How many times each variant is posted, from 2 up. Defaults to 3; with 3 variants that is 9 posts. Fewer than 2 can never conclude."Input schema / properties / slotHourUtc / descriptionPrevious value: -"Hour of day (UTC) to post at. Defaults to 18."New value: +"Hour of day to post at, 0 to 23, in UTC — convert from the person's time zone first. Defaults to 18. Every variant uses the same hour so time of day cannot decide the result."Input schema / properties / spacingDays / descriptionPrevious value: -"Days between posts. Defaults to 3."New value: +"Days between consecutive posts. Defaults to 3, which spreads the variants across different days of the week."Input schema / properties / title / descriptionPrevious value: -"Short name for the test, e.g. 'Hook style — scheduling posts'."New value: +"A short name the person will recognise in the app, e.g. 'Question vs story — editing tips'."Input schema / properties / variants / descriptionPrevious value: -"2-4 opening lines to compare. Same idea, genuinely different openings."New value: +"Two to four opening lines to compare, each a genuinely different way into the same idea, e.g. [\"Why do your edits take all week?\", \"I edit a week of videos in one afternoon.\"]."get_performance1 field changedInput schema / properties / limit / descriptionPrevious value: -"How many of the newest published posts to include in detail. Defaults to 20, capped at 100. The summary always covers every published post."New value: +"How many of the newest published posts to include in detail, from 1 to 100. Defaults to 20. The summary always covers every published post, whatever this is."get_post1 field changedInput schema / properties / postId / descriptionPrevious value: -"The post id, as returned by list_posts or schedule_post."New value: +"The post id from list_posts, schedule_post, update_post or list_evergreen. With or without dashes."list_posts2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum posts to return, newest first. Defaults to 20, capped at 100."New value: +"How many posts to return, newest first, from 1 to 100. Defaults to 20."Input schema / properties / status / descriptionPrevious value: -"Optional status filter: draft, scheduled, posted or failed. Omit for all."New value: +"Only posts with this status: draft, scheduled, publishing, posted or failed. Omit to list every status."schedule_post4 fields changedInput schema / properties / accountIds / descriptionPrevious value: -"Account ids from list_connections to publish to."New value: +"One or more account ids from list_connections, e.g. [\"3f2a9c...\"]. The post goes to every account listed."Input schema / properties / caption / descriptionPrevious value: -"The caption text. Optional when media is supplied."New value: +"The caption as it should appear. Optional when media is supplied. Limits: X 280, Bluesky 300, Threads 500, Pinterest 500, Google Business 1,500, Instagram 2,200, TikTok 2,200, LinkedIn 3,000, YouTube 5,000, Facebook 63,206."Input schema / properties / mediaUrls / descriptionPrevious value: -"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."New value: +"Public https links to the images or video to attach. Required for Instagram, TikTok, YouTube and Pinterest. Kind comes from the file extension; append #video or #image to a link without one. A file attached to the chat is not a link and cannot be used."Input schema / properties / scheduledAtUtc / descriptionPrevious value: -"When to publish, as an ISO-8601 UTC timestamp. Omit to save as a draft."New value: +"When to publish, as an ISO-8601 UTC timestamp such as 2026-10-20T17:00:00Z — convert from the person's time zone first. Must be in the future. Omit to save a draft for the person to review."update_postget_link_in_bioschedule_post1 field changedInput schema / properties / tiktokPrivacyAdded value: +{
+ "default": null,
+ "description": "Required when any target is TikTok: who can see the post — public, friends, or private (only the account owner). Ask the person; TikTok requires them to choose and allows no default. Only public posts can be measured, so performance and hook tests need public.",
+ "type": [
+ "string",
+ "null"
+ ]
+}cancel_postcheck_draftcreate_hook_testget_performanceget_postlist_connectionslist_evergreenlist_hook_ruleslist_postsschedule_postDraft, schedule and publish social posts in your own voice across 11 platforms.
Schedule, validate and publish social posts to 12 networks; every post is rule-checked first.
Schedule social media posts to 10 platforms: Instagram, TikTok, X, YouTube, LinkedIn, and more
Schedule and publish social media posts to 10 platforms from your AI agent
Add one secure layer between your agents and this server.
