get_postRetrieve a single post's targets, status, media, schedule, publish results, and live URL when published. Use it to inspect or verify one social post before or after scheduling.
Fetch one post with its targets, status, media, schedule, publish results, and live URL when published.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes |
Changes observed during successful MCP inspections.
v0.3.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's real contribution is disclosing what the response will contain — targets, status, media, schedule, publish results, and a live URL only when published. That conditional ('when published') is genuinely useful behavioral detail, though error/not-found behavior and auth requirements are not addressed.
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 dense sentence that front-loads the verb and resource, then lists return contents in priority order. No filler, nothing redundant.
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 and only one input parameter, the description usefully carries the return-value burden by enumerating the fields returned and their conditional nature. The remaining weak spot is the unidentified postId, which leaves the invocation path slightly under-explained.
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 single required parameter postId is undocumented in both schema and description. The description says 'one post' but never explains the identifier's format or where to obtain it (e.g., from list_posts), so it does not 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?
The description states a specific verb ('Fetch') and resource ('one post'), and enumerates the payload (targets, status, media, schedule, publish results, live URL). This clearly separates it from list_posts and the mutation siblings (create_post, update_post, delete_post), though it never names those 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?
There is no when-to-use guidance: nothing tells the agent to use this after list_posts returns an ID, or to prefer it over get_post_analytics / list_post_analytics for these fields. The singular 'one post' weakly implies retrieval by a known ID, but no alternative or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.