Schedule and manage social media posts across 13 platforms (Bluesky, Threads, Instagram, LinkedIn, Mastodon, YouTube, Facebook, Pinterest, Telegram, Nostr, X/Twitter, Discord, Tumblr and more). OAuth 2.0 + PKCE, 10 tools, draft-first workflow for AI agents.
Scored across 10 tools
Most tools target clearly distinct actions (approve, delete, duplicate, get, list). The only real overlap is between approve_draft and create_post with schedule_directly set to true, which both can push content toward publishing, but the descriptions make the intended paths reasonably clear.
Every tool follows a consistent snake_case verb_noun pattern (create_post, delete_post, get_post, list_accounts, approve_draft, etc.). No mixed conventions or ambiguous single-word names.
Ten tools is well-scoped for a social-media post management server, covering creation, templates, accounts, queue listing, and lifecycle actions without bloat.
Core lifecycle is covered: create, update, delete, duplicate, approve/schedule, and read. Minor gaps exist — no way to list published/historical posts (only scheduled posts and drafts), and scheduling is reachable only via approve_draft or schedule_directly.
Approve a draft post and schedule it for publishing at a specific time. This promotes a draft to the scheduled queue — it will publish at scheduled_time without further approval needed. Only works on posts with status 'draft'.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID of the draft to approve. | |
| scheduled_time | Yes | ISO 8601 datetime when to publish. Must be in the future. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| _note | No | |
| status | No | |
| scheduledFor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly=false, destructive=false, openWorld=true); the description adds the substantive behavior: the record is moved to a scheduled queue and will auto-publish without a second approval gate. That is real value beyond structured data, though error behavior for non-draft input and reversibility (can it be unscheduled?) are not 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?
Three short sentences, front-loaded with the action and its effect, then the constraint. Slight redundancy between 'schedule it for publishing at a specific time' and the em-dash clause, but nothing is 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?
With an output schema present, return values need no explanation, and the description covers the action, the effect, and the eligibility precondition. Missing only edge-case handling (non-draft post, past timestamps) and whether the scheduling is undoable, which an agent might want before committing.
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 (post_id, and scheduled_time as a future ISO 8601 datetime). The description restates that publishing occurs at scheduled_time but adds no syntax, format, or constraint 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?
Names a specific verb and resource ('Approve a draft post') and states the resulting state transition ('promotes a draft to the scheduled queue'). This distinguishes it cleanly from create_post, update_post, and list_scheduled_posts, which do not perform a draft→scheduled approval.
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 precondition — 'Only works on posts with status draft' — plus the consequence of use (publishes at scheduled_time with no further approval), which tells an agent when this is the right step. It stops short of naming alternatives (e.g., use update_post to edit the draft first) or saying what to do for non-draft posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a draft post using a saved template as the base content. You can override the text and other fields before saving. Use list_templates to get template IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| account_ids | Yes | Account IDs to post to. Use list_accounts to get IDs. | |
| template_id | Yes | Template ID from list_templates. | |
| scheduled_time | No | ISO 8601 publish time. Required when schedule_directly is true. | |
| content_override | No | Override the template text. Leave blank to use template text as-is. | |
| schedule_directly | No | When true, schedule immediately instead of saving as draft. Requires scheduled_time. | |
| first_comment_override | No | Override the template first comment. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| _note | No | |
| draft | No | |
| status | No | |
| targets | No | |
| scheduledFor | No | |
| templateUsed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is already covered. The description adds that a draft is produced and overrides are applied before saving, but it omits any mention of the scheduling path (schedule_directly), which is the main behavioral branch of 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?
Three short sentences, front-loaded with the core action, with no filler. The template-ID sentence duplicates the schema's own 'Template ID from list_templates' note, a small 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?
With an output schema present and full parameter coverage, the definition only needs to convey purpose and workflow, which it largely does. The remaining gap is the draft-versus-direct-schedule behavior and how it relates to the sibling create_post.
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 six parameters are already documented in the schema. The description's note about overriding 'the text and other fields' loosely reinforces content_override but adds no syntax or constraint 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 ('Create a draft post using a saved template as the base content') and notes the override capability before saving. It does not differentiate itself from the sibling create_post, which an agent could easily confuse for template-based creation.
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 one concrete workflow hint ('Use list_templates to get template IDs'), which is useful prerequisite guidance. However, it never says when to use this versus create_post or duplicate_post, nor when the draft-vs-schedule distinction matters, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a post in Posthive. BY DEFAULT posts are saved as DRAFTS and require manual approval in the Posthive review queue before anything is published. Nothing is published automatically unless schedule_directly is explicitly set to true with a future scheduled_time. Use list_accounts to get valid account IDs before calling this tool. Each platform has its own character limit for both the post text and the first_comment — the request is rejected with a 400 if either exceeds it for any selected account: Bluesky 300, Threads/Mastodon/Pinterest 500, Instagram/TikTok 2200, Discord 2000, LinkedIn 3000, Telegram/Tumblr 4096, YouTube 5000, Nostr/Lemmy 10000, Twitter/X 25000, Facebook 63206. Check the content and first_comment length against the shortest limit among the selected platforms before calling, and warn the user if a caption (especially a long hashtag block) would be rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The post text content. | |
| dry_run | No | Full pipeline test without real API calls. | |
| media_type | No | Instagram media type. 'post' = feed image/carousel, 'reel' = video reel, 'story' = story. Only relevant for Instagram accounts. | |
| media_urls | No | Array of already-uploaded media URLs (images or video). Upload via POST /api/v1/upload first to get URLs. | |
| account_ids | Yes | Array of account IDs. Use list_accounts to get IDs. | |
| per_account | No | Per-account content overrides. Keys are account IDs. | |
| youtube_type | No | YouTube video type. 'short' = YouTube Short (vertical, ≤60s), 'video' = standard upload. Only relevant for YouTube accounts. | |
| first_comment | No | Optional first comment to fire after the post goes live. | |
| repeat_ends_at | No | ISO 8601 datetime after which no more repeat occurrences are created. Omit for indefinite repeating. | |
| scheduled_time | No | ISO 8601 datetime for publish time. Required when schedule_directly is true. | |
| repeat_interval | No | Repeat this post automatically after each successful publish. Spawns the next occurrence at the same time. | |
| schedule_directly | No | When true, post is scheduled directly and publishes at scheduled_time without manual approval. Requires scheduled_time. Defaults to false (saves as draft). |
| Name | Required | Description |
|---|---|---|
| id | No | |
| _note | No | |
| draft | No | |
| status | No | |
| targets | No | |
| scheduledFor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, not destructive, and interacts with external platforms. The description adds valuable behavioral context beyond annotations: the default draft/approval flow, the exact condition for automatic publishing (schedule_directly + future scheduled_time), and that requests are rejected with a 400 when character limits are exceeded for any selected account.
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 description is front-loaded with the most important behavioral facts (default draft, approval, schedule_directly condition) before moving to setup guidance and detailed character limits. The long character-limit list is useful but slightly bulky, though every sentence provides actionable information for correctly invoking the tool.
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?
Given the complexity (12 parameters, nested objects, output schema present), the description covers the critical operational details: default draft behavior, how to publish directly, account ID lookup via list_accounts, and rejection conditions for content length. It does not discuss every optional parameter (e.g., media_type, repeat_interval), but those are fully documented in the schema and output schema exists.
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 baseline is 3, but the description adds meaningful semantics for content and first_comment by enumerating per-platform character limits (e.g., Bluesky 300, Threads/Mastodon/Pinterest 500, etc.) and advising the agent to check against the shortest limit among selected platforms before calling.
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 in Posthive.' It clarifies the default draft/approval workflow and the schedule_directly alternative, but does not explicitly name or differentiate from sibling tools like create_from_template or duplicate_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: posts default to drafts requiring manual approval, and nothing publishes automatically unless schedule_directly is true with a future scheduled_time. It also directs the agent to call list_accounts first and warns about platform-specific character limits, but does not state when to avoid this tool or use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a pending or draft post from the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID from list_scheduled_posts. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| deleted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is an irreversible write. The description adds the useful scope constraint that only pending/draft queue items are eligible, but it says nothing about what happens on non-queued posts, whether deletion is permanent, or error 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?
A single front-loaded sentence with no filler: verb, resource, and scope constraint in one pass. Nothing is wasted or repeated from structured fields.
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?
The tool is simple (one required string parameter), an output schema exists so return values need no explanation, and annotations cover the destructive profile. Only the permanence/eligibility-failure behavior is left unstated, a minor gap for a tool this narrow.
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?
Only one parameter (post_id) and schema description coverage is 100%, with the schema even pointing to list_scheduled_posts as the source of IDs. The description adds no additional meaning about the identifier, so the baseline of 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?
Names a specific verb (Delete) and resource (post) and narrows the scope to pending or draft posts in the queue, which sharply limits what the agent expects it to succeed on. It does not reference any sibling tool, so an agent gets no explicit cross-tool differentiation beyond the verb itself.
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 'pending or draft' qualifier implicitly tells the agent this is for unpublished, queued items only, which functions as weak when-to-use guidance. There is no explicit exclusion of published posts, no mention of alternatives like update_post or duplicate_post, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone an existing post as a new draft. Copies content, accounts, and per-account overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID to duplicate. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| _note | No | |
| draft | No | |
| status | No | |
| targets | No | |
| scheduledFor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral value beyond them: the copy is created as a draft (not published) and carries content, accounts, and per-account overrides, which tells the agent what state the new record lands in.
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, zero filler, with the core action front-loaded and the copy behavior following as supporting detail. 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?
With an output schema present, return values need not be explained, and for a one-parameter tool the description covers action, mechanism, and resulting state adequately. Minor omissions remain, such as what happens if the source post does not exist or lacks accessible accounts, but nothing essential for correct invocation 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?
There is only one parameter and schema description coverage is 100% ('Post ID to duplicate.'), so the schema fully documents it. The description adds nothing about ID format or source-post requirements beyond what the schema states, 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?
The description gives a specific verb ('Clone'), a specific resource ('an existing post'), and the resulting artifact ('as a new draft'), which functionally separates it from create_post and create_from_template among the siblings. An agent can tell what produces the new record 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?
Usage is implied: clone when you want a copy of an existing post rather than authoring one from scratch. However, the description never explicitly names an alternative (create_post, create_from_template) or a condition for choosing among them, so the 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.
Get full details of a single post by ID, including per-platform publish status.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post ID from list_scheduled_posts or create_post. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| draft | No | |
| status | No | |
| content | No | |
| targets | No | |
| createdAt | No | |
| perAccount | No | |
| firstComment | No | |
| scheduledFor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the scope of the response ('per-platform publish status'), which is useful, but says nothing about pagination, freshness, or failure behavior for a missing ID.
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?
One sentence, front-loaded with the verb and resource, and every clause earns its place by specifying the ID input and the response scope. No filler or redundant restatement of the 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?
An output schema exists, so return values needn't be spelled out, and annotations carry the safety profile; the description plus schema is effectively complete for this simple one-parameter read. Only minor gaps (missing-ID behavior) remain.
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 parameter's description already tells the agent where the post_id comes from ('list_scheduled_posts or create_post'). The description adds no further syntax or format 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?
The description gives a specific verb and resource ('Get full details of a single post by ID') and scopes the return ('per-platform publish status'), which clearly separates it from list tools. It doesn't explicitly name a sibling to avoid, so it stops short of 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?
Usage is only implied: the agent infers it should call this when it holds a post ID and wants details. There is no explicit when-to-use/when-not guidance or named alternative (e.g., list_scheduled_posts for bulk views), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected social media accounts for this Posthive workspace. Returns account IDs, platforms, and display names. Use these IDs when creating posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| accounts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that—no auth requirements, rate limits, or scoping constraints that aren't already implied by openWorldHint=false.
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 primary action and resource, followed by return details and a usage cue. Every sentence earns its place with no waste.
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, parameterless list tool with an output schema and annotations covering safety, the description is complete: it states the resource, scope, return fields (though redundant with the output schema), and the primary use case.
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 are zero parameters, so baseline is 4. The description adds no parameter information, but none is needed given the empty schema and 100% schema coverage.
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 'connected social media accounts for this Posthive workspace', which is distinct from sibling list tools like list_templates and list_scheduled_posts. However, it does not explicitly name or contrast with those siblings, so it falls short of 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?
Clearly indicates when to use the tool: 'Use these IDs when creating posts.' This gives the agent a concrete context for calling it. It does not describe any exclusions or alternatives, so it remains at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming scheduled posts and drafts in the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20, max 100). | |
| status | No | Filter by status. Omit to return all. |
| Name | Required | Description |
|---|---|---|
| posts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds only the 'in the queue' framing and does not disclose ordering, pagination, or the fact that non-upcoming statuses (done/failed) can be returned — a gap worth noting since 'upcoming' slightly undersells the schema's status filter.
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?
A single tight sentence with the resource front-loaded and zero filler. It is appropriately sized, though the qualifying word 'upcoming' is imprecise given the status filter supports done and failed.
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?
An output schema exists, so return values need not be explained, and 100% schema coverage documents both optional params. The remaining gap is a lack of ordering/pagination context and any usage framing relative to siblings, but for a simple read-only list tool this is close to 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?
Schema description coverage is 100%, so both parameters (limit with default/max, status enum) are fully documented in structured fields and the baseline is 3. The description adds no parameter detail beyond the schema and its word 'upcoming' arguably conflicts with the done/failed enum values.
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 (scheduled posts and drafts in the queue), which is enough to separate it from read/write siblings like get_post or create_post. However, it does not name or contrast itself with any sibling, so the differentiation is inferred from the resource noun alone.
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?
There is no statement of when to use this tool versus alternatives such as get_post (single post), list_templates, or list_accounts. No prerequisites, no exclusions, no routing guidance — the agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved post templates in this Posthive workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| templates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds workspace scoping ('in this Posthive workspace') but says nothing about result ordering, pagination, or whether templates are shared across the workspace, which for a list tool is the remaining useful behavior to disclose.
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?
A single sentence with the resource and scope front-loaded and no filler words. 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?
With no parameters, a full output schema, and annotations covering the read-only safety profile, the definition is essentially complete for a simple list operation. The only minor gap is the absence of any note on result size or scoping behavior across workspace members.
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 parameter semantics carry no burden and the baseline for an empty schema applies. There is nothing for the description to compensate for.
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 (saved post templates) scoped to a Posthive workspace, which is fully clear to an agent. It does not explicitly differentiate itself from the sibling create_from_template, which is the only nearby risk of confusion, so it stops short of 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?
Usage is only implied: the tool obviously lists templates when the agent needs to see available templates. There is no statement of when to prefer it, no preconditions, and no mention of related sibling tools such as create_from_template or duplicate_post that operate on the same resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update content or scheduled time of a queued or draft post. Only pending/draft posts can be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| post_id | Yes | Post ID from list_scheduled_posts. | |
| per_account | No | ||
| first_comment | No | ||
| scheduled_time | No | New scheduled time (ISO 8601). |
| Name | Required | Description |
|---|---|---|
| id | No | |
| status | No | |
| scheduledFor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the write profile is covered. The description adds the state restriction on which posts are mutable, which is useful. It does not disclose whether omitted fields are cleared, permission requirements, or reversibility, so the added value is modest.
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, zero filler, with the mutation and the eligibility precondition front-loaded. 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?
An output schema exists, so return values need no explanation, and annotations cover the destructive profile. However, for a tool with a nested per_account object and two undocumented parameters, the description is thin on how per-account text vs first_comment vs content interact.
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 only 40% and the description names just two of five parameters (content, scheduled_time), without format or field-level detail beyond what the schema already says. The nested per_account object and first_comment are undocumented in both the schema and the description, so the description fails to compensate for the coverage gap.
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 (update a post) plus the two editable areas (content, scheduled time) and the eligible post states. It does not name a sibling to distinguish from (create_post, duplicate_post, delete_post), but the purpose is unmistakable.
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?
"Only pending/draft posts can be updated" gives an explicit precondition that tells the agent when the tool will fail, which is genuine usage guidance. It stops short of naming alternatives (e.g., use approve_draft to publish, get_post to inspect) but the constraint is clear.
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.
create_post2 fields changedInput schema / properties / repeat_ends_atAdded value: +{
+ "description": "ISO 8601 datetime after which no more repeat occurrences are created. Omit for indefinite repeating.",
+ "type": "string"
+}Input schema / properties / repeat_intervalAdded value: +{
+ "description": "Repeat this post automatically after each successful publish. Spawns the next occurrence at the same time.",
+ "enum": [
+ "daily",
+ "weekly",
+ "monthly"
+ ],
+ "type": "string"
+}approve_draftcreate_from_templatecreate_postdelete_postduplicate_postget_postlist_accountslist_scheduled_postslist_templatesupdate_post
Add one secure layer between your agents and this server.