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

The description goes well beyond the annotations by disclosing that each item is staged separately, transcoded in parallel, then bound by a parent container; that it counts as a single post against the daily quota; and that the result is public and irreversible, requiring confirm: true. This aligns with destructiveHint=true and adds meaningful 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 sentences, front-loaded with the primary purpose, then concise behavioral context. Every sentence adds relevant information: item range, internal staging/transcoding process, quota impact, and irreversibility/confirmation 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?

For a destructive publish action with no output schema, the description covers the essential invocation concerns: media type and count, processing behavior, quota accounting, irreversibility, and the mandatory confirm flag. Combined with rich per-parameter schema descriptions and annotations, this is sufficient for an agent to select and 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 description coverage is 100%, so the schema already documents all six parameters thoroughly. The description reinforces the 2-to-20 item constraint and explains why confirm must be true, but it does not add materially new parameter-level meaning beyond what the schema provides.

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 ('Publish'), a specific resource ('2 to 20 images or videos as one carousel post'), and clear constraints. It distinguishes this from single-post or thread-publishing siblings by emphasizing the carousel format and item range.

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 implies this is the tool for publishing a multi-item carousel of 2 to 20 media items. It does not explicitly name alternatives like create_post or publish_staged, but the scope is clear enough that an agent should not confuse it with single-post tools.

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, but the description adds critical behavioral context: the post becomes public immediately, Threads has no edit endpoint, and confirm: true is mandatory. It also discloses the wait-then-publish flow, going well 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 sentences, front-loaded with the core action, then critical consequences, then a routing rule. No wasteful prose; 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?

For a 13-parameter publish tool, the description covers the central behavior, irreversibility, confirmation requirement, and the main sibling alternative. The only gap is the lack of any mention of the expected return value or failure behavior, especially 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 each parameter already has a rich description, so the baseline is 3. The main description adds little per-parameter meaning beyond the schema; it reinforces the 500-char limit and confirm requirement but does not introduce new parameter 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?

The description states a specific verb and resource: 'Publish one post to Threads', and explains the internal flow (creates media container, waits, then publishes). It also distinguishes itself from the sibling create_thread by the 500-character rule, so an agent can disambiguate without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit when-to-use ('publish one post') and an explicit when-not-to-use with a named alternative: 'For anything over 500 characters use create_thread instead.' It also communicates the required confirmation flag and irreversibility, which are essential usage conditions.

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=true, but the description adds substantial behavioral detail: the operation can half-publish, all parts are length-checked before the first post goes out, failures name how far publishing got, and the result is public and irreversible. This meaningfully exceeds annotation-only information.

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 dense sentences, each earning its place. It front-loads the purpose, then covers the critical partial-failure behavior, then the confirmation requirement. 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?

Despite having 10 parameters and no output schema, the description is sufficient for correct invocation. The schema covers all parameter meanings, while the description supplies the critical operational context: partial publishing, validation ordering, failure reporting, and the mandatory confirm flag. Nothing essential for safe 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% and the schema already documents every parameter and the confirm requirement. The description mentions 'needs confirm: true' but that only restates the schema. It adds no new parameter-level semantics beyond what the structured schema provides.

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 ('publish'), a precise resource ('several posts as a thread'), and the mechanism ('each replying to the one before'). It further clarifies that a thread is just a chain of ordinary posts, distinguishing this from a dedicated thread resource.

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 signals when to use this tool: when publishing multiple posts as a reply chain. It gives useful context about Threads having no thread endpoint, but it does not explicitly name alternatives or state when not to use 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?

Annotations already mark destructiveHint=true, but the description adds critical behavioral context: permanent deletion, cascade to replies and likes, no archive/undo, a rolling 24-hour cap, and the explicit confirm requirement. This goes well beyond the annotations and fully discloses the consequences.

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, front-loaded sentences: the main action first, then consequences, rate cap, and the confirmation requirement. Every sentence adds essential information 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?

Given the destructive nature and absence of an output schema, the description covers all critical invocation concerns: ownership, permanence, cascading effects, rate limit, and confirmation. The agent has enough to call the tool safely and 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%, so the schema already fully documents id, account, and confirm. The description adds no per-parameter details beyond what the schema provides; its extra context is mostly behavioral rather than semantic.

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 ('delete'), a specific resource ('one of your own Threads posts'), and explicitly notes there is no edit endpoint, clarifying its unique role among siblings. It clearly distinguishes itself from read-only and create 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?

The description gives actionable context: the post must be your own, the deletion is permanent, and confirm must be true. It explicitly rules out undo/archive/edit alternatives, though it does not mention hide_reply as a possible non-destructive alternative for replies.

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 readOnly, idempotent, non-destructive, and open-world hints, so the safety profile is handled. The description adds a meaningful behavioral caveat: data starts 13 April 2024, is unreliable before 1 June 2024, and earlier windows return nothing. This is genuinely useful 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?

Two short sentences carry all essential information with no filler. The metric list and profile scope are front-loaded, and the important data-availability caveat is placed second without bloating the description.

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, idempotent insights tool with a rich schema, the description covers what is returned and the critical temporal limitation. It does not describe the exact return shape, but no output schema exists and the listed metrics give sufficient expectation for an agent.

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 four parameters thoroughly. The description mostly restates the metrics list and date caveat rather than adding new parameter-level meaning, though it slightly supplements the 'since' parameter with the reliability window.

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 resource (the whole profile) and enumerates the exact metrics returned: views, likes, replies, reposts, quotes, link clicks, and follower count. The phrase 'Profile-level' clearly distinguishes it from the sibling get_post_insights, which targets individual posts.

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 makes it clear this is for profile-level metrics rather than post-level insights, and it gives an explicit time-window constraint. It does not explicitly name alternatives or state when not to use it, but the profile-level framing is strong enough context for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: newest-first ordering, aggregation across all posts, and the inbox-view framing. It does not mention pagination or filtering behavior, but that is documented in the 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?

Two focused sentences with no filler. The core scope ('every reply you have received, newest first, across every post') is front-loaded, and the use-case guidance ('inbox view', 'find what needs answering') adds value in the second sentence 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 read-only list tool with fully documented parameters, the description is nearly complete. It conveys scope, ordering, and when to use it. The only minor gap is that it does not describe the response shape or mention the cursor attribute, though the schema's cursor parameter description already implies its presence.

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 four parameters are already documented in the input schema. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('read'), resource ('every reply across every post'), and ordering ('newest first'), and explicitly contrasts with the per-post walk by saying 'without walking each post one at a time.' This clearly distinguishes get_all_replies from sibling get_replies.

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 a clear use case: 'use it to find what needs answering.' It implies the alternative of checking posts individually and frames this as the aggregate inbox view, though it does not explicitly name an alternative tool or state when not to use 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?

Beyond the readOnlyHint annotation, the description discloses the possible statuses (IN_PROGRESS, FINISHED, ERROR, EXPIRED) and the failure-reason detail. This adds useful behavioral context about what the tool returns without contradicting 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?

Two sentences, front-loaded with the status enumeration and followed by practical use cases. Every sentence earns its place with no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only status check with no output schema, the description sufficiently covers output semantics and likely user intents. It could mention that the container_id comes from staging, but the overall context is clear enough for an agent to select and call the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: account is documented, but container_id has no schema description. The tool description does not compensate by explaining that container_id identifies the staged container, nor does it mention the account parameter at all. Description adds little to parameter understanding.

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 status check for a staged container and enumerates the exact status values returned. It is distinct enough from siblings like get_post or get_posts because 'container' is a staging resource, though the description does not explicitly contrast itself with those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives two concrete use cases: checking a slow video and verifying whether a staged post is still within its 24-hour window. These are clear contextual triggers, but there is no explicit when-not-to-use guidance or named alternative 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?

Beyond the annotations (read-only, idempotent, non-destructive), the description reveals the flattening behavior, the parent-naming format, the recursive scope, and the ownership restriction. This is useful behavioral context, though it does not cover response pagination or error conditions.

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, each with distinct value: the core behavior, the ownership constraint, and the practical use case. 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?

With no output schema, the description gives a sufficient mental model of the return value (flattened list with parent naming) and the intended decision context. Minor gaps remain around 'reverse', pagination, and how this differs from get_replies/get_all_replies, but these are partially covered by the 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 80%, so the schema already documents id, limit, cursor, and account. The description adds only that the post must be owned, which the id schema already states. It does not compensate for the undocumented 'reverse' parameter.

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 (a whole conversation under one of your posts) and a concrete behavior (every reply including replies-to-replies, flattened, with each reply naming its parent). It is clear but does not explicitly contrast with sibling tools such as get_replies or get_all_replies, so it stops short of full differentiation.

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 provides clear usage context: 'Only works on posts you own' and 'This is what to read before deciding what deserves an answer.' It does not, however, state when to prefer this over get_replies/get_all_replies or give exclusions.

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 the tool as read-only and non-destructive. The description adds meaningful behavioral constraints beyond those annotations: Threads rejects multiple breakdowns per call, at least 100 followers are required, and any provided date range is ignored. This is exactly the kind of contextual behavior an agent 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 short sentences deliver all key facts with no filler. The core purpose is front-loaded, and each additional sentence adds a distinct operational 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 read-only, single-dimension demographic breakdown tool, the description covers what the tool does, the key constraint, the minimum follower threshold, and the date-range caveat. The schema covers parameter details, and no output schema is expected for invocation. 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 coverage is 100%, so the schema already documents both parameters. The description's mention of dimensions and the one-per-call rule largely duplicates the schema's enum and description, adding little semantic value beyond what is already structured.

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 what the tool does: provides a follower breakdown by country, city, age, or gender. It is easily distinguished from siblings like get_account_insights and get_post_insights because it is specifically about follower demographics.

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 concrete usage context: one dimension per call, a 100-follower minimum, and that date ranges are ignored. It does not explicitly name alternative tools or state when not to use it, but the constraints are clear and actionable.

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 read-only and idempotent, and the description adds value beyond that by explaining that pending replies are invisible to everyone until approved and that the result set is empty unless reply approvals were enabled. This is useful behavioral context not present 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 three short sentences with no filler. It front-loads the core meaning with the first sentence and uses the remaining two to clarify important behavioral details.

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 operation, the description plus well-documented parameters and safe annotations are mostly sufficient. There is no output schema, but the description clarifies what is being returned, so an agent can understand the tool's purpose without needing further detail.

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 describes all three parameters with complete coverage, so the schema carries the parameter-documentation burden. The description adds no additional parameter-specific meaning, which is acceptable but does not exceed the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource: replies waiting for approval on posts with enable_reply_approvals. It also distinguishes itself from sibling tools like get_replies and get_all_replies by noting that pending replies are invisible until approved.

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 when the tool is relevant: posts published with reply approvals enabled, and notes the queue is empty unless that setting was used. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough for an agent to infer appropriate 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 convey read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds value by enumerating the returned fields (text, media, permalink, topic tag, link attachment, quoted post, has_replies), which explains the tool's behavioral output beyond what annotations and schema 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 one sentence, front-loads the core behavior ('One Threads post by its numeric id'), and packs the return-field list efficiently without repetition. Every phrase contributes context.

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-record retrieval tool with rich read-only and idempotent annotations, the description plus schema covers what an agent needs: the id source, the account context, and the expected response fields. The absence of an output schema is mitigated by the explicit field enumeration.

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 describes both parameters (id and account) at 100% coverage, so the schema already carries the parameter documentation. The description only repeats 'numeric id' and does not add new semantic details about the parameters 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 clearly identifies the resource (a single Threads post) and the selection method (numeric id), and lists the full field set, which distinguishes it from collection-style tools like get_posts. It relies on the title for the verb 'Read', so it is clear but not maximally self-contained.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for retrieving exactly one post when you already know its numeric id, but it does not explicitly say when to prefer it over siblings like get_posts or get_replies. No alternative guidance or exclusion criteria are provided, so usage is only 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 cover safety and side effects (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the bar for added behavioral value is lower. The description adds a non-obvious metric nuance: 'Reply metrics count direct replies only, not the whole tree underneath.' This is genuinely useful behavioral context beyond annotations. It doesn't discuss error cases or output shape, but annotations cover the safety 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?

Two short sentences, both substantive. The first sentence names the exact metrics and scope; the second adds an important definitional caveat. Every word earns its place, and the most important information 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?

For a read-only metrics tool with robust annotations and a fully described schema, the description is mostly complete: it names all returned metric categories and flags an important counting nuance. There is no output schema, so a bit more detail about return shapes or time ranges would be nice, but the description provides enough for an agent to select and 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 description coverage is 100%, so the schema already documents the id and account parameters adequately. The description adds no additional parameter-level detail beyond the overall scope of 'one of your posts.' Baseline 3 is appropriate because the schema carries the 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 clearly identifies the tool as returning metrics—views, likes, replies, reposts, quotes, and shares—for a single post. It conveys the resource and scope, and the metric enumeration makes it easy to distinguish from account-level tools like get_account_insights. However, it doesn't explicitly differentiate itself from get_post or get_posts, so it stops short of full sibling differentiation.

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: it is the tool to call when you need engagement metrics for one of your own posts. But there is no explicit guidance on when to choose it over get_post, get_account_insights, or get_replies, and no mention of alternatives. A clear context is present, but exclusions and alternatives are not.

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, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: the response is ordered newest-first, contains ids and permalinks, and id/permalinks have an asymmetric relationship across the API. It does not cover pagination or rate limits, but the schema documents pagination parameters.

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, front-loaded with resource, scope, and ordering, followed by a substantive note about why the ids matter. Every sentence earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with full schema parameter coverage, the description covers the essentials: whose posts, ordering, key returned fields, and the critical dependency other tools have on the IDs. It does not describe every returned field, but no output schema is present and the description gives enough orientation 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 every parameter already has a description in structured form. The prose adds no parameter-specific detail, so the baseline of 3 is appropriate; the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: reading your own Threads posts, not general or public posts. It also specifies the ordering ('newest first') and content ('ids and permalinks'), making it clearly distinct from siblings like get_post, get_top_posts, or search_keyword.

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 a clear context for use: results are the source of numeric IDs that other Threads tools require, and permalinks cannot be converted back to IDs. It does not explicitly name alternative tools or state when not to use it, but the ID-origin framing makes the primary use case obvious.

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 read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: the quota is rolling over 24 hours, specific action limits, and that Threads refuses everything once any quota is exhausted. This helps the agent understand why the check matters.

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 and information-dense. It front-loads the core semantic, then provides the quota limits and the practical operational recommendation, all in three short sentences with 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 read-only tool with one optional parameter and no output schema, the description is complete: it explains the quantity being measured, the platform limits, the consequence of exhaustion, and when to invoke the tool. Nothing essential is missing for an agent to select and 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?

The single parameter, account, is already fully documented in the schema with a description, default behavior, an example, and a pointer to list_accounts. Schema coverage is 100%, so the description does not need to add parameter-level detail; it adds no new param semantics, making baseline 3 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 what the tool does: reports how much of the rolling 24-hour publishing quota has been spent. It gives concrete limits for posts, replies, and deletes, making the resource and semantics immediately identifiable and distinct from sibling tools like create_post or get_posts.

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 provides an explicit usage cue: check before a bulk run rather than discovering the quota is gone halfway through. There is no alternative quota tool among siblings, so the lack of an explicit 'when not to use' is not a significant gap.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds the key scoping behavior: this returns only direct replies and does not recurse into nested replies. That is meaningful behavioral context beyond the annotations, though it does not detail pagination or auth behavior.

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 no filler. The core behavior is front-loaded, and the sibling differentiator is placed in a single clear follow-up sentence.

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 operation with thorough schema descriptions and safety annotations, the description is mostly complete. It covers the tool's scope and the key alternative, though it does not describe the output shape and does not contrast with the sibling get_all_replies. These are minor gaps, not blockers.

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?

All five parameters are already described in the schema, including id, limit, cursor, account, and reverse. The description does not add any param-specific 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?

The title and description clearly state that this tool reads the direct replies to a post, one level deep. It also distinguishes itself from get_conversation by explicitly excluding the full reply tree, so an agent can confidently identify what this tool does and what it does not do.

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 routing guidance: use get_replies for direct one-level replies, and use get_conversation for the whole tree including replies to replies. This directly tells the agent when to choose this tool and when to choose a sibling.

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, idempotent, non-destructive behavior. The description adds the important cost trait—one API request per post—along with the insight that absolute likes mostly rank by age, which shapes expected results. This goes beyond the annotations without contradicting them.

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 tight sentences with no filler. The core action is front-loaded, the rationale follows, and the cost warning earns its place. Every sentence contributes to correct invocation.

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 workflow, ranking rationale, and request-cost behavior, which is sufficient given that all parameters are optional and fully schema-documented. It does not specify the exact return shape, but 'rank them' plus the sorting explanation makes the output intent clear enough.

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%: sample, account, and sort_by are each documented in the schema itself. The description reinforces the cost tradeoff for sample size but adds no new parameter semantics beyond what the schema already states. 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 states a concrete composite action—fetch recent posts, pull metrics, rank them—and clarifies the ranking methodology (engagement rate vs. raw likes). This clearly differentiates it from raw listing tools like get_posts or get_post_insights.

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 on when this tool is valuable: when the user wants to know which posts 'landed' relative to views, not just which accumulated the most likes. It also warns about cost-per-post and advises a modest sample. It does not explicitly name sibling alternatives or exclusion conditions, but the intended use 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?

Beyond the annotations (mutation, idempotent, non-destructive), the description discloses two non-obvious behaviors: hiding a top-level reply cascades to nested replies, and the operation is reversible in one call so no confirmation is needed. This is valuable context that helps an agent predict side effects.

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 twwo concise sentences: the first states the action, the second gives the two critical behavioral caveats. There is no wasted wording or repetition of schema content.

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 three-parameter mutation with rsich annotations, the description covers action, scope, cascade behavior, and reversibility. There is no output schema, but the tool is simple enough that the description is complete without detailing return values.

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 adds general behavioral context around hide and reply_id (cascade, reversibility), but no parameter-specific detail beyond what the schema already provides.

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 ('Hide'/'unhide'), a clear resource ('a reply on one of your posts'), and a distinguishing condition ('Hiding a top-level reply cascades to everything nested under it'). No sibling tool covers this exact action, so the 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?

The description gives clear context: this tool is for hiding/unhiding replies on your own posts, with the cascade behavior and reversible one-call nature. It does not name alternatives or exclusions, but no sibling tool is an obvious substitute, so the intended usage is well 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful behavioral context about what the response will tell the agent (default profile, token expiry days) and positions the tool as a first step in multi-account scenarios. It does not mention the live-lookup behavior implied by the 'fast' parameter, but that is captured in the 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?

Two sentences, no filler. The first sentence lists what is returned; the second sentence gives a concise invocation directive. Every phrase adds value and the main output 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?

For a read-only tool with one optional parameter and robust annotations, the description covers the essential return categories and the primary usage scenario. There is no output schema, so a bit more explicit structure (e.g., that it returns an array/object) would be helpful, but the current text is sufficient for a competent agent 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%: the only parameter, 'fast', is fully explained in the schema ('Skip the live profile lookups and return only what is configured locally'). The tool description adds no additional meaning for the parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('list') and resource ('connected Threads profiles'), and goes beyond a simple label by enumerating what is returned: the default profile and token expiry in days. This clearly separates it from siblings like whoami (single identity) and lookup_profile (search).

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 an explicit usage trigger: 'Call this first when more than one profile might be connected.' This is a clear context for when to use it, though it does not name alternative tools for the opposite case or explicitly state when not to use 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?

Annotations already mark the tool read-only, idempotent, and non-destructive; the description adds that geo-gating is only enabled for some profiles and that whoami determines eligibility, which is behavior not captured in annotations. It also conveys that the output is a prerequisite for create_post. No contradictions 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?

Two sentences deliver purpose, eligibility caveat, and usage timing with no filler. The first sentence is the core definition, front-loaded before supporting context. 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?

For a simple read-only list with one optional parameter, no output schema, and rich annotations, the description covers what the tool returns, when to call it, and a related eligibility check. It complements the schema's account parameter guidance with list_accounts. An agent has enough to invoke it correctly in a geo-gating workflow.

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 the single optional account parameter, including its default and a pointer to list_accounts, so the description does not need to add parameter detail. The description's phrase 'this profile' loosely ties to the account parameter but does not explain its semantics further. With 100% schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the country codes a profile may restrict a post to, grounding the 'list' verb in a concrete resource. It references geo-gating and create_post, which distinguishes it from all sibling tools. The title reinforces the domain without ambiguity.

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 explicitly instructs to read this before passing allowlisted_country_codes to create_post, giving a clear usage context. It also points to whoami as the way to check geo-gating eligibility, effectively positioning this tool as a follow-up to that check. It lacks an explicit 'when not to use', but the context is sufficient.

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 readOnly/idempotent annotations, the description discloses a rate limit, a minimum-follower filter, and an expanded-access requirement for non-Meta accounts. It does not describe error behavior for missing or non-public profiles, but the annotations and constraints cover the main safety-relevant behavior.

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, each contributing a distinct piece of information: what the tool returns, the public/minimum-follower constraint, and the access/rate limitations. 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?

With no output schema, the description explicitly lists the return fields (follower count and seven-day totals for views, likes, quotes, reposts) and covers limiting conditions. For a simple single-parameter-required lookup, nothing needed 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?

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description only restates the 'by username' lookup theme and adds no new semantics for the account or username 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?

The combined title and description make clear this tool looks up a single public Threads profile by username and returns follower count plus seven-day engagement totals. It is differentiated from read siblings by focusing on a profile resource rather than posts or insights, though it does not explicitly name an alternative.

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 when to use the tool: to fetch a public profile by username with follower and engagement metrics. It also states important access constraints (100+ followers, 1,000-lookup cap, expanded-access limitation), but it does not explicitly say when to prefer a sibling tool instead.

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 (destructiveHint: true), the description and schema text disclose that approving makes content public immediately, cannot be undone, requires confirm: true, and that Threads has no edit or unsend. This is exactly the behavioral context an agent needs for an irreversible mutation.

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, ordered action first and confirmation caveat second. Every sentence adds necessary operational information, with no repetitive 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 mutation tool with no output schema, the description explains outcome, irreversibility, and confirmation enough to call it correctly. A small gap is not pointing to get_pending_replies as the way to obtain pending reply IDs, and the confirm requirement is framed only around approving even though the schema suggests it applies generally.

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 parameters already carry clear meanings in their own descriptions. The tool description adds no param-level detail beyond what the schema provides, meriting the baseline score of 3.

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 specific verbs ('Approve'/'ignore') with a named resource ('reply waiting in the approval queue') and says what each action does ('making it public'/'stays hidden'). This clearly distinguishes it from sibling tools like get_pending_replies and hide_reply.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: the tool acts on replies in an approval queue, and the action enum defines the two intended workflows. It does not explicitly name sibling alternatives or say when not to use them, but the scope is unmistakable.

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=true and idempotentHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the call waits for processing, makes the container public, and requires explicit confirmation ('confirm: true').

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 deliver the action, source, sequencing, effect, and the critical confirmation requirement. There is no filler and the most important facts are 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?

For a destructive, non-idempotent publish operation, the description together with the schema and annotations covers the prerequisite (stage_post), blocking behavior (waiting for processing), effect (makes public), and required confirmation. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 even without description support. The description reinforces that container_id comes from stage_post and that confirm must be true, but adds little beyond what the schema already states.

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 ('Publish') on a specific resource ('a container created by stage_post'), and the phrase 'This is what makes it public' clearly distinguishes it from staging and other post-related siblings. An agent can tell exactly what this tool does.

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: use this on containers produced by stage_post, and wait for processing first. It does not explicitly name alternatives or exclusions, but the sequencing and prerequisite are clear enough to guide correct use.

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 a destructive, non-idempotent write, so the bar is lower. The description adds valuable specifics: the resulting post is public and irreversible, and an explicit confirm flag is required. This goes beyond the generic destructiveHint and appropriately warns the agent about the consequence of using the 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 front-load the purpose and immediately follow with the critical safety condition. There is no filler, redundancy, or irrelevant detail.

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 plus the fully described schema covers the essential invocation facts: required fields, optional account selection, and the confirmation requirement for an irreversible public action. It does not describe the response after publishing, but no output schema exists and the most important safety context is present.

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 descriptions for text, account, confirm, and quoted_post_id, so the baseline is 3. The description's mention of confirm: true restates the schema's requirement rather than adding new parameter meaning.

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 clear action ('Publish a post') and a specific resource ('an existing Threads post'), so it is obvious this tool creates a quote rather than an original post or a plain repost. The verb and object distinguish it from siblings like create_post and repost without needing to inspect 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?

The description implies this tool is for quoting an existing post, but it does not explicitly say when to prefer it over repost, reply_to, or create_post, nor does it state exclusions. The only guidance beyond purpose is the mandatory confirm: true requirement, which is more parameter usage than tool-selection guidance.

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

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

Annotations already mark this as non-read-only, non-destructive, and idempotent. The description adds valuable context beyond the annotations: the automatic refresh window, the manual force-now behavior, and the lifetime constraints. It does not specify what happens when the token is outside the refresh window, but the lifecycle guidance largely covers expected behavior.

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 no filler. The primary action is front-loaded, followed by the crucial lifecycle constraints, and the optional/manual nature of the call is clarified at the end. 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?

For a single-optional-parameter, no-output-schema tool with rich annotations, this description is complete. It explains what the tool does, when it can be called, when it cannot, and why an agent would call it manually instead of relying on the server's automatic refresh.

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 only parameter, 'account', is fully documented in the schema with type, username example, default behavior, and a pointer to list_accounts. With 100% schema description coverage, the description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Refresh'), the exact resource ('long-lived access token'), and the concrete outcome ('another 60 days'). It clearly distinguishes itself from the sibling tools by focusing on token lifecycle rather than posting, lookup, or account listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit validity conditions: a token can be refreshed once it is 24 hours old and never after expiry. It also tells the agent when the tool is unnecessary (because the server auto-refreshes) and what to do for expired tokens (authorise again), which is an effective alternative.

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 destructiveHint annotation, the description reveals that replies are public immediately, count against a 1,000-reply daily quota, and require confirm:true. The schema further adds that Threads has no edit endpoint and no unsend, giving the agent a clear picture of irreversibility.

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 concise sentences front-load the action and immediately state the most important behavioral caveats. There is no filler or unnecessary repetition of schema content.

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 captures the essential behavioral constraints and the schema covers the parameters well, so an agent can invoke the tool correctly. It does not describe the response shape or explain how to obtain post IDs, but those are minor gaps given the schema and sibling 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?

With 86% schema description coverage, the input schema already documents id, text, account, confirm, image_url, and video_url. The description adds the confirm requirement but no new per-parameter meaning, so it remains at the high-coverage baseline of 3.

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 ('Publish'), a specific resource ('a reply to a Threads post'), and scope ('yours or anyone's'). This clearly distinguishes it from create_post, quote_post, and repost without requiring the agent to inspect sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context: use this tool when the goal is to reply to an existing Threads post, not to create a new post or quote/repost. It does not explicitly name alternatives or state when not to use it, 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.

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

The description adds meaningful behavioral detail beyond the annotations: the repost is immediately visible to followers, the API has no un-repost call, and confirmation is required. This explains why destructiveHint is true and why confirm must be enforced, which is exactly the kind of context an agent needs before invoking a permanent public action.

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 filler. The primary action is stated first, and the critical warning about visibility and irreversibility is placed immediately after. Every sentence earns its place and the overall structure 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?

For a simple tool with only one required parameter, a complete input schema, and rich annotations, this description is sufficient. It covers the action, the public consequence, the irreversibility, and the confirmation requirement. No output schema exists, but for this kind of one-shot action the description provides what an agent needs to invoke it correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides full descriptions for all three parameters, so the baseline applies. The description does not add meaningful per-parameter meaning beyond saying the post is 'existing'; the confirm behavior is also covered in the schema. It is adequate but does not raise the value above what the schema already provides.

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 action ('repost') and the resource ('an existing Threads post') plus the destination ('your own profile'), so an agent knows what the tool does. It is more specific than a generic verb and is distinguishable from create_post and delete_post, though it does not explicitly differentiate itself from the sibling quote_post, which is also a repost-like 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 gives clear context: use this when you want to share an existing post to your own profile. It also flags the important constraint that the action is immediately visible and irreversible, which helps an agent decide whether to proceed. It does not name alternative tools like quote_post or list a when-to-use/ when-not-to-use rule, but the implied usage is sufficiently 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?

The annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral constraints beyond those annotations: the 2,200-query rolling limit and the threads_keyword_search permission requirement. 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?

Two tightly written sentences. The first front-loads the core action, and the second bundles the quota and permission constraints without filler. 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?

Covers the essential call context: purpose, quota, and permissions. The schema handles all parameters. However, since there is no output schema, the description does not explain the expected return shape or pagination behavior beyond the cursor parameter's own schema description.

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 input schema already documents all parameters well. The description adds no extra parameter-level meaning beyond the word 'keyword' in the purpose statement, which maps to q. 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, and method: 'Search public Threads posts by keyword.' This is clear and unambiguous. It doesn't explicitly differentiate from the sibling search_topic_tag, but 'keyword' versus 'topic tag' is implied.

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 useful context: a quota cap and a permission requirement. However, it does not explicitly tell the agent when to choose this tool over alternatives like search_topic_tag or get_posts. Usage is implied rather than explicitly guided.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: results are public-only, matching is exact (one tag per post, no # prefix), and the tool shares a quota with search_keyword. 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 sentences, each earning its place: scope, matching semantics, and budget constraint. The core function is front-loaded in the first sentence, and there is zero filler or repetition of schema content.

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 5-parameter search tool with no output schema, the description covers the important operational aspects: public scope, exact-match behavior, and the shared rate budget. Minor gaps remain — the response shape is not hinted at, and the search_type parameter's TOP vs RECENT distinction is unexplained — but these are secondary for a read-only search operation.

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 80% (4 of 5 parameters documented), which puts the baseline at 3. The description adds real value on top by clarifying tag semantics — exact match, one per post, written without # — which affects how an agent should construct the tag argument. The search_type enum (TOP/RECENT) remains undocumented in both description and schema, a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource precisely (public posts by topic tag) and explicitly differentiates from the most similar sibling, search_keyword, by stating this is an exact tag match rather than a text search. The verb is implied by the name/title but the resource and matching semantics make the tool's function 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 names the alternative tool (search_keyword) and clarifies the boundary between them: exact tag match versus text search, which effectively tells an agent when each tool applies. It also discloses the shared 2,200-query daily budget, an operational constraint affecting tool choice. However, it stops short of an explicit 'use this when / use that instead' statement.

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 (openWorldHint true, readOnlyHint false), the description discloses key behaviors: the container is invisible, holds for 24 hours, is published later with publish_staged, and causes no public visibility. This gives an agent a concrete mental model of side effects rather than just generic mutation flags.

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 short and front-loaded with the core purpose. There is slight redundancy between 'Nothing appears anywhere' and 'Nothing is public,' but the rest of the sentences earn their place by explaining the 24-hour hold, the publish_staged relationship, and the human-review use case.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter tool with no output schema, the description covers the crucial workflow: stage, hold for 24h, publish later, nothing is public. It does not spell out the return value, but the term 'container' and the explicitly named publish_staged step make the flow intelligible.

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 adds no parameter-level detail, but it does not need to: the schema already documents constraints like 500-character limit with emoji bytes, public HTTPS URLs, media type limits, and reply_control enum values.

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: 'Build a media container without publishing.' It clearly distinguishes this from publishing tools by stating nothing appears anywhere and calling it 'the only draft state Threads has,' so an agent can tell it apart from create_post and publish_staged.

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 usage context: this is the draft state and 'the right way to show a human a post before it goes public,' and it names publish_staged as the follow-up. It does not explicitly state 'use create_post instead if you want to publish immediately,' so it stops short of full when-not guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value by revealing that it returns live profile data, specifying fields like username, name, bio, verification, and geo-gated post eligibility. It does not discuss rate limits or auth failure behavior, but that is acceptable for this simple check.

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 filler. Purpose and return fields are front-loaded, and the usage instruction is a concise closing note. 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 zero-required-parameter, read-only identity tool, the description covers what it returns, the token context, and when to call it. Even without an output schema, it explicitly lists the key response fields, so the agent has enough 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?

The schema description fully documents the only optional parameter, including default behavior and a pointer to list_accounts. The tool description itself adds no parameter-specific detail, so the baseline of 3 applies 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 names the specific operation ('confirm which Threads profile the current token acts as') and enumerates the returned fields. It clearly differentiates from the sibling list_accounts by focusing on the active token's identity rather than listing all connected profiles.

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 an explicit usage cue: 'Use this to check credentials before anything else.' It does not name alternatives or when-not conditions, but the context is clear for a read-only identity verification step.

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