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

No annotations provided. The description only includes an HTTP method, omitting any behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects.

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

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

The description is minimal but fails to provide sufficient detail. It is under-specified rather than concise, missing critical 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?

Given no output schema and no behavioral context, the description is severely incomplete. It does not explain what the tool returns, how to use the fields parameter, or any edge 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 0%; the description does not explain the meaning or constraints of 'account_id' or 'fields' beyond their names. It adds no semantic value over the schema.

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

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

The title 'Get one ad account' clearly states the verb and resource. The description adds an HTTP path template but doesn't improve clarity. It is distinguishable from sibling 'ad_accounts_list' which lists 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?

No guidance on when to use this tool versus alternatives like 'ad_accounts_list' or other get tools. No mention of prerequisites or use cases.

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, and the description does not disclose any behavioral traits such as being read-only, destructive, or requiring authentication. It simply states the endpoint without any behavioral context.

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

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

The description is extremely concise but at the expense of completeness. It is under-specified, providing no useful information beyond the endpoint. Effective conciseness requires conveying essential information succinctly, which is absent here.

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 parameters, no output schema, and no annotations, the description is critically incomplete. It lacks any context about the return format, pagination (limit), or field selection behavior.

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

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

Schema description coverage is 0%, and the description does not mention the parameters (fields, limit) at all. The schema provides basic types and constraints, but the description adds no semantic meaning to the parameters.

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

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

The description 'GET /me/adaccounts' is essentially a tautology of the title and name. It restates the HTTP method and path without explicitly stating the function of listing ad accounts. The title provides the purpose, but the description fails to add any value.

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 the many sibling tools like ad_account_get, campaigns_list, etc. The description gives no context about prerequisites or 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?

No annotations provided, and the description does not disclose behavioral traits such as error handling, rate limits, or what happens if the ID is invalid. It only implies a 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 extremely short but not concise in a helpful way; it lacks essential details and is underspecified for a tool with two parameters.

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

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

With no output schema, no annotations, and no explanation of parameters or return value, the description is completely inadequate for an agent to correctly invoke or interpret the tool.

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

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

Schema description coverage is 0%, and the description does not explain the parameters ('id' and 'fields'). The agent is left guessing what 'fields' means or what valid values are.

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 'GET /{creative_id}.' merely states the endpoint, which is a tautology with the title 'Get one ad creative'. It does not explain what an ad creative is or what the tool does beyond an HTTP method.

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

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

No guidance on when to use this tool versus siblings like 'adcreatives_list' or 'campaign_get'. It does not specify that it is for a single creative by ID vs listing.

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, and the description minimally indicates it's a GET request (read operation), but does not disclose any behavioral traits such as rate limits, pagination behavior, or data scope. The agent has no insight into side effects or constraints.

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 brief but not concise in a helpful way; it omits critical information. Every sentence should earn its place, but this single sentence provides minimal value and could be expanded significantly.

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 complexity of 5 parameters, no output schema, no annotations, and many sibling tools, the description is severely incomplete. It does not explain return values, pagination, or how it differs from similar list tools, leaving the agent underinformed.

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%, meaning no parameter descriptions in the schema. The description adds no information about parameters (e.g., account_id format, fields usage, limit behavior), so it fails to compensate for the lack of schema documentation.

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 is just the endpoint path 'GET /act_{id}/adcreatives.' which barely adds any meaning beyond the title 'List ad creatives under an ad account.' It does not explain what ad creatives are or what listing entails, making it only slightly better than a tautology.

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 sibling tools like adsets_list or campaigns_list. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision-making support.

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?

Without annotations, the description must convey behavioral traits, but it only provides the HTTP method and path. No mention of pagination, filtering behavior, error handling, or rate limits.

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 concise but under-specified. It front-loads the URL structure but omits necessary details. Appropriate length for what it contains, but not optimally helpful.

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 7 parameters, nested objects, no output schema, and no annotations, the description is severely incomplete. An agent would lack critical information to use the tool correctly.

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

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

Schema coverage is 0%, and the description adds no semantics for parameters like fields, filtering, effective_status, limit, auto_paginate, or max_pages. Only the parent parameter is partially explained via URL path.

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 HTTP method (GET) and resource (adsets) with specific path construction for two parent types. It distinguishes from sibling tools like ads_list, campaigns_list, etc.

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 on when to use this tool compared to alternatives. The description only explains URL structure without context on selecting parent type or other usage notes.

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 provided, so description carries full burden. It only reveals the HTTP method and path construction, but omits behavioral traits like pagination (auto_paginate, max_pages), rate limits, or side effects. Agent cannot infer safety or performance characteristics.

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?

Very concise single sentence with a mapping table. Front-loaded with HTTP method and path. However, could include more info without adding much length (e.g., brief parameter hints).

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 7 parameters, nested objects, no output schema, and no annotations, the description is insufficient. It does not explain return format, how to handle pagination, or provide examples. Agent would struggle to use this tool effectively without additional documentation.

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 description should explain parameters beyond parent. It does not describe fields, filtering, effective_status, limit, auto_paginate, or max_pages. While some are self-explanatory, filtering and effective_status need context for correct 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 the tool lists ads via a GET request and explains how the parent.type parameter selects the API path (account, campaign, adset). This distinguishes it from sibling tools like adsets_list and adcreatives_list.

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

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

No guidance on when to use this tool vs. alternatives. No mention of when to prefer other tools like ad_accounts_list or adsets_list. The description only provides path mapping, not 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, and the description only gives an HTTP method and endpoint. It does not disclose any behavioral traits such as read-only nature, rate limits, or side effects.

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

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

The description is extremely short but under-specified. It is concise at the expense of clarity, lacking essential context and earning its place only as a placeholder.

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 no output schema and no annotations, the description should explain return values and behavior, but it provides none. The tool's simplicity is not an excuse for omission.

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?

Both parameters (id and fields) are undocumented in the schema and description. The description adds no meaning about what id represents or how to use the fields 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 'GET /{campaign_id}.' is extremely vague and almost a tautology. It does not state what a campaign is or what retrieving it accomplishes, nor does it distinguish from siblings like campaigns_list.

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

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

No guidance on when to use this tool vs alternatives (e.g., when to fetch a single campaign vs listing all campaigns). No prerequisites or usage context 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?

No annotations are provided, and the description lacks any behavioral details such as pagination, filtering support, rate limits, or side effects. The agent is left to guess from parameter names.

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 short but at the expense of utility. It is not front-loaded with helpful information and fails to earn its place by providing value beyond the endpoint template.

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 7 parameters, no output schema, and no annotations, the description is severely incomplete. Critical details about return values, default behavior, and parameter semantics are absent.

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 adds no information about parameters. The agent must rely solely on parameter names and types, which is insufficient for proper invocation.

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 'GET /act_{id}/campaigns' which indicates listing campaigns, matching the tool name and title. However, it is minimal and does not elaborate on the scope or distinguish from sibling tools like 'campaign_get' or 'adsets_list'.

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

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

No guidance on when to use this tool versus alternatives. Sibling tools exist for related operations, but the description provides no context for selection.

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

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

With no annotations, the description covers key behavioral traits: the endpoint's authentication method (APPID|APPSECRET as access_token), the effect of omitting input_token, and the return fields. It does not mention read-only nature, but that is implied.

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 effective sentences with no fluff. Information is front-loaded, starting with the HTTP method and endpoint, then listing return fields and special behavior.

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 no output schema, the description adequately lists the return fields. It covers the core functionality and authentication context. Could mention error handling for invalid tokens, but not essential.

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%, but the description adds meaning to the parameter 'input_token' by stating it is optional and defaults to the server's configured token. This supplements the empty 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 clearly states the tool inspects a Meta access token and lists the returned fields (token type, app_id, expires_at, scopes, is_valid). It distinguishes from sibling tools which focus on ads, pages, Instagram, WhatsApp, etc.

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

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

The description explains when to use (to inspect a token) and the behavior when input_token is omitted. It also notes the requirement for FB_APP_ID and FB_APP_SECRET. It lacks explicit alternatives or when-not-to-use, but the sibling tools serve different purposes.

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?

Discloses read-only nature (Always GET), path constraints, and version stripping behavior. No annotations provided, so description carries burden well, though could mention error handling or response format.

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

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

Three sentences, front-loaded with 'Escape-hatch', no wasted words. Each sentence adds meaningful constraint or usage guidance.

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

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

Fairly complete given no output schema and many siblings: it defines purpose, constraints, and usage context. Lacks explicit description of return value but raw GET implies raw response.

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 has 0% description coverage, so description must compensate. For 'path', it adds syntax and constraints (starting with '/', safe characters, version stripping). For 'params', it only describes it as an object with no further detail, leaving ambiguity.

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?

Clearly states it is a raw GET to any Graph API endpoint, acting as an escape-hatch. Distinguishes from siblings by specifying it is a fallback when no specialized tool fits.

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 states when to use ('use only when no specialized tool fits') and provides constraints on path format (must start with '/', safe characters, version stripping). Implicitly indicates not to use if a specialized tool exists.

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 fully disclose behavior. It explains the authentication mechanism and the nature of the id parameter, but does not describe the return data or any side effects, which is a 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 description is concise with two sentences, front-loads the endpoint, and adds critical notes without fluff.

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 incomplete for a tool with no output schema and no annotations. It fails to mention what the response contains, error conditions, or any pagination details, leaving the agent underinformed.

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 explains ig_user_id and via_page_id, but the 'fields' parameter is left undocumented, leaving part of the meaning unclear.

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 retrieves an Instagram Business/Creator account via GET endpoint, and the note about ig_user_id vs username adds specificity. However, it does not explicitly distinguish from sibling tools like ig_media_get beyond context.

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

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

The description explains the prerequisite of obtaining ig_user_id from a linked Facebook Page and the need for a Page Access Token, but it lacks guidance on when not to use this tool or comparison to 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?

No annotations are provided, and the description only implies GET behavior via the endpoint string. It does not disclose pagination behavior (auto_paginate, max_pages), rate limits, or auth details beyond user_id. Minimal transparency for a tool with 7 parameters.

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

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

The description is very short (one sentence), but it is underspecified rather than efficiently concise. It could include key behavioral details without being much longer.

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 7 parameters, 3 required, no output schema, and high complexity (pagination, enum kind), the description is severely incomplete. It lacks any explanation of return values, pagination logic, or the difference between top and recent media.

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 compensate. It only mentions hashtag_id (via the path) and user_id, and indirectly kind ('top_media or recent_media'). It adds no meaning for fields, limit, auto_paginate, or max_pages, leaving 5 of 7 parameters undocumented.

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 'GET /{hashtag_id}/top_media or /{hashtag_id}/recent_media', which clearly identifies the tool as retrieving hashtag media for top or recent categories. It distinguishes from siblings like ig_hashtag_search, but does not explain the difference between top and recent 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 notes that 'user_id is required by Meta', providing a context-specific requirement. However, it offers no guidance on when to use this tool versus alternatives (e.g., ig_media_list), nor any exclusions or complementary 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?

No annotations are provided, so the description must disclose behavior. It clarifies the HTTP method (GET) and the user_id distinction, but lacks details on rate limits, error conditions, or scope limitations.

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

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

Two short sentences with no redundancy. Every word adds value: the API endpoint, parameters, purpose, and a critical distinction about user_id.

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 tool's simplicity (2 params, no output schema), the description covers purpose, result, and parameter specifics. Minor gaps like pagination or error handling do not significantly detract from 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?

Schema description coverage is 0%, so the description compensates by explaining 'q' is the search query and 'user_id' is the IG Business Account id, adding meaningful context beyond the raw schema.

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

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

The description clearly states the verb 'Search Instagram hashtag' and the resource 'hashtag_id', and explicitly distinguishes it from sibling 'ig_hashtag_media' by noting the output is used by that 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?

The description implies usage context by referencing 'ig_hashtag_media' but does not explicitly state when to use this tool vs alternatives, nor provides exclusions or when-not-to-use guidance.

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

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

No annotations are present, so the description must disclose behavioral traits. It only states the HTTP method, implying read-only, but does not mention auth requirements, rate limits, or what happens on error.

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 short but under-specified rather than concise. It lacks necessary detail for a 4-parameter tool, making it incomplete.

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

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

With no output schema, no annotations, and no parameter descriptions, the description is completely insufficient. An agent cannot understand input requirements or expected output.

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%, yet the description does not explain any of the four parameters (media_id, via_page_id, fields, locale). The agent has no guidance on what values to provide.

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 combination of the title 'Get one IG media item' and description 'GET /{media_id}.' clearly indicates the tool retrieves a single media item by ID. However, it does not differentiate from sibling tools like ig_media_list.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools such as ig_media_list and ig_media_insights exist but are not mentioned or contrasted.

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 provided, so description carries full burden. It discloses that metric set depends on media_type and lists specific metrics per type. However, it omits behavioral details like rate limits, required permissions, error scenarios (e.g., invalid media_id, unsupported media type), or whether results are aggregated or per post.

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

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

Concise and front-loaded with the endpoint. Lists metric sets clearly, but could benefit from bullet points for readability. No wasted words.

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

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

Given no output schema, description is moderately complete for typical use cases. It explains metric variability but lacks parameter semantics, usage context, and error handling. For a tool with 3 required params and complexity, more detail is needed.

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% (no parameter descriptions), so description must compensate. It adds value by listing possible metric values per media type, but does not explain the purpose of media_id, via_page_id, or how to use the metric array (e.g., can request a subset, must match media type). Incomplete guidance for a 3-param 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 states it retrieves insights for an Instagram media item via GET endpoint, and specifies the metric sets for different media types (IMAGE/CAROUSEL_ALBUM, VIDEO/REELS, STORY). This distinguishes it from sibling tools like ig_media_get (metadata) and ig_user_insights (user-level 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?

No guidance on when to use this tool vs alternatives like ig_user_insights or page_insights. Does not mention prerequisites (e.g., media must belong to a business account, token requirements) or when not to use it.

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

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

With no annotations, the description must disclose behavioral traits. It does not indicate whether the operation is read-only, what the response format is, how pagination works, or any side effects. The existence of auto_paginate and max_pages parameters is not explained.

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 short but fails to convey necessary information. It is under-specification, not conciseness. The single sentence does not earn its place as it provides no value beyond the endpoint.

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 6 parameters (2 required), no output schema, and no annotations, the description is completely inadequate. It does not explain return values, pagination behavior, or any constraints, leaving the agent with no actionable understanding.

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 adds no meaning to any of the 6 parameters. The description does not mention parameter names or their roles, leaving the agent to infer nothing from the 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?

Description is merely the endpoint path 'GET /{ig_user_id}/media.' This is a tautology that adds no information beyond the tool name and title. It does not state what the tool does—it lacks a specific verb like 'list' or 'retrieve' and does not clarify that it returns media posts.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., ig_media_get for a single media, ig_hashtag_media for hashtag-based search). The description does not mention prerequisites, context, or 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?

No annotations provided; the description only mentions period is required and lists metrics, but lacks disclosure of rate limits, pagination, auth needs, or data 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 short and front-loaded but too terse; it conveys essentials but lacks depth without being overly verbose.

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 6 parameters, no output schema, and no annotations, the description is insufficient; it omits return format, pagination, and request construction details.

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

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

With 0% schema coverage, the description should detail each parameter; it only addresses period and metric, leaving via_page_id, since, until 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 clearly states the tool is for GET /{ig_user_id}/insights, lists common metrics, and distinguishes from media-level or generic insights 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 for Instagram user insights but does not explicitly state when to use vs alternatives or provide exclusion criteria.

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 describes the tool as 'read-only' and clarifies it does not support async jobs. It also explains that object_id can be prefixed if numeric. This provides sufficient behavioral context for a read operation. A minor gap is the lack of detail on rate limits or response format, but the core safety profile 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 only 4 sentences, all front-loaded with the most critical information: the HTTP method, sync-only nature, and object_id/level requirements. Every sentence serves a purpose without redundancy.

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

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

Given the tool's complexity (12 parameters, no output schema), the description adequately covers core concepts (object_id, level, common fields, sync limitation) but omits details on many advanced parameters and return value structure. For a Meta Insights API, experienced users may find it sufficient, but novices would need more 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?

The input schema has 12 parameters with 0% description coverage. The description adds value by explaining object_id (prefix logic), level (must match), and lists common fields (spend, impressions, etc.). However, it does not describe time_increment, breakdowns, filtering, pagination parameters, or other nuanced options. Given the low schema coverage, the description partially compensates but leaves significant gaps.

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 the 'GET /{object_id}/insights' endpoint for retrieving ads insights synchronously. It distinguishes itself from the async alternative by explicitly saying the server does not support async for huge date ranges, thus clarifying its scope.

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

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

The description provides explicit guidance on when to use this tool: for sync requests and for objects like account, campaign, adset, or ad with a matching level. It also specifies when not to use it (for huge date ranges where async is recommended) and mentions that the read-only server does not support the async flow.

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, and the description does not disclose behavioral traits like authentication requirements, rate limits, or destructive effects. The minimal description fails to inform the agent about what happens when the tool is invoked.

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 concise at 7 words, but this conciseness comes at the cost of completeness. It is front-loaded with the endpoint, but lacks essential details.

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

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

Given the tool has 3 parameters with no descriptions, no output schema, and no annotations, the description is severely incomplete. It does not cover return values, error handling, or usage context, making it inadequate for an agent to use 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 input schema has 0% description coverage, and the description adds no meaning beyond property names. 'fields' and 'locale' are not explained, leaving their purpose and format unclear.

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 'GET /{page_id} — page metadata' clearly states the verb (GET) and resource (page metadata), and distinguishes from siblings like 'pages_list' and 'page_posts' by focusing on a single page. However, it does not explicitly differentiate 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?

No guidance provided on when to use this tool versus alternatives such as 'pages_list' or 'page_insights'. The agent has no context for appropriate selection.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions HTTP method and token requirement, but omits details on response structure, pagination, rate limits, or error handling. For a tool with no annotations, this is somewhat incomplete.

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 concise with no extraneous words. It front-loads the endpoint and token requirement, then quickly covers key parameters. Every sentence adds value.

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

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

With no output schema and no annotations, the description leaves out return value details and error cases. For a 5-parameter tool, it covers input semantics adequately but misses output expectations, which is a gap for the agent to fully understand the tool's usage.

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 compensates by explaining the 'metric' array, 'period' default, and formats for 'since' and 'until'. It adds meaning beyond the schema's property names and types, though 'page_id' is not elaborated beyond the endpoint path.

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 is a GET endpoint for page insights, mentioning metric names and period. However, it does not explicitly differentiate from sibling tools like 'insights' or 'ig_user_insights', which serve similar purposes for different contexts.

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 includes prerequisites (Page Access Token, automatic resolution) and usage details (metric array, period defaults, date formats). But it does not explicitly state when to use this tool over alternatives, though the name strongly implies Facebook page 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 must disclose behaviors. It mentions 'paged by created time' for the default edge, but does not explain pagination behavior (auto_paginate, max_pages), authentication needs, rate limits, or response structure. The transparency is adequate but missing key details.

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 sentence plus a list of edge options. It is concise and front-loaded with the default edge. However, a bulleted list for edges would improve scannability. Overall, it earns its place without wasted words.

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

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

Given the complexity (8 parameters, no output schema, no annotations), the description is incomplete. It does not cover return format, authorization, pagination behavior, or most parameters. The edge differentiation is useful, but the agent needs more context to use all parameters correctly.

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

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

Schema coverage is 0%, so the description should explain all parameters. It only covers the 'edge' parameter with enum values. Parameters like page_id, fields, since, until, limit, auto_paginate, and max_pages are not described, leaving the agent to guess their purpose.

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 lists posts on a Facebook Page and distinguishes multiple edge types (published_posts, posts, feed, tagged), each with a brief explanation. This differentiates it from sibling tools like post_get and post_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 explains each edge option and what content it returns, guiding the agent on when to use which edge for different post types. It lacks explicit prerequisites or when-not-to-use guidance, but the edge descriptions are sufficient for most use cases.

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, description carries full burden. Discloses it's a GET request and returns access_token, a key behavioral detail. Lacks mention of pagination or auth, but sufficient for a simple 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?

Single sentence front-loaded with HTTP method and purpose, no wasted words.

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

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

Tool has 2 simple parameters and no output schema; description adequately conveys its role as a discovery tool within a family of Page tools. Could mention pagination but not critical.

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% (no descriptions on parameters). Description does not explain the 'fields' array or 'limit' integer, failing to compensate for missing schema documentation. Only implies output fields but not how to customize.

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?

Clearly states the verb (GET/List), resource (Facebook Pages), and outcome (returns id, name, access_token). Distinguishes from siblings by noting it's the first step to discover page_id for other Page 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?

Explicitly says 'Run this first to discover page_id values for other Page tools', providing clear when-to-use guidance and establishing it as a prerequisite.

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 full burden. It only implies a read operation via the GET method but lacks details on permissions, rate limits, or pagination behavior. The description is insufficient for a 7-parameter tool.

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

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

The description is extremely short but under-specified. It lacks critical details and is not appropriately concise for a tool with 7 parameters and no annotations.

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

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

Given the complexity (7 parameters), absent output schema, and no annotations, the description is severely incomplete. It fails to explain return values, parameter usage, or any context needed for effective tool invocation.

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

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

Schema coverage is 0% and the description does not explain any parameter's meaning, including the required 'post_id' and 'via_page_id' or optional ones like 'fields' and 'order'. The description adds no value beyond the schema.

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

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

The description 'GET /{post_id}/comments.' minimally states the HTTP method and endpoint, but does not explicitly state that it lists comments on a post. It is a tautology of the name and title without adding new information or differentiating 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?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternative comment-related tools or other list tools, leaving the agent without 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, the description carries the full burden. It correctly implies a read operation via GET, but does not disclose idempotency, potential rate limiting, or any security considerations beyond token usage. It is adequate but minimal.

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 redundancy. The first sentence states the HTTP method and endpoint, the second explains the ID format and authentication. It is efficient, though could be slightly expanded without becoming verbose.

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

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

For a 3-parameter tool without output schema, the description covers identification and authentication. However, it omits the optional 'fields' parameter entirely and does not describe the response format. Given the simplicity, it is partially complete but leaves 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 has zero descriptions, so the description must compensate. It explains the post_id format (composed of page_id and post_id) and the via_page_id as the token source. The optional 'fields' parameter is not described, but the two required parameters are well explained.

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 'GET /{post_id}' and explains the ID format, distinguishing it from sibling tools that handle ads, pages, or other resources. It specifies exactly what resource is retrieved: a single Facebook 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 provides context on when to use this tool (to get a single post) and explains the post ID format and token requirement. However, it does not explicitly state when not to use it or mention alternatives like page_posts for listing.

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 bears full responsibility for behavioral disclosure. It indicates a read-only GET operation but does not mention authentication needs, rate limits, pagination, or whether the request is idempotent. The description provides minimal behavioral context beyond the endpoint.

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, consisting of a single sentence that packs the endpoint, parameters, and data type. No superfluous words. The structure front-loads the key information, making it easy 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?

Given the lack of output schema, the description does not explain the return format or what the analytics data looks like (e.g., a list of objects, aggregated counts). It also omits error handling, potential response sizes, and the behavior of optional parameters. The tool has 6 parameters with 4 required, but the description provides insufficient context for effective use.

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 add meaning. It explains that start and end are Unix timestamps in seconds, and implies phone_numbers and country_codes are filters ('by phone number, by country'). However, it does not describe waba_id, granularity options (HALF_HOUR, DAY, MONTH), or the effect of these filters. The endpoint format adds some context but leaves significant gaps.

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 retrieves WhatsApp Business analytics messages sent/delivered/read by phone number, by country, etc., and provides the endpoint format. It specifies the resource ('analytics') and action (GET), distinguishing it from sibling analytics tools that target other platforms (e.g., insights, page_insights). However, it lacks detail on the response structure, which could improve clarity.

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 guidelines are provided for when to use this tool versus alternatives like insights or page_insights. The description does not mention prerequisites, such as requiring a WhatsApp Business Account ID, or note constraints like date range limits. There is no guidance on when not to use it.

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

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

No annotations exist, so description bears full burden. It only states it returns WABAs but omits traits like read-only nature, required permissions, error handling, or pagination 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?

Two sentences, efficient and front-loaded with the main action. Could be improved by adding parameter descriptions.

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 no output schema and 3 parameters, the description lacks essential context: no mention of return format, pagination, field selection, or default limit behavior.

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

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

Schema coverage is 0% and description only mentions business_id. No explanation for fields array or limit parameter, leaving the agent uninformed about their 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?

Description clearly states HTTP GET method, resource path, and that it returns WABAs owned by the parent Business. Distinguishes from siblings like wa_phone_numbers and wa_analytics by focusing on owned 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?

Hints at finding business_id via Business Manager or /me/businesses, which is helpful. However, no explicit guidance on when to use this vs alternative WhatsApp tools or exclusion conditions.

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

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

No annotations exist, and the description only provides the endpoint. There is no disclosure of error behavior, rate limits, or pagination behavior despite relevant parameters. The description fails to inform the agent about side effects or constraints.

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 short sentence, but it is under-specified rather than concise. It provides minimal actionable information and omits essential details.

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

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

With 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the return format, pagination, or any other behavioral aspects needed for proper 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 does not mention any parameters or their meanings. The agent must rely solely on parameter names, which is insufficient for correct 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 states the HTTP method and endpoint, which implies listing message templates under a WABA, but it does not explicitly state the action 'list' or clarify the scope. The title provides better clarity, but the description alone is vague.

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 like wa_template_get. The description lacks any context for selection.

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

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

No annotations. Description specifies returned fields but does not explicitly state read-only nature or any behavioral constraints. Adequate for a simple GET.

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?

Extremely concise, front-loaded with path and key fields. No wasted words, but could be better structured with parameter explanations.

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

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

No output schema, so description partially compensates by listing returned fields. Missing details on error handling or optional parameters like 'fields'.

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%. Description only mentions phone_number_id via path, and does not explain parameters like 'fields' array. Fails to add meaning beyond 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?

Description clearly states verb (GET), resource (phone number), and specific returned fields. Title reinforces singular retrieval, distinguishing it from wa_phone_numbers list.

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

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

No explicit when/alternatives guidance, but sibling tool wa_phone_numbers implies this is for single phone number, making usage clear implicitly.

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, and the description only states the HTTP method (GET). It does not disclose permissions, rate limits, pagination, or any side effects, leaving the agent uninformed.

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 too short and under-specified. It provides no more value than the endpoint string itself, failing to earn 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?

With no output schema and no context about return values or pagination, the description is completely inadequate for a listing operation. The agent cannot determine how to handle the response.

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 adds no meaning to the two parameters. The 'fields' parameter is left completely undefined, which may confuse the agent.

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

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

The title clearly states 'List phone numbers under a WABA', which indicates the tool's purpose. However, the description only repeats the endpoint without distinguishing it from the sibling tool 'wa_phone_number_get'.

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 like 'wa_phone_number_get'. The description lacks context for agent decision-making.

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

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

The description indicates a read operation via 'GET', but no annotations are provided to confirm safety or side effects. No behavioral traits such as authentication requirements, response format, or potential errors are disclosed. The minimal information is insufficient for an agent to understand the tool's 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 extremely short (one line), but it is under-specified rather than concise. It does not earn its place as it merely restates the tool's purpose without adding value. Considerable context is missing, reducing its effectiveness.

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 absence of output schema and annotations, the description should provide more context about return values, usage scenarios, and parameter details. It fails to do so, making the tool definition incomplete for safe and 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 only mentions 'template_id' implicitly via the path. The 'fields' parameter is not explained at all. The description adds no meaning to the parameters beyond their names, leaving the agent to guess their purpose and acceptable values.

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

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

The description 'GET /{template_id}' clearly states the action (GET) and resource (a template by ID). It is not a tautology as it adds the HTTP method, but it does not distinguish from sibling tools like 'wa_message_templates' which likely lists templates. The name and title already convey the purpose, so the description adds minimal additional clarity.

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. There is no mention of prerequisites, limitations, or when not to use it. The description lacks any usage context, leaving the agent without direction on appropriate invocation scenarios.

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