Read, draft and schedule social media posts to 8 platforms (Instagram, X, TikTok, LinkedIn, YouTube, Threads, Facebook, Fanvue) from Claude, Cursor or any MCP client. OAuth or bearer token; no post-now tool by design. Docs: https://github.com/Thorarinsson22/smart-post-studio-mcp
Scored across 6 tools
Each tool targets a distinct action on a distinct resource: cancel_post reverts to draft, update_post edits fields, create_post makes new posts, and the three read tools split cleanly between platforms, single-post results, and the queue. The cancel vs update boundary is explicitly clarified by descriptions. No meaningful overlap remains.
All six tools follow a consistent snake_case verb_noun pattern (cancel_post, create_post, get_connected_platforms, get_post_results, list_posts, update_post). Verb choice matches the operation type predictably (get/list for reads, create/update/cancel for mutations).
Six tools is well-scoped for a post scheduling/publishing domain, covering the create-read-update-cancel lifecycle plus platform discovery. Every tool earns its place with no filler.
The surface covers creation, listing, single-post retrieval, editing, and cancellation (soft revert to draft), which is nearly full lifecycle coverage. The main gap is a hard delete_post for drafts or failed posts, though cancel_post may be intended to cover this.
Cancel a scheduled post: reverts it to draft so it will not fire. Does not delete anything.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses the state transition (reverts to draft, will not fire) and the non-destructive nature, which is meaningful context. It still omits auth/permission needs, reversibility (can it be rescheduled?), idempotency, and error behavior for an already-published post.
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 statements, front-loaded with the action and effect, with the non-destructive clarification placed last. No padding, though the second sentence is a fragment rather than fully integrated prose.
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-parameter tool with no output schema and no annotations, the description covers the essential outcome (draft revert, no deletion). It is borderline adequate but silent on return value, failure cases, and permission requirements that an agent may need before invoking.
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 0% and the description never mentions the required 'id' parameter or what identifier it expects (post id vs. scheduled-job id). With one undocumented parameter, the description does not compensate for the schema gap, leaving semantics to inference.
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 (cancel a scheduled post) and adds the concrete effect: reverts to draft so it will not fire. It implicitly distinguishes itself from update_post and does not overlap with the read/result siblings, though it never explicitly names an alternative.
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 by the effect description (use when a scheduled post should not fire) and by the 'does not delete' note, which steers away from destructive expectations. However there is no explicit when-to-use vs update_post, and no prerequisites or state conditions (e.g. post must be scheduled) are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a draft or scheduled post. scheduled_at (ISO 8601) must be at least 10 minutes in the future; omit it for a draft. media_urls are fetched server-side (max 25 MB each).
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | ||
| platforms | Yes | Must be platforms the account has connected — see get_connected_platforms. | |
| media_urls | No | Public https URLs of images/videos to attach. | |
| scheduled_at | No | ISO 8601. Omit for a draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavior: the 10-minute future scheduling rule, server-side media fetching, and a 25 MB per-file cap. However, it says nothing about the publish outcome, permission/auth requirements, rate limits, or whether the created post is immediately live, leaving meaningful gaps for a creation 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?
Two dense sentences with the core capability front-loaded and constraints following immediately. No filler, though 'media_urls are fetched server-side' could be marginally clearer about what that implies for the caller.
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 creation tool with no annotations and no output schema, the description covers scheduling and media adequately but omits what happens after creation (e.g., post identifier returned for later update/cancel) and any permission prerequisites. It is functional but not complete for the full create-post workflow.
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?
Beyond the schema's 75% coverage, the description adds semantics the schema lacks: scheduled_at must be at least 10 minutes in the future, and omission means draft; media_urls are fetched server-side with a size limit. It does not clarify the platforms parameter beyond what the schema already documents.
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 states a specific verb and resource ('Create a draft or scheduled post') and immediately clarifies the two operating modes via the scheduled_at flag. It does not explicitly distinguish itself from siblings like update_post or cancel_post, but the create semantics are unambiguous from the name and first sentence.
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 clearly tells the agent when to omit scheduled_at (draft) versus provide it (scheduled), and gives the timing constraint that governs that choice. It stops short of naming alternatives such as update_post for editing an existing post, so there is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which platforms this account can post to right now, and whether each publishes from the cloud or from the user's desktop app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the meaningful behavioral trait: results are live ('right now') and each entry carries a delivery mode (cloud vs. desktop app). It says nothing about auth requirements, permissions, or the shape/flatness of the returned list, so the disclosure is partial.
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 that states both the resource and the per-item attribute, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey return semantics, and it does at a high level: a per-platform list with a publishing route. For a zero-parameter read tool this is close to sufficient, though it never describes the field names or shape of the returned object.
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 there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless, account-scoped lookup.
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 the exact resource (platforms this account can post to) and adds a second dimension — whether each platform publishes from cloud or desktop. An agent can distinguish this read-only lookup from siblings like create_post or list_posts. It does not explicitly name the siblings it differs from, keeping it 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?
No when-to-use guidance and no alternatives referenced. The connection to create_post (check availability before posting) is only inferable from the phrasing 'can post to right now' rather than stated. An agent gets no explicit rule for choosing this tool over get_post_results or list_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one post with its per-platform results (after it fires).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses one meaningful behavioral trait — results only exist after the post fires — but says nothing about what happens if the post hasn't fired, auth requirements, or error/empty 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. The parenthetical condition is compact, though the phrasing "after it fires" is slightly informal.
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 one-param read tool with no annotations and no output schema, the description conveys the core result shape (per-platform results) but leaves the id's meaning and the not-yet-fired case unexplained.
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 0% and the single id parameter is undocumented in the schema. The description's "one post" weakly implies id identifies the post, but adds no format or source guidance for the identifier.
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 (Fetch) and resource (one post with its per-platform results), and the singular phrasing distinguishes it from list_posts. It doesn't explicitly name a sibling, but the scope contrast with the list tool is evident.
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?
"After it fires" implies the temporal precondition for using this tool, which is useful context, but no alternative or exclusion is named (e.g. when to prefer list_posts instead). 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.
List the queue: drafts, scheduled, posted and failed posts, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows, 1-100. Default 25. | |
| status | No | Filter by status (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real behavioral context: the default scope spans all four statuses and results are ordered newest first, which an agent cannot derive from the schema. It says nothing about read-only safety, result shape, or pagination behavior beyond the limit field, so gaps remain.
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 (status enumeration, sort order) conveys information the agent needs. 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 simple read-only two-parameter list tool with full schema coverage and no output schema, the description covers scope and ordering adequately. It could say more about what each returned post contains, but the core call is unambiguous.
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% with an enum on status and a documented limit range/default, so the schema already does the heavy lifting. The description adds only the ordering guarantee ('newest first') and the fact that omitting status returns all statuses, which is marginal param-level value.
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 ('the queue') and enumerates exactly what is returned (drafts, scheduled, posted, failed posts) with sort order. It is clear enough to distinguish from siblings like create_post or get_post_results, though it never explicitly contrasts itself with any of them.
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 by the verb and the enumerated statuses; there is no statement of when to prefer this over get_post_results or how it relates to the queue-modifying siblings. No prerequisites or exclusions are given, so the agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update caption, platforms or schedule of an existing post. Requires expected_updated_at from a fresh list_posts/get_post_results read (optimistic locking).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| caption | No | ||
| platforms | No | ||
| scheduled_at | No | ||
| expected_updated_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses the optimistic-locking mechanism, which is valuable, but omits other mutation-relevant facts such as permission requirements, reversibility, conflict-handling behavior, or response format. This is a meaningful gap for a write tool with no structured safety hints.
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 tightly written sentences that front-load the operation and follow with the critical precondition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a five-parameter mutation tool with no annotations, no output schema, and zero schema descriptions, the definition covers the core action and the locking requirement but leaves the agent without parameter-level guidance or behavioral context. It is minimum viable but not 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 0%, so the description must compensate. It names three parameters (caption, platforms, schedule) but provides no syntax, format, or type details, and completely omits id and expected_updated_at semantics beyond the locking note. With five parameters at zero coverage, the description adds marginal meaning and leaves the agent guessing.
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 clear verb (Update) and resource (post) and enumerates the mutable fields (caption, platforms, schedule). It is distinguishable from sibling create_post by being an update on an existing post, though it does not name siblings 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?
Specifies a required precondition ('requires expected_updated_at from a fresh list_posts/get_post_results read'), effectively naming the sibling tools that must be called first. It does not state exclusions (e.g., which posts cannot be updated or what to do on conflict), but the context 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.
cancel_postcreate_postget_connected_platformsget_post_resultslist_postsupdate_post
Add one secure layer between your agents and this server.