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

No annotations are provided, and the description does not disclose potential side effects (e.g., POST/DELETE can mutate data), error handling, or authentication requirements. As a generic passthrough, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The two-sentence description is concise, front-loads the purpose, and provides essential context (base URL) without unnecessary 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 provides the base URL and scope, but does not describe output format, error behavior, or authentication. Given it's a passthrough to an external API with no output schema, some gaps remain, but the core purpose is covered.

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

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

Only the path parameter has an example description in the schema; query and method lack any explanation in both schema and description. The description mentions path relative to base URL but does not clarify query semantics or method usage.

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 it is a passthrough for any Threads Graph API endpoint not covered by sibling tools, with the base URL provided. This distinguishes it from the specific sibling tools.

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

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

It explicitly says to use it for anything the tools above do not cover, and explains that paths are relative to the base URL. This gives clear guidance on when to select this tool over more specific ones.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently warns that the post is immediately public, has no draft state, and that deletion does not undo visibility. It also explains that images are fetched server-side and must be publicly reachable HTTP(S) URLs, which is a significant implementation detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by high-impact caveats. Every sentence earns its place, covering permanence, undo, and image URL requirements without redundancy or 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 publish tool with no annotations and no output schema, the description covers the most important operational realities: public visibility, no draft state, deletion semantics, and image URL constraints. It does not explain return values or user_id, but the included context is sufficient for an agent to invoke the tool correctly in most cases.

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 80%, so the schema already documents most parameters. The description adds meaningful value beyond the schema by emphasizing that image_url must be publicly reachable and that local paths will not work. This clarifies the most error-prone parameter without repeating every schema description.

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 begins with 'Publish to Threads,' a specific verb and resource that clearly identifies the tool's function. It also distinguishes itself from siblings by noting that the only undo is threads_delete_post, making the create-vs-delete relationship explicit.

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

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

The description gives clear context about publishing and the absence of a draft state, but it does not explicitly say when to use this tool instead of alternatives like threads_get_my_posts or threads_delete_post. The sibling names make the distinction inferable, but no direct when-to-use or when-not-to-use guidance is provided.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It explicitly warns 'Irreversible,' which is a critical behavioral trait for a delete operation, and it restricts the action to the user's own posts. However, it does not mention permissions, error cases, or side effects beyond deletion.

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, direct sentences with no filler or redundant information. It front-loads the core operation and immediately adds the critical irreversibility warning.

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

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

For a simple one-parameter tool with no output schema, the description is largely sufficient: it defines the scope, the target resource, and the irreversibility. It could go further by noting authentication requirements or response behavior, but these are not essential for basic 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 0%, and the description makes no direct mention of post_id. The parameter name is self-explanatory and the phrase 'one of your own posts' implies an identifier, but the description does not add explicit semantic guidance or clarify what post_id refers to.

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') and a specific resource ('one of your own posts'), making the operation unambiguous. It clearly distinguishes this tool from the sibling get/create/profile/insights tools, even without an explicit comparison.

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 does not provide any when-to-use or when-not-to-use guidance, nor does it mention an alternative tool. The only implicit signal is that this is the sole delete-related tool among the siblings, but no explicit usage context or exclusions are given.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not mention that the operation is read-only, safe, or free of side effects. While the 'get' prefix implies a safe operation, this is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the core purpose and a practical usage tip. It is well-structured, front-loaded with the primary function, and avoids unnecessary 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?

For a tool of this complexity, the description is incomplete. It omits explanations of the parameters, does not describe the output format or structure, and lacks information about potential edge cases or error handling. The user is left to infer important details from the schema alone.

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 description does not explain the meaning or purpose of the 'limit' or 'user_id' parameters. The schema provides some constraints (e.g., default, min, max) but the description adds no semantic value, leaving users to guess how these parameters affect the returned posts.

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

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

The description clearly states the tool returns recent posts with permalinks, which identifies the core function. It also hints at its use case after publishing to verify outcomes, but does not explicitly differentiate it from sibling tools such as threads_get_post_insights or threads_create_post.

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

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

The description suggests calling after publishing to confirm the post went out, providing a concrete scenario. However, it does not explicitly state when to use this tool over alternatives or when not to use it, leaving room for ambiguity.

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

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

With no annotations, the description carries the burden for disclosing side effects, permissions, or error conditions. It only states the data returned and implies a read-only operation via the word 'Engagement', but does not explicitly confirm safety, ownership restrictions, or failure 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 a single, concise sentence that enumerates the relevant metrics. It is not verbose or redundant, but it could be slightly more explicit about the action (e.g., 'Retrieve engagement metrics for a post').

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

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

Given the simple nature of the tool (one parameter, no output schema), the description is reasonably complete for a basic retrieval. However, it does not mention the output format, potential errors, or whether the post must be owned by the caller, leaving some ambiguity.

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 provides zero description for the post_id parameter. The tool description does not explain how to identify the post or whether it must be owned by the current user. Since schema coverage is 0%, the description should compensate but does not.

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 indicates that the tool retrieves engagement metrics (views, likes, replies, reposts, quotes) for a specific post. It is distinguishable from siblings like profile retrieval or post creation, though the verb 'get' is implied rather than stated.

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it does not explain when 'get_my_posts' would be more appropriate for listing posts, or how to obtain a post_id.

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

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

With no annotations, the description carries the full burden, but it only says 'A Threads profile' and the user_id convention. It does not disclose whether the endpoint is read-only, requires authentication for other users' profiles, or what happens with invalid IDs, leaving the agent to infer the behavior from the name.

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?

At two sentences, it is compact and contains no filler. The second sentence is a useful tip, but the first sentence is a fragment that could be strengthened to an active verb phrase without increasing length.

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

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

For a simple two-parameter tool with no output schema, the description gives the essential user_id trick and the schema covers fields. However, it omits response format, authentication expectations, and any distinction from sibling tools, leaving the agent to fill in gaps.

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 describes 'fields' but leaves 'user_id' undocumented, and the description compensates by explaining the special 'me' value and how to discover one's own numeric id. This is meaningful semantic information beyond the schema, though it still doesn't fully explain what user_id represents in general.

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 the noun phrase 'A Threads profile' rather than an explicit action like 'Gets a Threads profile,' so the operation is left to inference from the tool name. It identifies the resource and the special user_id='me' convention, but doesn't clearly state what the tool does or how it differs from siblings.

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

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

There is no guidance on when to use this tool versus alternatives such as threads_get_my_posts. The only usage hint, 'Pass user_id='me' for the authenticated account,' addresses parameter input, not selection context.

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