Feedlio

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false, so the safety profile is covered; the description adds useful context that it writes into the media library and yields a uid for reuse. It does not say whether the download is synchronous or requires polling (a get_upload_status sibling exists), nor what happens on a failed/unreachable URL — a meaningful gap for an open-world network operation.

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 tight sentences with zero waste: the primary behavior and return value come first, the alternative routing second. Every clause carries operational information.

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, the description correctly states the return value (uid) and its intended use. For a 3-param, open-world write tool the main missing piece is whether the agent must poll upload status or handle failure modes before using the uid.

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 three parameters are documented in the schema itself, including the workspace_uid guidance about matching the post's workspace. The description only reinforces the 'publicly reachable' constraint on url and adds nothing about formatting or naming behavior 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?

States a specific verb ('downloads'), source (publicly reachable URL), destination ('user's Feedlio media library'), and the output (uid). The scope distinction from create_upload_link is made explicit, so an agent can distinguish this from the sibling without opening either 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?

Gives an explicit when-to-use condition ('publicly reachable image or video URL'), names the alternative for the opposite case ('For a file on the user's device (no public URL), use create_upload_link instead'), and even names the downstream consumer (create_post.media_uids). Nothing 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, but 'the post record is kept with status cancelled' clarifies what the destruction actually means (a status change, not a row removal) — real value beyond the annotation. It stops short of saying whether a cancelled post can later be revived via reschedule_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 sentences, zero waste. The primary effect is front-loaded and the disambiguation follows immediately.

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 mutation tool with full annotation coverage, the description covers what happens, what persists, and which sibling to use instead. It omits reversibility (whether a cancelled post can be rescheduled), a minor remaining gap.

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 schema already documents post_uid as 'uid from list_posts,' which the description merely repeats. No additional format, sourcing, or validation detail is added, so 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 ('cancel') and resource ('a scheduled post') plus the effect ('so it will not be published'). It also names the sibling it is not (delete_post), so an agent can separate the two without opening schemas.

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?

Explicitly routes the agent: use this tool to stop publication while keeping the record, and use delete_post 'to remove it entirely.' That is an explicit when/when-not with a named alternative, plus a pointer to list_posts as the uid source.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive, so the description's job is to add nuance — and it does: publishing is irreversible, publish_now only queues, and the result must be checked via list_posts. The only gap is that 'irreversible publishing' sits uneasily beside destructiveHint=false without reconciling that destructive refers to deletion, leaving a small ambiguity.

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?

Front-loaded with the account-selection prerequisite, then the mode choice, then the irreversibility warning, then platform extras — a sensible priority order. Every sentence carries a constraint, though the platform-specific paragraph partially duplicates nested schema descriptions and could be trimmed without losing guidance.

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 12-parameter, deeply nested, non-idempotent mutation with no output schema, the description covers the account resolution path, mode exclusivity, irreversibility, return value (post_uid), and the four platform-specific sub-objects with their prerequisite lookups. Nothing an agent needs in order to call this 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 92% so the baseline is 3, but the description adds genuine semantics the schema cannot express: the exactly-one-of constraint between scheduled_at and publish_now (there is no oneOf/top-level exclusivity in the schema), the rule that one platform settings object applies to every account of that platform, and that a YouTube post takes exactly one video. It repeats some nested-object descriptions already present in the schema, which keeps it off a 5.

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 on one or more connected social accounts') and immediately distinguishes itself from siblings by naming reschedule_post / cancel_post as the consumers of its return value and by describing its own create-and-schedule dual mode. An agent can separate this from update_post or list_posts without opening a 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?

Explicit prerequisites and exclusions: call list_social_accounts first, use only accounts with can_post: true, copy platform_slug verbatim, never guess. It gives the decision rule between the two modes ('when in doubt, schedule'), requires explicit user consent for publish_now, and adds per-platform preconditions (get_tiktok_creator_info, list_pinterest_boards) plus the Dev.to isolation constraint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavior beyond annotations: the link is one-time, expires in 30 minutes, supports files up to 500 MB, converts WebP to JPG/PNG, and returns fields such as upload_page_url, upload_url, and ticket_uid. These details are exactly what an agent needs before invoking a non-readOnly, non-idempotent 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?

The description is dense but front-loaded and every sentence carries operational value: routing condition, return format, upload options, follow-up steps, size limit, and conversion behavior. There is 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?

Although there is no output schema, the description explains the relevant return fields and the full upload lifecycle, including polling with get_upload_status and reusing media_uid in create_post. Combined with full schema coverage, the definition is complete enough for an agent to invoke it correctly.

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 schema already documents both name and workspace_uid. The description does not add parameter-level meaning beyond the schema, so the baseline score 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?

The description states a specific action and resource: creating a one-time upload link for an image or video on the user's device. It also explicitly distinguishes this from the public-URL path used by sibling add_media_from_url, so an agent can select it confidently.

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 gives explicit when-to-use conditions ('user wants to post an image or video that is on their device, not at a public URL') and names the downstream alternatives/workflow: get_upload_status for polling and create_post for publishing. It also explains the two upload paths: user opens upload_page_url, or the agent POSTs to upload_url itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the safety bar is lower, but the description adds nothing beyond them. It does not mention that repeat calls create duplicates (non-idempotent), whether the caller becomes owner, or what the response contains.

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 short, front-loaded sentence with zero filler. It is appropriately sized structurally, though the brevity comes at the cost of substance rather than being a model of efficient density.

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 one-parameter creation tool with no output schema, the description still leaves open what is returned (workspace id?), whether duplicates are allowed, and any post-creation expectations. The mutation context is only conveyed by the tool name and annotations.

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 a single required parameter with 100% schema description coverage ('Workspace name'), so the schema carries the load. The description contributes no extra meaning such as constraints on the name or whether it must be unique.

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 (create) and resource (workspace), so the agent can tell it apart from delete_workspace and list_workspaces by name alone. But the sentence is a near-verbatim restatement of the title, adding no distinguishing detail about what a created workspace contains or defaults to.

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 guidance on when to use this versus add_media_from_url/set_default_workspace, no prerequisites (plan limits, name uniqueness), and no note on what to do afterwards. Usage must be entirely inferred from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description isn't carrying the safety burden alone; it still adds the workflow requirement to confirm with the user before calling, which annotations cannot express. 'Irreversible' is consistent with destructiveHint and deletion remaining idempotent, so there's no contradiction, though it says nothing about downstream effects on posts referencing the file.

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: the action and scope come first, the uid source and the irreversibility warning follow. Nothing is wasted and nothing important is buried.

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 two-parameter destructive tool with full annotations and no output schema, the definition covers the action, the identifier source, and the safety precondition. Only the collateral impact (e.g. whether posts using the media are affected) is left unstated.

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 schema already documents that media_uid comes from list_media and that workspace_uid may be omitted for the default workspace. The description repeats the uid provenance but adds no meaning beyond the schema, so the baseline of 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 precise verb-plus-resource ('Permanently delete a file from the media library') and names the sibling list_media as the source of the uid. It doesn't explicitly contrast itself with delete_post or delete_workspace, so sibling differentiation is only implicit in the resource noun.

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?

'Irreversible — confirm with the user first' establishes a required precondition for use, and '(uid from list_media)' routes the agent to the tool that supplies the identifier. There's no when-not guidance, but the usage context is clear enough for an agent to act on.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's added value is real: 'Permanently... Irreversible' plus a confirm-first instruction and the platform-side persistence caveat. It still doesn't describe what happens on an invalid/repeated uid or the response shape, keeping it just short of top marks.

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 tight sentences with the destructive scope front-loaded, the identifier source next, and the platform-side boundary last. No redundancy against the schema or 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?

For a single-parameter destructive tool with no output schema, the description covers purpose, argument source, irreversibility, user confirmation, and the caveat about the social platform. Nothing material an agent needs before calling 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?

Only one parameter and schema coverage is 100%, so the schema already documents post_uid. The description's 'uid from list_posts' mirrors the schema and adds no format or edge-case detail beyond it, 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 (permanently delete) and resource (a post from Feedlio) with the source of the identifier (uid from list_posts). It also clarifies the boundary of the operation ('does not remove content already published on the social platform'), which makes it distinguishable from cancel_post and update_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 for how to obtain the argument and an explicit confirm-with-user prerequisite before calling. It does not, however, explicitly contrast with the sibling cancel_post, leaving the delete-vs-cancel decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond that: deletion is irreversible through MCP, the workspace vanishes from the user's list, the default workspace is protected, and scheduled posts survive the deletion. These are exactly the side effects an agent needs before calling a destructive 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 dense sentences, each carrying a distinct constraint: irreversibility/confirmation, default-workspace protection, and scheduled-post behavior. The destructive nature is front-loaded in sentence one with zero 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 single-parameter destructive tool with no output schema, the description covers everything an agent needs: the risk profile, the confirmation requirement, the blocking precondition, and the uncascaded side effect. Nothing material is left to inference.

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 coverage is 100%, so the schema already documents workspace_uid. The parenthetical "uid from list_workspaces" duplicates the schema description rather than adding new meaning. Baseline 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?

States a specific verb and resource ("Delete a workspace") and immediately identifies the identifier source (uid from list_workspaces). An agent can distinguish this from create_workspace or set_default_workspace without opening the 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?

Gives clear preconditions and ordering constraints: confirm with the user first, switch the default workspace before deleting, and cancel scheduled posts if they shouldn't publish. It does not name the sibling tools (set_default_workspace, cancel_post) explicitly, so the agent must map actions to tools, but the conditions themselves are unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish that this is a safe read-only operation. The description adds valuable behavioral context: it returns a link and the user must complete the connection themselves in Feedlio's dashboard, explaining why direct connection is not possible.

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 two focused sentences with no wasted text. It front-loads the key constraint and then states exactly what the tool returns.

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 link-generation tool, the description covers the essential workflow: why direct connection is impossible, what the tool returns, and who completes the action. Schema and annotations fill in the remaining structural details.

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 schema fully documents the single optional platform_slug parameter, including its purpose. The description does not add parameter-level details beyond that, which is acceptable given 100% schema coverage but limits the score to the baseline.

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: it returns a dashboard link rather than performing the connection itself. It clearly explains the tool's role, though it does not explicitly differentiate itself from siblings like list_social_accounts.

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 gives clear context for when this tool is needed: connecting a social account requires an OAuth popup that cannot be driven from a chat call. It does not name alternative tools or explicit exclusions, so it falls short of a perfect usage score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context by naming the returned posting options and specifying the action to take when can_post is false, though it does not cover every possible response detail or failure mode.

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 main purpose and then gives the critical usage rule. Every sentence contributes directly to understanding what the tool returns and when to call it, with no wasted text.

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 tool with one fully documented parameter and rich annotations, the description supplies the important output fields and the pre-post workflow. It is complete enough for an agent to call it correctly without an output schema.

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 social_account_uid is fully documented as a TikTok account uid from list_social_accounts. The description itself does not add meaning beyond the schema, 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?

The description states a specific verb and resource: it returns what a connected TikTok account is allowed to post right now, including named fields such as privacy_level_options, can_post, and max video length. It also ties the tool directly to create_post.tiktok.privacy_level, making its role distinct from sibling tools like create_post or list_social_accounts.

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 gives a clear usage rule: call it before every TikTok post, and if can_post is false, tell the user to try again later. The context is explicit, though it does not name when not to use it or compare it against alternatives beyond the create_post reference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description contributes the actual state machine (pending/uploaded/failed/expired) and what each state means for downstream action. It does not say whether the call is cheap enough to poll, how long before pending turns to expired, or where the error payload lives, which would be the remaining behavioral detail.

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 resource and its source, then a compact parenthetical mapping each state to its consequence. Every clause earns its place and there is 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?

With no output schema, the description does the work of explaining return values by enumerating the four possible statuses and their meanings, which is exactly what an agent needs to branch on. Minor gaps remain (expiry timing, where the error detail is surfaced, polling expectations) that keep it from being fully self-sufficient.

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 single parameter ticket_uid is already documented as coming from create_upload_link, so the description only echoes the schema's origin note. No additional syntax, format, or lifetime semantics for the ticket are added; 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 resource and operation – retrieving the status of a link produced by create_upload_link – and names the originating sibling tool, so an agent can place it in the upload workflow without inspecting the schema. It is distinguishable from create_upload_link and create_post, the siblings that share its domain.

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?

Goes beyond mere purpose by prescribing the next action per state (use media_uid in create_post when uploaded; create a new link when failed), which effectively tells an agent where to go next. It lacks an explicit statement of when to poll versus wait, or that this should be called after create_upload_link rather than before, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds the genuinely useful fact that results carry a uid consumed by create_post, but stays silent on pagination (page/limit exist) and on the fact that document/audio items cannot be attached despite being listable.

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 sentences, zero filler, with the core capability stated first and the downstream usage second. Nothing could be removed without losing information.

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 read-only list tool with annotations covering safety, this is nearly complete: it names the resource, the scope, and the shape of at least one returned field (uid), which matters because there is no output schema. Missing only pagination guidance and the type-vs-attachability caveat.

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 60%, so the description is not obligated to carry everything, yet 'images/videos' reinforces the type filter's practical meaning and the uid hint connects results to a parameter. It still leaves page and limit unexplained in either place, so it does not fully 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 ('List images/videos in the user's Feedlio media library'), which cleanly separates it from siblings like add_media_from_url or list_posts. The only blemish is that the schema's type enum also allows document/audio, so the stated scope is slightly narrower than what the tool actually returns.

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 second sentence gives a concrete downstream use (feed the uid into create_post.media_uids), which implies 'use this to find attachable media'. It never says when to prefer add_media_from_url, create_upload_link, or delete_media instead, nor what happens when the library is empty.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered without the description. The description adds the workflow context but says nothing about pagination, result size, or what a board object contains.

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, front-loaded with what the tool does and followed by the single most useful integration fact. 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 single-parameter list tool with full annotation coverage, the description plus schema give enough to call it correctly and to use the result. Minor gap: no note on return shape (board id/name) or whether all boards are returned, and there is no output schema to compensate.

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 is already documented as 'uid of a Pinterest account from list_social_accounts'. The description adds no further meaning about the parameter, which is acceptable at full 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 and resource ('Lists the boards on a connected Pinterest account') and is clearly distinct from sibling list tools such as list_media, list_posts and list_social_accounts.

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?

Explains the downstream purpose — Pinterest posts must target a board, so the returned board id is passed to create_post.pinterest.board_id — which tells the agent why and when to call this before create_post. It does not explicitly name list_social_accounts as the prerequisite for obtaining social_account_uid, though the schema covers that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds non-obvious behavior: results come most-recent-first and timestamps are UTC ISO 8601. That is real context beyond structured fields, though pagination defaults and total-count behavior are unstated.

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 tight sentences, zero filler, with the core scope and ordering front-loaded and the timezone caveat second. Every clause carries information.

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 description covers identity, scope, ordering, and time semantics, which is adequate for a read-only list tool with annotations carrying safety. But with six optional parameters, low schema coverage, and no output schema, the absence of any pagination or search guidance leaves a real gap.

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 only 17% — just the platform slug is documented — and the description does not compensate for the other five parameters (page, limit, search, content_type, workspace_uid). It only alludes to workspace scoping in prose; nothing explains filtering or paging semantics an agent would need to call it well.

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 ('List posts') and adds scope (a Feedlio workspace), the statuses included, and the sort order, so an agent knows exactly what set it gets back. It does not explicitly contrast itself with siblings like list_media or list_workspaces, which is the only thing keeping it from 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 by the listed statuses; there is no statement of when to prefer this over list_media or when filtering is required. The one real piece of guidance is the presentation instruction to convert timestamps using list_workspaces, which is helpful but limited to output formatting rather than tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely new behavioral facts: the shape of each result (uid, platform_slug, can_post), that create_post rejects ineligible accounts, and that platform slugs must be taken verbatim rather than inferred. It stops short of covering ordering, pagination, or the size of a typical result set, keeping it at 4 rather than 5.

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?

Four tight sentences: purpose first, then result shape, then the create_post handoff, then the failure case. No restatement of the title or annotations, and every sentence carries decision-relevant information.

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?

Two simple parameters with full schema coverage, no output schema, and closed-world/read-only annotations. The description supplies the one thing the structured data cannot: what the returned fields mean and how to use them correctly downstream. Nothing an agent needs to call this successfully 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%, so the baseline is 3. The description goes slightly beyond it by establishing that platform_slug values are authoritative and must come from real account records rather than being guessed, which informs how the social_platform filter should be populated. It adds no detail on workspace_uid beyond the schema's own note.

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?

Opens with a specific verb+resource ('List the social media accounts connected to a Feedlio workspace'), which is clearly distinct from sibling listers like list_workspaces, list_media, and list_posts. An agent can route to this tool without inspecting the 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?

Explicitly ties the tool to the downstream create_post flow, states the eligibility rule (can_post: true), and gives a when-not path for can_post: false ('tell the user instead of retrying'). That is both positive routing and an exclusion, which is the top of the rubric.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: results can include workspaces with locked_by_plan: true that are unusable until upgrade or dashboard action. It doesn't cover pagination limits or the return shape, keeping it below a 5.

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 tight sentences with the core purpose front-loaded and no filler. The parenthetical '(accounts, posts)' is slightly awkward but earns its place by naming affected resources.

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?

A paginated list tool with no output schema should at least hint at bounds or ordering, which it doesn't. The locked-plan disclosure is valuable, but the pagination parameters and result shape remain unexplained, leaving an agent guessing on page/limit behavior.

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 33% — page and limit have no descriptions at all, and the description says nothing about pagination or filtering semantics. With low coverage the description should compensate, but it does not; only 'search' is self-documenting in 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?

States a specific verb ('List') and resource ('authenticated user's Feedlio workspaces') with clear ownership scope. It is distinguishable from siblings like list_posts or list_social_accounts by resource, though it doesn't explicitly say so.

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 guidance on when to call this versus related tools (e.g., before create_workspace or set_default_workspace), nor any prerequisites. The second sentence explains plan-locked behavior but is not usage selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already state that this is a non-destructive, idempotent mutation with no open-world side effects. The description adds the useful constraint that the target must be a scheduled post, but it does not cover failure cases, timezone behavior, or permissions.

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 a single front-loaded sentence with no filler. The parenthetical uid hint is directly useful and does not distract from the core action.

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 two-parameter, idempotent mutation with full schema coverage and clear annotations, the description is largely complete. The remaining gap is minor: it could say more about what happens when the post is no longer scheduled or how time zones are interpreted.

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 are fully documented in the schema, including the ISO 8601 future-datetime format. The description only repeats the post_uid source and adds no further parameter meaning 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 and resource: change the scheduled time of a scheduled post. It also identifies where the uid comes from (list_posts), which helps distinguish it from broader update_post usage, though it does not explicitly name sibling alternatives.

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 implies the tool should be used for posts that are still scheduled and points to list_posts for the uid. However, it gives no explicit exclusions such as not using it for published posts or using update_post for other edits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the downstream effect: subsequent calls that omit workspace_uid inherit this setting. It stops short of saying whether this is per-user, per-account, or requires admin rights.

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 with no padding; the core action is front-loaded and the scoping note follows immediately. Nothing to trim.

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, idempotent setter with no output schema, the description covers action and effect adequately. Gaps are permission/scope persistence and what the response confirms, which are minor but non-trivial for a settings mutation.

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 and schema coverage is 100% ("uid from list_workspaces"), so the schema already carries the semantics. The description adds no format hints or examples beyond what the schema states, which is the baseline case.

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 ("Set which Feedlio workspace is the default"), plus the consequence in a second sentence. An agent can distinguish it from list_workspaces/create_workspace/delete_workspace by verb alone, though the description never explicitly contrasts 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?

The note that "new posts/queries that omit workspace_uid use this one" implies when the tool matters, but the description never says when to call it versus simply passing workspace_uid per call, nor any prerequisite. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say non-read-only, idempotent, non-destructive; the description goes further by disclosing PATCH-style merge semantics ("only the fields you pass change"), that target accounts are immutable here, and the time-based eligibility cutoff. That is exactly the extra context the annotations do not provide.

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?

Four tight sentences, front-loaded with the core operation and identity, then merge semantics, then editability boundaries. No filler and no restatement of the title or name.

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?

Covers eligibility, partial-update behavior, and the account-immutability boundary, which is everything needed to invoke a 10-param mutation safely. It does not say what a successful edit returns, which is a minor gap given there is no output schema.

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 60%, and the description maps the editable parameter groups (text, media, first comment, scheduled time, per-platform settings blocks) so the agent knows which top-level params are updatable. It still defers per-field rules (pinterest board_id requirement, TikTok privacy sourcing, tag limits) to 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?

States a specific verb and resource (edit a scheduled post) and pins the identity semantics with "keeping the same post (uid from list_posts)". It is clearly distinguishable from create_post and cancel_post, which it names.

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 explicit when-to-use (only posts still scheduled, not already publishing or due within minutes) and explicit when-not/alternatives (change target accounts via cancel_post and create_post instead). Nothing 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.