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

Annotations already declare readOnlyHint=true, so the description's main addition is the proTrialDaysLeft field explanation. It also implies the tool lists multiple instances and accounts, adding context beyond the annotations. No contradictions.

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 sentences with no fluff. The core purpose is front-loaded, and the proTrialDaysLeft note is a targeted, useful addition. Perfectly sized.

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 zero parameters and an output schema absent, the description is quite complete. It tells the agent what to expect from the output (list of instances, accounts, default target) and even explains a key field. The only minor gap is not specifying the exact output format, but the description covers the essentials.

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 has zero parameters, and the schema already defines that (100% coverage). The description adds value by explaining what the output contains, which is especially useful since there is no output schema. With no parameters to clarify, the baseline of 4 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 clearly states a specific verb ('List') and resource ('connected browser instances, the account each is logged into, other available accounts, and the default target'). It distinguishes from siblings by its unique read-only nature, though it doesn't explicitly name a sibling, the purpose is clear and specific.

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 usage for checking account status and available accounts, but does not explicitly say when to use this tool versus alternatives. It provides context about the proTrialDaysLeft field, which helps agents decide when to use write tools, but no exclusions are given.

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 declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description must carry the state-change story — and it does: later calls act as the new account, open Instagram tabs are reloaded, and the active-account case is a no-op. That side-effect disclosure is genuinely useful beyond the annotations, though it doesn't cover failure modes (e.g. not-logged-in accounts) or persistence across sessions.

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 a parenthetical cross-reference; the core action and its consequence on later calls are front-loaded, and nothing is wasted.

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 no-required-parameter state-switch tool with no output schema, the description covers the action, the source of the target id, the side effect on open tabs, and the no-op case. It could go slightly further on what the caller should do after switching or what happens on failure, but nothing essential 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 description coverage is 100%, so all four parameters are already documented, including the userId/username alternative and the `instant` pacing rule. The description adds no parameter detail beyond restating that the target comes from account_info, so the baseline 3 is correct.

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 ('Switch') and resource ('the browser profile to another logged-in account'), and explicitly points to account_info for the account list, which is the adjacent sibling an agent would confuse it with. An agent can tell this apart from account_info 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 clear preconditions (account must be logged in, id/username comes from account_info) and an explicit no-op case ('Switching to the active account is a no-op'), plus per-parameter usage rules for `instant`. It stops short of naming an alternative tool or stating when switching should be avoided.

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 declare readOnlyHint=false but destructiveHint=false; the description explains why by stating it writes a CSV file to disk and returns the path, so the agent understands the side effect is a local file artifact. It also discloses the PRO entitlement requirement, which annotations do not cover.

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 tightly packed sentence: action, payload, output format, and return value are front-loaded, with the entitlement prerequisite in a trailing parenthetical. 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 single-optional-parameter export tool with no output schema, the description covers everything needed: what is exported, the file format, the return value, and the PRO requirement. Nothing an agent needs to invoke 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?

There is a single optional parameter with 100% schema description coverage, so the schema already explains the instance id and its default. The description adds nothing about the parameter, which is acceptable given the coverage 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?

States a specific verb (export), resource (full antibot follower analysis), content (risk + type per follower), format (CSV) and return value (path). This distinguishes it reasonably from antibot_scan and antibot_report, 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?

The description implies the tool is for getting the complete analysis as a file, and it discloses the INSSIST PRO prerequisite, which is useful gating information. However, it gives no explicit when-to-use versus antibot_scan (which presumably produces the analysis) or antibot_report.

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 establish the safe read-only, non-open-world profile, but the description adds genuinely new behavioral context: the result is empty until a scan runs, and PRO entitlement is required. It also characterizes the payload (risk/type totals plus unreviewed high/medium-risk followers), which annotations do not cover.

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 lead with what the report contains, then append the empty-state and PRO preconditions parenthetically. Every clause carries information and nothing is wasted.

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 takes on the burden of describing return values (totals by risk/type plus flagged followers) and notes the empty-state and entitlement preconditions. For a simple one-parameter read tool this is nearly complete, with only the export/scan routing left implicit.

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% with a single optional 'instance' parameter fully documented in the schema, so the baseline is 3. The description adds nothing about the instance parameter (or fallback to the active instance), so there is no uplift 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: 'follower quality analysis' producing 'totals by risk and type' plus flagged followers, drawn from the last scan. This clearly separates it from antibot_scan (which runs a scan), even though no sibling is named explicitly. The core purpose is unambiguous.

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?

'Empty until a scan has run' is an implied precondition that usefully tells the agent to call antibot_scan first, and the INSSIST PRO requirement is a real gating condition. However, it gives no explicit routing guidance versus the close alternatives antibot_scan and antibot_export, leaving the when-to-use 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?

Adds meaningful context beyond annotations: it runs in the background (async), the follow-up action is to poll antibot_report, and it explicitly removes no one, matching destructiveHint=false. Does not contradict annotations; the INSSIST PRO requirement is a useful operational constraint.

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 front-loaded with the verb and output, then async behavior, then the critical safety caveat, then the license requirement. No waste.

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 the async workflow (poll antibot_report), safety (removes no one), and licensing. No output schema exists, but the description adequately explains what the scan yields. Missing detail on scan duration or rate limits, but otherwise 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 100%, so the schema already documents both 'instant' and 'instance' thoroughly. The description adds no parameter-specific syntax or defaults beyond what is in the schema, so 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+resource (start a follower scan) and details exactly what it produces: per-follower bot/suspicious/fresh/clean scores. This distinguishes it clearly from siblings like peers_scan and unfollowers_scan which scan different populations.

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?

Implies usage (run a scan, then poll antibot_report) and makes clear it is detection-only, but does not explicitly state when NOT to use it or contrast with peers_scan/unfollowers_scan alternatives in the sibling list.

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?

Beyond the annotations (which already indicate a non-read-only, non-destructive write), the description discloses that rate-limited calls return done:false and that the tool requires INSSIST PRO. This adds actionable behavioral context for handling throttling and eligibility, going beyond what annotations alone 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?

The description is two short sentences with the primary purpose front-loaded. Every clause adds operational value: the action, the rate-limit caveat, and the PRO requirement. No filler or repetition.

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 the simple write action, the fully documented schema, and annotations covering destructive behavior, the description covers the key additional constraints (rate limits, PRO) that an agent needs to call the tool correctly. There is no output schema, but for a straightforward comment-post operation this is sufficient; one could wish for a note on the success response shape, but the rate-limit mention already implies a done field.

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%, with clear descriptions for post, text, instant, and instance. The tool description itself adds no parameter-specific details, so the baseline of 3 applies; the schema does the heavy lifting.

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 clearly states the action ('Post a comment on a post'), which is a specific verb plus resource. It distinguishes the tool from siblings like comment_delete, comment_like, and comment_reply by focusing on creating a new comment rather than mutating existing ones.

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 gives implicit usage context by stating the core action, plus useful operational constraints like rate-limiting behavior and the INSSIST PRO requirement. However, it does not explicitly contrast with alternatives such as comment_reply or comments_list, so an agent must infer when this tool is preferred over those.

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, and the description meaningfully builds on them: "Permanent" makes the irreversibility concrete, "Rate-limited calls return `done: false`" exposes a detectable failure signal, and "Requires INSSIST PRO" discloses a subscription prerequisite. This is strong added behavioral context beyond the structured fields.

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 front-loads the core action, then appends scope, consequence, behavior, and requirement in order of importance. Every clause earns its place — approximately 20 words carry four distinct pieces of decision-relevant information with zero waste.

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 destructive 4-parameter tool, the description covers the critical operational facts: scope, permanence, rate-limiting behavior with a detectable signal, and the PRO requirement. The only gap is the success-response shape, which matters more because no output schema exists — but the described failure signal partially compensates.

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 the baseline is 3 and the schema already documents all four parameters well, including that commentId comes from comments_list and post accepts id/shortcode/URL. The description adds only marginal semantic value by constraining valid targets to own comments or comments on own posts.

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?

"Delete a comment — your own, or any on your own post." uses a specific verb + resource and adds a scope qualifier that distinguishes it from comment_add, comment_reply, comment_like, and comments_list. An agent can tell exactly what this tool operates on and under what ownership boundary.

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 scope constraint ("your own, or any on your own post") conveys clear context about what the tool cannot do, which prevents misuse on others' content. However, no alternatives are named and no explicit when-to-use vs when-not-to-use guidance is given, so routing among the many sibling comment tools 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 mark readOnlyHint=false, and the description goes further by exposing a rate-limit signal ('Rate-limited calls return `done: false`'), the unlike toggle, and the PRO requirement. This adds meaningful runtime behavior beyond the structured fields and does not contradict annotations.

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 short clauses carry the core action, the rate-limit caveat, and the licensing requirement with no filler. The verb-first construction front-loads the 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 mutation with full schema coverage and no output schema, the description includes the essential operational caveats: how to invert the action, how to recognize rate limiting, and the PRO requirement. Nothing critical is missing for correct invocation.

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%, with descriptions for commentId, unlike, instant, and instance. The description only reinforces `unlike: true` and does not add substantive parameter semantics, so it stays at the baseline for fully documented schemas.

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?

Description opens with a concrete action on a specific resource ('Like a comment') and immediately defines the unlike toggle. This distinguishes it from sibling comment tools such as comment_add, comment_delete, and comment_reply, which perform different operations.

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?

'Like a comment, or unlike with `unlike: true`' gives a usable trigger and inverse case, and 'Requires INSSIST PRO' states a prerequisite. It stops short of explicitly naming sibling alternatives or when-not-to-use, 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.

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

Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false, but the description does not add much beyond that. It discloses rate-limited calls return 'done: false' and requires INSSIST PRO, which is useful behavioral context. However, it does not describe the success response shape or any other side effects, so the added value over annotations is modest.

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 with no filler. The purpose is front-loaded, and the behavioral note is placed second. Every word earns its place, and it is appropriately sized for a simple action tool.

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 5 parameters, no output schema, and moderate complexity, the description covers the essential purpose and one behavioral nuance (rate limiting). However, it does not mention what a successful response looks like, nor does it clarify prerequisites like authentication or how to handle failures. The schema fills parameter gaps, but the description could be more complete about expected outcomes.

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%, meaning all parameters are already described in the schema. The description itself adds no parameter-specific details, such as syntax, examples, or relationships between parameters. Baseline for high coverage is 3, and the description does not elevate that.

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 clearly states the verb 'Reply' and the resource 'a comment', making the primary purpose unambiguous. However, it does not explicitly differentiate from sibling tools like comment_add (which likely adds a new comment rather than replying to an existing one), so it relies on the name and parameter hints rather than explicit distinction.

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 use this tool versus alternatives such as comment_add or comment_delete. The description only states what it does, not the context or exclusions. The parameter 'commentId' hints at usage from comments_list, but that is in the schema, not the description. No when-to-use or when-not-to-use information is provided.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description usefully adds the PRO-subscription requirement, which annotations do not convey, but it says nothing about pagination behavior, return shape, or rate limiting.

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 worded sentences with the core action front-loaded and the PRO constraint appended. No waste, though it is arguably terse given the tool surface, which keeps it from a 5.

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, but the cursor parameter itself references nextCursor, implying the pagination contract, and annotations cover the read-only/open-world nature. For a straightforward read tool, the description plus structured fields give enough for correct invocation.

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 five parameters (post, cursor, instant, replies, instance) are already documented in the schema. The description adds no additional parameter detail 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?

States a specific verb ('List') and resource ('comments on a post and their replies'), which clearly separates it from the mutation siblings comment_add, comment_delete, comment_like, and comment_reply. However, it does not explicitly name or contrast any sibling, so differentiation is inferable rather than stated.

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 'Requires INSSIST PRO' note is a useful precondition, but there is no explicit when-to-use vs. alternatives guidance (e.g., how it relates to comment_reply or pagination flows). Usage is only implied from the verb 'List'.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds real value beyond them by disclosing the state change (request moves into the inbox) and the INSSIST PRO licensing prerequisite, which the annotations do not convey.

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 tight sentence with a parenthetical prerequisite; the purpose is front-loaded and nothing is wasted.

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 mutation with full schema coverage and annotations handling the safety profile, the description is nearly complete. No output schema exists, so return values need not be explained, though the description could note what happens on failure or for a non-PRO account.

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 (instant, instance, thread_id) are fully documented in the schema, including the cross-reference to dm_requests. The description adds no additional parameter 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?

States a specific verb+resource ('Accept a pending DM message request') and adds the resulting effect ('moving it into the inbox'), so an agent knows exactly what the operation accomplishes. It does not explicitly name sibling tools like dm_requests or dm_remove, so differentiation relies on the agent inferring from 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?

The phrase 'pending DM message request' implies the precondition (a request must exist), and the PRO requirement is a useful gating note. However, there is no explicit when-to-use-vs-alternative guidance (e.g., accept vs dm_remove vs dm_read) and no stated behavior when the request is not pending.

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 establish read-only and non-destructive behavior. The description adds a useful behavioral detail: it returns only Instagram's single inbox page and cannot be paged further. This goes beyond the annotations and gives the agent realistic expectations.

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 sentences, front-loads the core action, and includes only essential scope and limitation information. It is easy to parse and contains 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 read-only listing tool with no output schema, the description states what is returned (conversations, last message, awaited-reply flag) and the critical single-page limitation. It is adequate for an agent to select and invoke the tool, though it could name the output structure more explicitly.

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 input schema fully documents both parameters (instant and instance) with clear descriptions, so the tool description does not need to add parameter semantics. No additional parameter information is present in the description, matching the baseline for 100% schema 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?

The description uses a specific verb ('List') and identifies the resource ('recent DM conversations') plus the key fields returned ('last message', 'whether a reply is awaited'). It also clarifies scope with 'Instagram's single inbox page,' which helps separate it from related DM tools like dm_read or dm_requests.

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 the tool is for fetching a summary of recent conversations and explicitly notes the no-pagination limitation. It does not name alternative tools or state when not to use it, so there are no exclusions, but the intended context is clear enough.

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 establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description only needs to add beyond that. It does: it discloses the mutation's exact reach ('up to its latest message'), the resulting state change, and a subscription-tier requirement the annotations do not cover. It stops short of stating reversibility or idempotency.

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 compact sentences with no filler. The core action is front-loaded, and the parenthetical cleanly isolates the separate prerequisite constraint.

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-purpose, low-parameter mutation with no output schema, the description covers what the tool does, its scope, and a gating requirement. Coverage is nearly sufficient; only the absence of any note on idempotency or expected result leaves a small 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 100%, so the schema already documents thread_id, instance, and instant in detail (including the caution about unspaced/burst actions). The description adds no parameter-level meaning beyond the schema, which is the expected baseline when coverage is complete.

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 ('Mark a DM conversation as read') plus the exact scope of the change ('up to its latest message', 'clearing its unread flag'). That scope detail distinguishes it from a plain message-reading sibling like dm_read, but no sibling is named 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?

Usage is implied by the effect described, and a real prerequisite is disclosed ('Requires INSSIST PRO'), which tells the agent a gating condition exists. However, there is no explicit when-to-use guidance, no statement of when not to use it, and no alternative tool named for related needs.

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, so the description's 'Read-only' is consistent. Beyond that, it discloses pagination behavior (returns newest limit, raise limit to reach older, has_more flag) and a requirement (INSSIST PRO). This adds useful context about how the tool behaves, beyond what annotations capture, though it doesn't describe the full return format.

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 three concise sentences with no filler. It front-loads the core purpose, then adds pagination details and the read-only/pro requirement. Every sentence serves a purpose, and the structure is 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?

The description covers the tool's behavior (ordering, pagination), disclaims side effects (read-only), and notes the PRO requirement. Combined with a fully documented schema, an agent has enough to call it correctly without additional context. No output schema exists, so return format is not expected here.

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 all parameters are well described individually. The description adds meaning to 'limit' by explaining it controls pagination (raise to reach older messages), which is not fully captured in the schema's 'How many of the newest messages to return'. This augments the parameter's functional purpose, earning a score above 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 clearly states the tool reads DM conversation messages, specifies ordering (oldest first), and notes it is read-only. This distinguishes it from sibling tools like dm_send or dm_mark_seen. The verb 'read' and resource 'DM conversation's messages' are specific and unambiguous.

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 usage (when you need to read messages) but does not explicitly state when to use this vs. alternatives like dm_list (to find thread_id) or dm_requests (for requests). It lacks exclusions or explicit 'when not to use' guidance, though the read-only nature hints at distinctions.

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, readOnlyHint=false, and openWorldHint=true, so the irreversible-removal profile is carried by structured data. The description adds the INSSIST PRO requirement, which is genuinely useful auth context. However, it doesn't describe what happens to the request on decline or whether it's reversible.

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 plus a parenthetical requirement. Front-loaded with the core action and scope constraint; nothing wasted.

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-target destructive action with full schema coverage and annotations carrying the safety profile, the description is largely complete. The PRO-requirement disclosure is a nice addition. A slightly richer statement of consequences (e.g., the request is removed from the requests list) would push it to 5.

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 all three parameters (thread_id, instant, instance) are documented in the schema, including the burst/pacing nuance for instant. The description adds no parameter detail beyond the schema, so the baseline 3 is correct.

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 compound action (decline and remove) on a specific resource (pending DM message request from dm_requests), and explicitly distinguishes from inbox chats. Sibling dm_accept and dm_requests exist, and this description scopes the target clearly enough that an agent can tell it apart.

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 scope constraint 'Does not touch inbox chats' implicitly tells when not to use it, but there's no explicit when-to-use guidance or named alternative (e.g., dm_accept for the accept path). Usage is implied 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 already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral detail beyond that: it returns Instagram's single requests page and cannot be paged further, and these requests are hidden from dm_list until accepted. This gives the agent important expectations about data visibility and pagination. It does not describe response structure, but that is a minor gap for a simple read-only list.

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 three sentences with no wasted words. The core action and scope are front-loaded, followed by the key behavioral caveat about pagination. The final 'Read-only' is redundant with annotations but harmless. Every sentence contributes useful 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 simple read-only list tool with two optional parameters and no output schema, the description is complete. It explains the exact domain (pending cold inbound requests), the relationship to dm_list, and the pagination limitation. An agent has enough information to select and invoke this tool correctly without needing further context.

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 both parameters (instant, instance) are documented in the schema. The tool description adds no parameter-specific information, so it provides no value beyond the schema. Baseline 3 is appropriate because the schema already carries the full burden.

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 opens with a specific verb and resource: 'List pending DM message requests.' It further clarifies scope by specifying 'cold inbound from non-connections' and distinguishes itself from dm_list by noting these requests do not appear there until accepted. This makes the tool's purpose immediately clear and unambiguous.

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 provides clear context by explaining that this tool handles pending cold inbound requests and explicitly contrasts it with dm_list, which shows accepted conversations. It does not explicitly state 'use when you need pending requests vs. accepted messages,' but the relationship to dm_list gives strong implied usage guidance. No exclusion criteria or mention of dm_accept/dm_read, so it is not a full 5.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses meaningful side effects: first-time contacts land in message requests, cold sends are capped daily, and rate-limited calls return `done: false`. It also flags the PRO requirement. No contradiction with the annotation profile.

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 sentences, all high-signal: recipient selection, side effects, rate-limit response, and a prerequisite. The most important action is front-loaded.

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 the core call path, the two addressing modes, side effects, the daily cap, the rate-limit response shape, and the PRO prerequisite, which is strong for a tool with no output schema. The only minor gap is the success/error response shape beyond the rate-limit case, but this does not block correct invocation.

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 schema already documents all parameters; the baseline is 3. The description adds useful relational semantics by stating that thread_id comes from dm_list and that thread_id and username are alternatives, and it explains the real-world consequence of a previously-unmessaged username.

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 opens with a concrete action ('Send a text message') and scopes it to a specific resource (a DM) with two explicit addressing modes. This is enough to distinguish dm_send from sibling DM tools such as dm_read, dm_accept, and dm_remove.

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 conveys when to invoke it: any time a text DM needs to be sent, addressed either by a thread_id obtained from dm_list or by username. It does not explicitly list alternatives or exclusions, but the context is unambiguous enough that an agent won't confuse it with read/list/accept operations.

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 destroy profile is covered. The description adds the key detail that it deletes saved data and requires PRO authorization, which goes beyond the annotations.

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 compact sentence plus a parenthetical credential note. Front-loaded with the core action and the data-deletion consequence; zero waste.

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-param mutation tool with full schema coverage and annotations, the description covers the essential behavioral quirks (data loss, PRO gate, link to downloads_start). No output schema, so no need to explain returns.

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 schema documents both parameters fully. The description adds only the PRO requirement, not parameter detail, so baseline would be 3, but the mention that jobId comes from downloads_start reinforces the schema's cross-reference.

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 (download), and crucially names the sibling it pairs with (downloads_start). An agent can immediately distinguish this from downloads_start and downloads_status.

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?

Implies usage by referencing downloads_start, but does not state when to cancel versus let it complete, nor any prerequisites beyond the PRO requirement. Usage is implied rather than explicit.

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 mark this as a non-read-only, non-destructive open-world write. The description adds substantial behavior beyond that: async execution with an immediate job id, background processing, output location (timestamped INSSIST/@username/ folder), json+csv manifests, an INSSIST PRO requirement, and the private-account follow constraint.

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?

Purpose and the two-mode split are front-loaded, and every clause carries information (async model, output paths, PRO gate). It is dense with parentheticals, but no sentence is wasted.

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 six parameters, no output schema, and an async job model, the description supplies everything needed: input shape, return value (job id), polling path (downloads_status), and where outputs land. Nothing essential to a correct invocation 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 baseline is 3, but the description adds cross-parameter semantics: username and url are mutually exclusive and only one may be supplied, and `media`/`limit` apply solely to username downloads. That mutual-exclusivity constraint is reinforced in prose rather than left to the schema alone.

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 opens with a specific verb+resource ("Download media to this machine") and immediately distinguishes the two operating modes: whole-account via `username` vs single post via `url`. An agent can tell exactly what this does relative to siblings like ig_fetch_post or downloads_status 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?

It states the selection rule explicitly ("give exactly one") and routes the agent to the correct follow-up tool: poll downloads_status. It also scopes the `instant` flag to a user-requested burst action, which is genuine when-to-use 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 declare readOnlyHint=true, non-destructive, closed-world, so safety is covered. The description goes beyond that by disclosing terminal states (finished/paused/failed), the on-disk folder and json-manifest output, and the PRO requirement — valuable behavioral context not present in annotations.

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 with no filler; the jobId-omission behavior and PRO gate are front-loaded after the core purpose. Slightly packed but every clause earns its place.

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?

No output schema exists, yet the description describes the returned fields (per-type counts, terminal state, folder, manifest path, per-file likes/comments/caption), covering what the agent needs. Only missing minor detail like pagination or refresh cadence for large job lists.

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 baseline is 3, but the description adds the meaning of omitting jobId (list all) and that jobId originates from downloads_start, plus the 'once on disk' timing nuance not captured 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+resource: reporting progress of a downloads_start job, with per-type item counts and terminal states. Clearly distinguishes itself from siblings like downloads_start and downloads_cancel by being the status/progress reader.

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 says 'Omit jobId to list all downloads' and names the sibling that produced the jobId (downloads_start). It implies the polling/reporting use case without listing exclusions, which is clear but not exhaustive.

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 meaningful behavioral context beyond the annotations: it creates a draft rather than publishing, returns a draftId for later use, opens an Instagram tab if needed, and requires PRO. Annotations already indicate a mutating operation (readOnlyHint false) and no destruction, so the description does not need to repeat those. It stops short of describing delays, errors, or session side effects, but is still transparent for this 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?

The description is three short sentences, front-loaded with the primary purpose, followed by necessary workflow and requirement details. Every sentence earns its place without 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?

For a 16-parameter, no-output-schema tool, the description covers the key workflow: create a draft, do not publish yet, use the returned draftId with draft_schedule or draft_publish. It also mentions the tab side effect and PRO requirement. A more explicit statement of the return shape would improve completeness, but the draftId reference largely covers the essential return information.

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 input schema fully describes all 16 parameters with detailed explanations, so the description does not need to repeat parameter meanings. The description adds no new parameter-level semantics beyond 'from photos/videos,' which aligns with the assets parameter. Baseline 3 is appropriate given 100% schema 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?

The description opens with a specific verb and resource: 'Create a draft post in INSSIST Post Assistant from photos/videos.' It also explicitly contrasts with publishing/scheduling by stating 'Not published/scheduled — follow with draft_schedule or draft_publish,' which clearly distinguishes it from the sibling draft tools.

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 provides explicit workflow guidance: 'Not published/scheduled — follow with draft_schedule or draft_publish using the returned draftId.' It also notes environmental prerequisites like opening an Instagram tab if needed and requiring INSSIST PRO, giving clear context for when and how to invoke the tool.

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 openWorldHint=false, and the description adds real context beyond them: the accompanying media is destroyed too, the effect is limited to the local queue, published entries are simply delisted rather than deleted remotely, and an INSSIST PRO license is required. That is exactly the disclosure a destructive tool needs.

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 sentences with zero filler; the destructive scope and its queue-only limit are front-loaded before the PRO licensing note. Nothing is repeated from the schema or annotations.

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 delete with no output schema, the description covers what is removed, what is left untouched, and the licensing gate. An agent has everything needed 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 both parameters (draftId, instance) are documented in the schema, including where draftId comes from. The description adds no parameter syntax or format detail beyond that, 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+resource ('Remove a post from INSSIST Post Assistant, with its media') and immediately scopes it: queue-only, never the Instagram post. This cleanly separates it from the sibling ig_post_delete, which an agent might otherwise confuse it with.

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 boundary condition is explicit: 'Only touches the INSSIST queue: a published entry is cleared from the list, the Instagram post itself is never affected.' That effectively tells the agent when this is the right tool versus ig_post_delete, though it never names the alternative or states prerequisites for published vs draft entries.

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 and non-destructive behavior. The description adds meaningful context beyond that: the untruncated caption relative to draft_list, the presence of a 'last error' field, and the INSSIST PRO requirement — a prerequisite an agent cannot infer from structured fields.

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 compact sentence with a clarifying parenthetical; the returned-field enumeration is front-loaded and every clause earns its place. 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 read tool with no output schema, enumerating the returned fields (status, schedule, caption, assets, music, place, mentions, last error) is genuinely useful. The PRO requirement is disclosed. Minor gap: no mention of failure behavior when the id is invalid.

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 (draftId, instance) are already documented in the schema. The description says 'by id' but adds no syntax or format details beyond what the schema provides; 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 and resource ('Read one Post Assistant post by id') and explicitly enumerates the returned fields, distinguishing it from draft_list by noting the caption is untruncated. An agent can tell exactly what this does versus its siblings.

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 contrasts with draft_list ('Same fields as draft_list, with the caption untruncated'), which implicitly routes the agent: use draft_list for enumeration, draft_get when full caption is needed. It does not state explicit exclusions, so it falls short of a 5.

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 this is a safe read (readOnlyHint=true, destructiveHint=false), so the description earns credit for going further: it discloses result ordering (soonest scheduled first, undated drafts last), cross-account scope, and an INSSIST PRO gating requirement. It omits pagination/limit behavior, which keeps it from 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: the primary action and scope come first, ordering semantics second, and the license constraint last in parentheses. Every clause carries information and nothing is padded.

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 listing tool with no output schema and fully documented parameters, the description supplies the scope, ordering, and prerequisite an agent needs. What is missing is any hint of pagination interaction between limit and result size, but overall it is nearly 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 description coverage is 100% with all three parameters documented, including the status value set and the instance fallback to the active instance, so the schema does the heavy lifting. The description adds only the implicit cross-account framing, which is marginal beyond the schema; 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 clear verb+resource ("List Post Assistant posts") and enumerates the covered states (drafts, scheduled, recently published/failed), so an agent immediately knows the scope. It does not, however, explicitly distinguish itself from siblings like draft_get or draft_create, so it stops short of the 5 threshold.

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?

"Across all logged-in accounts" implies the tool's usage context, and the license note signals a prerequisite, but there is no explicit when-to-use vs alternative guidance. Nothing tells the agent when to prefer draft_list over draft_get or when filtering by status is appropriate; usage is only inferable.

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 declare it as a non-read, non-destructive, non-open-world write; the description goes well beyond that by disclosing irreversibility ('cannot be undone here'), the ~45s wait, that slow uploads continue in the background, and a PRO entitlement requirement. These are exactly the behavioral facts an agent needs and structured fields do not carry.

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 action front-loaded; the parentheticals (background continuation, PRO requirement) each carry distinct, useful information. 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 2-parameter mutation with no output schema, the description covers the essentials: effect, timing, background behavior, and entitlement. It does not state error/rate-limit behavior, but that is a minor gap given the overall coverage.

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 (draftId, instance) are already documented. The description adds no syntax or format detail 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?

States a specific verb and resource ('Publish a draft to Instagram') and scopes it temporally with 'now'. It is clearly distinguishable from siblings like draft_schedule (future) and draft_create (create, not publish).

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 'now — immediate' framing and the 'see draft_list' pointer give clear context for when the result is immediate vs backgrounded. However, it never explicitly names the alternative (e.g. draft_schedule for a future post) so the routing decision is implied 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 cover the safety profile (readOnly=false, destructive=false, openWorld=false), and the description adds genuinely new context: the set of time slots is preserved and only reassigned, the pre-scheduled precondition, and a PRO entitlement gate. It stops short of describing atomicity or failure behavior, so not 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 sentences with zero filler; the core semantics are front-loaded and the alternative tool plus PRO note are tightly appended.

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 tool with no output schema and annotations already covering safety, the description supplies everything an agent needs: the permutation semantics, the precondition, the sibling to use for rescheduling, and the entitlement requirement.

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 further by clarifying that the draftIds array is an ordering that permutes existing slots rather than a list of target times, which sharpens the meaning of the 'wanted order' schema 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?

States a specific verb and resource (reorder scheduled posts) and precisely defines the operation as a permutation of existing times rather than an assignment of new ones. This distinguishes it from draft_schedule, which is named and ruled out.

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 precondition ('All must be already scheduled') and names the alternative tool plus the condition that selects it ('to move to a new time use draft_schedule'). Also flags the INSSIST PRO requirement up front.

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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, which is consistent with a scheduled write. The description adds real value beyond them: it requires Chrome to be running and online at publish time, and requires an INSSIST PRO account. It does not say what happens if a schedule already exists (overwrite vs error), which is a minor gap.

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; the action and its auto-publish consequence are front-loaded, followed by prerequisites and account requirement. 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?

Covers action, timing, prerequisites, runtime environment and account tier — everything needed to invoke correctly, and there is no output schema to explain. Only the conflict/overwrite behavior for an already-scheduled draft is 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 description coverage is 100%, with 'at' fully documented including ISO 8601, local-time default and future-only constraint, and draftId's origin. The description merely restates that draftId comes from draft_create/draft_list, so the schema does the heavy lifting — 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 (schedule) and resource (an existing draft) and adds the crucial outcome that it publishes automatically at that time, which separates it from draft_publish's immediate behavior. An agent can distinguish it from its siblings 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 prerequisite context: use draft_create first, or draft_list to obtain a draftId, and flags the INSSIST PRO requirement. It does not explicitly contrast with draft_publish for the 'publish now' case, but the scheduling semantics make the choice implied.

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 flag destructiveHint, and the description adds the partial-update semantics ('others unchanged'), the draft-only restriction, and the required INSSIST PRO license. No contradiction with annotations.

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 short sentences front-load the core action and scope, then add constraints. Every sentence contributes information; 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?

For a 17-parameter mutation tool, the description plus heavily documented schema leaves no critical invocation gap: it identifies the target resource, required minimal input, constraints, and licensing. No output schema is present, but no return-value behavior is necessary to invoke the tool 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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds meaningful patch semantics — 'Pass at least one field; others unchanged' — that is not captured by the schema's individual field descriptions.

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 action ('Edit') and resource ('an unpublished post') and enumerates the editable dimensions: caption, scheduled time, type, music, place, tags or framing. The exclusion 'Published or publishing posts cannot be edited' separates it from publish/edit-published siblings.

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?

Provides explicit usage constraints: pass at least one field and leave others unchanged, and states a clear when-not condition for published/publishing posts. It does not name an alternative tool in the description itself, though the 'at' parameter routes first-time scheduling to draft_schedule.

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?

Adds substantial behavioral detail beyond annotations: never waits, cursor continuation semantics, first-call behavior returning only the cursor, read-only confirmation, and the PRO prerequisite. No contradiction with readOnlyHint/openWorldHint/destructiveHint.

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?

Every sentence carries functional weight: scope, non-blocking nature, return contract, frequency guidance, access requirement. Front-loaded and dense with 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?

Despite no output schema, the description tells the agent exactly what to expect (events and cursor, or only cursor on first call) and how to sequence calls. Combined with 100% parameter schema coverage, this is sufficient for correct invocation.

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 adds value by explaining the cursor lifecycle ('pass back next time', 'First call without a cursor returns only the cursor') and reinforcing the 'never waits' behavior connected to the instant flag. It does not deeply explain each parameter, but the schema already covers them.

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 clearly identifies the tool as a polling endpoint for new Instagram activity with cursor-based pagination, and it distinguishes the behavior ('never waits', returns cursor) from a generic fetch. It does not explicitly name a sibling alternative, so differentiation is implicit rather than explicit.

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 usage context: 'Check on the schedule the user asked for, minutes apart, not in a loop' and states the PRO requirement. It does not explicitly enumerate when not to use it or name alternatives, but the scheduling guidance is actionable and specific.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds key behavioral details: the follower is not notified, can follow again, and the operation is rate-limited with a `done: false` indicator. It also mentions the INSSIST PRO requirement, providing transparency about prerequisites. No contradiction with annotations.

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 sentences with no fluff. The primary action and differentiation from ig_block are front-loaded, followed by behavioral notes and a requirement. Every sentence adds value.

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 tool with one required parameter and no output schema, the description covers all essential aspects: what it does, when to use it, key behavioral consequences, rate-limit behavior, and a prerequisite. No critical information for correct invocation 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?

The input schema covers all parameters with descriptions (100% coverage), so the description doesn't need to elaborate on parameter semantics. The description's reference to rate-limit output is not parameter-specific. Baseline 3 is appropriate since schema handles parameter documentation adequately.

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 ('Remove an account from your followers') and distinguishes it from blocking, explicitly naming the sibling ig_block as the alternative. This makes the tool's purpose unmistakable and differentiates it from related tools.

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 gives explicit guidance: 'Use this, not ig_block, when asked to remove a follower.' It also notes that the action doesn't notify the removed account and allows re-following, clarifying when this tool is appropriate. The rate-limit behavior ('Rate-limited calls return `done: false`') further informs usage expectations.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact — the INSSIST PRO gating — but says nothing about pagination behavior or the effect of the 'instant' burst flag, which matters for a read-only listing 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 short sentences, zero waste, purpose front-loaded before the prerequisite. Appropriately sized for a simple list tool.

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 zero-required-parameter, read-only listing tool with full schema coverage and no output schema, the description covers purpose and the PRO prerequisite. It omits only minor context such as pagination expectations, which the cursor param already implies.

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 cursor, instant, and instance all documented in the schema itself, so the baseline is 3. The description adds no parameter meaning beyond the schema, but none is needed.

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 pending follow requests') and scopes it to 'your account', which distinguishes it from generic list tools. It does not name or differentiate against close siblings like dm_requests or notifications_list.

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 only guidance is the prerequisite 'Requires INSSIST PRO.' There is no statement of when to use this versus dm_requests or notifications_list, and no exclusions or conditions beyond the paywall note.

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 mark this as a non-readonly, non-destructive, closed-world mutation. The description adds genuinely useful traits beyond that: partial-update semantics ('only fields you pass change'), the side effect that editing interrupts an in-progress run, and a PRO entitlement requirement. This is solid behavioral context.

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 short, front-loaded sentences with no wasted words. The key constraint (partial update) and the warning (interrupts a run) are stated compactly and early.

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 9-param, no-required-fields mutation tool with no output schema, the description covers the important behavioral facts (partial semantics, interrupt side effect, PRO gating) and annotations cover the safety profile. It is nearly complete, only missing explicit routing against sibling growth tools.

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 nine parameters are already documented in the schema. The description only summarizes the field groups and adds no syntax or format detail 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?

States a specific verb ('Set') and resource ('lead-engagement config') and enumerates the fields it controls. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like growth_start, growth_pause, or growth_status.

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 the usage context (configuring the growth run) and adds operational caveats like partial updates and interrupting a run, but it never states when to prefer this over growth_start/growth_pause or any prerequisite sequence. Guidance is implied rather than explicit.

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 mark this as a non-read-only, non-destructive, closed-world operation, so the safety profile is already covered. The description adds genuinely new context: it names the output artifact (a CSV file on disk) and its return value (the path), plus the PRO entitlement requirement, which an agent needs before invoking. It stops short of saying where the file is written or whether it overwrites, hence not 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 compact sentences, front-loaded with the action and output, with the prerequisite parenthetical at the end. 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?

For a simple one-parameter export with no output schema, the description covers action, artifact, return value, and entitlement gate. Only minor operational details (file location, overwrite behavior, size limits) are 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?

With a single optional parameter at 100% schema description coverage, the schema already explains 'instance' fully. The description adds nothing about the parameter, 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 and resource ('export lead-engagement results (leads and likes made) to a CSV file') and adds the return value. The 'lead-engagement' scope measurably distinguishes it from sibling exports like unfollowers_export and peers_export.

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 '(Requires INSSIST PRO.)' parenthetical gives a real prerequisite, and the growth_* siblings imply the context, but there is no explicit when-to-use or when-to-prefer-an-alternative 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?

Adds value beyond annotations: it specifies the concrete effect (no more likes) and an account-level requirement (INSSIST PRO). Annotations only declare readOnlyHint=false and destructiveHint=false, which the description doesn't contradict. It does not describe reversibility details beyond the growth_start reference.

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 primary effect is front-loaded and the requirement is parenthetically scoped. 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-optional-param toggle with no output schema, the description covers effect, dependency (growth_start), and licensing requirement. It is nearly complete, though it doesn't explain what happens to any in-flight engagement actions.

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 'instance' parameter is already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, 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 ('Turn off') and resource ('lead engagement') with the effect spelled out ('No further likes are made'). Clearly distinguished from the sibling growth_start, which it names directly.

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?

Names growth_start as the alternative and states the boundary condition ('until growth_start'), making the when-to-use relationship explicit without the agent needing to infer it.

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?

With annotations declaring readOnlyHint=false and destructiveHint=false, the description adds significant value by disclosing that it runs in the background and requires polling, plus the pacing mechanism (like budget, rate-limit backoff) and the INSSIST PRO requirement. This goes beyond what annotations 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?

Three compact sentences, front-loaded with the activation action and key operational details. Every sentence adds necessary information without waste.

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 activation, async behavior, polling, pacing constraints, and licensing. For a single-parameter tool with full schema coverage and no output schema, this is nearly complete, though it could mention expected duration or error handling.

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 the single parameter is fully documented in the schema. The description adds no parameter details, but with full coverage and only one optional parameter, baseline 4 is appropriate as the schema handles semantics.

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 ('turn on lead engagement') and details the concrete actions taken (scan configured sources, like leads' posts). Distinguishable from siblings like growth_configure and growth_pause by describing the activation action.

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?

Clear context that this starts the engagement process, with guidance to poll growth_status for results. Does not explicitly state when not to use it or name alternatives like growth_configure, but the async nature and polling instruction provide clear usage.

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, destructiveHint=false, and openWorldHint=false, so the safety profile needs no restating. The description adds real value beyond that by disclosing an entitlement requirement (INSSIST PRO) and the shape of the returned state, which is exactly the auth-need context the rubric rewards.

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 leads with the resource, then lists the returned state, with the PRO constraint tucked into a parenthetical. 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 enumeration of returned fields (on/off, config, leads/sources, likes, remaining budget) becomes the primary signal of return shape and is genuinely useful. A status-type read tool with full parameter coverage and clear annotations is adequately served, though error/timeout behavior is unaddressed.

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 (instance), and the schema documents it at 100% coverage including the 'defaults to the active one' fallback. The description adds nothing about the instance parameter, so baseline 3 applies — the schema is doing all the work.

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 names a specific resource and scope — 'lead-engagement state for the logged-in account' — and enumerates the concrete facets returned (on/off, config, leads/sources, likes, remaining budget). It is distinguishable from the action siblings (growth_start, growth_pause, growth_configure, growth_export), though it reads as a noun phrase rather than an explicit verb, so the read intent is inferred rather than stated.

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, no mention of alternatives such as growth_export or growth_configure, and no stated preconditions beyond the passing '(Requires INSSIST PRO.)' parenthetical. The relationship to the other growth_* tools is left entirely 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 indicate destructiveHint=true and readOnlyHint=false, so the description correctly aligns by listing mutating actions. It adds value by disclosing the rate-limiting behavior ('Rate-limited calls return `done: false`') and the single-target constraint, which are not in the annotations.

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 sentences with no fluff, front-loading the core actions and adding the rate-limit note and PRO requirement. Every sentence earns its place.

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 tool is simple, schema covers all parameters, and annotations cover destructive intent. The description adds the rate-limit return behavior and PRO prerequisite, which are essential for correct invocation. No output schema exists, but the tool's success/failure is largely self-explanatory.

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 parameters are fully documented. The description does not add semantic meaning beyond the schema; it only mentions the general target constraint. Baseline 3 is appropriate when the schema handles parameter details.

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 the exact actions ('Like, unlike, follow or unfollow') with a clear verb+resource mapping. It differentiates from siblings like comment_like, follower_remove, and ig_block by specifying the four possible actions. The constraint 'One target per call' further clarifies scope.

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 provides contextual prerequisites ('Requires INSSIST PRO') and a behavioral note about rate-limited calls, but it does not explicitly state when to prefer this tool over alternatives or list exclusions. An agent can infer usage from the action names, but explicit guidance is missing.

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?

Beyond the annotations, the description adds valuable behavioral context: blocking 'cuts all contact and hides your profile,' unblocking is available via a flag, rate-limited calls return `done: false`, and INSSIST PRO is required. This goes well beyond the destructiveHint and readOnlyHint annotations.

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 compact: three sentences, no filler, and the core action is stated first. Each sentence adds information: the operation, the behavioral effect, and the rate-limit/PRO caveats.

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 mutation tool with full schema coverage and meaningful annotations, the description covers the main behavioral effects, the unblock path, rate limiting, and a required-provision caveat. It does not describe the normal success response shape, but the rate-limit note gives a useful hint and the tool is simple enough that nothing critical 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 description coverage is 100%, so the schema already fully documents all four parameters. The description adds no new parameter-level meaning beyond mentioning `unblock: true`, which is already present in the schema. 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?

The description names a specific verb and resource: 'Block an account, or unblock with `unblock: true`.' It also explains the consequence of blocking, which makes the tool's purpose concrete and distinct from sibling tools like follower_remove or ig_action.

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 clearly states what the tool does and supports both block and unblock usage, but it does not explicitly tell an agent when to prefer this tool over alternatives or when not to use it. The operation is obvious from the name, but the guidance is mostly implied rather than explicit.

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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by listing returned data types (caption, owner, media urls), but does not disclose error behavior, rate limits, or how it handles private posts/invalid URLs. It meets the baseline for an annotated read-only tool but offers limited extra context.

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 information-dense sentences, front-loading what it does and what it returns. Every clause contributes to understanding: accepted URL forms, returned fields, and sibling differentiation. 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 read-only fetch tool with full schema coverage and clear annotations, the description is nearly complete: it names the resource, inputs, output fields, and sibling contrast. The absence of an output schema means return values are described in the text, which it does. Minor gaps remain around error/rate-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 100%, so all parameters are already documented in the schema, including the url/shortcode alternative and the instant pacing option. The description only echoes that url or shortcode works, adding no new parameter semantics. Baseline 3 is appropriate when schema does the heavy lifting.

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?

Specific verb and resource: 'Fetch one post by url or shortcode', followed by an enumeration of exactly what fields are returned. It explicitly distinguishes itself from the sibling ig_fetch_posts by saying 'Like ig_fetch_posts plus owner and full-size media.'

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 contrasts this tool with the sibling ig_fetch_posts ('Like ig_fetch_posts plus owner and full-size media'), giving a clear cue for when to choose it. It clearly states acceptance of /p/, /reel/, /tv/ URLs. It lacks explicit 'when not to use' guidance beyond the implicit difference from the plural fetcher, but the contrast is clear.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: newest-first ordering, internal pagination, and a nextCursor returned when more pages remain. This is real operational context, not restated annotation.

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 short sentences, front-loaded with the verb+resource and the field list, followed by ordering and pagination facts. Every sentence carries information; there is no padding.

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 compensates by enumerating the returned fields and explaining pagination via nextCursor. Combined with 100% schema param coverage and read-only annotations, an agent has enough to call it correctly. Minor gap: no note on auth/instance/instant behavior at the description level.

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 limit, cursor, instant, instance, and username are all already documented in the schema. The description mentions nextCursor, which loosely ties to the cursor parameter, but adds no format, range, or semantics beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (fetch most recent posts of an account) and enumerates the returned fields (caption, media type, likes, comments, timestamp, shortcode, permalink). This clearly separates it from ig_fetch_profile, ig_fetch_stories, and ig_fetch_saved by resource. It never names the near-identical singular sibling ig_fetch_post, so full differentiation is not achieved.

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 explains what comes back but gives no when-to-use, no when-not-to-use, and no reference to any alternative tool. An agent choosing between ig_fetch_posts, ig_fetch_post, and ig_fetch_profile gets no routing help from the text.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value by spelling out the returned payload (bio, links, counts, flags, viewer relationship), which matters because there is no output schema.

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 the action first and the payload second; no filler, no repetition of the title or schema.

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 fetch whose annotations already carry the safety profile, the description covers what it retrieves; the absence of an output schema is partly compensated by the field enumeration. It omits any mention of targeting scope (own account vs another user) and how it relates to account_info, which is the main residual 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 100%, so all three parameters (username, instant, instance) are already documented in the schema, including the pacing caveat on 'instant'. The description adds no parameter-level detail beyond what the schema provides, 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+resource ("Fetch profile of an account") and enumerates the returned fields (bio, links, follower/following/post counts, flags, viewer relationship), so an agent knows exactly what it gets. It stops short of naming how it differs from nearby siblings such as account_info or ig_fetch_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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer from the name alone whether to call this instead of account_info, profile_update, or ig_search.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the ordering trait ('newest first') which is genuine behavioral info not in the annotations. However it does not mention pagination behavior despite having a cursor param, nor rate-limit/pacing behavior (relevant given the instant param).

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 sentence, front-loaded with the verb, resource, and ordering. Every word earns its place with zero 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?

For a read-only list tool with full schema coverage and a clear annotation profile, the description is minimally adequate. But the agent isn't told when to prefer this over siblings like ig_fetch_posts, nor told pagination ends at a nextCursor, nor warned that instant bypasses pacing (which the schema mentions but the description should surface).

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 schema documents cursor, instant, and instance thoroughly, establishing a baseline of 3. The description doesn't explicitly restate parameters, but 'newest first' conversationally implies the ordering is fixed regardless of cursor, reinforcing the schema. Slightly above baseline but no added syntax 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 ('List') and resource ('your saved posts') with ordering info ('newest first'). This distinguishes it from ig_fetch_post/ig_fetch_posts (fetch individual posts) and ig_fetch_profile, though the description doesn't explicitly name siblings to sharpen the difference.

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, when-not-to-use, or alternative guidance. The agent must infer this is the right tool for saved posts versus other ig_fetch_* siblings purely from the name and one-line purpose. No mention of prerequisites such as needing an authenticated instance.

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 establish readOnly/openWorld/non-destructive, but the description adds meaningful context beyond them: results are session-scoped ('as the session sees them') and the tool returns empty rather than erroring when stories are absent or not viewable. It does not cover rate limits or auth, hence not 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 compact sentences, front-loaded with the action and resource, followed by the result behavior. 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?

For a read-only, open-world fetch with no output schema (so return values need not be detailed), the description covers action, scope, and empty-result behavior adequately. It stops short of describing what a successful story payload contains, though no output schema constrains that expectation.

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 the schema already documents username, instant, and instance. The description adds no parameter-level meaning beyond what the schema provides, 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?

Specific verb+resource: 'Fetch an account's currently live stories', with scope qualifier 'as the session sees them'. This distinguishes it from sibling fetch tools (ig_fetch_post, ig_fetch_profile) by resource. However, it never names or contrasts 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?

Usage is only implied by the resource name; there is no explicit when-to-use or when-not-to-use, and no alternatives such as ig_fetch_post or story_viewers are mentioned. 'Empty when none or not viewable' hints at outcome, not invocation 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 destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: permanent/irreversible deletion, the own-posts-only restriction, and an INSSIST PRO entitlement requirement. It stops short of noting pacing/rate-limit behavior for the non-instant path.

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 short sentences, each load-bearing: action, scope restriction, irreversibility, and the routing to the alternative, with the PRO caveat parenthesized at the end. Nothing is padded.

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 3-parameter destructive tool with annotations covering the safety hints and no output schema, the description supplies the constraints an agent needs before calling. Minor gap: no mention of failure modes or what happens to a scheduled post if attempted here, though the draft_delete pointer mitigates that.

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 the schema already explains post, instant, and instance. The description adds no parameter-level detail beyond that (e.g., accepted id formats or when instant is appropriate), 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 and resource ('Permanently delete a published Instagram post') plus the scope qualifier 'published'/'own posts only'. This is enough for an agent to separate it from ig_post_edit, ig_fetch_post, and draft_delete without opening any 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 names the boundary condition ('Own posts only') and a concrete alternative with its selecting condition: drafts and scheduled posts go to draft_delete. It also flags the irreversibility constraint, so the agent knows when not to call it without confirmation.

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 openWorldHint=true, so the overwrite risk is covered structurally; the description's added value is the PRO gating requirement and the ownership restriction. It does not say what happens to the previous caption on failure, whether the change is reversible, or mention pacing/rate limits, so it adds some but not rich behavioral context.

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 short sentences, zero filler, with the core action front-loaded and the constraints (own posts, PRO) following immediately. Every clause earns its place.

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 4-parameter mutation tool with a fully documented schema and destructive annotations, the description covers action, scope, and prerequisite. It leaves unstated whether the edit must come from the owning account and what a successful or failed edit returns, minor gaps 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 description coverage is 100% and every parameter (post, caption, instant, instance) carries its own description, including the empty-string-clears behavior and the pacing semantics of instant. The description adds no parameter syntax or format detail beyond that, 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 (Edit) and a tightly scoped resource (a published Instagram post's caption), which implicitly separates it from siblings like ig_post_delete, draft_update, and comment_add. It does not explicitly name an alternative, so it lands just 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?

"Own posts only" gives a clear when-not condition and "Requires INSSIST PRO" states a prerequisite, so an agent knows the eligible target and the account tier needed. It never names an alternative tool (e.g., draft_update for unpublished posts, ig_post_delete for removal), so it is clear context without full routing 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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the pivot-tool context but nothing about rate limits, pacing, or result shape. A middle score is appropriate given annotations carry most of the burden.

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 short sentences, front-loaded with the core action and each subsequent sentence earning its place by adding either downstream usage or a sibling redirect.

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 search pivot tool with full schema coverage and no output schema, the description supplies everything an agent needs: what it finds, what it feeds into, and the one adjacent tool to use instead.

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 each parameter is already well documented (including the @/# stripping, the two-request cost of omitting type, and the instant pacing hint). The description adds no param detail 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?

Specific verb (search) and resources (Instagram accounts and hashtags) with an analogy to the app's search box. It explicitly routes taggable places away to location_search, distinguishing it from that sibling cleanly.

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?

States when to use it ('Turn a half-remembered name into a username for the other ig_* tools') and when not to ('For taggable places, use location_search'), naming the alternative explicitly.

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 (readOnlyHint, destructiveHint), but the description adds genuinely new behavioral facts: the scan runs in the background (asynchronous), surfaces in the Insights dashboard, and requires INSSIST PRO. The async and licensing disclosures are the most useful additions.

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 that front-load the core action and follow with the async/result-handling detail and the PRO caveat. No filler 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?

With no output schema, the description sensibly explains where results appear and how to retrieve them (insights_report polling), and it flags the async nature and licensing requirement. An agent has enough to call it correctly, though typical scan duration or progress semantics are not described.

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 the schema already documents every parameter including 'instant', 'followers', and 'postsLimit'. The description adds no parameter-level meaning beyond that, making the baseline 3 correct.

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 ('Start (or refresh) an analytics scan of an account') and clarifies the refresh semantics. It also names the sibling insights_report as the polling/result endpoint, letting an agent distinguish this initiation tool from the reporting tool 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?

Clearly directs the agent to 'poll insights_report for progress and results', establishing the initiate-then-poll workflow. It also discloses the PRO prerequisite. It stops short of explicit when-not guidance (e.g., not to re-run while a scan is in flight), so it isn't a full 5.

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 safe-read profile (readOnly, non-destructive, non-openWorld). The description adds useful behavior beyond that: it emits progress during scanning, conditionally includes audience-quality metrics only if followers were scanned, and carries a PRO entitlement gate.

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-loads the action and keeps everything in two dense sentences with no filler. The metric list is long but each item is informative rather than 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, the description compensates well by enumerating the returned metrics and their conditional inclusion. Only minor gaps remain, such as behavior when no scan exists yet.

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 both params are already documented. The description adds only marginal meaning — implying username must be the account passed to insights_collect — so the baseline of 3 applies when the schema does the heavy lifting.

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 ("Read an insights_collect scan") and enumerates the concrete outputs (engagement, best times, heatmap, top posts, trends, follower growth). It clearly distinguishes this reporting tool from the sibling insights_collect that performs the scan.

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?

Implicitly routes the agent to use this after running insights_collect, and states a precondition ("Requires INSSIST PRO"). However it never explicitly says when-not to use it or names the alternative scan trigger beyond the implicit pairing.

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 and openWorldHint=true, so the safety profile is covered. The description adds a non-obvious behavioral filter — only places with coordinates are returned — which an agent could not infer from the schema. It does not mention rate limits or result caps.

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 short sentences, front-loaded with purpose before the handoff instruction and the result filter. 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?

No output schema exists, so the description usefully characterizes the return set (name + id, taggable-only). It omits anything about result quantity or ordering, but for a discovery lookup with fully documented params it is largely 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 100%, so query, instant, and instance are all documented in the schema, including the semantic distinction of 'instant'. The description adds nothing about parameter behavior, 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+resource (search Instagram places) plus the purpose (to get ids for tagging a post), which distinguishes it from siblings like ig_search and music_search. An agent knows exactly what it retrieves and why.

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 downstream routing: 'Pass a returned name to draft_create's `location`', which tells the agent where the output goes. It also scopes results to taggable places, but does not name an alternative tool for non-taggable place lookups.

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, openWorldHint, and destructiveHint, so the safety profile is covered without description help. The description adds genuine value beyond that by disclosing the downstream consumption path (track ids feed draft_create's musicTrackId), which is not evident from annotations or schema. It still says nothing about rate limits or result ordering.

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, front-loaded with the action and scope before the return value. Nothing is padded or 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?

For a read-only search with no output schema, the description covers purpose, domain, and output, and the schema fully covers parameters. The only minor gap is that it does not characterize result shape beyond 'track ids' (e.g., whether artist metadata accompanies them), but an agent has enough to call 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 limit ranges, query semantics, instant's pacing behavior, and instance defaulting in detail. The description adds no parameter meaning beyond that, 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 and resource ('Search Instagram's music library by title or artist') and immediately differentiates from generic siblings like ig_search or location_search by naming the domain. It also states what the tool produces (track ids), so the agent knows what it gets back.

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 gives clear context for use by tying the output directly to draft_create's musicTrackId parameter, which routes the agent correctly. It does not, however, state when NOT to use it or name an alternative search tool, so it stops just short of a full when/when-not treatment.

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 cover the safety profile (not read-only, open-world, non-destructive), and the description adds genuinely non-obvious traits: the 24h auto-expiry, that empty text clears the note, and that a paid INSSIST PRO plan is required. It stops short of describing return values or rate/pacing behavior, but the added context is substantive.

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?

Five short clauses, each carrying a distinct fact (cap, placement, lifetime, ranking effect, clear behavior, plan requirement), with the core action front-loaded and 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 no-output-schema mutation tool with full annotation coverage, the description supplies the ephemeral nature, the clear semantics, and the plan gate an agent needs to avoid a failed call. Only minor gaps remain (pacing/pagination of effects, error behavior) and those are low-stakes here.

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 the schema already documents text, instant, and instance, including the 60-char limit and the empty-clears behavior. The description restates the limit and clearing rule rather than adding syntax or edge-case detail beyond the schema, 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 and resource ('Set the logged-in account's Note') and immediately scopes it with the 60-char cap, placement (atop the DM inbox avatar), 24h lifetime, and visibility effect (top of the DM list). This is clearly distinguishable from siblings like profile_update or dm_send.

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 the clear/empty behavior and a prerequisite (INSSIST PRO), but never says when an agent should choose this over adjacent tools such as profile_update or dm_send, nor when not to use it. Usage is implied by the resource name 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful piece of context beyond that: the INSSIST PRO requirement, which the schema does not mention. It says nothing about pacing, volume, or refresh behavior, so the added value is limited.

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 fragments with zero filler; the resource and its contents are front-loaded ahead of the license note. It is efficient, though slightly telegraphic — there is no sentence that actually says what the tool does with the notifications (list/retrieve).

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 carries the burden of describing what comes back, and it only gestures at that by listing notification categories. It omits the shape of a notification record and any pagination semantics beyond what the limit parameter already states. The PRO prerequisite is a helpful addition, leaving the definition adequate 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 100%, so all four parameters (type, limit, instant, instance) are already fully documented with defaults, ranges, and ordering. The description's list of notification categories loosely echoes the type filter but adds no syntax or format information beyond the schema. Baseline 3 is correct.

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 names the resource (recent notifications) and enumerates the content types (comments, likes, follows, mentions), so an agent immediately knows what it returns. The verb is only implied by the tool name rather than stated, and there is no sibling it could be confused with (comments_list, dm_list cover different resources), so no differentiation is required. Clear, but not a full verb+resource statement.

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 gives no when-to-use or when-not-to-use guidance and names no alternative. The only directive is the PRO prerequisite, which is an eligibility note rather than usage guidance. An agent must infer from the name alone that this is the read path for notification data.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds useful context beyond them: the return value (file path) and an access requirement (INSSIST PRO). It does not mention file size limits, overwrite behavior, or rate limiting, so it stops short of full disclosure.

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 clauses, zero waste: the core action and return value are front-loaded, with the prerequisite and plan requirement as compact trailing notes. Every sentence carries distinct 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 compensates by stating the return value (file path), and it covers the plan prerequisite and the peers_scan sequencing. Given a simple 3-parameter, non-destructive tool, this is nearly complete; only the missing sibling differentiation keeps it from a 5.

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 (type, instance, username) are already documented in the schema, including the followers/following default and the omit-for-logged-in-account convention. The description adds no syntax, format, or constraint detail beyond that, 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?

States a specific verb+resource (export followers/following list) and the output artifact (CSV file, returns path). It names peers_scan as the prerequisite for other accounts. It does not, however, differentiate itself from close siblings like peers_report, unfollowers_export, or growth_export, which an agent could otherwise confuse it with.

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?

Provides one concrete sequencing hint ('Run peers_scan first for other accounts') and a plan gate ('Requires INSSIST PRO'), which is real usage context. But it never states when to choose this over peers_report or the unfollowers/growth export siblings, leaving the alternative-selection 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 the safe read-only, non-destructive profile, so the bar is lower. The description still adds real context beyond them: own-account calls hit stored data and return richer fields, `mutual` is null when unchecked, and INSSIST PRO is required. It doesn't cover pagination exhaustion or staleness limits, but the added disclosures are substantive.

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-loads the core purpose, then packs prerequisites and alternatives into short clauses. The nested parenthetical about the richer fields is dense, but nearly every clause carries routing or behavioral value.

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 tool takes optional params, returns a page, and has no output schema; the description covers the read semantics, per-account data source differences, prerequisite sibling, whole-list alternative, and plan gating. An agent has everything needed to call 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%, so the baseline is 3. The description references `from`/`limit` but adds no format, range, or behavioral detail beyond what the schema already documents for those and the other three parameters.

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 ('Read a page of a collected followers/following list') and scopes it with pagination params. It explicitly differentiates itself from sibling tools peers_scan (prerequisite for other accounts) and peers_export (whole list).

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?

Names both relevant alternatives and the exact conditions that select them: 'other accounts need peers_scan first' and 'Whole list: peers_export'. It also flags the PRO requirement, so the agent knows when the tool is even callable.

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 mark this as a non-read-only, open-world, non-destructive operation. The description adds the important PRO-subscription requirement not present in annotations, but says nothing about the async nature implied by 'start', whether the collection can be cancelled, or pacing behavior (aside from schema's `instant` flag).

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 the core action and the entitlement caveat placed as a parenthetical. Nothing is wasted.

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 agent relies on the description to understand the workflow, yet it never explains that this initiates a background collection whose results surface via peers_report/peers_export. It is adequate for identifying the tool but incomplete for the scan->report/export pipeline it belongs to.

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 all four parameters are already documented with their own descriptions, including the default account behavior and the burst-action caveat for `instant`. The description adds no parameter-level detail beyond the schema, 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 gives a specific verb (start collecting) and resource (an account's followers or following), and mirrors the `type` parameter's two modes. It does not distinguish itself from siblings like peers_export or peers_report, which handle the results of this scan.

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 word 'Start' implies this is the first step of a larger collection workflow and the parenthetical establishes a PRO entitlement prerequisite. However, it never states when to choose this over peers_export/peers_report or what to do after starting.

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 flag this as a destructive, open-world write. The description adds meaningful context beyond them: that the mutation is scoped to the bio only and leaves other fields untouched, and that it requires INSSIST PRO. It does not, however, describe reversibility or what the response looks like.

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 short clauses, front-loaded with the core action, then scope limits and the plan requirement. No padding.

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 but full annotation and parameter coverage, the description supplies the account scope, field-scope limits, and PRO prerequisite an agent needs. Return/confirmation behavior is the only minor 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%, so the schema already documents bio, instant, and instance fully, including the empty-string clearing behavior. The description adds only the bio-link exclusion, 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 (Edit) and resource (the logged-in account's bio, with an inline clarification 'the text under the name on the profile'). It is clearly distinguishable from siblings like note_set or ig_post_edit.

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 scope constraints: own account only, bio links unsupported (app-only), other profile fields untouched. It does not name an alternative sibling for the unsupported cases, so it falls just short of a 5.

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