list_post_resultsCheck per-platform posting results — success/failure status with error details for each platform a post was sent to.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID to check results for |
| Name | Required | Description | Default |
|---|---|---|---|
| result | No | The per-platform posting results with success/failure status and error details 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, and the description adds that the operation inspects per-platform delivery status and error details. It does not mention rate limits, authorization requirements, or pagination, but for a read-only lookup backed by an output schema those omissions are minor.
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 that opens with the verb and object, then specifies the exact returned information. There is no redundant filler, making the description easy to scan.
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-parameter read-only tool with an output schema and safety annotations, the description is largely sufficient. It could be more complete by hinting that this is the tool to use after scheduling or publishing to verify delivery, but nothing essential to invoking it 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 coverage is 100% and the sole parameter 'id' is already described as 'Post ID to check results for'. The description does not add new parameter-level meaning, 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 uses a specific verb ('Check') with a clear resource ('per-platform posting results') and defines the scope ('success/failure status with error details for each platform a post was sent to'). This distinguishes the tool from siblings like get_post or create_post, which target the post itself rather than per-platform delivery outcomes.
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 description implies this tool is used after a post has been sent to platforms to check delivery outcomes, but it does not explicitly say when to prefer it over get_post or whether get_post also surfaces similar results. No when/when-not guidance or named alternatives are provided.
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.