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

With no annotations, the description carries full responsibility for behavioral disclosure. 'Live' indicates real-time data, but the description does not mention how the account identifier is interpreted, what happens for invalid accounts, whether any authentication is required, or what 'etc.' includes. This is a significant gap for a tool with zero annotation coverage.

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 tight sentence that front-loads the core purpose and lists illustrative return fields. The trailing 'etc.' is slightly vague but does not undermine overall efficiency.

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

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

For a tool with one optional parameter and an output schema, the description covers the main purpose and return content. However, the missing parameter semantics (what 'account' is and default behavior) leaves an agent guessing about how to invoke it correctly, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description must explain the 'account' parameter. It implies the parameter selects the target account, but it never specifies whether it expects a username, ID, handle, or URL, nor what the default null behavior means. The description adds only marginal meaning beyond the bare schema.

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

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

The description states the resource ('one account') and the content of the snapshot ('username, name, followers, media count, etc.'), which distinguishes it from sibling list_accounts. However, it lacks an explicit retrieval verb like 'get' or 'fetch', relying on the noun phrase 'Live profile snapshot' to convey the 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 'one account' scope implies use when a single account's profile data is needed, which loosely separates it from list_accounts. But there is no explicit guidance on when to use this instead of similar siblings such as get_profile or business_discovery, and no exclusion criteria are 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 and does well by disclosing that the token is written to the macOS keychain (or chmod-600 file fallback) and is NEVER echoed back or logged. It also explains the effect of make_default and the optional app_secret behavior. It does not mention overwrite semantics or validation of the token, but the security-critical behavior is clearly conveyed.

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 efficiently structured: a one-sentence purpose, a clean parameter block, and a short security note. No redundant or filler content; every line adds needed 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 tool is a credential-storage operation with a meaningful side effect, and the description covers the purpose, all parameters, storage location, and secret-handling behavior. An output schema exists, so return values need not be explained. Minor gaps like duplicate-label handling or token validation are not addressed, but nothing essential is missing for an agent to invoke this 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 0%, so this dimension depends entirely on the description. The description provides a line for each parameter: label with a short-key example, access_token as a long-lived API token, ig_user_id as numeric, app_secret as optional with appsecret_proof benefit, and make_default with its exact behavior. This fully compensates for the schema's lack of descriptions.

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

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

Description opens with a specific verb and resource: 'Store an Instagram Business/Creator account for use by every tool.' It clearly establishes this as the credentialing/setup tool, distinguishing it from siblings like publish_image or set_default_account by explaining its role as the account source for all other tools.

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

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

The description implies usage: this is where an account is stored so every tool can use it, and make_default controls whether it becomes the fallback account. However, it never explicitly contrasts with siblings like set_default_account or remove_account, nor states when not to use this tool. Usage context is present but left mostly to inference.

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

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

With no annotations, the description carries the behavioral burden. It declares read-only behavior, public profile access, professional-account restriction, and clarifies how with_media and media_limit affect the response. It does not discuss rate limits or auth edge cases, but this is adequate for a read-only lookup edge.

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 concise sentences, each earning its place: the core capability, the read-only research framing, and the professional-account/media-limit constraints. 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?

An output schema exists, so return-value structure does not need to be spelled out. The description captures the essential behavior, constraints, and parameter effects. The main remaining gap is the account parameter and a more explicit pointer to sibling tools for self-account lookups.

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%, so the description is the main source of parameter meaning. It explains username as the lookup key and clarifies with_media and media_limit as a pair. However, the account parameter is never mentioned, leaving its optional/null default semantics unexplained.

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-plus-resource statement: it returns a public profile and optionally recent media for any business/creator account by username. This clearly differentiates it from sibling tools aimed at one's own account or media, such as get_profile or list_media.

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

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

The description explicitly frames the tool as read-only competitor/prospect research and states the hard constraint that it only works for Professional accounts, not personal accounts. It does not name alternative tools explicitly, but the professional/any-account scope gives a clear usage criterion.

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 burden of behavioral disclosure. It clearly flags that the action is irreversible and restricts deletion to owned comments or comments on the user's media, which are the critical operational traits. It does not discuss account or auth requirements, but the highest-risk behavior is disclosed.

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

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

The description is a single front-loaded sentence with no filler or unnecessary detail. It is slightly redundant with 'Permanently' and 'Irreversible' conveying the same idea, but this does not meaningfully hurt readability.

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 core destructive semantics and scope are present, and the output schema covers return values, but the optional account parameter is not explained and there is no guidance for multi-account contexts. The tool is usable with just comment_id, but the definition is not fully self-sufficient.

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

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

Schema description coverage is 0%, and the description mentions neither comment_id nor the optional account parameter. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond the schema and leaves the nullable/default account behavior unexplained.

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 ('Permanently delete a comment') and adds the ownership/media scope, making the operation unambiguous. It also clearly distinguishes this from the sibling hide_comment by emphasizing permanence and irreversibility.

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 an explicit condition for use: 'a comment you own (or a comment on your media)'. This helps an agent determine when deletion is appropriate, but it does not name alternatives like hide_comment or state when not to use this 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?

With no annotations provided, the description carries the full behavioral burden. It adds useful operational details: default metric list, supported period values, and the note that exact metrics vary by Graph API version with Meta errors naming the correct metric. However, it does not disclose authentication requirements, account-resolution behavior, or any side effects beyond the implicit read operation.

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

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

The description is compact and every sentence earns its place. The core purpose is front-loaded, and the parameter notes are terse but information-dense 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?

The tool has an output schema, so return-value documentation is not required. However, the description fails to clarify the 'account' parameter, which is nullable and defaults to null, and gives no guidance on default-account behavior or when account targeting is needed. These gaps make the definition partially complete for a 3-parameter 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 description coverage is 0%, so the description must compensate. It does explain the values and defaults for 'metrics' and 'period', but the 'account' parameter is left completely undocumented. This partial compensation is better than nothing but still leaves a meaningful 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 clearly identifies the tool as account-level analytics and enumerates the concrete metric types covered (reach, impressions, profile views, follower count). It distinguishes itself from media-level and audience-level siblings through the 'account-level' framing, though it doesn't explicitly name 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?

No explicit guidance is given for when to use this tool versus alternatives like get_media_insights or get_audience_insights. The phrase 'account-level analytics' implies the use case, but the description never states exclusions or conditions that would route an agent to a sibling 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?

With no annotations provided, the description carries the behavioral burden itself. It discloses a non-obvious failure mode (the Meta privacy floor and resulting Graph error) and version-dependent behavior, which is valuable context beyond just 'get audience insights'. Permissions and rate limits are not discussed, but for a read-oriented getter with an output schema this is a reasonably transparent description.

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 resource, 'Follower demographics'. The three sentences convey the prerequisite, the Graph API parameterization, and override behavior without excessive padding. The phrasing is somewhat telegraphic and 'All are override-able' is vague, but nothing is truly wasted.

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

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

For a 6-parameter tool with no annotations and zero schema descriptions, the description covers the main prerequisite and the most important parameter spellings, while the output schema covers return shape. However, 'period' and 'account' are left underspecified, there is no guidance on sibling tools, and the mention of 'engaged-audience metrics' alongside follower_demographics could confuse invocation. It is adequate but not fully complete.

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

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

The input schema has 0% description coverage, so the description must compensate by explaining parameter values. It does so for the key parameters: metric, metric_type, breakdown, and timeframe, including explicit option values. However, 'period' and 'account' are not meaningfully explained beyond 'All are override-able', so it does not fully compensate for the zero 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 opening phrase identifies a specific resource, 'Follower demographics', with concrete dimensions (age, gender, country, city), which is clearly distinct from siblings like get_account_insights or get_media_insights. It does not actually state a verb—'get' appears only in the tool name—and it never names a sibling contrast, so it falls short of a 5.

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

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

The description gives a concrete precondition: the account must have at least 100 followers, and it warns that below that the Graph returns an error surfaced cleanly. It also provides parameter guidance for newer Graph versions ('metric=follower_demographics', 'metric_type=total_value', 'breakdown=...', timeframe values). It does not explicitly say when not to use this tool or name alternative tools, so it is not 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'List comments' and reveals output fields; it does not disclose how the optional account parameter affects behavior, whether hidden comments are returned or filtered, pagination behavior, or any authentication or rate-limit 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?

A single, front-loaded sentence states the core operation and the returned fields with no filler. The parenthetical list is compact and easy to parse.

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 is minimally adequate for a simple read operation: it identifies the resource and required media_id can be inferred. However, it lacks guidance on the optional limit and account parameters, has no usage alternatives, and provides no behavioral context beyond listing fields. An output schema exists, but the description still leaves notable 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?

Schema description coverage is 0%, so the description must compensate by clarifying parameters. It does not explain media_id, limit, or account at all. The parameter names and defaults exist in the schema, but the description adds no meaning beyond what is already structurally visible.

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

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

The description clearly states a specific action and resource: 'List comments on a media object.' It also enumerates the returned fields (text, username, timestamp, like_count, hidden), making the purpose concrete. This distinguishes it from sibling tools like reply_to_comment, hide_comment, and delete_comment.

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 intended use is implied: call this when you need the list of comments for a media object, as opposed to acting on a comment. However, the description does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or preconditions such as requiring access to the media object.

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?

No annotations are present, so the description carries the behavioral disclosure burden. It surfaces the per-account rate limit, the prior lookup requirement, and the edge/limit constraints. It does not mention pagination or default-account behavior, but those are partly addressable via the existing output schema.

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

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

Two dense, well-organized blocks with no filler. The first sentence defines the operation, the second gives parameter constraints, and the final sentence provides prerequisite and quota 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 4-parameter tool with no annotations, the description covers purpose, main parameter semantics, a prerequisite, and quota awareness. The main gap is the unexplained account parameter. Since an output schema exists, the lack of return-value detail is acceptable.

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%, so the description must compensate. It explains edge values, the limit range, and where hashtag_id comes from. However, the optional 'account' parameter is entirely unexplained—an agent does not know what value format it expects or what null means.

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

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

States a specific verb and resource: 'Recent or top media for a hashtag id.' It also names the edge variants and limit range, making the tool's function immediately identifiable. The note about obtaining hashtag_id from search_hashtag separates it from that sibling tool.

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

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

Explicitly gives a prerequisite: 'Get the hashtag_id from search_hashtag first.' It also warns about Meta's 30-unique-hashtags per-7-days limit, which helps an agent decide when this call is appropriate. It does not enumerate alternatives like list_media or get_media, so exclusions are not fully explicit.

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

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

With no annotations, the word 'Return' is the only explicit behavioral signal that this is a non-mutating read operation, and the field list communicates what will come back. It does not disclose auth expectations, error behavior, or the role of the optional account parameter, but the core read behavior is clear.

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

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

The description is a single front-loaded sentence with no filler; every clause adds information. It is appropriately concise even though some usage context is absent.

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 low-complexity getter with an output schema, the basic call is clear: provide a media id. However, the optional account parameter and the distinction from list_media / get_media_insights are left unexplained, so an agent navigating many siblings gets only partial context.

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

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

Schema description coverage is 0%, so the description must compensate. 'by id' maps to the required media_id, but the optional account parameter is entirely unexplained, and the listed fields are output fields rather than 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 uses a specific verb ('Return') and identifies the resource ('full fields for one media object by id') with a parenthetical field list. It is clear, but it does not explicitly contrast itself with sibling tools like list_media or get_media_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 implies its use case: fetch a single media object's full fields when you already have the media id. It does not state when not to use it or direct the agent to alternatives such as list_media or get_media_insights.

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 behavioral burden. It adds useful context about the metrics override, feed-post defaults, and Reels/stories metric differences. It does not mention authentication, error behavior, or rate limits, so it is adequate but not comprehensive.

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 the core purpose front-loaded and the metric caveat placed directly afterward. It contains no filler, repetition, 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 output schema covers return-value shape, and the description provides the key selection cue that this is per-post rather than account-level analytics. The main gap is the lack of explicit guidance on the optional account parameter, but this is minor for a simple read-only analytics 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 description coverage is 0%, so the description needs to clarify parameters. It explains the metrics parameter well, including comma-separated overrides and media-type differences, but it leaves the account parameter and media_id format undocumented beyond the schema's type information.

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 per-post analytics and lists the relevant metrics, which distinguishes it from account-level siblings like get_account_insights and get_audience_insights. It lacks an explicit verb like 'get' or 'list,' but the phrase 'Per-post analytics' 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 implies when to use this tool by emphasizing 'per-post' analytics and notes that defaults suit feed posts while Reels/stories need explicit metrics. However, it does not explicitly name sibling alternatives or state when to prefer another tool, leaving the selection logic somewhat inferred.

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 conveys read-only intent via 'List' but omits pagination behavior, ordering, the notion of 'recent', and how the optional account parameter interacts with the default account. The 'tags edge' hint is technical, not behavioral.

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

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

A single, front-loaded sentence with no filler. Every word earns its place, and the parenthetical 'tags edge' adds precise context without bloating the text.

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

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

For a simple read-only list tool with an output schema, the description gives enough to understand the basic purpose. However, the zero annotation coverage and undocumented parameters create gaps around the account and limit semantics, so the definition is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It only tangentially clarifies 'account' through 'where the account is @-mentioned' and says nothing about the 'limit' parameter or its default. This leaves the agent without meaningful guidance for either 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 clearly states the verb 'List', the resource 'media', and the specific scope 'where the account is @-mentioned'. The parenthetical 'tags edge' further distinguishes this from siblings like list_media and get_hashtag_media.

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

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

The wording implies this tool is for retrieving media that mentions the account, but it never explicitly says when to use it over list_media or get_hashtag_media, nor when to supply the account parameter. Guidance is only inferred from the mention context.

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 behavioral disclosure burden. It discloses the critical Meta App Review permission requirement and implies a read-only operation, which is useful. However, it does not mention any other behavioral traits like rate limits, pagination, or error 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 compact and front-loads the core purpose in the first sentence. The second sentence adds a necessary access requirement without unnecessary verbosity.

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

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

The tool has only three parameters and an output schema, but the description leaves key gaps: parameter semantics, how to obtain conversation_id, and when to choose this over list_conversations. It is not complete enough for reliable tool selection and 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%, so the description must compensate for undocumented parameters, but it does not. conversation_id, limit, and account are entirely unexplained, leaving an agent to guess their meaning and expected formats.

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

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

The description clearly states the tool reads messages in a DM conversation, with a specific verb and resource. It is distinct from siblings like list_conversations and send_message, though it does not explicitly name or differentiate them.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_conversations or send_message. The Meta App Review requirement is a prerequisite but does not help an agent decide between sibling 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?

With no annotations provided, the description carries the full burden. It does indicate a read-only, public retrieval and specifies the returned fields, but it does not mention behavior around the optional account parameter, authentication, or errors. For a simple non-destructive getter this is adequate, though not rich.

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 well-structured sentence with the action and resource front-loaded. It lists the returned fields and contains no filler or redundant phrasing.

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

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

Although the tool is simple and has an output schema, the description omits guidance on the only input parameter and does not clarify when to prefer this tool over account_info. An agent cannot confidently decide how to fill the account argument or whether to use this tool versus a sibling.

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 has 0% description coverage for the single 'account' parameter, and the description does not mention it at all. There is no explanation of whether 'account' expects a username, an ID, what null/default means, or how it relates to the current authenticated account. The description fails to compensate for the schema's lack of parameter guidance.

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 ('Return') and resource ('the account's public profile fields'), and enumerates the exact fields included (followers, follows, media count, bio, website). It is clear in what it does, although it does not explicitly differentiate itself from sibling tool account_info.

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 account_info, list_accounts, or other sibling tools. The description implies a public-profile retrieval use case but gives no exclusions, prerequisites, or context for choosing it over alternatives.

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 fully covers the side-effect profile ('never mutates'), the underlying action (live GET on the default account's profile), and the failure behavior (ok=false with a hint when no account is set), leaving no ambiguity.

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

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

The description is two tight sentences: the first upfront states the tool's purpose and scope, and the second adds behavior and failure details. Every sentence earns its place with no 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 parameterless healthcheck with an output schema present, the description covers what is verified, how it verifies it, when it is safe to call, and what happens in the unconfigured case. Nothing material needed to invoke or interpret the tool 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?

The tool has zero parameters and the input schema is empty, so there is nothing to document. The description appropriately adds no unnecessary parameter details, matching the baseline expected for a parameterless tool.

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 ('Verify') and a clear resource: MCP configuration readiness, including accounts, token backend, and Graph reachability. It also explains the operational action ('Does a live GET on the default account's profile'), which clearly distinguishes it from sibling data-retrieval tools like get_profile or list_accounts.

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

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

It explicitly states this is safe to call anytime and never mutates, which gives clear situational guidance. It does not directly name sibling alternatives or exclusions, but the diagnostic framing and the note about returning ok=false when no account is set make the intended use 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully states that the operation is reversible ('hide=false unhides') and scoped to 'public view', which implies the comment is not deleted. However, it omits any mention of permissions, account context, or side effects, so coverage is adequate but not rich.

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, no filler, and the most important behavioral detail ('hide=false unhides') is front-loaded. Every word 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 toggle tool with an output schema, the description is minimally workable but leaves gaps: there is no usage guidance and no explanation of the optional 'account' parameter. The agent can probably call it correctly using the schema, but the definition is not fully self-contained.

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%, so the description must compensate for all three parameters. It explains the 'hide' parameter's false behavior, and 'comment_id' is inferable from its name, but the 'account' parameter is entirely unexplained and could be ambiguous.

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 ('Hide') and resource ('a comment'), and clearly indicates it toggles visibility with 'hide=false unhides'. The phrase 'from public view' differentiates this from permanent deletion, which is a key sibling 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?

No guidance is provided about when to use this tool versus alternatives like delete_comment or reply_to_comment. The description states the action but does not offer exclusions, prerequisites, or routing to a sibling 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?

With no annotations provided, the description carries the full burden. It explicitly discloses a critical security behavior: 'Never returns tokens.' This goes beyond the basic list semantics and helps an agent understand a key constraint, though it does not explicitly state read-only behavior beyond the verb 'list.'

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

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

The description is a single dense sentence with no filler. The core action and returned fields are front-loaded, and the important security note is added without bloat.

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-parameter listing tool with an output schema already present, the description is complete. It states what is returned, implies read-only behavior, and adds the crucial exclusion of tokens. Nothing essential is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, and the baseline for no-parameter tools is 4. The description adds value by specifying what the response contains (labels, ig_user_id, default flag), which is more than the empty input 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 uses a specific verb 'List' with the resource 'configured Instagram accounts' and names the returned fields (labels, ig_user_id, default flag). It clearly distinguishes the tool from siblings like add_account, account_info, and get_profile.

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 to use when you need an overview of configured accounts, but it does not explicitly state when not to use it or name alternatives. Usage context is implied rather than directly 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It usefully reveals the required Meta App Review permission and managed-message scope. However, it does not mention pagination behavior, ordering, or whether only conversations with messages are returned.

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

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

The description is a single, front-loaded sentence with no filler. The core action and a critical authorization requirement are both included economically.

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

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

For a tool with two optional parameters and no annotations, the description leaves key context unclear—especially the purpose of `account` and how results are limited. The presence of an output schema covers return values, but invocation semantics remain incomplete.

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%, so the description must compensate for undocumented parameters. It does not explain `limit` or, more importantly, `account`, whose meaning as an optional string/null is ambiguous. Only the parameter names and defaults provide minimal clues.

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 ('List') and resource ('Instagram DM conversations'), making the core operation clear. It does not explicitly differentiate from sibling tools like get_messages, but the resource is distinct enough to avoid confusion.

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

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

The only usage guidance is a permission requirement ('REQUIRES Meta App Review (instagram_manage_messages)'). There is no advice on when to use this tool versus get_messages or other siblings, nor are exclusions or alternatives mentioned.

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 behavioral burden. It discloses the ordering and the limit range, but does not explicitly state that this is a read-only operation, how the account parameter selects the target, or what happens with the null default.

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

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

Two compact sentences with the core operation and ordering front-loaded. The second sentence adds the only essential constraint; there is no filler or elaboration.

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

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

The tool is simple and has an output schema, so the description is mostly adequate. However, the account parameter semantics and alternative routing are not fully covered, leaving some ambiguity 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 descriptions are absent (0% coverage), so the description needs to compensate. It adds the 1-100 range for 'limit,' but leaves the meaning and null behavior of 'account' undocumented beyond the phrase 'for the account.'

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 first sentence names a specific operation, 'List recent media (posts/reels) for the account,' with explicit sort order ('newest first'). This clearly identifies the resource and distinguishes it from related siblings such as get_media (single item) and get_hashtag_media.

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

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

The description implies the tool is for retrieving an account's recent posts/reels, but it does not explicitly state when to choose this over get_media or other media-list siblings, nor does it mention any exclusions or prerequisites.

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 behavioral burden. It discloses the multi-step creation flow: child containers per image marked is_carousel_item, then a CAROUSEL parent, then publishing. It also communicates the public-https constraint. It does not detail irreversible side effects or failure modes, but the core behavior is transparent.

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: the first sentence states purpose and constraint, the second explains the internal flow. Every sentence adds value and there is no redundant wording.

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?

An output schema exists, so return-value details are not required. Still, the description omits meaningful invocation context: what the account parameter controls when omitted, whether caption is a per-carousel caption, and how publishing limits apply. These gaps matter for an agent choosing between this and sibling publish tools.

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

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

Schema description coverage is 0%, so the description must compensate. It enriches image_urls with the 2-10 range and public-URL requirement, but leaves account and caption semantically unexplained. The required parameter is well covered, while optional parameters rely on name inference.

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 'Publish a multi-image carousel (2-10 images)', which names a specific verb, resource, and numeric constraint. It clearly differentiates this tool from sibling single-media publishers like publish_image, publish_video, publish_reel, and publish_story.

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 tool is for multi-image carousels and not for other media types, and it adds a public-URL requirement. However, it does not explicitly name alternative tools or state 'use publish_image for a single image', so there is clear context but no formal 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?

With no annotations, the description carries the behavioral burden and does well: it discloses that Instagram fetches the image bytes from the URL itself, which explains why the URL must be public, and that the two-step Graph flow is handled internally. This conveys meaningful operational behavior beyond the schema, though it omits details like failure handling or account selection.

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, each carrying distinct information: purpose, URL requirement, caption limit, and internal flow. It is front-loaded and free of filler, making it easy for an agent to parse quickly.

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?

An output schema exists, so return values are covered. The description addresses the main operational gotchas: public URL fetching, caption length, and the internal two-step Graph flow. The only notable gap is the account parameter semantics, but the optional nature with a default null and sibling account tools make this a minor deficiency.

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 has 0% description coverage, so the description must compensate. It effectively explains image_url (must be public https) and caption (<= 2200 chars), but it says nothing about the account parameter, such as whether null means 'use the default account.' One of three parameters remains undocumented in the description, leaving a partial 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 states a specific action and scope: 'Publish a single image to the feed.' The word 'single' differentiates it from sibling tools like publish_video, publish_carousel, and publish_story, while 'feed' distinguishes it from publish_story. This is enough for an agent to select it correctly 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 clear context for when to use the tool: for a single image, not video or carousel. It also provides explicit preconditions, noting that image_url must be a public https URL and caption must be <= 2200 chars. It does not explicitly name alternative tools, but the scope constraints make the when-not condition 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the rolling 24h window and Instagram's cap, but does not explicitly state that the tool is read-only, whether authentication is required, or how the optional account parameter affects the result. The output schema likely covers the return shape.

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

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

One concise, front-loaded sentence contains the core purpose and the key Instagram cap context. There is no filler or redundant information.

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

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

The description is adequate for a simple read-only tool with an output schema, but it leaves the account parameter completely unexplained and does not explicitly connect this to pre-publishing workflow. Minor gaps reduce its completeness.

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', has zero schema description and is not mentioned in the tool description. The agent must infer that it selects which account's quota to check and what null means, which is a significant gap for a multi-account tool.

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 the remaining posts in the rolling 24h publishing quota, with the Instagram API cap context. It is specific enough to distinguish from publishing and media tools, though it does not explicitly name a sibling 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 quota context implies this should be checked before publishing to avoid hitting the cap, but the description does not explicitly say when to use it, when not to use it, or mention alternatives. Usage is inferred rather than stated.

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

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

With no annotations provided, the description carries the full behavioral burden and does a solid job: it discloses the public-URL requirement, the share_to_feed side effect of surfacing in the main grid, and the asynchronous processing with a 90-second polling window. It doesn't mention failure modes or permissions, but the existence of an output schema reduces the need to document return 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 brief and front-loaded with the primary action, then covers the key constraint and option behaviors in short sentences. There is no filler or repetition; 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?

Given that an output schema exists and the tool is a straightforward publish action, the description covers the essential operational context: URL format, feed visibility, optional thumbnail, and async polling. The main gap is the undocumented account parameter, but overall the description provides enough guidance for an agent to call 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 description coverage is 0%, so the description must compensate for the input schema's lack of parameter documentation. It adds meaningful context for video_url (must be public https), share_to_feed (surfaces in main grid), and cover_url (optional thumbnail). However, it leaves account and caption undocumented; caption is fairly obvious, but account semantics remain ambiguous.

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, 'Publish a Reel,' which clearly states the tool's core action. It doesn't explicitly differentiate from sibling tools like publish_video or publish_story, but the resource type 'Reel' is distinct enough that 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 implies when to use the tool by naming the resource type, and it gives a key prerequisite ('video_url must be a PUBLIC https URL') plus optional behavior for share_to_feed and cover_url. However, it does not explicitly state when not to use this tool or directly compare it to sibling publish tools, leaving some selection inference to the agent.

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?

There are no annotations, so the description carries the burden of explaining side effects, authentication needs, or reversibility. It only adds the input constraints 'exactly one' and 'PUBLIC https', which are more about parameters than about what happens when the story is published.

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 very short and front-loaded, with no filler. The 'PUBLIC https' phrase is somewhat elliptical, but the overall definition is compact and scannable.

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 only three parameters and an output schema, a brief description can be sufficient. Still, the missing account semantics and lack of any note about authenticated default accounts leave a notable gap for an agent that must decide whether to pass account or rely on prior setup.

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 has zero property descriptions, so the description partially compensates by explaining that image_url and video_url are mutually exclusive and must be public HTTPS URLs. However, the meaning and behavior of the 'account' parameter are completely unexplained, and the schema allows an empty object despite the claimed 'exactly one' rule.

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 operation: publish a Story, an image or video. It distinguishes this from sibling tools like publish_image, publish_video, publish_reel, and publish_carousel by naming the Story resource explicitly.

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

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

It provides clear context that this is for Story publishing and that exactly one media URL is needed. However, it does not explicitly say when to prefer this over publish_image, publish_video, publish_reel, or publish_carousel, nor does it mention prerequisites such as account setup.

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 and adds real value by disclosing that containers process asynchronously and that the tool polls status up to 90s before publishing. It does not cover auth requirements, failure behavior after timeout, or side effects, so it is not a 5.

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

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

Two sentences with no filler, and the critical async behavior is placed right after the core action. Every sentence adds information.

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

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

For a mutation tool with no annotations and multiple publishing siblings, the description is missing decision guidance and account/caption semantics. The output schema and async note mitigate the lack of return-value explanation, but the gaps keep it below complete.

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

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

Schema coverage is 0%, so the description must document parameters. It only constrains video_url (public https) and ignores account and caption semantics; account in particular is non-obvious and needs explanation of which account it targets. This is partial compensation at best.

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 concrete verb and resource ('Publish a video to the feed') and is immediately distinguishable from image/story/carousel siblings. It does not explicitly contrast with publish_reel, leaving a small ambiguity because reels are also video.

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 a required precondition (public https URL) but never says when to choose publish_video over publish_reel, publish_story, or publish_image. No alternative tools or exclusion criteria are mentioned, so an agent must infer usage from the name/resource.

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 burden and does explicitly disclose the destructive keychain-token deletion. However, it does not state that the action is irreversible, what happens to related account state, or whether permissions are required, so transparency is only partial.

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 tightly written sentence with no filler, and the primary action is front-loaded. Every word contributes to the tool's meaning.

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 one-parameter tool, the description states the core behavior and the keychain side effect, and an output schema exists to cover return values. Still, it omits important practical context like finding valid labels via list_accounts and any default-account removal constraints.

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 coverage for the single required 'label' parameter, and the description does not explain what label values are valid, how to obtain them, or that list_accounts can supply them. The phrase 'configured account' hints at the label but does not add real parameter-level 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 names a clear verb ('Remove') and a specific resource ('a configured account'), and adds the concrete side effect of deleting its stored token from the keychain. This cleanly distinguishes it from sibling tools like add_account, list_accounts, and set_default_account.

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 about when to use this tool versus alternatives, no mention that it complements list_accounts/add_account, and no note about constraints such as whether the default account can be removed. The context is implied only by the wording 'configured account.'

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?

No annotations are present, so the description carries the burden. It clearly indicates a write action and states the return value ('Returns the new comment id'). However, it does not mention auth requirements, rate limits, or any other side effects beyond the obvious creation of a reply.

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 extremely concise: three short sentences, each earning its place. It front-loads the purpose, then provides the key constraint and output expectation 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?

For a simple write tool, the description covers the core action, a constraint, and the output. However, the undocumented account parameter and lack of any usage guidance or behavioral context make it incomplete enough to warrant a mid-range score.

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%, so the description must compensate. It adds meaning for message with the 2200-character limit and implies comment_id, but it fully ignores the optional account parameter. This leaves a meaningful gap in 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 states a specific verb and resource: 'Reply to a comment.' It clearly distinguishes this from sibling tools like get_comments, hide_comment, and delete_comment by naming the action the tool performs.

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 purpose 'Reply to a comment' implies when the tool should be used, but there is no explicit guidance about when not to use it or how it relates to alternatives such as hide_comment or delete_comment. It does provide a useful constraint (message <= 2200 chars), but not full usage context.

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?

No annotations are provided, so the description must carry the behavioral burden. It does convey that this is a resolution/lookup operation, not a mutation. However, it does not mention authentication needs, error conditions, rate limits, or what happens when the hashtag is not found, which would be useful given zero annotation support.

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

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

One tight sentence with no filler. The key purpose is front-loaded, and the workflow dependency is placed at the end as supporting context. Every word earns its place.

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

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

The tool is simple and has an output schema, so the description need not restate return values. However, the unexplained optional 'account' parameter and the absence of any behavioral caveats leave the description slightly incomplete for an agent deciding how to call this 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 0%, so the description must explain the parameters. It only clarifies that 'hashtag' is the hashtag name, but the optional 'account' parameter is completely unexplained. This is a meaningful gap because the agent cannot infer when or why to provide an account.

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 precise verb ('Resolve'), the resource ('hashtag name'), and the result ('Graph id'), and even places it in a workflow ('needed before get_hashtag_media'). This clearly differentiates it from sibling tools like get_hashtag_media or get_mentions.

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 says the tool is needed before get_hashtag_media, giving a concrete usage context. It does not enumerate when not to use it or discuss alternatives, but the workflow dependency is strong, actionable 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?

With no annotations provided, the description carries the behavioral disclosure burden. It reveals auth requirements, the IGSID recipient requirement, and the limitation around paid message tags. It does not discuss result behavior or side effects, but the output schema can cover return shape.

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, front-loaded with the action, and every sentence adds value: the action, the requirements, the ID definition, and the limitation. There is no filler or repetition of schema fields.

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 send-DM tool with an output schema, the description covers the core constraints and the key non-obvious parameter. It could mention how the optional account field is resolved, but overall it gives an agent enough to invoke the tool correctly within its documented context.

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

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

Schema coverage is 0%, so the description must explain parameters. It usefully defines recipient_id as an IGSID and clarifies a potentially confusing prerequisite, but it does not explain the 'account' parameter or any constraints on 'text'. The description partially compensates but not fully.

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 'Send a DM,' which clearly names the verb and resource. It is distinct from sibling tools that list messages or publish media, though it does not explicitly name a differentiating sibling for sending DMs versus replying to comments.

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 prerequisites: Meta App Review and the 24-hour standard-messaging window. It also states when not to use it by noting that paid message tags outside the window are not handled here, though it does not name an 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It states the immediate effect of setting a default account but does not disclose whether the change persists across sessions, whether it overrides previous defaults, whether the label must reference an existing configured account, or what error behavior occurs for an invalid label.

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 front-loads the verb and object. Every word contributes meaning, and there is no redundant restating of the tool name or schema. The scoping condition is included efficiently.

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 setter with an output schema, the description gives the core semantics and usage condition. However, with no annotations and no parameter explanation, it omits important context around label validity, persistence, and side effects. It is minimally adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for the bare `label: string` parameter. It does not explain what `label` should contain, how it maps to configured accounts, whether it needs to match an existing account label exactly, or any format constraints. The only weak semantic hint is the phrase 'configured account,' which is not tied directly to the 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 uses a specific verb ('Set') with a concrete resource ('which configured account') and a precise condition ('when a tool's `account` arg is omitted'). This clearly distinguishes the tool from sibling account-management tools like list_accounts, add_account, remove_account, and account_info, which handle listing, adding, removing, or inspecting accounts rather than changing the default fallback.

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 when the tool matters: it affects behavior only when the `account` argument is omitted from other tool calls. It does not explicitly name alternatives or exclusions, but no sibling tool appears to serve the same default-setting purpose, so the guidance is sufficient for an agent to select this tool.

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