get_postGet full details of a single post by ID, including per-platform publishing status and error messages.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID |
| Name | Required | Description | Default |
|---|---|---|---|
| result | No | The full post record including its id, status, per-platform publishing status, and error messages as returned by the AdaptlyPost API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying that the result includes per-platform publishing status and error messages, giving the agent a better sense of what the response will contain.
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 focused sentence that front-loads the action and resource, then adds the key distinguishing detail about per-platform status and error messages. No wasted words.
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 single-ID lookup tool, the description is complete: it names the resource, the identifier, and the notable contents. An output schema exists, so return-value details do not need to be spelled out, and annotations cover the safety profile.
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 only parameter 'id' is already described as 'Post ID' in the schema. The description's use of 'by ID' reinforces the parameter's role but adds no new format or semantic detail beyond 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?
The description states a specific verb ('Get full details'), a specific resource ('a single post by ID'), and the useful scope of those details ('per-platform publishing status and error messages'). This clearly distinguishes it from list-style siblings like list_posts and list_post_results.
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 mention of 'a single post by ID' implies this tool is for fetching one known post rather than listing or bulk operations. However, it does not explicitly name alternatives or state when not to use it, leaving the routing decision mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly separated by resource and action, but get_post and list_post_results both expose per-platform publishing status/errors, which could cause misselection. create_post and bulk_schedule_posts are closely related, though the descriptions make the single-vs-bulk distinction clear.
All tools follow a consistent verb_noun pattern: create_post, list_posts, upload_media, retry_failed_platforms, etc. Even multi-word actions like bulk_schedule_posts preserve the same style, making the naming predictable and easy to navigate.
With 12 tools, the set is well-scoped for a social media scheduling server. It covers post lifecycle management, bulk operations, media handling, account discovery, and retries without feeling bloated or sparse.
The tool surface covers the full publishing workflow: account listing, media upload, post creation, scheduling, listing, retrieval, updating, deletion, draft publishing, retry, and per-platform result inspection. Limitations like not updating published posts reflect expected platform constraints rather than missing server functionality.