Open MCP Servers

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.2
Disambiguation4/5
Tools are organized by platform and resource, and even the many list/get variants have descriptions that clarify their scope. A handful of similarly named retrievers—like meta_get_posts vs. meta_get_published_posts and meta_get_instagram_media vs. meta_get_instagram_single_media—require careful reading, but no tools are true duplicates.
Naming Consistency4/5
The dominant meta_verb_noun and threads_verb_noun pattern is clear and predictable across nearly all tools. Minor inconsistencies such as meta_get_instagram_media being a list operation rather than a single-item getter, and mixing create/publish verbs for content creation, prevent a perfect score.
Tool Count1/5
200 tools is an extreme count that far exceeds any reasonable MCP server scope. Even for a broad Meta API wrapper, the sheer number creates significant selection overhead and makes it difficult for an agent to reliably choose the right tool.
Completeness4/5
The surface covers Facebook Pages, posts, messaging, Instagram publishing, comments, DMs, ads, audiences, pixels, Threads, and product catalogs in impressive depth. Minor lifecycle gaps remain—such as no update for ad rules or saved audiences, no catalog creation, and no Instagram media editing—but agents can generally work around them.
Average 3.7/5 across 189 of 200 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds no behavioral context such as pagination, permissions, or response format. It doesn't contradict annotations, but it adds nothing beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with one sentence and an Args section, but the Args section duplicates schema information and is unnecessary. It's concise but not well-structured as it repeats parameters. It's acceptable but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 1 required, no output schema. The description provides minimal info: it lists saved audiences for an ad account, but doesn't explain pagination parameters, result format, or any notes on return structure. Given the read-only nature and lack of output schema, more detail on what is returned would be helpful. It's incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only response_format has description). The description only mentions ad_account_id, which is obvious from the name. It doesn't explain 'after' (pagination cursor), 'limit' (page size), or 'response_format' as the schema does for the latter. The description fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'saved audiences (targeting presets)' for an ad account, distinguishing it from create/delete saved audience tools. However, it doesn't explicitly differentiate from other list tools like meta_list_custom_audiences, but 'saved audiences' is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention other audience tools or provide context like 'use this for read-only retrieval' or 'if you need custom audiences, use meta_list_custom_audiences'. The description only states purpose, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-idempotent action. The description only restates 'Creates' without adding details about required permissions, potential errors, response shape, or consequences of repeated calls. It provides no behavioral context beyond what is already implied by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the action, but it includes a redundant 'Args:' listing that duplicates the schema's parameter definitions. This structure is functional but could be clearer; it is not overly verbose but also not optimally streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with a nested targeting object and no output schema, this description is incomplete. It doesn't explain what a saved audience is used for, the expected fields of the targeting object, the return value (e.g., created audience ID), or any constraints. An agent would need to consult additional resources or infer from naming to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameters with generic labels like 'Ad account ID' and 'Audience name', which add little over the schema. The 'targeting' parameter is described only as 'Targeting spec object', leaving the complex structure undocumented. With schema coverage at 50%, the description should compensate but does not, leaving the agent without necessary details for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates) and the resource (saved audience), and even clarifies 'reusable targeting preset'. It distinguishes the tool from siblings like meta_create_custom_audience by naming the specific resource type, though it doesn't explicitly contrast it with alternative audience types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as meta_create_custom_audience or meta_create_lookalike_audience is provided. The description doesn't mention any conditions, prerequisites, or when not to use it, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context—it doesn't mention side effects, authentication requirements, rate limits, or what happens when the ad doesn't exist. Given the presence of annotations, a 2 is appropriate because the description contributes almost nothing beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and avoids verbosity, but it is under-specified. The main sentence is clear, and the args list is minimal. However, it lacks any additional structure to guide usage, such as examples or expectations. It's concise but not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description is minimal. It doesn't explain what 'detailed information' includes, so an agent doesn't know what fields to expect. With many sibling tools (meta_get_ad_rule, meta_get_ad_creative, etc.), the description doesn't help disambiguate. There is no output schema, so the description should clarify the return content but doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% because ad_id lacks a description in the schema. The description adds 'Ad ID' for ad_id, which is redundant with the parameter name and provides no semantic depth (e.g., format, example, source). For response_format, the schema already has a full description, and the tool description adds nothing extra. With low schema coverage, the description should compensate more but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets detailed information about a specific ad.' This is a specific verb and resource. However, it doesn't differentiate itself from sibling tools like meta_get_ad_insights or meta_get_ad_preview, which also fetch ad-related data. The term 'detailed information' is vague and could overlap with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as meta_list_ads, meta_get_ad_insights, or meta_get_ad_preview. No context about prerequisites, typical use cases, or how it differs from other ad-related fetch tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations, which already declare readOnlyHint and idempotentHint. It does not mention return format, pagination, permissions, or any side effects. The statement 'Gets details' simply reaffirms the read-only nature already captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the purpose in the first sentence. However, the Args section is redundant and contains the incorrect parameter values, which detracts from its efficiency. It still earns a 4 for overall conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool and read-only annotations, the description is mostly adequate but incomplete. It lacks explanation of what 'details' means, does not clarify the response_format values correctly, and does not describe the return value, which is especially important since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description incorrectly specifies response_format values as 'json' or 'text', while the input schema enum is ['markdown', 'json']. This is a factual error that could lead an agent to pass an invalid value. The 'pixel_id' description 'Pixel ID' adds no meaningful info beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Gets details for a single Meta Pixel.' It clearly distinguishes from list-type siblings by saying 'single.' However, it does not explicitly distinguish from get_pixel_stats or other detail-oriented tools, leaving some ambiguity about what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as meta_list_pixels or meta_get_pixel_stats. The description only states what it does; the agent must infer usage from the tool name and sibling context, which is insufficient for complex decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已声明 destructiveHint=true，而描述只重复了“deletes”这一基本行为，没有增加任何额外的行为特征，例如删除是否不可逆、是否影响关联的广告活动或是否触发级联删除。在已有注解的情况下，描述未提供增值信息，仅与注解保持一致。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述非常简短，一句核心功能加上一个简单的参数说明，没有冗余内容。结构上可直接扫描，但 Args 部分与schema信息重复，略有冗余，不过整体仍算高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于破坏性操作，即使有注解，描述仍缺乏完整上下文：未说明返回值、权限要求、操作是否可逆或需要哪些前置条件。虽然工具简单，但正因为操作不可恢复，应至少提供警告或后续操作指引，因此不完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema的描述覆盖率为0%，描述中的 Args 部分补充了 audience_id 是“Saved audience ID”，这比schema本身多了一点语义。但该信息基本可以从参数名和工具名推断出，未说明ID格式、如何获取或必须存在的上下文，因此补偿不足。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以明确的动词和资源开头：“Deletes a saved audience”，清楚说明了操作对象。它能与兄弟工具（如 meta_delete_custom_audience、meta_delete_post）通过资源类型区分，但未提供任何超出标题的细节，因此略低于满分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有说明何时应该使用此工具，也没有提及与其他删除类工具的适用场景差异。仅凭“Delete Saved Audience”推断用途，但缺乏如“需要 audience_id，可从 meta_list_saved_audiences 获取”等使用引导，因此没有提供有效指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds no behavioral context beyond restating that it gets information. It does not disclose what data is returned, whether errors occur for invalid IDs, or how response_format affects output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and contains no filler. The Args list mostly mirrors the input schema, so it is concise but not information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description should explain what 'detailed information' includes and how response_format changes the result. It does neither, nor does it mention required permissions or behavior for invalid ad set IDs, leaving the tool under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only restates adset_id as 'Ad set ID,' adding little meaning beyond the schema. It does not mention response_format at all, and with 50% schema description coverage plus no output schema, it fails to compensate for the gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: it 'gets detailed information about a specific ad set,' which distinguishes it from listing, creating, updating, or deleting ad sets. However, it does not explicitly differentiate itself from sibling tools like meta_get_adset_insights, so the purpose is clear but not sharply separated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as meta_list_adsets, meta_get_adset_insights, or meta_get_ad. The phrase 'specific ad set' implies you need one ad set by ID, but no explicit usage context, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds little beyond restating the read operation; it does not disclose pagination behavior or whether replies are included, and it omits the 'after' cursor parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the key action before the arg list. The arg list partially duplicates schema constraints but is readable and useful; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, an agent still has no idea what the return shape is. The missing 'after' parameter, lack of reply-vs-top-level clarity, and absence of pagination or formatting guidance make the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for media_id ('Instagram media ID') and limit (max, range, default), but schema coverage is only 25% and the 'after' pagination parameter is entirely unexplained. It also fails to mention response_format, though the schema does describe that enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Gets comments on an Instagram media object.' This distinguishes it from siblings like meta_get_instagram_comment_replies and meta_get_post_comments, though it doesn't explicitly say it returns only top-level comments rather than replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. It doesn't mention that replies are handled by meta_get_instagram_comment_replies or how this relates to comment moderation siblings, so an agent must infer routing from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe, read-only operation. The description adds minimal behavioral context—'all available' implies a complete enumeration but doesn't mention pagination, response format, or error behavior. With annotations covering the safety profile, the description adds some value but not enough for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, fitting within a line or two. However, the 'Args:' section is redundant with the schema and only covers one parameter inaccurately; it doesn't front-load the most critical behavioral info (what the tool returns). It's concise but not optimally structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a read-only browse tool with no output schema, the description should explain the returned data format and any caveats (e.g., pagination, localization). None of that is present. The description only states the purpose and one parameter, leaving an agent uncertain about what to expect from the call. This is inadequate for a tool with three parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the description should compensate for the undocumented 'type' parameter. It lists the category types, but incorrectly includes 'adlanguage' which is not in the schema enum (adTargetingCategory, adcountry, adlocale). This mismatch could mislead an agent. Additionally, it says nothing about 'class' or 'response_format', leaving two parameters without added context. The description does not fully compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Browses all available targeting category types') and the resource (targeting categories for ad targeting). It distinguishes from the search tools by using 'browse' terminology, though it doesn't explicitly name an alternative. Sibling differentiation is implied but not explicit, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the search variants (e.g., meta_search_targeting_interests). The description only mentions 'for ad targeting' without specifying when browsing is preferred over searching or when to use the type parameter. This is a significant gap for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, implying a mutating operation (publishing). The description adds no additional behavioral context beyond that, such as authentication requirements, rate limits, or side effects like creating a new post. For a mutation tool with sparse annotations, the description should explain more, but it doesn't.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one clear sentence. However, it includes an 'Args' list that duplicates the schema parameters, adding redundancy without new information. The structure is acceptable but not optimally front-loaded; the core purpose is stated first, but the args list is unnecessary given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters but no output schema, and the description does not mention what the tool returns (e.g., post ID) or any error conditions. It also fails to mention three optional parameters (location_id, reply_control, response_format) that an agent might not discover without opening the schema. The description is incomplete for a publish operation with multiple options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so most parameters are already documented. The description adds the clarification that image_url must be 'Public URL of the image (JPEG or PNG)', which is a slight enrichment over the schema's 'Public image URL'. However, it omits location_id, reply_control, and response_format, which are covered by the schema. The added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Publishes an image post to Threads' with a specific verb and resource. It clearly distinguishes from text/video/carousel publish tools by mentioning 'image'. However, it doesn't explicitly say this is the tool to use for image posts only, though the name reinforces that. The purpose is clear but not exceptionally detailed beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like threads_publish_text, threads_publish_video, or threads_publish_carousel. It simply states what it does without any context about choosing it over siblings. An agent has no explicit direction on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a mutating (non-readOnly, non-idempotent) operation, and the description adds little beyond restating the action. It does not disclose side effects, permission requirements, video processing timing, or what the API returns. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The Args list is largely redundant with the schema, but it doesn't bloat the definition enough to hurt usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish operation, the core call is understandable, but the description omits the behavior of the response_format parameter and gives no indication of the call's return value or post-publishing result. There is no output schema to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), and the Args list partially compensates by clarifying page_id and emphasizing that file_url must be publicly accessible. However, title and description just restate their names, and response_format is completely absent from the description despite being a schema parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb and resource: 'Publishes a video post to a Facebook Page.' This clearly identifies the action and differentiates it from photo, live, reel, and story tools, though it doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over meta_create_post, meta_cross_post, meta_create_photo_post, or meta_publish_page_reel. There are no exclusions or selection criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Gets' is consistent but adds no new behavioral context (e.g., required permissions, error behavior, return structure). It adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The parameter list is redundant with the schema but doesn't harm clarity. It is short and efficient, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't describe what data is returned (fields, format, etc.) or mention the response_format parameter. It also doesn't clarify how this tool differs from meta_get_ad, leaving an agent under-informed. For a simple get, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only one parameter (response_format) with a description; creative_id lacks a schema description. The description's Args section repeats 'Creative ID' without adding insight into its meaning, source, or constraints. With 50% schema coverage, the description fails to compensate for the missing documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Gets detailed information about a specific ad creative', using a specific verb and resource. This distinguishes it from listing (meta_list_ad_creatives) and creation (meta_create_ad_creative), though it doesn't specify what 'detailed' includes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like meta_list_ad_creatives or meta_get_ad. It implies retrieval by ID but doesn't state conditions, exclusions, or how it differs from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description itself adds no behavioral context beyond the title. It does not mention how the response is structured, how response_format affects output, or any error or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded, but the 'Args' block largely duplicates the schema's existing parameter description and omits response_format. It is not harmful, but it does not add enough value to warrant a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get-by-ID operation, the annotations and full schema coverage provide a reasonable baseline. However, the description does not clarify what 'detailed information' includes, does not explain when to use response_format='json' versus 'markdown', and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters, so a baseline of 3 is appropriate. The description only restates campaign_id without adding new semantic detail, and it omits any mention of response_format despite that parameter existing in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Gets detailed information about a specific campaign.' This distinguishes it from list-style tools like meta_list_campaigns and from analytics tools like meta_get_campaign_insights, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as meta_get_campaign_insights or meta_list_campaigns. It only implies that a specific campaign_id is needed, and provides no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description does not add any behavioral context beyond a basic 'lists': it omits pagination (via 'after' parameter), response format options, or any note about result size or limitations. For a listing tool, pagination behavior is a significant missing disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the main purpose and listing parameters in a clear, readable format. It uses minimal words without unnecessary detail. However, it sacrifices completeness for brevity, missing two parameters entirely, though that is not a structural flaw per se.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple listing operation, but the description does not cover essential operational details like pagination (the 'after' parameter) or the output format control (response_format). With no output schema and low parameter coverage, an agent would lack key information needed to make correct calls, especially for paginated lists. The description is adequate for a first call but incomplete for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to page_id ('Facebook Page ID') and limit ('Max results (1–100, default 20)'), which are already partially documented in the schema (limit has default/min/max). It completely omits the 'after' parameter (used for pagination) and does not describe response_format, despite schema coverage being only 25%. The description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists photo albums on a Facebook Page' with a specific verb and resource, distinguishing it from sibling tools like meta_get_page_photos (which lists photos, not albums) and meta_get_page_videos. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to choose albums over photos or when pagination is needed. It simply states the function without any conditions, exclusions, or comparisons to sibling tools, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so safety is covered. However, the description adds minimal behavioral context beyond that—it does not mention pagination (despite an 'after' parameter), rate limits, or that only non-live videos are returned. There is no contradiction, but the description fails to add meaningful behavioral detail that the annotations do not already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences: a clear purpose statement and a parameter list. The purpose is front-loaded, and every word earns its place. No fluff or redundancy; ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and a simple listing operation, the description is under-specified. It does not explain the return format, whether results are paginated (despite an 'after' parameter), or how this differs from related tools like live videos or ad videos. An agent would lack enough context to call it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%—only response_format has a description). The description partially compensates by explaining page_id (Facebook Page ID) and limit (max results, 1–100, default 20). However, it does not address the 'after' parameter (likely for pagination) or the response_format (already covered in schema). It adds value for two of four parameters but leaves gaps that an agent must infer from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Lists videos uploaded to a Facebook Page.' It is specific enough to distinguish from many siblings, though it does not explicitly differentiate from other video-related tools such as meta_get_live_videos or meta_list_ad_videos. The purpose is unmistakable, but a slight nod to what it is not would elevate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It simply states what it does, with no mention of when not to use it (e.g., for live videos, ad videos, or Instagram media). Given the large sibling set, the absence of any selection criteria leaves the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds no additional behavioral detail such as return formatting, pagination, or rate limits. It merely repeats the intended action 'Lists' without supplementing the annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence and an 'Args' list. It is well-structured and front-loaded with the core purpose. No filler or redundancy. It could benefit from slight expansion, but for its simplicity it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does not explain what the tool returns (e.g., fields, format, or any filtering/pagination). It does not mention how response_format affects the output or any limitations. For a list operation, this is a significant gap—agents are left without knowing what to expect from the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (response_format documented). The description adds a brief label for ad_account_id ('Ad account ID') which is not in the schema, but this is trivial and does not explain format, validation, or usage nuances. The response_format parameter is left entirely to the schema, which already provides description. Overall the description contributes minimal value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'Lists' and resource 'custom conversions' for a specific scope 'ad account'. This distinguishes it from sibling tools like meta_create_custom_conversion (create vs list) and meta_list_custom_audiences (conversions vs audiences). The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of exclusions, prerequisites, or specific scenarios where this tool is preferred over siblings like meta_get_custom_audience or meta_list_custom_audiences. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. 'Publishes' implies a mutation, but it does not disclose permissions, rate limits, idempotency, or side effects beyond creating a story. The return of a Media ID is mentioned but does not convey behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear purpose statement, an Args list, and a Returns line. It is front-loaded and every sentence adds value, though the Args section could be integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publishing tool, the description covers the essential purpose, required parameters, and return value. However, it lacks context about prerequisites (e.g., needing a professional account, verifying media URL validity), potential errors, or limitations. The absence of an output schema makes the return description important, and it is present, but broader operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief semantic meaning for all three required parameters, matching the schema for media_url and media_type and adding a description for ig_account_id that the schema lacks. However, it does not elaborate on format requirements, allowed values beyond the enum, or how the media URL must be accessible. It omits the optional response_format parameter, though that is already explained by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (publishes), the resource (an image or video story), and the target (Instagram professional account). It is specific enough to distinguish from tools like photo or reel publishing by name and context, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 publishing tools (e.g., meta_publish_instagram_photo, meta_publish_instagram_reel, meta_publish_page_story). It does not mention prerequisites like account type or media URL requirements, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. It does not clarify whether this performs a partial update (leaving unspecified fields unchanged) or a full replacement, nor does it describe any side effects or requirements. Annotations already indicate idempotentHint and destructiveHint, so the description contributes nothing new, though it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary followed by an args list. The information is front-loaded and easy to scan. The args list is detailed but not excessively long for a tool with six parameters. It avoids unnecessary fluff and is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers most parameters. However, it lacks crucial context about update semantics (partial vs. full) and does not mention error conditions or prerequisites (e.g., pixel must exist). Since there is no output schema, the description could also explain what the response contains, but it does not. The description is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all parameters except response_format, and provides partial enum values and an example for automatic_matching_fields. This is valuable because schema coverage is only 17%, leaving most parameters without descriptions. However, it omits response_format entirely, which has a schema description, and it does not explain the meaning of fields like automatic_matching_fields—only provides an example. It is helpful but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Updates pixel settings' which is a clear verb (Updates) and resource (pixel settings). It is specific enough to distinguish from create/get/delete siblings, but does not explicitly name alternatives. For an agent, the verb 'updates' implies modification of an existing pixel, which is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for modifying existing pixel settings, nor any prerequisites like the pixel must exist. No alternative tools are referenced, and no conditions for use vs. non-use are given. The agent must infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already declare (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It does not disclose the default output format (markdown) or the option to request JSON, nor any rate-limit or pagination specifics. Since annotations cover the safety profile, the description's contribution is minimal, but it fails to mention observable behaviors like response format preference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two lines) and front-loads the purpose, but it is under-specified for a complete tool definition. It does not waste words, but it sacrifices necessary context (e.g., usage guidance, output behavior). It is efficient but not adequately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description is minimally complete: the schema covers response_format, annotations cover safety, and the description gives the essential identifier. However, it omits any mention of the return structure, error cases, or when to prefer this over threads_get_posts. Given that an output schema is absent, the description should provide more detail about what 'details' means, such as contents of a post object or example usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies media_id as 'Threads media ID', which is not described in the schema, providing some added meaning. However, it omits any mention of response_format, which the schema already documents with an enum and default. With 50% schema coverage, the description partially compensates but does not fully cover the parameters or explain how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Gets') and resource ('details for a single Threads post') with an identifier ('by ID'). It differentiates from siblings like threads_get_posts (plural) and threads_get_post_insights implicitly, but does not explicitly name alternatives or scope constraints. It is specific enough for an agent to understand its core function, though it could be sharper about what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that threads_get_posts should be used for listing multiple posts, nor any exclusions or prerequisites (e.g., needing a media_id from a prior call). The usage context is only implied by the singular/plural distinction in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive or idempotent. The description adds nothing about side effects, required permissions, rate limits, or visibility of the post (e.g., public to followers). It simply states what it does, which is largely evident from the name. No contradiction with annotations, but the description does not enrich behavioral understanding beyond the minimal facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with the purpose stated in the first sentence and parameters listed in a clear, readable format. It is front-loaded with the core function. However, it omits two parameters, which makes it incomplete but still concise. The structure is effective for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, but the description only mentions 3, leaving reply_control and response_format undocumented both in the description and (partially) in the schema. There is no output schema, so return format is unspecified. The description does not mention any behavioral nuances like authentication requirements, public visibility, or rate limit consumption. For a publish action, this is a significant gap—users need more context on how the post will be presented and what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers the three main parameters (threads_user_id, text, link_attachment) but adds limited meaning beyond the schema. It clarifies that 'text' contains the URL and that 'link_attachment' is the URL for the preview, which is slightly redundant with the schema's 'URL for link preview.' It omits the optional reply_control and response_format parameters entirely. Given schema coverage of 60% for these three, the description barely compensates for the missing two. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Publishes a thread post with a link attachment.' This specifies the verb (publishes), resource (thread post), and a distinguishing feature (link attachment) that differentiates it from other thread publish tools like threads_publish_text or threads_publish_image. However, it does not explicitly name sibling tools to reinforce the differentiation, 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.
Usage Guidelines2/5
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 the other publish variants (text, image, video, carousel, gif). The description does not mention conditions like 'use when you want to include a link preview' or point users to alternative tools for other post types. This leaves selection to inference from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'recent events' and 'for debugging' but discloses no additional behavioral traits such as pagination, result limits, or response structure. Given the annotation coverage, the lack of further description is partially acceptable, but the description still doesn't mention anything beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a minimal Args list. It is front-loaded with the core purpose and includes no fluff or redundant details. Every word earns its place, making this an example of efficient, well-structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what 'events' look like in the response (e.g., fields, time range, limits), but it doesn't. It also omits details like whether the events are a list or include metadata. For a debugging tool, the agent would benefit from knowing the response format and the meaning of 'recent'. The description is too sparse to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% because response_format has a full description, while pixel_id has none. The description's 'Args' section only repeats 'pixel_id (string): Pixel ID', which is essentially the parameter name and provides no additional meaning (e.g., where to find the pixel ID or expected format). The description does not compensate for the missing schema description, failing to enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets'), the resource ('recent events received by a pixel'), and the context ('for debugging'). It distinguishes itself from pixel-related siblings like meta_get_pixel and meta_get_pixel_stats by focusing specifically on events. However, it doesn't specify what constitutes 'recent' or the event types, leaving a slight ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'for debugging' as the use case, but provides no guidance on when to use this tool versus alternatives like meta_get_pixel_stats or meta_list_pixels. There is no explicit 'when to use' or 'when not to use' instruction, and no mention of alternatives. The agent must infer the intended usage from the tool name and sibling context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds useful context by disclosing the quota (250 posts per 24 hours) and the return shape (current usage and limit). No contradiction with annotations. It does not go deeper, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a single purpose sentence followed by Args and Returns. The purpose is front-loaded and there is no filler, though the Args block is somewhat redundant with the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only tool with no output schema, the description covers the essential contract (usage vs. quota). It is adequate but lacks guidance on when to check limits during a publishing workflow and does not mention how the response_format parameter affects output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 50%, the description was expected to compensate for the undocumented `threads_user_id`, but it merely restates the parameter name ('Threads user ID'), adding no meaning about how the ID should be obtained or formatted. The `response_format` parameter is described in the schema but not in the description, so total value added is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Checks') and resource ('publishing rate limit usage for Threads'), making the purpose immediately clear. The 'for Threads' qualifier distinguishes it from the closely related sibling meta_check_instagram_publishing_limit, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool, such as checking limits before publishing to avoid throttling, nor any reference to alternatives like meta_check_instagram_publishing_limit. The agent must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false), so the description does not need to repeat that. It adds minor context by mentioning the reverse parameter, but does not describe pagination, rate limits, or the exact structure of the returned replies. Given the annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one purpose statement plus a short args list. It is front-loaded and free of fluff, though it could be slightly more structured by including response_format in the args list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-replies tool, the description is minimally adequate but leaves gaps. It does not clarify whether 'replies' means direct comments on the post or nested replies, nor does it mention pagination or output format behavior beyond the schema's response_format description. Since the output schema is absent and annotations cover safety, a score of 3 reflects partial completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers media_id and reverse with brief explanations, but omits response_format entirely. Since schema description coverage is only 33% (only response_format has a description in the schema), the description should compensate by explaining all parameters. It fails to describe response_format, which is a significant gap, though the schema does include a description for it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it retrieves replies to a Threads post, using a specific verb and resource. It is distinct from sibling tools like threads_get_post or threads_get_conversation, though it does not explicitly differentiate or mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other similar Threads or Instagram tools, such as threads_get_media_children or meta_get_instagram_comment_replies. No exclusions or conditions are provided, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond the basic read operation, such as whether only currently-live broadcasts are returned, pagination behavior, or account access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and contains no unnecessary prose. The Args block is slightly redundant with the JSON schema, but it still adds a useful semantic for the required parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description gives the core purpose and the required parameter. However, it does not describe the shape/content of the returned live broadcasts, and it lacks any guidance for distinguishing it from similar live-video or Instagram-media tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents response_format but leaves ig_account_id as a bare string, and the description compensates by defining it as 'Instagram account ID.' This fills the key schema gap, though it does not explain how to obtain or format the account ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Gets live video broadcasts from an Instagram account.' This is specific enough to identify the tool's function, but it does not explicitly differentiate it from nearby siblings like meta_get_live_videos or meta_get_instagram_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as meta_get_live_videos or meta_get_instagram_media. The description only states what it does and never mentions exclusions or when a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's read-only nature is consistent. It adds the condition of multiple locations but doesn't describe return format, pagination, or other behaviors beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. The Args section is redundant with the schema but doesn't waste words. It is well-structured but could be improved by integrating parameter info more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, one required, the description omits the optional parameters. Without an output schema, it doesn't describe the return type. It's minimal but not complete for agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (response_format). The description only mentions page_id, ignoring limit and response_format. It doesn't compensate for the low coverage, offering minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists location pages for a business with multiple locations', which is a specific verb and resource. It is distinct from siblings like meta_get_page or meta_list_pages, though it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It suggests use when a business has multiple locations but doesn't mention alternatives or when not to use. No explicit exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, offering little behavioral context. The description only states that it creates a label and does not disclose whether duplicate labels are allowed, what side effects occur, or what authorization is needed, beyond the obvious write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a one-sentence purpose followed by a succinct argument list. Every line serves a purpose, and no unnecessary details are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description covers the object and both required parameters, but it omits return value details, behavior on duplicate names, and expected output. An agent could likely use it minimally, but more context would be needed to handle edge cases confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only response_format is documented), yet the description merely restates parameter names: 'ad_account_id (string): Ad account ID' and 'name (string): Label name.' This adds minimal meaning beyond the schema and lacks format constraints, examples, or parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and identifies the resource as 'a label for organizing ads, ad sets, or campaigns.' This clearly distinguishes it from sibling tools like meta_create_ad or meta_create_ad_rule, since the object is a label rather than an ad or rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 meta_list_ad_labels to read existing labels or meta_create_ad_rule for rule creation. There are no prerequisites, caveats, or preferred scenarios described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent mutation. The description confirms it creates a new resource and returns its ID, adding the prerequisite that it relies on an existing custom audience or page. It does not detail error conditions or side effects beyond creation, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the main purpose and then listing arguments in a clear, readable format. It avoids extraneous detail and includes a brief return statement, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all required parameters and the return value, but it does not explicitly differentiate this tool from sibling audience tools or mention the optional response_format. It also assumes knowledge of prerequisites without elaboration, leaving some context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to ratio (range and explanation), origin_audience_id (source), and country (examples), which are beneficial since the schema lacks descriptions for ad_account_id and name. However, it omits the optional response_format parameter, though that is covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a lookalike audience based on an existing custom audience or page, which is a specific and distinct action. It differentiates from sibling audience tools by the term 'lookalike', though the mention of 'page' is not fully reflected in the parameter description for origin_audience_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like meta_create_custom_audience or meta_create_saved_audience. It only describes what it does without specifying conditions, exclusions, or when to prefer it over other audience-creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns a paginated list with type, content, and timestamps, and mentions the pagination cursor, which clarifies the output shape. It doesn't discuss rate limits or auth, but for a read operation with these annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with Args and Returns sections, front-loading the core purpose. Every line adds information, with no fluff. It's slightly repetitive of the schema but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 output schema, the description explains inputs and return values well, but omits the response_format parameter which affects output shape. There's also no mention of when to use this over siblings, which is a minor gap in context. Overall, it's a functional but not comprehensive definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful detail for limit (range 1-100, default 20) which is not in the schema's description, and restates channel_id and after. However, it omits response_format, which is documented in the schema with a clear description. Since schema coverage is 75%, the description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Gets messages in an Instagram broadcast channel') that is unambiguous and distinguishable from related tools like conversation or post messages. It doesn't explicitly contrast with sibling tools, but the title and description are aligned, giving it a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative messaging tools such as meta_get_instagram_messages or meta_get_conversation_messages. It provides no context about selecting this over siblings, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by specifying required permission (instagram_manage_messages) and token type (user token vs page token), which are behavioral requirements the annotations don't convey. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear one-sentence purpose, a bulleted parameter list, and a final usage note. It front-loads the main purpose and is free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns and any pagination behavior. It only says it lists conversations, leaving the response structure to the agent's imagination. It also omits the response_format parameter from the parameter list, which affects output. While it includes permission and token details, the description is not complete enough for an agent to know what to expect from the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers 4 of 5 parameters, omitting response_format. It repeats defaults and enums that are already in the schema, adding little new meaning. Since schema coverage is 80%, the description should at least mention the missing parameter, but it doesn't. The added permission/token info is not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (lists) and resource (Instagram DM conversations), making its purpose unambiguous. It implicitly differentiates from page-level conversation tools, though it doesn't name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over alternatives, such as page conversation tools or message-level tools. It does state required permissions and token type, but these are usage constraints, not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so the description need not restate safety. It adds only that the returned data is 'detailed information' but does not disclose specific fields, auth requirements, or response behavior, leaving behavior somewhat underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action, followed by a compact Args list. It is efficient, though the Args section largely mirrors the schema and no Returns or error sections are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one required parameter and annotations that cover safety, so the description is close to adequate. However, there is no output schema and the description does not say what fields are included in 'detailed information' or how it differs from sibling getters, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents response_format (enum, default, description) but not media_id; the description fills the media_id gap with only 'Instagram media ID,' which is minimal. With 50% schema coverage, the description partially compensates but adds little beyond the property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Gets detailed information about a specific Instagram media object,' which is a clear verb+resource and 'specific' signals single-object scope. It does not explicitly name a sibling alternative, but the 'specific' wording and title distinguish it from list-style tools like meta_get_instagram_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of related media tools (e.g., meta_get_instagram_media, meta_get_instagram_media_insights, meta_get_instagram_media_children). There are no conditions, prerequisites, or exclusions, so an agent must infer usage entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds the specific return fields (name, category, follower counts, Instagram link) but does not disclose any additional behavioral traits like permission requirements, rate limits, or error behavior. Since annotations cover the safety profile, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and avoids redundancy. The 'Args' section is a minor structural oddity but still readable. Every sentence serves a purpose, and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only two parameters and no output schema, the description adequately conveys the return content. However, it lacks any mention of when to choose this tool over siblings and does not discuss potential errors or response format selection, leaving some gaps for an agent to discover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so page_id and response_format are already documented. The description simply repeats page_id's meaning without adding new context (e.g., how to obtain the ID, formatting constraints). The response_format parameter is not mentioned in the description, but it is fully defined in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets detailed information about a specific Facebook Page' and lists what data is returned. It distinguishes from list tools like meta_list_pages by focusing on a single page, though it does not explicitly name alternatives. Overall, it is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings such as meta_get_page_picture, meta_get_page_events, or meta_list_pages. It does not mention exclusions or selection criteria, leaving the agent to infer that this is for general page details. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds no behavioral context beyond stating that it retrieves information; no auth, rate-limit, or return-format details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, efficient sentences with no filler. The function statement is front-loaded and the parameter documentation is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only a minimal description, so an agent must infer what 'detailed information' includes. While annotations cover safety, the description lacks guidance on expected return structure and when to prefer sibling tools. It is adequate for a simple read but incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section provides the post_id format '{page_id}_{post_id}', which is absent from the input schema. This compensates for the 50% schema description coverage. The response_format parameter is left to the schema, which already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' and clearly identifies the resource as 'detailed information about a specific Facebook post.' The word 'specific' distinguishes it from the plural sibling meta_get_posts, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like meta_get_posts, meta_get_post_insights, or meta_get_post_comments. No exclusions or alternative conditions are stated. Usage is only implied by the tool's name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-content context (catalog name, product count, vertical, business info, store settings), but doesn't address error behavior, rate limits, or alternate outcomes. Given annotations carry the safety burden, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a docstring format with Args and Returns sections. The core purpose sentence is front-loaded. Minor redundancy exists with the schema (catalog_id restated), but the overall structure is efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with 2 well-documented parameters and no nested objects, the description adequately covers what the tool returns. The return fields are enumerated, and the absence of an output schema is mitigated by the Returns clause. No critical information needed for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both catalog_id and response_format are already documented in the structured schema. The description restates catalog_id but adds no new syntax or format details beyond the schema. The 'Returns' clause helps clarify what the response contains, but parameter semantics are largely redundant with the schema — appropriate for the 100% coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets details for a single product catalog' — a specific verb, resource, and scope. The name and title already convey the resource, but the description adds the 'single' qualifier that distinguishes it from sibling tools like meta_list_product_catalogs. It could more explicitly name the list/get siblings for differentiation, but 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.
Usage Guidelines2/5
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. There is a closely related sibling, meta_list_product_catalogs, but the description never mentions it or notes when a single catalog lookup is appropriate. No exclusions or context is provided beyond the operational mechanics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as read-only and non-destructive, so the description does not need to re-establish that. It does add useful context by naming the return fields and mentioning pagination through the `after` cursor. However, it does not describe how pagination works, what the output structure looks like, or how status filtering behaves when omitted, so the added behavioral transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose and uses a compact args list. It is easy to scan and does not include unnecessary prose. It slightly duplicates the schema's parameter descriptions, but the overall length is still reasonable and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool, the description covers the essential context: what it lists, which ad account it targets, available filters, pagination, and the kinds of fields returned. Since there is no output schema, the explicit mention of return fields helps fill that gap. It could be more complete by explaining how to use the pagination cursor or the interaction between `status_filter` and the default behavior, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, and the parameter details in the description largely mirror the schema: ad account ID format, status enum values, limit bounds, and the pagination cursor. The description adds little beyond the schema and omits `response_format`, which is present in the schema. Since the schema already documents the parameters well, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Lists campaigns for a Meta ad account.' It also enumerates the returned fields (names, objectives, status, budget info), which helps an agent understand what the tool provides. It does not explicitly differentiate itself from siblings like meta_get_campaign or meta_list_adsets, but the plural 'campaigns' and the ad-account scope make the intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives such as meta_get_campaign, meta_list_adsets, or meta_get_campaign_insights. There is no mention of when not to use it, what scenarios it fits, or how it differs from the single-campaign lookup tool. Usage context is only implied by the phrase 'Lists campaigns for a Meta ad account.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds the category list but no additional behavioral details (e.g., output structure, pagination, rate limits). With annotations present, the description adds minimal extra 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. The Args section is compact and clearly lists parameter semantics, with no filler words. It could be slightly more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks any mention of the return format, pagination, or how the 'limit' parameter works. Since there is no output schema, the agent has no idea what the search results look like (e.g., whether they come as a list, count, or structure). The description does not mention the response_format parameter, which is only explained via schema. This is insufficient for a search tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a clear mapping for the 'type' parameter (adworkposition, adworkemployer, adeducationschool, adeducationmajor) and explains the query parameter 'q'. This compensates for the low schema description coverage (only response_format has a schema description), giving vital meaning to the two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (searches) and the resource (demographic targeting options) with specific categories (job titles, employers, education). This distinguishes it from sibling tools like targeting interests or geolocations, though it does not explicitly named them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like meta_search_targeting_interests or meta_search_targeting_geolocations. It only states what it does, leaving the agent to infer usage from the name and categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns 'Location keys to use in ad set targeting,' which is useful context beyond annotations. However, it does not describe response format details or mention the response_format parameter, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose followed by a bullet list of args. It is front-loaded and free of fluff. However, it leaves out response_format from the args list, which is a minor structural gap but does not detract significantly from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers purpose, key args, and return value. It does not mention pagination, rate limits, or the response_format option, and it does not clarify default behavior (e.g., type defaults to city). While adequate for basic usage, it leaves some operational details unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only response_format has a description in the schema). The description compensates by explaining q, type, and limit with examples and enum values, but it omits response_format entirely. It adds meaning for most parameters but not all, so it partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Searches for geographic targeting options' with examples (countries, regions, cities, zip codes), which specifies the verb and resource. It distinguishes from sibling tools like meta_search_targeting_interests by focusing on geographic types, but it does not explicitly name alternatives. This is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other targeting search tools (e.g., meta_search_targeting_interests, meta_search_targeting_demographics). It does not mention prerequisites, exclusions, or when not to use it. The agent is left to infer from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds no behavioral context beyond what annotations imply. It does not mention side effects (e.g., replacing the entire message), permission requirements, or rate limits. No contradiction, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the function in one sentence followed by a concise parameter list. It is efficient and avoids redundancy, though it could be slightly more polished (e.g., adding 'response_format' to the list).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with no output schema, the description covers the essential parameters and clearly states the action. It lacks context on authentication requirements, potential limitations (e.g., restricted post types), and the response_format option (though present in schema). Given the complexity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief semantic hints for the three primary parameters: post_id (Post ID), page_id (Page ID for token), and message (New message text). This adds meaning beyond the schema's type information. However, it omits the response_format parameter entirely, though that is documented in the schema with an enum and description. Schema coverage is low (25%), so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing Facebook Page post's message text. This is a specific verb (updates), a specific resource (Facebook Page post), and the exact action (message text). It distinguishes from siblings like meta_create_post (creates new) and meta_delete_post (deletes) because it explicitly says 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies it is for existing posts but does not state exclusions (e.g., not for creating new posts) or mention prerequisites like permissions. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint=false, etc.), so the description carries the full burden of behavioral disclosure. It states the action (uploads a video) but does not disclose outcomes (e.g., whether a video ID is returned, whether existing videos are overwritten), prerequisites beyond 'Public URL', or any side effects. The parameter descriptions are mostly tautological and do not explain behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The Args list is somewhat redundant with the schema but is compact and does not add unnecessary prose. Every sentence earns its place, though the Args section could be trimmed to only non-obvious parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and unhelpful annotations. The description does not explain what the call returns (e.g., video ID or upload status), does not mention response_format, and does not cover any error conditions or necessary prerequisites beyond 'Public URL'. For a mutation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate. It provides one-line descriptions for four parameters, but only file_url adds real semantics ('Public URL of video file'). ad_account_id, title, and description are restatements of the parameter names. It omits response_format entirely, which is the only parameter with a schema description. The compensation is partial and shallow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Uploads'), a specific resource ('a video'), and a specific target ('ad account's video library'), plus a clear purpose ('for use in creatives'). This clearly distinguishes it from siblings like meta_upload_ad_image (uploads an image) or meta_create_video_post (creates a video post).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Uploads a video... for use in creatives'), giving context for when to call it. However, it does not explicitly name alternatives or exclusions, such as 'use meta_create_video_post if you want to publish a post' or 'use meta_list_ad_videos to retrieve existing videos.' The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry the safety profile (readOnlyHint=true, destructiveHint=false). The description adds one behavioral detail beyond annotations: the scope restriction to the authenticated user's mentions. However, it does not disclose return format, pagination, or ordering behavior, leaving gaps for a list-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by an Args section that mirrors the schema parameters. It is compact and front-loaded with the core purpose, though the Args lines are slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a straightforward read-only list tool with two parameters (one required) and no output schema. The description covers the essential purpose and the required parameter, but offers no detail on what the returned mention data looks like, how results are ordered, or whether pagination exists — minimal but adequate for a simple fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes response_format (enum with markdown/json), while threads_user_id has no schema description. The description documents threads_user_id but only as 'Threads user ID,' which barely adds meaning beyond the parameter name itself. Schema coverage is 50%, and the description only partially compensates for that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and scope: 'Gets posts where the authenticated user was @mentioned.' This clearly differentiates from threads_get_posts (all posts) and threads_get_replies (replies), though it doesn't explicitly name those siblings or call out the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With over 150 sibling tools including several Threads read tools (threads_get_posts, threads_get_replies, threads_search), the description offers no context on when this specific mentions query is appropriate compared to those similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, providing the safety profile. The description adds no behavioral context beyond the basic purpose—no mention of pagination behavior, return format, rate limits, or what data is included in the response. Since annotations cover safety but the description adds no extra behavioral details, it falls short of the baseline for tools with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence purpose followed by an argument list. It front-loads the main function. The argument list is somewhat redundant with the schema but acceptable. It is appropriately sized and structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of return value structure, the agent cannot understand what the response contains. The presence of an 'after' parameter suggests pagination, but the description does not mention it. Additionally, the response_format default (markdown) is not clarified in the description (though schema provides it). The description is insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (response_format is described). The description compensates by explaining page_id and limit ('Facebook Page ID', 'Max results (default 20)'), which adds value beyond the schema. However, it does not describe the 'after' parameter (pagination cursor), leaving that gap. The partial compensation but incomplete coverage yields a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets ratings and reviews for a Facebook Page.' This is a specific verb-resource pair that distinguishes it from sibling page tools like meta_get_page (page info) and meta_get_page_insights (analytics). The title reinforces this without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the basic purpose, implying it should be used when page ratings/reviews are needed. However, it does not explicitly state when not to use it or compare it to alternative tools such as meta_get_post_reactions or meta_get_page_insights. The usage context is implicit rather than explicit, earning a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no guidance (all hints are false), so the description carries the full burden for behavioral disclosure. It only states the action without explaining side effects, such as whether sharing is additive or replaces existing share settings, what permissions are required, or if the operation is reversible. It also fails to mention that the response_format parameter controls output format, which is a behavioral aspect. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence followed by a list of parameters. There is no fluff, and the primary action is stated upfront. This is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and low parameter coverage, the description is incomplete. It does not explain what the tool returns, how to interpret errors, or why business_id is required (likely for authorization). The presence of the response_format parameter is not acknowledged in the description, leaving the agent to guess its purpose. Given the tool's complexity as a sharing operation with multiple IDs, more contextual detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only response_format has a description). The description lists the three parameters with minimal glosses ('Pixel ID', 'Target ad account ID', 'Business ID') that essentially restate the parameter names. It adds the word 'Target' to ad_account_id, but otherwise does not explain the meaning or relationship of these parameters. For a low-coverage schema, the description fails to compensate by providing additional context or use-cases for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Shares a pixel with another ad account.' This clearly identifies the resource (pixel) and the operation (sharing), distinguishing it from other pixel-related tools like meta_create_pixel or meta_get_pixel. The verb is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: use this tool to share a pixel with another ad account. However, there is no explicit guidance on when to use it vs alternatives, nor any mention of prerequisites like admin permissions or whether sharing overrides existing shares. No exclusions or alternative routing is provided, so it only meets the 'implied' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as a safe read (readOnlyHint=true, destructiveHint=false, idempotentHint=false), and the description adds the key behavioral trait that the tool recursively returns the entire reply tree at all nesting levels rather than a single page. However, it does not disclose pagination limits, rate-limit exposure, or what shape the returned tree takes beyond the bare notion of a tree. With annotations covering most of the safety profile, a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line purpose statement is dense and front-loaded with the key scoping phrase ('all replies at all levels'). The Args block repeats schema information without adding value for media_id and reverse, which is slight waste, but overall the text is compact and the central purpose is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, single-parameter-required tool, the description mostly suffices: it explains what is returned and the ordering option. However, it does not pass a structured output schema and does not clarify the response_format parameter, nor does it distinguish itself from the near-identical sibling threads_get_replies. An agent can call the tool correctly, but may not pick it over the sibling for the right scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block documents media_id and reverse, but the parameter_semantics coverage signal shows schema description coverage is only 33%, and the third parameter response_format is absent from the description entirely. Since response_format is a functional enum ('markdown' vs 'json') that changes the output shape, the omission leaves a real gap that the schema alone cannot fill because its schema description is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and a precise resource ('full conversation tree... for a Threads post') and explicitly scopes it as 'all replies at all levels.' This distinguishes it from the sibling threads_get_replies, which likely returns a flatter or single-level structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling threads_get_replies, which has a highly similar purpose. The 'full conversation tree' phrasing implies it is the comprehensive variant, but no explicit when-to-use or when-not-to-use instruction is provided, so an agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false and idempotent=false, so the creation side effect is implied. The description adds no behavioral context beyond that: it does not mention permissions, duplicate handling, validation errors, or what the response will look like. With no output schema, some behavioral or return-value disclosure would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and scannable, with a clear one-sentence purpose followed by a compact Args list. The enum list and rule example are useful and not excessive. The only minor redundancy is repeating enum values already present in the schema, but this does not hurt usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all required inputs and gives enough detail to construct a valid request. However, it does not explain what the tool returns, how to interpret success/failure, or when to use it relative to other conversion-related tools. Given there is no output schema and the operation is a mutation, a bit more context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, but the description compensates well for the required parameters. It clarifies the meaning of ad_account_id, name, pixel_id, lists all custom_event_type enum values, and gives a concrete JSON example for the rule parameter. It omits the optional response_format, but the schema already documents that parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates a custom conversion for tracking specific actions.' This clearly distinguishes the tool from siblings like meta_list_custom_conversions or meta_create_custom_audience by naming the exact resource type. It is not a tautology and adds meaningful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The phrase 'for tracking specific actions' implies a use case, but the description does not mention related tools such as meta_send_conversion_event, meta_list_custom_conversions, or pixel prerequisites. An agent is left to infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description must disclose side effects. It only states 'Publishes a photo post' and lists parameters; it does not address permissions, idempotency, error conditions, or the impact of 'published' being false. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact argument list, front-loaded with the main action and no redundant text. Every line adds necessary context, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and a moderate parameter set, so the description should clarify return behavior and edge cases. It does not explain what the response_format parameter does or how results are returned, nor does it cover the semantics of 'published: false' (e.g., draft vs. scheduled). These gaps leave an agent uncertain about the full API contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 40% description coverage, and the description adds useful clarifications: it defines 'url' as 'Public URL of the image', 'caption' as 'Photo caption/message', and notes 'published' defaults to true. However, it omits the 'response_format' parameter entirely, leaving the agent unaware of this option and its enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publishes a photo post to a Facebook Page,' which is specific and distinct from siblings like meta_create_video_post or meta_create_live_video. It names the action and resource precisely, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies from the tool name and the phrase 'photo post' that it is for photo publishing, but it does not explicitly mention alternatives or when not to use it. There is no guidance on selecting this over video or live-video tools, though an agent can infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds the conversion-tracking purpose but does not disclose other behavioral aspects such as non-idempotency (creating a new pixel each call) or that no duplicate enforcement is mentioned. It does not contradict annotations, but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and functional, but the Args list duplicates schema information and omits the response_format parameter. It is not verbose, but it could be better structured by integrating parameter explanations inline rather than a separate list that adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description does not mention the return value (e.g., the created pixel ID), error conditions, idempotency implications, or any prerequisites like needing an existing ad account. An agent would likely need to infer these, making the description incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only response_format having a description. The tool description lists ad_account_id and name with trivial descriptions ('Ad account ID', 'Pixel name') that merely restate the parameter names without adding format hints (e.g., ad account format like 'act_123') or constraints. It omits the response_format parameter entirely. Low coverage and minimal added meaning result in weak parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the action ('Creates'), the resource ('Meta Pixel'), and purpose ('conversion tracking'). It distinguishes this from sibling pixel tools like meta_list_pixels, meta_get_pixel, or meta_delete_pixel by implying a creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool relative to alternatives like meta_list_pixels or meta_update_pixel. An agent can infer its purpose, but there is no guidance on preconditions (e.g., requiring an ad account) or when to prefer another tool. Sibling names provide context but the description itself lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's addition of the permission requirement ('Requires instagram_manage_comments permission') provides extra behavioral context. It also specifies that the media is found via mentions in captions or comments, which is more specific than generic read-only. No contradictions. It adds value beyond annotations, though it doesn't mention pagination or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The args list is somewhat redundant with the schema but not verbose. The structure is efficient and readable, though it could be tightened by removing the redundant arg list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low param coverage, the description should provide more context. It doesn't explain the 'after' parameter (likely for pagination), nor does it clarify the return structure or any limits beyond the max. It also omits any error conditions or notes on account setup. While annotations cover safety, the missing pagination info is a notable gap for a list-like tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only response_format has a description). The description lists ig_account_id and limit but provides minimal added meaning beyond what the schema shows (defaults/types). It doesn't explain 'after' at all, and the purpose is largely inferable. Since coverage is low, the description should compensate, but it does not elaborate on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Gets media where the Instagram account was @mentioned in a caption or comment.' This is a specific verb (gets), resource (media), and condition (mentioned). It distinguishes from siblings like meta_get_instagram_media (which likely gets media posted by the account) and meta_get_instagram_comments. 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, alternatives, or scenarios. It only states the function and permission requirement. While the purpose implies usage (when you want mentions), it doesn't explicitly compare to similar tools like meta_get_instagram_media or threads_get_mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Lists' verb is consistent. The description adds some behavioral context by explaining the type parameter semantics ('uploaded' vs 'tagged'), which goes beyond the schema's bare enum. However, it does not disclose pagination behavior (the 'after' parameter) or response structure, which could be important for large photo sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a structured args list. It front-loads the purpose and packs essential parameter meanings into a compact format. There is no redundancy, and it remains readable and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is adequate but not comprehensive. It explains the main parameters but lacks details on pagination (after parameter) and response format (though schema covers response_format). It also doesn't mention any use-case distinctions from siblings. Given the low schema coverage and no output schema, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema description coverage, the description compensates by explaining page_id, type, and limit. It gives meaningful context for the core parameters. However, it omits the 'after' pagination token entirely, and response_format is only covered in the schema. For the key parameters, it adds good value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists photos uploaded to a Facebook Page' which is a clear verb+resource. It distinguishes from video/album tools by its explicit focus on photos. However, the description only mentions 'uploaded' while the type parameter also includes 'tagged', making the opening sentence slightly incomplete. Still, the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like meta_get_page_albums or meta_get_page_videos. The description does explain the difference between 'uploaded' and 'tagged' types, but this is intra-tool guidance, not cross-tool. An agent would have to infer from the name that this is for photos, with no direction on exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operation's safe, non-mutating nature is known. The description aligns with those annotations by saying it 'gets' a URL, but it adds no extra behavioral context such as auth needs, rate limits, or caching behavior. This is acceptable for a simple read operation but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence purpose and followed by a compact args list. There is no filler, though the size parameter partly repeats the schema's enum and default. Overall it is appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with no output schema, this is mostly complete: it states the output is a URL and covers the relevant page_id and size parameters. It does not mention response_format, but the schema describes it fully. No critical behavioral or usage information seems missing for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only response_format has a description), so the description must compensate. It does add meaning for page_id as 'Facebook Page ID' and for size as picture size with allowed values and default. The response_format parameter is already described in the schema, so all parameters have adequate semantic coverage across the definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: getting the profile picture URL for a Facebook Page. It names the resource (page picture) and the return value (URL), which is specific and actionable. It does not explicitly differentiate from sibling tools like meta_update_page_picture or meta_get_page_photos, though the name and resource make the distinction fairly apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent must infer from the name alone that this is the read-only way to fetch a page's profile picture; sibling tools such as meta_update_page_picture are not referenced or contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful semantic detail that posts are scheduled/unpublished, but it does not mention pagination via 'after' or the output format behavior. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and direct, with no fluff. The Args block is somewhat redundant with the schema, but it keeps the description tight and readable. Minor structural improvement would be to integrate parameter notes naturally and mention omitted parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the response contains and how to control pagination, but it does not. Two of four parameters ('after' and 'response_format') are effectively undocumented in the description, and no return format or pagination behavior is described. The tool is simple, so this is a moderate gap rather than a fatal one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for page_id and repeats limit constraints already present in the schema, but it completely omits the 'after' parameter and the response_format parameter. With schema description coverage at only 25%, the description needed to compensate for these gaps and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists'), a specific resource ('scheduled (unpublished) posts for a Facebook Page'), and the parenthetical '(unpublished)' clearly separates this from published-post tools like meta_get_published_posts. The scope is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'scheduled (unpublished)' implies when to use the tool, but there is no explicit guidance on when not to use it or which sibling to choose instead. Given the large list of post-related siblings, explicit alternatives or exclusions would improve this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the resource scope ('image library') and notes the default limit, but does not disclose pagination behavior, return shape, or the meaning of the 'after' cursor. With annotations handling the primary behavioral traits, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of fluff. The Args block is easy to scan. It loses one point only because the missing 'after' parameter means it is concise but not as useful as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, the description should explain enough for correct invocation. It gives the required ad_account_id and the limit default, but fails to describe the 'after' pagination parameter, the response_format option, or what the returned image data contains. This is a notable completeness gap for a paginated list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It explains ad_account_id and limit, but omits 'after' entirely, which is likely a pagination cursor and is also undocumented in the schema. This is a meaningful gap because a listing tool without pagination guidance is incomplete for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lists images in an ad account's image library.' This clearly distinguishes it from sibling tools like meta_upload_ad_image, meta_list_ad_videos, and meta_list_ad_creatives by narrowing the resource to images in the ad account library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need to list ad account images. However, it does not explicitly state when not to use it, nor does it mention alternatives such as meta_list_ad_videos or meta_upload_ad_image, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds modest context by stating that results respect a limit and return asset details including IDs, names, and type-specific metadata, but it does not disclose pagination, access prerequisites, or response edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear one-line purpose followed by a structured Args/Returns breakdown. Every sentence adds useful content, and there is no filler or redundant annotation duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with four parameters and no output schema, the description supplies required inputs, allowed asset types, limit behavior, and a return-value summary. It is slightly incomplete because it does not mention response_format and does not guide the agent toward specialized sibling tools when only one asset type is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters, and the description mostly repeats business_id, asset_type values, and the limit default/maximum rather than adding new meaning. It helpfully lists the allowed asset_type values, but it omits response_format entirely; the schema compensates for that omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Lists assets... for a Business Manager') and enumerates the asset types, so an agent can tell this is a Business Manager asset listing. It stops short of explicitly differentiating this aggregate tool from sibling tools like meta_list_ad_accounts, meta_list_pixels, or meta_list_instagram_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the more specialized sibling listing tools. The agent must infer intended usage from the name and asset_type enum; there is no when/when-not or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the ad-account scoping and the 'all' semantics, but it does not disclose pagination, permission requirements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core behavior in the first sentence. The Args block is slightly redundant with the schema, but it is short, scannable, and does not add unnecessary noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and read-only annotations, the description is mostly adequate. However, it omits any mention of pagination or the shape of the returned pixel list, and there is no output schema to compensate for that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section gives ad_account_id a human-readable meaning that the schema lacks, which is useful. response_format is not repeated in the description, but the schema already documents its enum, default, and description, so the combined coverage is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lists all Meta Pixels for an ad account,' which gives a specific verb, resource, and scope. The word 'all' distinguishes it from singular pixel tools like meta_get_pixel and from mutation tools like meta_create_pixel or meta_delete_pixel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over siblings such as meta_get_pixel, meta_get_pixel_stats, or meta_get_pixel_events. The agent must infer selection solely from the verb, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, so the description correctly aligns with 'Sends' as a write operation — no contradiction. The description adds useful behavior beyond annotations: it discloses that test_event_code 'won't affect production data' and that event_id is 'for deduplication with browser pixel.' However, it omits other behavioral traits an agent might need, such as async processing, the returned event receipt ID, or required authentication. It adds some value but not rich coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clean one-line purpose statement followed by a compact bullet list of arguments, with required params naturally front-loaded before optional ones. It is appropriately sized (~150 words) for a 10-param tool. Minor waste: the action_source enum is duplicated verbatim from the schema, which adds length without new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is high (10 params, nested objects, enums, no output schema), and the description documents all required params well. But it omits the response_format parameter entirely, leaves many optional subfields of custom_data and user_data undocumented, and — with no output schema present — never explains the return value. The schema covers gaps for field shapes, but the absence of any return-value note is a real deficiency for a sending tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal value: it explicitly states the 'at minimum one of' requirement for user_data identifiers, which the schema only loosely implies, and it documents action_source's enum. But it lists only a subset of user_data and custom_data fields (omitting ct, db, fn, ge, ln, st, zp, madid, country, status, contents, predicted_ltv, etc.), so it does not fully compensate or enrich beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Sends a server-side conversion event to Meta via the Conversions API.' The term 'server-side' and 'CAPI' in the title distinguish it from browser-pixel tracking and sibling tools like meta_send_offline_event (which sends to offline event sets) and meta_test_conversion_events (which tests events). The intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance exists. The description never names alternatives such as meta_test_conversion_events, meta_send_offline_event, or meta_create_event, nor states the conditions that would select one over the other. The 'server-side' phrasing only implies context; an agent has to infer that this is the intended path for CAPI sends rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description only restates the action without adding new behavioral context, such as whether existing comments remain visible when disabled, or any permission requirements. It adds minimal value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The purpose is front-loaded, and the Args section is structured and readable. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema and annotations that cover idempotency and non-destructiveness, the description covers the essential action and parameters. It does not mention potential effects on existing comments or required permissions, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, with descriptions in the schema. The description repeats the parameter meanings (media_id and enabled) but adds no additional details about formats, constraints, or edge cases. Since the schema carries the full load, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (enable/disable), the resource (Instagram media object), and the action (comments). It is specific and unambiguous, and the sibling meta_hide_instagram_comment is distinct because it targets individual comments rather than the media-level comment toggle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like meta_get_instagram_comments or meta_hide_instagram_comment. There is no mention of preconditions, such as needing a valid media ID or specific permissions, nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint=true and destructiveHint=false, which already cover safety and idempotency. The description adds only that it 'Returns confirmation of the update,' but does not clarify whether the update is partial (only provided fields are changed) or full (unspecified fields are reset). This is a behavioral gap not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It lists the required and optional parameters in a straightforward manner, though the formatting could be improved by referencing the schema for detailed parameter types and defaults. No unnecessary text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential information to call the tool (product_id required, optional fields), and it mentions the return value (confirmation). However, it does not explain whether the update is partial or full, what the confirmation format looks like, or how the response_format parameter affects the output. Given the tool's moderate complexity and lack of an output schema, these gaps make it less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions for all eight properties, so the baseline is 3. The description merely lists the field names without adding any additional meaning or clarifications beyond what the schema already provides (e.g., price in cents, availability semantics).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it 'Updates a product's details' and lists the specific updatable fields (name, description, price, availability, image_url, url). This differentiates it from get/create/delete product tools, and the verb 'update' unambiguously indicates a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like meta_create_product or meta_get_product. It only says 'Updates a product's details,' implying it is for existing products, but it does not state any prerequisites, exclusions, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds 'permanently' which reinforces irreversibility beyond the annotation, but does not disclose any other behavioral aspects like permissions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of one sentence plus a redundant Args block that duplicates the schema. It is efficient and front-loaded, though the Args list could be omitted since the schema covers it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but lacks context about irreversibility beyond 'permanently', potential errors, or permission requirements. It is sufficient for basic usage but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes media_id as 'Threads media ID'. The description repeats this with 'Threads media ID to delete', adding no new semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Deletes') and resource ('Threads post'), and emphasizes 'permanently' to clarify the effect. It clearly distinguishes this from other tools by specifying the Threads platform, which is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 threads_hide_reply or meta_delete_post. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds valuable context by stating the threads_basic scope requirement and that only users who have allowed their followers list to be visible are returned. It also discloses the return structure (User IDs, usernames, profile picture URLs), adding insights beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Note sections, front-loading the core purpose. It is concise but includes necessary details. The limit bounds are repeated from the schema, but this is minor redundancy. Overall, it avoids bloat and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main return values and constraints, but lacks explicit clarity on user scope (authenticated vs. specified user ID). It also omits guidance on the response_format parameter and does not discuss error states or rate limits. For a read tool with moderate complexity, it is functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'after' parameter as a pagination cursor, which the schema does not describe. It also confirms the limit bounds, though that is redundant with the schema. However, it does not mention the response_format parameter, which is documented only in the schema. Given schema coverage is only 25%, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists followers of a Threads user, differentiating it from threads_get_following which handles the following list. However, the phrase 'authenticated Threads user' conflicts slightly with the existence of a threads_user_id parameter, leaving ambiguity about whether the tool queries the authenticated user's followers or any specified user's followers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention threads_get_following or contrast with other Threads tools. The note about scope and visibility is a prerequisite, not a usage guideline. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only or idempotent, and the description confirms the mutating behavior by saying 'Creates.' It also adds that a new creative ID is returned. It does not disclose permissions, validation constraints, or broader side effects, but the annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a one-sentence purpose and then uses a clean, structured Args list followed by a return-value line. It is appropriately sized for nine parameters, with no redundant filler, though the optional creative-source fields could be grouped more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nine parameters and no output schema, and the description provides the key creation path plus the returned ID. It does not explain how object_story_id relates to image_url/link_url or what happens when both/both styles of inputs are supplied, which is a meaningful completeness gap for a flexible creation endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description compensates by providing meaningful labels for most parameters, including the {page_id}_{post_id} format for object_story_id and the ownership relationship for page_id. It omits response_format, though the schema already documents that parameter, and it does not clarify whether image_url and object_story_id are mutually exclusive alternatives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action and resource: 'Creates an ad creative' from an existing Facebook Page post, which distinguishes it from sibling tools like meta_create_ad and meta_get_ad_creative. However, the 'existing post' framing is narrower than the optional image_url/link_url parameters suggest, so the stated scope is slightly misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: creating an ad creative from a Page post. It does not explicitly state when to prefer this tool over alternatives like meta_upload_ad_image or meta_create_ad, nor does it mention exclusions such as when not to use object_story_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already reports destructiveHint=true, and the description's 'Deletes' is consistent with that. The description adds the object being destroyed—an automated ad rule—but provides no extra behavioral context such as permanence, cascading effects, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded with the action, and contains only the necessary parameter explanation. Every sentence contributes to understanding the tool, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete operation, the description plus the destructiveHint annotation provide an adequate call contract: what action is performed, which identifier is needed, and whether the operation is destructive. It could note irreversibility or side effects, but the low complexity makes the current level mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args block clarifying that rule_id is 'Ad rule ID.' This is minimal, yet it gives the agent enough semantic context for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Deletes an automated ad rule.' This clearly identifies what the tool does and distinguishes it from delete tools for other object types like meta_delete_ad. It does not explicitly contrast with siblings such as meta_get_ad_rule or meta_create_ad_rule, but the verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as meta_delete_ad, meta_get_ad_rule, or meta_list_ad_rules. The description simply states the action, leaving usage context to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the fact that deletion is 'permanent', which goes beyond the annotation but doesn't explore side effects, reversibility, or error behavior. This is a moderate addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is front-loaded and concise, with the permanent warning immediately following. The 'Args' section redundantly repeats schema documentation, adding slight overhead, but overall the text is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no output schema, the description covers the essential details: what it deletes, the permanence, and the parameter. It doesn't mention prerequisites like authentication or success/failure responses, but those are not critical for a tool this straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with media_id described as 'Instagram media ID'. The description repeats the parameter name and adds no extra meaning about its format or origin. Baseline 3 is appropriate when the schema fully documents the one required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Deletes' and the resource 'Instagram media object' with explicit types (post, reel, story). This distinguishes it from sibling delete tools like meta_delete_post (likely Facebook) and meta_delete_instagram_comment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention exclusions or conditions for using other delete tools, leaving the agent to infer context from the resource type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral detail by enumerating the full set of returned metrics (performance, cost, engagement, conversions, video, quality), which goes beyond the bare read-only annotation. It does not contradict any annotation, and it gives the agent concrete expectations about the output contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into Args and Returns sections, which is helpful, but it is quite verbose – the Returns section lists over 30 metric names, many of which are self-explanatory and could be summarized. It duplicates some parameter info already fully covered by the schema. It is not front-loaded beyond the first sentence, and the length may reduce skimmability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple filtering options and a rich set of return metrics), the description covers the arguments and return metrics thoroughly. It omits mention of the response_format parameter, but that is fully described in the schema with a default of 'markdown'. It also does not discuss rate limits or required permissions, but for a read-only tool with annotations confirming safety, this is acceptable. The description provides enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the schema already documents parameters. The description adds value by providing an example for ad_account_id (act_123456789) and explicitly stating that 'since' overrides 'date_preset' – a behavioral nuance not present in the schema. It also lists example breakdown dimensions, though the schema already enumerates them. This exceeds the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets performance insights for a Meta ad account' – a specific verb, resource, and scope. It distinguishes itself from sibling insight tools (e.g., meta_get_campaign_insights, meta_get_ad_insights) by explicitly naming 'ad account', though it does not name alternatives directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of the many insight-related siblings (campaign, adset, ad, Instagram account). It does not mention any exclusions or conditions. The agent must infer usage from the resource type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description needs only to add context; it does not. The phrase 'detailed information' is consistent with these annotations but adds no further behavioral detail such as response size, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a tight argument listing, with no redundant words. It front-loads the purpose and presents the parameter example in a structured way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter, the description and schema together cover the required parameter, an optional output format, and the tool's purpose. It omits details about the response contents, but with no output schema and a standard 'detailed information' phrase, this is a minor gap; the sibling list provides plenty of context that this is an ad account detail lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents the required ad_account_id parameter with a concrete example ('act_123456789'), compensating for the schema's lack of description for that field. It does not mention response_format, but the schema already describes it fully, so effective coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets detailed information about a specific ad account.' This distinguishes it from list-type siblings like meta_list_ad_accounts by emphasizing a single account, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over sibling tools such as meta_list_ad_accounts or meta_get_ad_account_activity. The intended use is only implied by the name and the required ad_account_id parameter, leaving an agent to infer the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds no behavioral context beyond restating that this is a read operation; it does not mention response format, error behavior, or any additional constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a clear one-line purpose followed by a compact Args section. It wastes no words, though the Args section lists only one of two parameters, which slightly reduces completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only, get-by-ID tool, the description plus annotations and schema is largely sufficient for an agent to invoke it correctly. Minor gaps remain: it does not describe what 'details' are returned and does not explicitly connect rule_id discovery to meta_list_ad_rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a minimal semantic for rule_id ('Ad rule ID'), but this is largely self-evident. It omits response_format entirely, although the schema already provides a full description for that parameter. With schema description coverage at 50%, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets details') and resource ('a specific automated ad rule'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like meta_list_ad_rules, which list many rules, and meta_create_ad_rule/meta_delete_ad_rule, which mutate rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies this tool is for retrieving one ad rule by ID, which hints at when to use it, but it does not explicitly mention alternatives or when not to use it. There is no direct guidance such as 'to list all ad rules, use meta_list_ad_rules instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds only parameter details (comment_id and limit) and does not disclose any additional behavioral traits such as pagination, rate limits, or response format. It neither reinforces nor contradicts annotations, and provides minimal extra context beyond what annotations already establish.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by a clear parameter list. It avoids unnecessary verbosity and is appropriately sized for a simple read operation, though it could be slightly more structured (e.g., describing the response).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no mention of response structure, pagination, or how to obtain comment_id, the description is adequate for a basic read but leaves some gaps. Given the tool's simplicity and annotation coverage, it is sufficient for an agent to call it correctly, but it could clarify prerequisites and return format to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (response_format has a description). The description compensates by explicitly explaining comment_id ('Parent comment ID') and limit ('Max replies (1–50, default 20)'), offering meaning that the schema lacks. This fully covers the two parameters that were previously undocumented, making the parameter semantics strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Gets') and resource ('replies to a specific Instagram comment'), making the tool's purpose unambiguous. It implies a distinction from tools that retrieve top-level comments (e.g., meta_get_instagram_comments) but does not explicitly name a sibling or state what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives. There is no mention that a comment_id must first be obtained from meta_get_instagram_comments, nor any exclusion criteria. The intended usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. readOnlyHint=true and destructiveHint=false already convey the safety profile, and the description merely restates the read-only nature. It does not mention pagination, time filtering behavior, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single purpose sentence followed by a compact Args list, with the purpose front-loaded and no filler. The Args section is somewhat redundant with the schema, but it is brief and easy to scan, so the overall structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with read-only annotations and schema-covered parameters, the description provides the core purpose and parameter meanings. The absence of an output schema is mitigated by response_format in the schema, which tells the agent the result will be markdown or JSON. It lacks explicit routing guidance against sibling list tools, but nothing essential for invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section covers three of four parameters and adds 'Facebook Page' context for page_id, but limit and time_filter descriptions mostly mirror the schema's types, defaults, and enums. response_format is omitted from the description, though the schema provides its description. With schema description coverage at 25%, the description partially compensates but does not add significant semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, resource, and scope: 'Lists events created by a Facebook Page.' This clearly distinguishes it from sibling tools like meta_get_posts (posts vs. events) and meta_create_event (create vs. list). No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—use this when you want to list Facebook Page events—but does not explicitly state when to use it over alternatives or mention any exclusions. There is no direct comparison to similar list tools like meta_get_posts or meta_get_published_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds minimal behavioral context beyond 'via insights' and does not disclose potential caveats such as access token requirements, metric availability, or response limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a clean, readable Args list. Every sentence adds value without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with annotations covering safety, the description is mostly complete. It lacks explicit mention of response_format in the Args list and does not elaborate on what each demographic metric returns, but the schema and enums cover the key details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, and the description compensates by explaining page_id as 'Facebook Page ID' and metric as a 'Demographic metric' with the allowed enum values. The response_format parameter is not mentioned in the description, but the schema already provides its meaning and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('fan/follower demographic breakdowns for a Facebook Page'), and clarifies the data source ('via insights'). It is clear and distinct from the general meta_get_page_insights sibling, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need fan/follower demographic breakdowns for a Facebook Page. However, it does not explicitly contrast it with similar insight tools like meta_get_page_insights or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the resource scope and a parameter limit but does not mention pagination, authentication, or response behavior. This is not a contradiction, but it adds limited behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded with the core action, followed by a minimal args list. There is no filler, redundant prose, or unnecessary background.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, so the description plus annotations cover a basic call using page_id and limit. However, the 'after' parameter is entirely undocumented and there is no output schema, leaving pagination and response-shape questions unanswered. Adequate for a default call but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description needed to compensate for undocumented parameters. It helpfully explains page_id and restates limit's range and default, but it leaves the 'after' pagination cursor completely unexplained, and response_format is only described in the schema. This is partial compensation, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Gets posts that tag this Facebook Page.' The qualifier 'tag this Facebook Page' clearly distinguishes this from sibling post-retrieval tools such as meta_get_published_posts or meta_get_visitor_posts, even without explicitly naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The only selection cue is the purpose statement itself, so an agent must infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the specific reaction types returned, providing useful output context, but does not disclose other behavioral specifics like pagination, rate limits, or auth requirements, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. Including an 'Args' section that repeats post_id is somewhat redundant with the schema, but the overall text is short and the reaction list is valuable. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters (one required, one optional enum), the description plus schema and annotations cover the essentials: input (post_id) and output nature (reaction counts). The lack of an output schema and explicit response_format guidance is minor given the schema covers it. The agent can call it correctly without missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (response_format has a description, post_id does not). The description adds a basic meaning for post_id ('Post ID') but duplicates the schema's type info, and it does not mention response_format beyond the schema. It partially compensates for the coverage gap but does not go beyond what the schema already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Gets reaction counts (like, love, haha, wow, sad, angry) on a post.' This clearly distinguishes it from siblings like meta_get_post (post content) and meta_get_post_insights (analytics), which do not focus on reaction counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. It does not mention any conditions, exclusions, or related tools, leaving the agent to infer suitability from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond that, such as the scope of 'visitor posts' on the wall. It does not disclose pagination behavior, ordering, or the fact that only public visitor posts may be returned. With annotations covering the safety profile, the description adds some value but lacks richer behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a compact args list without fluff. Every sentence adds value; there is no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool is a read operation, the description covers the core purpose and two key parameters. However, it lacks explicit guidance on pagination (after) and the availability of response_format (though schema covers it). It also does not mention any authentication or rate-limit specifics, but these are likely common across the tool family. Overall, it is adequate but leaves some edge details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is only 25% (only response_format has a description). The description adds clarifications for page_id ('Facebook Page ID') and limit ('Max results (1–100, default 20)'), which are useful. However, it omits 'after' (pagination cursor) and 'response_format' (though response_format is described in schema). Thus it partially compensates for the low schema coverage but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets'), resource ('posts published by visitors'), and location ('Facebook Page wall'). This clearly distinguishes it from siblings like meta_get_posts (which likely returns all posts) and meta_get_published_posts (likely page's own posts). The purpose is unambiguous and instantly separates it from the many other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used specifically for visitor posts as opposed to page posts, nor does it note any exclusions or prerequisites. An agent would have to infer usage from the name and title, which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds a useful note about the return fields (creative IDs, names, and page post IDs), but does not disclose pagination behavior, API limits, or other operational traits beyond the 'after' cursor parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one line states the purpose, a short Args block documents parameters, and a Returns line covers output. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list operation, the description gives enough context to call the tool correctly: the required ad_account_id, pagination support, limit default, and the return shape. It does not discuss usage versus siblings, but the core invocation context is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes response_format, leaving ad_account_id, limit, and after undocumented. The description compensates by explaining each of these three parameters, including the default for limit and the purpose of after as a pagination cursor. It omits response_format, but that parameter already has a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists ad creatives for an ad account') with a specific resource and scope. It is distinguishable from close siblings like meta_list_ads by the 'ad creatives' object, though it does not explicitly name or contrast any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as meta_list_ads, meta_list_campaigns, or meta_list_adsets. The context signals show a large sibling set, so explicit routing guidance would be valuable, but none is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by stating what the tool returns ('product set IDs, names, filters, and product counts') and hints at pagination via the limit parameter. This is a moderate value-add but does not disclose any additional behavior like error conditions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a front-loaded purpose, a clear args list, and a return-value note. The args list is somewhat redundant with the schema but packaged efficiently. All sentences serve a purpose, and the format makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing operation, the description is reasonably complete. It states what the tool returns, which is crucial since there is no output schema. Annotations cover the safety profile, and the schema covers parameter details including response_format. The description does not mention potential prerequisites (e.g., needing a valid catalog), but that is not required for a basic list call. Given the tool's low complexity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it repeats 'catalog_id' and 'limit' with the same constraints already present (1–100, default 25). It does not add semantics for response_format, which is also documented in the schema. No significant value beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('product sets (subgroups)') with scope ('in a catalog'). This clearly distinguishes it from sibling tools like meta_list_products and meta_list_product_catalogs, which list different entities. The parenthetical clarifies what a product set is, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Sibling tools include meta_list_products and meta_list_product_catalogs, and there is no guidance on choosing between them. The context is clear that this is for product sets, but no exclusions or alternative routing are provided, leaving the agent to infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate it is not read-only and not destructive, so the description needs to disclose more. It states the return value (message ID) and the mutation action, but does not mention potential side effects, permissions, rate limits, or error conditions. It adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action, and the Args/Returns structure is clear. It repeats schema info but does so efficiently without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 simple parameters and no output schema, so the description covers what is needed: the action, parameters, and return value. It does not mention edge cases, but for a straightforward send operation, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description largely replicates the schema's parameter descriptions. It does clarify that link_url is optional, but this is already implied by not being in the required list. No meaningful additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sends a message) and the specific resource (Instagram broadcast channel), which distinguishes it from other message-sending tools like meta_send_instagram_message. However, it does not explicitly name alternatives, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when targeting a broadcast channel, which is clear enough, but it does not provide explicit guidance on when not to use this tool versus similar ones like meta_send_instagram_message or when certain prerequisites apply. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation performs a partial update and notes that migration keeps the original campaign ID. Since annotations are all false (no idempotent, destructive, or read-only hints), the description carries the burden of behavioral disclosure, but it does not elaborate on potential side effects (e.g., archiving a campaign), idempotency, or error outcomes. It is not contradictory, but it is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the primary action. The Args list is well-structured and readable, though it partially duplicates the schema. It is not overly verbose, and every sentence adds information (e.g., partial update, migration option, parameter meanings). The structure is clear and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no helpful annotations, the description covers parameter semantics and the core behavior, but it lacks guidance on when to use the dedicated migration tool instead, and it does not describe the return value or error handling. It is adequate for basic invocation but missing context that would help an agent choose this tool over the migration sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explicit descriptions for all parameters except response_format, including budget units ('in cents'), enum values for status, and the migration flag behavior. The schema lacks descriptions for several parameters (name, status, daily_budget, lifetime_budget), so the description compensates well, though it omits response_format which is already described in the schema. The added detail goes beyond the schema, making it valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing campaign and explicitly notes that only provided fields are changed, which is specific and distinguishes it from create/delete tools. However, it also mentions the option to migrate to Advantage+ Shopping, and there is a dedicated sibling tool (meta_migrate_campaign_to_advantage_plus) that could cause confusion about the primary purpose. The update verb and resource are clear, but the migration mention creates a minor blur.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains partial-update behavior ('Only provided fields are changed') which implies usage for modifying existing campaigns, but it does not explicitly state when to use this tool versus the dedicated migration tool or other campaign tools. It also does not mention any exclusions or prerequisites, so the agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds return format details (User IDs, usernames, profile pictures) and pagination semantics (limit, after). It does not mention rate limits or authentication nuances beyond 'authenticated user', but those are acceptable given the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence for purpose and a structured 'Args:' list with clear parameter descriptions. It wastes no words and is easy to parse. The return statement adds essential output info without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description covers the required parameter, optional pagination, and return format. There is no output schema, so the return description fills that gap. It does not mention authentication letails or rate limits, but those are less critical given the annotations and simplicity. The tool is fully callable as described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only response_format has a schema description). The description compensates by explaining threads_user_id, limit (with range and default), and after (pagination cursor). It omits response_format, but that is described in the schema. Overall, it adds meaning for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Lists accounts that the authenticated Threads user is following.' It clearly distinguishes from write tools like threads_publish_text, though it does not explicitly name a sibling like threads_get_followers. 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.
Usage Guidelines2/5
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 (e.g., threads_get_followers or threads_get_mentions). It does not mention when not to use it or any specific context. The agent is left to infer appropriate usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal the operation is not read-only and not destructive. The description adds little beyond restating the action and the target profile. It does not disclose permissions needed, whether the repost is publicly visible, reversibility, rate limits, or any other side effects beyond what is obvious from the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one direct sentence followed by a compact argument list. It front-loads the core action and resource, contains no filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no output schema, the description is minimally sufficient to identify the action and arguments. However, it lacks return-value expectations, auth or permission context, and any guidance on when to use this versus sibling publishing tools, so it is not fully complete for confident autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves threads_user_id undocumented, and the description compensates by labeling it 'Your Threads user ID'. media_id is given a 'Thread media ID' qualifier that clarifies the parameter, and response_format already has a full schema description. Combined, all three parameters are effectively documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Reposts (shares)' with a clear resource 'existing thread' and target 'your profile'. It is immediately distinguishable from the many publish/create siblings in the tool list, which involve new content rather than sharing an existing thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—sharing an existing thread—but provides no explicit guidance on when to choose this tool over alternatives like threads_publish_text or threads_publish_image. There are no exclusions, prerequisites, or conditions stated, so the agent must infer selection from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-idempotent, non-destructive operation, and the description adds the useful detail that it 'Returns: The created study ID'. It does not, however, explain side effects, permissions, or the downstream implications of starting a study, so behavioral disclosure is only average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loaded with the purpose, and organized into a short Args list plus a Returns line. It is not bloated, though some parameter detail duplicates what the input schema already provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Most invocation details are covered by the schema and the Args list, but the description does not explain the difference between SPLIT_TEST and HOLDOUT or how cells and treatment percentages should be arranged. With no output schema, the Returns line helps, but key decision semantics remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The Args list mostly repeats schema field names and descriptions, adding only minor examples like 'act_123456789' and confidence levels 90/95/99, without deeper meaning such as how treatment_percentage values should be distributed across cells.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates an A/B test (ad study) to compare campaigns or ad sets', naming a specific verb, resource, and intent. This clearly differentiates it from read-only siblings like meta_get_ad_studies and from general ad-creation tools like meta_create_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence implies when to use it — whenever an A/B test is needed — but there is no explicit guidance about when not to use it or which sibling to prefer, such as meta_get_ad_studies for reading existing studies. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=false, so it's a non-idempotent write operation. The description adds that it 'Returns: Poll/message ID,' which is useful context beyond the annotations. However, it doesn't disclose other behaviors like rate limits, permission requirements, or error conditions. Given that annotations already cover the basic mutability, the added return information earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear statement followed by a structured list of parameters and return value. It is front-loaded with the core purpose and contains no redundant or filler content. Every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three required parameters, all documented in both the schema and description. The return value is specified. While it doesn't mention that the broadcast channel must already exist or any error behaviors, for a straightforward create operation this is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every parameter is already described in the schema (channel_id, question, options with min/max items). The description repeats these definitions verbatim without adding further meaning, such as expected formats or additional constraints. With full coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Creates a poll in an Instagram broadcast channel.' It identifies the verb (creates), the resource (poll), and the context (broadcast channel). This distinguishes it from sibling tools like meta_send_broadcast_channel_message or meta_get_broadcast_channel_messages, which handle messages or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it's implied that this tool is for creating polls, the description provides no explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites. It does not reference sibling tools or conditions under which another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (a write operation), so the burden on the description is reduced. The description adds no further behavioral details—it does not disclose side effects (e.g., the event becomes public), idempotency implications (repeated calls may create duplicates), or permission requirements. It merely states the action, which is minimally additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose followed by a structured argument list. It is efficient and contains no filler. The argument list is slightly verbose for a schema that already defines types, but it consolidates the information in a readable format. The structure is well organized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description should indicate what the tool returns (e.g., an event ID) or at least hint at the response format. It does not. It also omits the response_format parameter, which is part of the schema. While it covers the main input parameters, it lacks return-value details and any caveats about event visibility or timezone handling, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, so the description must compensate. It lists most parameters with types and uses, notably specifying ISO 8601 format for start_time and end_time, and clarifying optionality for several. However, it omits the response_format parameter entirely and does not mention constraints like end_time being after start_time, so it is not exhaustive. Overall, it adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Creates an event on a Facebook Page.' It names the exact resource (Facebook Page event) and distinguishes it from sibling tools like meta_create_post and meta_create_photo_post, which target different content types. The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other creation tools. It does not mention any prerequisites (e.g., admin permissions) or conditions that would make this tool preferable to alternatives like meta_create_post or meta_create_live_video. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a write operation and not idempotent or destructive. The description adds that the tool returns the created product ID, which is useful, but it does not disclose behavior around duplicate retailer_id values, catalog existence, or authorization requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded and the return behavior is stated clearly at the end. The Args list is long but compact and scannable; it repeats schema information but is not bloated or misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter create tool with no output schema, the description covers the core purpose and return value, and the schema covers all parameters. However, it is incomplete in a few ways: response_format is absent from the description, requiredness is only partially indicated, and there is no guidance about uniqueness or duplicate behavior for retailer_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter details in the description. The description largely duplicates the schema and adds little new semantic meaning; notably, it omits the response_format parameter that appears in the schema, creating a minor inconsistency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Adds a product to a catalog,' naming a specific verb, resource, and scope. It also states 'Returns the created product ID,' confirming this is a create operation and distinguishing it from the many product/catalog siblings like update, delete, get, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The create semantics are implied by 'Adds' and by the sibling names (meta_update_product, meta_delete_product), so an agent can infer when to use this tool. However, there is no explicit when-to-use, when-not-to-use, or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. The description adds the date format for since/until, but does not disclose any other behavioral traits such as rate limits, pagination, or what the returned log entries contain. Given the annotations cover the safety profile, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a clean parameter list. It is concise and front-loaded with the purpose. No fluff or redundant detail. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only log retrieval tool, the description is close to adequate but has notable gaps. It fails to document the response_format parameter even though it appears in the schema, and it does not describe what fields the activity log will contain or any pagination behavior. There is no output schema, so the description should at least hint at the return structure. The date range and limit are covered, but the omission of response_format is a clear deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only response_format has a description), so the description should compensate. It does add context for since/until by specifying the YYYY-MM-DD format, which the schema lacks. However, it omits the response_format parameter entirely, which is a significant omission since that parameter has an enum and controls output format. The description adds value for some parameters but does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('activity/change log for an ad account'), making it immediately clear what the tool does. It distinguishes itself from the many other 'get' tools in the sibling list by focusing on the activity log specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you call it when you want an activity log) but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or alternative tools. There is no explicit guidance for choosing between this and other meta_get_ad_* tools, though the name and first line make the use case fairly apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the result includes user roles and provides an ID format example, but does not mention pagination, permission requirements, or the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a short Args block with a useful example. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with rich annotations, this description is largely sufficient: it identifies the resource, the output concept (users and roles), and the required parameter format. It only lacks explicit usage-context guidance and response-shape detail, which are minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves ad_account_id undocumented aside from type, and the description compensates with a concrete format example (act_123456789). The response_format parameter is already fully documented in the schema with an enum and default, so no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and a specific resource ('users who have access to an ad account with their roles'). This clearly distinguishes it from sibling ad-account tools by focusing on user access rather than account details, activity, or campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like meta_get_ad_account or meta_list_ad_accounts. No conditions, exclusions, or sibling references are provided, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context about return contents (name, type, status, dates, results) but does not disclose additional behavioral traits such as authentication needs or rate limits. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a front-loaded purpose sentence followed by concise Args and Returns sections. Every sentence provides useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description covers the core behavior, arguments, and return shape. The only minor gap is that the Args list omits response_format, but the input schema documents it. Overall, an agent has enough information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes ad_account_id and response_format but not limit. The description compensates by documenting limit's range and default, and repeats the ad_account_id format. It does not mention response_format, though the schema already covers it. Overall, partial added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists'), a specific resource ('A/B tests (ad studies)'), and the scope ('for a Meta ad account'). This clearly distinguishes it from related siblings like meta_create_ad_study and meta_get_ad_study_results by action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as meta_get_ad_study_results for detailed results or meta_create_ad_study for creating a study. The intended usage is implied by the name and first sentence, but there are no explicit conditions, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate those. The description adds the 'specific audience' scope but no additional behavioral context such as response shape or conditions. It is consistent with annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and immediately readable. The Args block duplicates schema information but is minimal enough to not be harmful. Overall, it is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only get operation, the name, schema, and annotations together are nearly sufficient. However, there is no output schema and the description only says 'details,' so the agent is not told what fields or response format to expect beyond the response_format parameter. A sentence describing the returned data would make this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both audience_id and response_format. The description merely repeats audience_id without adding new meaning, and it does not mention response_format. This is the baseline 3 case where the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Gets details') and a precise resource ('a specific custom audience'), and the qualifier 'specific' distinguishes it from listing or creating custom audiences. This is enough for an agent to identify this as a single-record retrieval operation, distinct from siblings like meta_list_custom_audiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: call this when you already have an audience_id and need details for one custom audience. However, it does not explicitly mention when not to use it or point to alternatives such as meta_list_custom_audiences for enumeration, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds return value information (estimated daily outcomes and bid suggestion) but does not disclose potential edge cases, rate limits, or how estimates might vary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear first sentence followed by labeled Args and Returns sections. Every line adds useful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description covers the purpose, key parameter, and return values. Annotations handle safety. It could be more complete by clarifying how this differs from meta_get_reach_estimate, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description labels adset_id as 'Ad set ID,' which adds little beyond the parameter name and does not explain where to obtain the ID or its format. The response_format parameter is already well-described in the schema, so the description contributes minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets delivery estimate for an existing ad set,' identifying a specific verb and resource. It is distinct from a generic reach estimate, though it does not explicitly differentiate from the similar sibling meta_get_reach_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an existing ad set' provides a clear usage context, indicating the tool applies to existing ad sets rather than prospective targeting. However, it does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the return payload and the broadcast-channel concept, but no extra behavioral traits such as authorization needs, pagination, or rate limits, which is acceptable for a simple read-only tool but doesn't exceed baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every section earns its place: the purpose sentence, the context sentence, the args line, and the returns line. There is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with one required parameter and annotations covering safety, the description is largely complete: it states the required input and the returned fields. It is slightly incomplete in not mentioning response_format or distinguishing itself from related broadcast-channel message tools, but those are covered by the schema and title respectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description only repeats the ig_account_id argument without adding usage details. The response_format parameter is fully documented in the schema, so the description adds no meaningful parameter semantics beyond the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists broadcast channels') and the scope ('for an Instagram professional account'), and adds a one-line explanation of what broadcast channels are. However, it doesn't name or contrast any sibling tools such as meta_get_broadcast_channel_messages, so sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is relevant by referencing Instagram professional accounts and one-to-many messaging, but it includes no explicit 'when to use' conditions, prerequisites, or alternatives. An agent can infer the use case but not distinguish it from related broadcast-channel tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the rate-limit context ('Limited to 30 unique hashtag searches per 7 days'), which goes beyond the readOnlyHint annotation. It also states that the tool returns recent searches. However, it does not mention pagination or the exact shape of the returned data, which is a minor omission given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with two short sentences and an args list. It avoids filler and repetition while delivering the key purpose and the limit note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description only vaguely says 'This returns the recent searches' without describing the response structure. It does not specify whether the result is a list, includes timestamps, or how pagination might work, leaving agents with limited information to interpret the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description identifies ig_account_id as 'Instagram account ID', but this adds little beyond the parameter name. response_format is already documented in the schema with its enum values. With schema coverage at 50%, the description only minimally compensates for the undocumented required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('gets') and resource ('hashtags recently searched by the Instagram account'), making the operation unambiguous. The name and the explicit phrase 'This returns the recent searches' further clarify the intent. Although it does not reference siblings by name, the resource is specific enough to distinguish from meta_search_instagram_hashtag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as meta_search_instagram_hashtag. The description only states what it does and a rate limit, without any selection criteria or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context beyond those annotations by naming the required pages_messaging permission and clarifying that this operation returns page inbox conversations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, followed by a compact Args list and a single permission note. Every line adds useful information without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation, the description covers the core call details and permission requirement, but with no output schema it does not describe the returned conversation shape or pagination behavior. It also leaves the relationship to sibling tools like meta_get_conversation_messages implicit, so the agent must infer when this tool is the correct choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description compensates for most gaps by explaining page_id, limit (max, range, default), and after as a pagination cursor. It omits response_format, but the input schema already describes that parameter's enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Lists conversations (messages) in a Facebook Page inbox.' It clearly identifies the Facebook Page scope and distinguishes it from Instagram conversation tools, though it does not explicitly differentiate from the sibling meta_get_conversation_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as meta_get_conversation_messages or meta_get_instagram_conversations. The only context provided is the pages_messaging permission requirement, which is a prerequisite rather than a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the 'video library' scope, which is useful, but says nothing about pagination, ordering, or return format, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, followed by a brief list of arguments. It is efficiently structured without unnecessary detail, though it could be slightly more organized by including format or pagination notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a read-only list operation, the essential call parameters are present and the purpose is clear. However, without an output schema, the description does not explain what fields each video entry contains, and the 'after' pagination parameter is unexplained, leaving some ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description carries responsibility. It explains ad_account_id and limit, but leaves 'after' completely undefined. The response_format parameter is only described in the schema. Thus it partially compensates for low schema coverage but with notable gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists videos in an ad account's video library', using a specific verb and resource. This distinguishes it from sibling tools like meta_list_ad_images or meta_upload_ad_video without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (listing videos) but does not explicitly state when to use it over alternatives, nor does it mention exclusions. There is no guidance on contexts where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description's 'Lists' wording is consistent and adds the scope of returned data (audience names, types, size estimates, delivery status). It provides value by enumerating the return payload beyond the annotation, though it does not note pagination cursor lifecycle beyond the after parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded with the core purpose; the Args block and return list are functional with minimal filler. Every sentence earns its place, though the response_format omission is a content gap rather than a structure flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly describes return values. For a list operation of moderate complexity it covers the core flow, but the undocumented response_format parameter means an agent cannot know the output can be markdown or json without inspecting the schema. This is a real but small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (ad_account_id and response_format documented in schema). The description compensates partially: it explains ad_account_id, limit (range 1–100, default 20), and after (pagination cursor), which adds meaning the schema's bare schema types lack. However, response_format is entirely undocumented in both schema and description, leaving an unresolved parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists custom audiences in a Meta ad account') and is clearly distinguishable from siblings like meta_list_saved_audiences and meta_list_custom_conversions. A later sentence names the concrete return fields (names, types, size estimates, delivery status), fully grounding what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings meta_list_saved_audiences, meta_list_custom_conversions, and meta_get_custom_audience are semantically close, and the description gives no differentiating context or exclusion criteria, so an agent must guess which list tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and non-destructive; the description adds a meaningful dependency on page tokens from meta_list_pages and lists the returned fields. This is useful behavioral context beyond the annotations, though pagination behavior is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and reasonably concise: purpose, context, prerequisite, args, and return values are each separated. It earns its length, though the Args section restates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the critical prerequisite and return fields, but it leaves the 'after' pagination parameter undocumented and does not mention pagination behavior. Given no output schema, the missing parameter context makes this only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats page_id and limit semantics already present in the schema and does not explain the 'after' parameter, which has no schema description. It also omits response_format, so the parameters are only partially covered and the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Lists lead generation forms for a Facebook Page.' It is clear about what the tool does, but it does not explicitly name or contrast with sibling tools such as meta_get_leadgen_leads, so differentiation is left to the reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit context: lead forms are tied to OUTCOME_LEADS campaigns, and it states a required prerequisite ('meta_list_pages must be called first to load page tokens'). It does not discuss when not to use the tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds 'permanently,' which usefully signals irreversibility. However, it does not disclose side effects on related ad structures, permission requirements, or behavior on failure, so it only modestly exceeds the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the first sentence states the core behavior clearly. The Args section is somewhat redundant with the input schema but does not add meaningful bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool, the description and annotations together cover what the tool does and what identifies the target. There is no output schema, so the response shape is not described, but that is a minor gap for a simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by defining ad_id as 'Ad ID to delete,' giving the parameter a semantic role rather than just a name and type. It does not provide format or source details, but this is sufficient for a single simple ID parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Deletes an ad permanently.' The 'ad' resource clearly distinguishes it from sibling delete tools like meta_delete_post, meta_delete_adset, and meta_delete_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives, no exclusions, and no prerequisites. The description only states the action, leaving the agent to infer usage from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=false, and the description adds meaningful context by stating the deletion is permanent. It does not discuss authentication or side effects like deleting replies, but the annotations carry much of the safety burden and the 'permanent' warning adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action and the key warning about permanence. The Args bullet duplicates the schema, which is slight redundancy, but overall the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive operation, the description covers the essential behavior and permanence, and the annotations cover the destructive and non-idempotent profile. It does not describe the return value, which is acceptable given the simplicity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes comment_id as 'Comment ID to delete' with 100% coverage. The description's Args section repeats that information without adding format details, source requirements, or ownership constraints, so it adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Deletes') and resource ('a comment on an Instagram media object'), making the tool's purpose unmistakable. It also adds 'This is permanent,' which helps distinguish it from non-destructive sibling tools like meta_hide_instagram_comment or meta_toggle_instagram_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as hiding a comment or deleting the entire media object. The permanence statement implies this is for irreversible deletion, but there is no explicit when-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (destructiveHint: true) and does not contradict them. However, it adds no additional behavioral context beyond the annotation, such as permanence, cascading effects, or error behavior. With annotations already covering the destructive nature, the description provides minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single purpose sentence and a parameter line. It is front-loaded with the action and avoids any fluff. Every word is purposeful, making it an model of efficiency for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic essentials but lacks context such as irreversibility (already implied by destructiveHint) or what happens on success/failure. It does not mention any prerequisites like access permissions or ownership. For a delete operation, this is a minor gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description's line 'pixel_id (string): Pixel ID to delete' adds essential meaning by clarifying the purpose of the parameter. Though brief, it effectively explains that the pixel_id identifies the pixel to be deleted, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action (deletes) and the specific resource (Meta Pixel). It is a clear, specific verb+resource statement that distinguishes from siblings like meta_delete_post or meta_delete_ad, since the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, irreversibility, or any context about when deletion is appropriate. The description lacks any when-to-use or exclusion criteria, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the behavioral constraint that one of the four IDs must be provided, which is useful but not deeply elaborated. No mention of rate limits, pagination, or response format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, starting with the purpose and following with a clear bulleted list of arguments. There is no redundant wording, and the 'Provide one of' callout is concise and helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only insights tool, the description covers the main selection logic but leaves gaps: it does not specify what happens if no ID is provided (contradicting the schema's zero required parameters), nor does it describe the output format or pagination. The response_format parameter exists in the schema but is not mentioned in the description, though it is documented there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, leaving six parameters undocumented. The description compensates by explaining the ID parameters (e.g., 'All ads in campaign') and giving a date format for since/until. It also clarifies the constraint of providing exactly one ID. However, it omits response_format, which is documented only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets performance insights at the individual ad level, which is a specific verb and resource. The 'ad level' scope differentiates it from siblings like meta_get_campaign_insights and meta_get_adset_insights. It also lists the key parameters, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on parameter selection ('Provide one of: ad_id, adset_id, campaign_id, or ad_account_id') but offers no guidance on when to use this tool versus other insights tools. It does not mention alternatives or conditions that would favor this tool, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful return-value context beyond annotations, specifying that winner, confidence level, and per-cell metrics are included. It does not discuss auth, errors, or output-format effects, but those are minor given the read-only annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main purpose, and uses an Args/Returns structure that is easy to scan. The Args section is somewhat redundant with the schema, but the overall size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter read-only tool with no output schema. The description names the required input and summarizes the return content well enough for an agent to invoke it; it does not over-explain, and the missing output-format details are already covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents study_id and response_format, including the enum and default. The description repeats study_id but adds no new semantic detail and does not mention response_format; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Gets') and resource ('detailed results of a specific A/B test (ad study)'). It distinguishes a single study's results from the sibling listing tool by using 'specific,' but it does not explicitly name meta_get_ad_studies or other alternatives, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need detailed results for one ad study. It gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as meta_get_ad_studies for listing studies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Lists' is consistent with those. The description adds no further behavioral context such as pagination, returned fields, or permission requirements, but the annotation coverage mitigates this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence states the core behavior, followed by a minimal args block. There is no filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with one required parameter, the definition is minimally sufficient: page_id is documented, response_format is covered by the schema, and annotations confirm safety. However, there is no output schema or description of the return shape, so an agent cannot anticipate what fields or pagination behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds mild value by clarifying page_id as 'Facebook Page ID', which is not in the schema. response_format is omitted from the description, but the schema provides a full explanation and a default, partially compensating for the low schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and a clear resource 'users blocked by the Facebook Page'. This makes the operation unambiguous and distinguishes it from related sibling tools such as meta_block_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 users blocked by a Facebook Page. However, there is no explicit guidance about when not to use it, prerequisites, or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds some context by specifying the professional-account scope and pagination behavior, but it does not disclose return shape, ordering, or relationship to other media endpoints. This is acceptable given the annotations, but not especially rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with the core purpose front-loaded and an Args block that efficiently covers each key parameter. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list operation with one required parameter, the description and schema together provide enough information to invoke the tool correctly. A mention of the returned media object shape would improve completeness since there is no output schema, but the absence is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful parameter detail beyond the schema: it explains where ig_account_id comes from, clarifies limit's allowed range and default, and marks after as a pagination cursor. It omits response_format, but that parameter is fully described in the schema, so the overall parameter guidance is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists media (posts, reels, stories) from an Instagram professional account, so an agent can identify the primary resource and action. It does not explicitly contrast itself with siblings like meta_get_instagram_single_media or meta_get_instagram_stories, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: it targets Instagram professional accounts and tells the agent to obtain ig_account_id from meta_list_instagram_accounts. However, it does not say when to choose this tool over closely related siblings such as meta_get_instagram_single_media, meta_get_instagram_stories, or meta_get_instagram_media_children, leaving usage conditions largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the extra requirement of 'Requires Instagram Shopping,' which is useful context not captured in annotations. However, it does not describe output format, pagination, or failure behaviors, so it only moderately extends beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence stating the purpose and a minimal args list. It is appropriately front-loaded and contains no unnecessary details, though the 'Args:' formatting is slightly informal. It earns its place without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required parameter, the description provides the essential purpose and the key prerequisite (Instagram Shopping). It is sufficient for an agent to understand what it does and how to invoke it, given the schema and annotations cover the rest. No output schema is present, so the description doesn't need to detail returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies media_id as 'Instagram media ID,' adding meaning beyond the schema's bare type definition. However, it does not mention the response_format parameter, which is fully documented in the schema. With 50% schema coverage, this partial compensation is adequate but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'product tags on an Instagram media object.' It is highly specific and distinguishes itself from sibling tools like meta_get_instagram_media by focusing solely on product tags, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus alternatives is provided. The only contextual hint is 'Requires Instagram Shopping,' which is a prerequisite rather than a usage directive. The intended use is implied by the name and description, but it does not mention alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful return-content context (price, availability, sale price, condition, inventory), which is helpful since no output schema exists. It does not disclose error behavior, auth requirements, or rate limits, but these are less critical for a simple read with strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Args section is slightly redundant with the schema but is minimal and does not add notable clutter. The Returns line provides valuable response details without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with complete schema coverage and strong annotations, the description is mostly sufficient: it names the required identifier, explains it is for a single product, and lists key return fields. A minor gap is that it does not clarify how product_id relates to product catalogs or feeds, but this does not block correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, including the response_format enum and default. The description only restates product_id without adding new meaning and does not mention response_format, so it adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Gets details for a single product.' It distinguishes this tool from siblings like meta_list_products, meta_create_product, meta_update_product, and meta_delete_product by emphasizing 'single product' and focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need details for one specific product by product_id. However, it does not explicitly state when not to use it or mention alternative tools like meta_list_products for browsing multiple products. The usage context is present but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the eligibility-filter behavior, but it does not disclose pagination behavior, return shape, or any rate-limit considerations. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, followed by a compact args list. It has minimal filler, though the args section partially repeats schema type information. Overall it is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description covers the essential purpose and core parameters, but it misses 'after' and 'response_format', and there is no output schema to compensate. It is sufficient for a minimal call but has clear gaps around pagination and output controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, so the description carries a heavier burden. It explains page_id and limit, but completely omits 'after' (a pagination cursor) and 'response_format' (output control). An agent reading only the description would not know how to paginate or request JSON output, leaving important parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Gets posts that are eligible for boosting/promotion on a Facebook Page.' This clearly identifies the tool's purpose and distinguishes it from siblings like meta_get_posts or meta_get_published_posts by emphasizing the promotion-eligibility filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: use this when you need posts that can be boosted or promoted. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5, but the context is unambiguous enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that: no mention of pagination, rate limits, result structure, or any side effects. It merely restates the purpose, providing no extra value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence summary followed by a minimal argument list. It is front-loaded with the action and scope, and every word earns its place. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not hint at the return shape (e.g., an array of rule objects), pagination, or what fields are included. For a list operation, this lack of output information leaves a gap, though the simplicity of the tool and the read-only annotations somewhat reduce the risk of misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents ad_account_id as 'Ad account ID', adding meaning beyond the schema's type-only definition. The response_format parameter is described in the schema itself (markdown/json with a default), and the tool description compensates for the schema's missing description of ad_account_id. Together, both parameters are well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists'), a resource ('automated rules'), and a scope ('for an ad account'), making it clear what the tool does. This clearly distinguishes it from the sibling meta_get_ad_rule, which retrieves a single rule, and from meta_create_ad_rule or meta_delete_ad_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need all rules for an ad account) but does not explicitly mention alternatives or exclusions. For example, it does not say 'Use meta_get_ad_rule to fetch a single rule.' The guidance is left to inference from the tool name rather than being spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by stating the returned fields (product IDs, names, prices, availability) and exposing pagination/filtering behavior, which are not visible in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with an Args bullet list and a Returns sentence. It is slightly redundant with the schema's parameter descriptions, but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with strong annotations and high schema coverage, this is largely complete: it states required catalog_id, optional limit/after/filter, and return fields. Minor gaps are the vague 'and more' return description and no explanation of filter operator semantics, but these are not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so params are already documented. The description mainly restates catalog_id, limit, after, and filter with the same meanings; it adds no new parameter details and omits response_format, though the schema covers it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('products in a product catalog'), and the required catalog_id clarifies scope. It is clear enough to separate from siblings like meta_get_product, meta_list_product_catalogs, and meta_list_product_sets, though it does not 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool is implied to be used when you need to enumerate products within a given catalog, supported by catalog_id, pagination, and filter arguments. There is no explicit statement of when to use an alternative (e.g., meta_get_product for a single product) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation that is not destructive in the deletion sense. The description adds no additional behavioral context, such as whether setting status to PAUSED stops delivery or ARCHIVED permanently removes the ad from rotation. It merely restates the allowed enum values, which are already defined in the input schema. Thus, it adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — a single clear verb phrase followed by a compact parameter list. It front-loads the action and avoids extraneous text, making it efficient for an agent to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple update tool with 4 parameters, no output schema, and no nested objects. The description covers the core action and three of the parameters, but it omits the response_format parameter and does not address potential ambiguity around whether name and status are mutually exclusive or if at least one is required. The schema fills some gaps, but the description leaves room for misuse or confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only response_format has a description). The tool description lists ad_id, name, and status, providing some meaning (e.g., 'New name', allowed status values), but it omits response_format entirely. It also does not clarify whether at least one of name or status must be provided, or if both can be updated together. The schema's enum and response_format description partially compensate, but the description does not fully address the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('updates') and a resource ('an existing ad'), and it names the editable fields ('status or name'). This clearly distinguishes it from sibling tools like meta_create_ad (creates) and meta_update_adset (updates an ad set).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this tool is for updating an existing ad's status or name, but it does not mention any exclusions or alternatives (e.g., 'use meta_create_ad to create a new ad'). It also does not state any preconditions beyond having an existing ad_id, but the purpose is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It adds useful behavioral context: 'Only provided fields are changed' and the caveat about soft opt-out allowing up to 5% spend. However, it does not disclose permissions, reversibility, side effects, or what happens when fields are omitted beyond the stated partial update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses a clear bulleted list for arguments. Every sentence adds value, and the 'Only provided fields are changed' note is placed prominently. No redundant fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers all key behavior and parameters except response_format. It explains scoping (only provided fields change), the soft opt-out caveat, and field formats. Missing return-value details and prerequisites are minor given the tool's straightforward update action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description compensates well by explaining most parameters in plain terms: daily_budget in cents, end_time in ISO 8601, status enum values, and placement_soft_opt_out behavior. However, it omits the response_format parameter entirely, which is present in the schema and has its own description, so not all parameters are covered in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation with a verb and resource: 'Updates an existing ad set. Only provided fields are changed.' It also communicates partial-update semantics, which distinguishes it from a full replace. It doesn't explicitly name sibling tools like meta_update_ad or meta_update_campaign, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'updates' and the resource 'ad set', and the phrase 'Only provided fields are changed' implies a PATCH-like behavior. However, it gives no explicit 'when to use this vs. meta_create_adset or meta_update_ad' guidance, and no conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the two-step flow (creates a container, then publishes) and returns a Media ID, which is useful context beyond annotations. However, annotations are minimal (readOnlyHint false, destructiveHint false) and do not cover failure modes, rate limits, or idempotency implications. The description does not disclose any potential side effects or requirements, so it only partially meets the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a short intro and an args list. It front-loads the two-step flow, which is useful. However, the args list largely duplicates schema descriptions, adding some redundancy. Still, it is well-structured and efficient for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GIF publishing tool, the description covers the essential elements: it identifies the input (GIPHY URL), the two-step mechanism, and the return value. It does not delve into prerequisites like authentication or rate limits, but given the schema and sibling context, it is adequately complete for an agent to invoke correctly. Lack of output schema is offset by the explicit return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the baseline is 3. The description repeats parameter names and meanings that are already in the schema, adding little extra value. It does clarify the two-step flow, which indirectly explains how parameters are used, but doesn't provide syntax or format details beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it publishes a GIF post to Threads using a GIPHY URL, which is specific and distinguishes it from other Threads publishing siblings like threads_publish_image or threads_publish_video. The verb 'publishes' and resource 'GIF post' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for GIF-specific posting but does not explicitly mention when to use this versus other publishing tools. It lacks exclusions or alternative recommendations, though the mention of 'GIPHY URL' signals the intended use case. Minimal guidance compared to the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the description's 'Permanent action' adds only slight emphasis. It also explains that page_id is used 'for authentication,' which is useful context not in the schema. However, it does not disclose error handling, reversibility beyond permanence, or any other behavioral traits that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences followed by a clean argument list. The action and permanence are front-loaded, and every sentence adds value. There is no redundant or irrelevant text, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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) and the safety-related annotations (destructiveHint, not idempotent), the description provides adequate context. It specifies the scope (Facebook Page post), the permanence, and authentication role of page_id. The schema itself adds the prerequisite to call meta_list_pages first. Nothing critical for basic invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (page_id described, comment_id not). The description compensates by listing both parameters and adding meaning: comment_id as 'the Comment ID to delete' and page_id as 'for authentication,' which clarifies purpose. This goes beyond the bare schema types and provides necessary context for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Deletes a comment on a Facebook Page post') with a clear resource and scope. It distinguishes itself from sibling tools like meta_delete_post or meta_delete_instagram_comment by explicitly noting Facebook Page comments. The addition of 'Permanent action' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as meta_hide_comment (which hides rather than deletes) or meta_delete_instagram_comment. It does not mention any prerequisites beyond authentication, nor does it suggest when deletion is appropriate. The only usage hint is 'Permanent action,' which warns of consequences but does not direct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds 'This action is permanent and cannot be undone,' reinforcing the destructive hint with irreversibility. This provides additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence for the action, a simple Args block, and a one-sentence permanence warning. It is front-loaded and contains no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the action, input, and permanence, and the annotations cover the safety profile. It does not elaborate on cascading effects or return values, but these are not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes product_id as a required string 'Product ID' with 100% coverage. The description repeats this information without adding extra meaning such as format, source, or validation rules. Since schema coverage is high, baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deletes a product from a catalog' with a specific verb and resource. It is clearly distinct from sibling tools like meta_get_product, meta_create_product, and meta_update_product by naming the delete operation and the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that meta_update_product should be used for modifications, nor does it give any contextual conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it supports breakdowns and date presets, but does not elaborate on return format, pagination, or other behavioral details. Since annotations cover the main safety aspect, a score of 3 is appropriate for the additional behavioral context provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear purpose line and a concise, structured argument list. It is front-loaded with the main purpose and parameter details, with no unnecessary verbiage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main identifier parameters and date range but omits response_format and any details about the expected return values. With no output schema and low schema coverage, this leaves significant gaps for an agent to know what to expect from the tool. It is only partially complete and lacks important context for full usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 38%, so the description carries significant burden. It explains the purpose of each identifier (ad_account_id for all ad sets, campaign_id for all in a campaign, adset_id for a specific one), and includes the default for date_preset. It also clarifies the relationship between since/until and date_preset. However, it omits response_format and gives minimal detail on breakdowns, which prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('performance insights for ad sets'). It clearly identifies the tool's purpose and distinguishes it from other insight tools by name and resource. It is not a tautology and conveys a concrete action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes usage instructions for identifier selection ('Provide ad_account_id or campaign_id or adset_id') and explains the scope of each identifier. However, it does not explicitly contrast with sibling tools like meta_get_campaign_insights or meta_get_ad_insights, and lacks exclusions for when not to use this tool, leaving the when/alternative guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and destructiveHint=false, and the description's 'Gets' aligns with that. The description adds the carousel-media scoping but does not disclose output composition, pagination, or authentication requirements; the annotation coverage keeps this acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the purpose, and contains no filler or boilerplate. The Args block is minimal and directly tied to the required parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required parameter and no output schema, the description states what is retrieved and what media_id refers to. It is mostly complete, though it does not mention return-shape details or pagination and does not help disambiguate among the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes response_format, while media_id has no schema description, so the description's 'Carousel media ID' fills a real gap. However, it is a thin label that does not explain how to obtain or validate the media_id, and it adds no extra meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('individual media items in a carousel/album post'), so an agent immediately understands what this tool does. The carousel/album qualifier clearly distinguishes it from generic media tools like meta_get_instagram_media and meta_get_instagram_single_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving child media items of a carousel/album post, but it never states when to prefer this over related tools like meta_get_instagram_media, meta_get_instagram_single_media, or threads_get_media_children. It provides no explicit alternatives, exclusions, or precondition guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a minor nuance by specifying 'custom tabs' (excluding default tabs), but does not disclose pagination, rate limits, or error scenarios. Given the strong annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence followed by a concise Args list. It is front-loaded with the purpose and includes only necessary parameter documentation, with no extraneous content. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with annotations covering safety, the description is largely complete. It specifies the action and the required parameter. However, it omits details about the return format (e.g., list of tab objects) and any authorization requirements, which could be relevant for an agent. Since no output schema is provided, a bit more context would be beneficial, but the core need is satisfied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: response_format has a description in the schema, while page_id does not. The description compensates by explicitly stating 'page_id (string): Facebook Page ID,' adding meaning for that parameter. The other parameter is already documented, so overall the description fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Lists custom tabs on a Facebook Page,' with a specific verb, resource, and scope. It distinguishes itself from sibling tools, none of which deal with page tabs, so there is no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as page admin permissions or access token requirements. The only usage hint is implicit in the action of listing tabs, which is insufficient for an agent choosing between many similar getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only and non-destructive. The description adds useful behavioral context beyond that: a two-step API process and a concrete rate limit of 30 unique hashtag searches per 7 days per IG account. It stops short of describing error cases or exact 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, then parameters, then a quota note. The two-step process sentence is slightly redundant with the opening sentence, but the overall text is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers required parameters, defaults, auth context, and the key rate limit, which is enough for an agent to select and invoke the tool correctly. There is no output schema, and the description stays vague on the exact shape of returned media, but invocation-critical information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema description coverage, the description compensates well by explaining ig_account_id as auth context, hashtag format, edge options, and the limit range. However, response_format is omitted from the description, and the meaning of top_media versus recent_media is not elaborated beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: search a hashtag, get its ID, then retrieve top or recent media. It is clear about the resource and action, but it does not explicitly distinguish itself from sibling tools like meta_get_instagram_recent_hashtags or meta_get_instagram_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an agent needs media for a hashtag, and it explains the two-step flow. However, it does not provide explicit when-to-use guidance, exclusions, or alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only false, idempotent true, and destructive false. The description adds a useful behavioral dependency (page tokens must be loaded via meta_list_pages) and explains when the message is visible. No contradiction with annotations; it could disclose more about output/errors but is adequate for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and prerequisite are front-loaded and concise. However, the Args section largely duplicates the already complete input schema, so some content does not earn its place; it is compact but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple settings tool with full schema coverage and annotations, the description provides the key prerequisite and behavioral context. It does not explain output/return values, but the response_format parameter in the schema covers format selection, and no output schema makes return details less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates page_id, message, and enabled almost verbatim and omits response_format; it adds slight value by tying page_id to the prerequisite token loading, but not enough to raise above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Sets the away message for a Facebook Page') and adds the display condition ('shown when the page is set to away mode'). It does not explicitly contrast with sibling settings tools like meta_set_instant_reply or meta_set_greeting, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite ('meta_list_pages called first to load page tokens') and the context of when the message applies. It does not explicitly state when not to use it or name an alternative tool, but the context and prerequisite provide clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false), idempotency, and non-destructiveness. The description adds the permission requirement but doesn't clarify partial-update semantics, rate limits, or failure behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A succinct mission statement followed by a well-organized parameter list with examples. The description is front-loaded and adds necessary information not present in the schema, with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters, and mentions the permission, but misses partial-update behavior, return value, and potential rate limits. For a 10-parameter mutation tool with no output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed semantics for all 10 parameters, compensating for the low 40% schema coverage. It includes clarifications (about vs description), examples for hours and category, and describes nested contact_address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates a Facebook Page's profile information, specifying the resource and the action. Lists the fields it covers, distinguishing it from sibling tools like meta_update_page_picture or meta_update_page_cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions the required permission but does not say when to prefer this over other update tools, nor provides exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral constraints: follower_demographics requires 100+ followers and since is required for time-series metrics. No contradictions found. It doesn't cover rate limits or auth, but those are not needed for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized as a bulleted list of arguments with clear labels. It is front-loaded with the main purpose and then details parameters efficiently. No wasted words, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and schema covers only breakdown and response_format, the description explains most parameters and their constraints. It omits response_format (but schema documents it) and default metrics (schema has default). Overall, it covers all critical usage details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only breakdown and response_format have descriptions), but the description compensates by explaining the metrics list, since/until format, breakdown options, and dependencies. It adds significant meaning beyond the schema, especially for metrics and date parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Gets account-level metrics for the authenticated Threads user.' This is a specific verb-resource pair that distinguishes it from per-post tools like threads_get_post_insights, though it does not explicitly name that sibling. The scope is evident from 'account-level.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (account-level vs. post-level, follower threshold for demographics, since required for time-series) but does not explicitly route users to alternative tools. It implies usage based on scope and requirements, but lacks direct comparisons to siblings like threads_get_post_insights.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a mutating, non-idempotent, non-destructive write operation. The description adds useful context that the rule is automated and can execute actions such as PAUSE via execution_spec, but it does not disclose side effects, permissions, or lifecycle behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short summary followed by a tight argument list with examples. Every line earns its place, and the JSON examples are dense but necessary given the complex object parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with the schema, the description is sufficient to construct a valid create-rule request: all required parameters are named and illustrated, optionality is marked, and response_format is documented in the schema. It could be stronger by stating the return shape or default schedule behavior, but these are not blockers for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description carries nearly all parameter meaning. It explains each argument and provides concrete JSON examples for evaluation_spec, execution_spec, and schedule_spec, which is essential for correctly forming complex nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates an automated rule for managing ads, ad sets, or campaigns.' This clearly distinguishes the tool from siblings like meta_create_ad, meta_create_adset, and meta_list_ad_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The intended use must be inferred from the verb 'Creates' and the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation destructive and non-read-only, and the description adds the crucial warning 'This cannot be undone,' which is not in the structured metadata. It also reveals that deletion is actually an archival action, providing meaningful clarity about the underlying behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action and irreversibility before the argument block. The Args section is redundant with the input schema, but the overall length is appropriate for a one-parameter tool. There is no filler or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive mutation tool, the description plus annotations and schema covers the essential facts: what is deleted, that it is archival, and that the operation is irreversible. It does not describe return values, permissions, or effects on child adsets and ads, but these are not necessary to invoke the tool correctly. The absence of an output schema is not a critical gap here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage and already documents campaign_id as 'Campaign ID'; the description only restates it as 'Campaign ID to delete' without adding format, source, or likely-value guidance. This meets the baseline for high schema coverage but provides no extra semantic value. The agent gains nothing beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Deletes (archives)') and resource ('a campaign'), and the irreversibility warning clarifies the operation's meaning. This clearly distinguishes it from sibling delete tools for ads, posts, and adsets by targeting the campaign resource. No ambiguity about what the tool operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this is the destructive campaign-removal operation, which differentiates it from meta_get_campaign, meta_update_campaign, and other campaign tools by implication. However, it never explicitly states when to use this tool rather than an alternative or mentions prerequisites such as pausing or listing campaigns first. The usage guidance is adequate but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the returned metrics (spend, impressions, clicks, CTR, actions) but does not disclose other behaviors such as rate limits, auth requirements, or response size. With annotations handling safety, this adds some value but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then organized into an args list plus a return note. It is reasonably concise for a 7-parameter tool, with each parameter earning its place through added semantics. Slight verbosity in the args list is justified by the need to compensate for schema gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, how to filter, date ranges, breakdowns, and the returned metrics. For a read-only insights tool with no output schema, it provides sufficient guidance. It does not mention pagination or limitations, but these are minor given the read-only annotation and clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, but the description compensates by explicitly documenting the uncovered parameters: since, until, and ad_account_id. It also adds context for campaign_id ('omit for all') and date_preset ('default: last_30d'). The breakdowns list is duplicated but with useful examples. This goes beyond the schema to clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Gets performance insights for campaigns in a Meta ad account.' It clearly distinguishes from sibling insight tools like meta_get_account_insights and meta_get_adset_insights by specifying the campaign level. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'for campaigns' but no explicit alternatives or exclusions are given. An agent would infer this is campaign-level versus other levels, but there is no guidance on when to choose this over meta_get_account_insights or meta_get_ad_insights. Clear context exists, but no direct routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the note that page_id is for authentication, which is useful, and mentions the limit range. However, it does not describe return format, pagination behavior (despite the 'after' parameter), error conditions, or rate limits – context an agent might lack without an 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses a clean list for parameters. No redundant words; every sentence earns its place. It efficiently communicates the necessary parameter hints without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what the tool returns (e.g., a list of messages, format, any metadata). It does not. It also lacks mention of pagination handling or error behaviors. For a read-only tool with annotations, it covers the essentials but misses return details that an agent would benefit from, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only response_format has a description). The description explains page_id (for auth), conversation_id (source), and limit (max messages, range). It does not explain the 'after' parameter (pagination cursor) and does not repeat response_format since the schema already covers it. This partially compensates for the low coverage but misses a key pagination param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Gets messages from a specific Page conversation' – a clear verb+resource pair that distinguishes it from sibling tools like meta_get_instagram_messages (which fetch Instagram messages) and meta_get_page_conversations (which lists conversations, not messages). The specificity to 'Page conversation' removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by instructing that conversation_id comes from meta_get_page_conversations, establishing a workflow. It does not explicitly state when not to use it or name alternative tools (e.g., for Instagram), but the 'Page' qualifier and the sourcing hint provide enough context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by disclosing the required permission and the exact return content (catalog IDs and names), and nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose is the first sentence, followed by short Args/Returns/Requires blocks. The Args block is mildly redundant with the schema, but the overall structure is scannable and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 no nested objects and no output schema, the description covers what it returns, the required permission, and the applicable account type. Minor omissions like pagination behavior and edge cases (e.g., non-professional accounts) keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both ig_account_id and response_format already fully described in the schema. The description's Args section only restates the schema's parameter documentation and adds no syntax, format, or edge-case detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Lists product catalogs available for Instagram Shopping') and scopes it to a professional account, which distinguishes it from siblings like meta_list_product_catalogs and meta_get_product_catalog. It also states the downstream purpose (product tagging), making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context — professional account, product-tagging use case, and the required instagram_shopping_tag_products permission — but it never names sibling alternatives such as meta_list_product_catalogs or meta_get_product_catalog, nor states when this tool should be chosen over them. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond what annotations provide, but it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a minimal Args line. It is front-loaded with the core purpose and contains no filler. Every part serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description conveys the basic action. However, there is no output schema and the description does not indicate the shape or contents of the returned CTA data. This is a moderate gap for an agent that may need to process the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaning for page_id, which lacks a description in the schema. response_format is already documented in the schema with its default and purpose. Together, schema and description fully cover the parameters, with the description compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets'), resource ('call-to-action button'), and scope ('configured on a Facebook Page'). This clearly differentiates it from siblings like meta_get_page or meta_get_posts because the resource is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the CTA button, but it does not explicitly name alternatives or when-not-to-use. Since no sibling tool retrieves the same resource, the context is clear, but explicit routing is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the specific behavioral context that it returns only Page-published posts and excludes visitor posts, which is not in the annotations. This is useful beyond the basic read-only implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is a single, front-loaded sentence that immediately conveys the key purpose and exclusion. The Args block is somewhat redundant with the schema but is brief and doesn't bloat the description. Overall, it is efficient with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and main exclusion, but it omits details about pagination (after parameter), response format, and return structure. While the tool is a simple read and annotations handle safety, the two undocumented parameters leave gaps that could affect correct 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), and the description only mentions page_id and limit, repeating basic info already in the schema (type, default, range). It does not explain 'after' (pagination cursor) or 'response_format', leaving two parameters undocumented. The description does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and resource ('posts published by the Page itself'), and explicitly differentiates from the feed edge by excluding visitor posts. This clearly identifies the tool's scope and distinguishes it from sibling tools like meta_get_posts and meta_get_visitor_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear 'when-not' condition (excludes visitor posts) and references an alternative ('unlike the feed edge'), giving the agent a decision point. It does not explicitly name sibling tools or cover other usage scenarios, but the key distinction is enough to guide correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the burden. It discloses the return value as 'Comment ID of the reply' and clarifies which ID to supply. However, it does not mention permissions, rate limits, or what happens when comment_id is omitted, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an args list and a returns line. It has no filler, front-loads the purpose, and conveys the key optionality and ID disambiguation concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations, the description provides the return value and key parameter distinctions. However, it is ambiguous what happens when comment_id is omitted (whether it posts a top-level comment on the media), and it lacks prerequisites or error conditions. The response_format is only covered by the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial meaning beyond the schema. It clarifies that media_id is 'not the comment ID' and that comment_id is optional, 'If replying to a specific comment,' which goes beyond the schema's wording. The response_format default is only in the schema, so no repetition is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Replies to a comment on an Instagram media object,' using a specific verb and resource. It also distinguishes from related tools by clarifying that media_id is 'not the comment ID,' which helps separate it from Facebook comment reply tools like meta_reply_post_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies usage by naming the Instagram media object, and the tool name and sibling list provide context, but it doesn't state exclusionary conditions or mention that this is for Instagram rather than Facebook comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, idempotent, non-destructive operation. The description adds useful behavioral context beyond that: the reply is sent immediately when someone messages the page, and page tokens must be loaded first via meta_list_pages. This gives the agent a clearer operational picture than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a prerequisite and a concise param list. The Args block somewhat duplicates the schema, but it is short and useful for quick comprehension, so the structure remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with four parameters, this description is largely complete: it explains the tool's behavior, names the required parameters, defaults, and a key prerequisite. It does not describe the return value or error scenarios, but with no output schema and simple semantics, the provided information is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the three main parameters (page_id, message, enabled) with definitions essentially matching the schema, and omits response_format entirely. It adds no substantive meaning beyond the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Sets the instant reply message for a Facebook Page' and explains the behavior ('automatic message sent immediately when someone messages the page'). It does not explicitly call out sibling tools like meta_set_away_message or meta_set_greeting, but the instant-reply concept is precise enough to differentiate it in most cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives important usage context by explaining what the instant reply is and when it fires. It also states an explicit prerequisite: 'Requires: meta_list_pages called first to load page tokens.' It does not discuss when to prefer this tool over related automated-response tools, but the context provided is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description isn't burdened with stating safety. However, it adds minimal extra behavior: it lists metrics and says returns metric values. It doesn't mention the response_format parameter or any potential side effects, but annotations cover the safe read nature, so a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus argument details. The purpose is front-loaded, and every sentence adds value. No fluff or repetition. It's well-organized with an args list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should be more explanatory about the return format. It says 'Returns: Metric values for the post' which is vague. It also omits the response_format parameter, which is in the schema but could affect how results are presented. Without an output schema, an agent might not know what to expect in the response. Given the simplicity, more detail on the response structure would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema for media_id ('Threads media ID') and metrics (lists valid options: views, likes, replies, reposts, quotes, shares, reach, saved). It also clarifies the return type. However, it does not describe response_format, though the schema does with a description. Since schema coverage is 67% and the description helps fill gaps for two params, this is above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets performance metrics for a specific Threads post. This distinguishes it from user-level insights tools like threads_get_user_insights and Facebook post insights tools like meta_get_post_insights. The verb 'Gets' plus the resource 'specific Threads post' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you need a media_id for a specific post) but provides no explicit when-to-use vs alternatives. It doesn't mention that this is for single-post metrics as opposed to user-level or aggregate metrics, and doesn't reference sibling tools. The purpose is clear but no exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: the two-step flow (creates a container, then publishes it). This is beyond the annotations, which are minimal (readOnlyHint=false, etc.) and don't reveal this internal process. It also states the return value (Media ID). While it doesn't mention potential intermediate states or failure handling, the two-step disclosure is valuable and adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a two-sentence overview, an Args list, and a Returns line. It front-loads the core purpose but repeats some parameter details already in the schema (e.g., text length). Still, it is efficient and scannable, earning a 4 rather than a 5 due to slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a publish operation with seven parameters, this description is fairly complete: it explains the two-step process that involves a container creation, a crucial detail for understanding the API call pattern, and describes the return value. It does not cover all parameters (though schema handles them) nor error handling, but it hits the key points for invoking the tool correctly. The presence of the two-step flow and return type makes it complete enough for an agent to act.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the baseline is 3. The description lists only 4 of 7 parameters and adds little beyond what the schema already provides (e.g., text max length matches schema). It omits location_id, reply_control, and response_format, but the schema describes those well. The description does not compensate for the missing 14% coverage, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Publishes a text-only post to Threads' – a specific verb and resource that distinguishes it from sibling publishing tools (image, video, carousel, gif, link) by explicitly saying 'text-only'. This makes the tool's intent unambiguous without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for text-only posts but does not explicitly mention alternatives or when to choose this over sibling publishing tools. An agent could infer from the name and siblings, but there is no direct guidance like 'for images use threads_publish_image'. It provides context but no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The note 'Video processing may take time. Polls for up to 60 seconds.' adds useful behavioral context beyond annotations, which are all false. This informs the agent about async behavior and latency, though it doesn't cover all aspects like idempotency (annotations say false) or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines plus a note, front-loading the purpose. It is efficient but incomplete, as it only mentions a subset of parameters, which could mislead an agent that doesn't inspect the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers only 3 parameters and doesn't mention location_id, reply_control, or response_format. It also omits return value details. However, the schema descriptions cover those params, and the polling note is valuable. Overall, it's moderately complete but relies heavily on schema for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists only three parameters (threads_user_id, video_url, text) and adds minimal semantic value: it only describes 'text' as 'Caption text', which is not in the schema. The other three parameters (location_id, reply_control, response_format) are omitted entirely, and video_url/threads_user_id are just restated. With schema coverage at 67%, the description should compensate for undocumented params but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Publishes a video post to Threads.' This is specific and distinguishes it from sibling tools like threads_publish_text and threads_publish_image by explicitly mentioning 'video post'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for video posts, but no explicit when/when-not or alternatives are mentioned. The context is clear that it's for video, but it doesn't state to use this over text/image tools. Still, the purpose alone gives adequate context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the possible status codes and clarifies the purpose, but does not mention polling behavior or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the purpose stated first, followed by clear Args and Returns sections. Every sentence adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool, the description covers the essential purpose, the required parameter, and the expected return values. It could mention polling behavior or retry logic, but for a read-only, idempotent operation with annotations covering safety, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains container_id as 'Container ID from a publish step', adding meaning beyond the schema, which has no description for it. The response_format parameter is already documented in the schema, so the description doesn't need to repeat it. This compensates for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (checks publishing status) and the specific resource (Instagram media container), and adds context that it's for reels/videos needing processing. This distinguishes it from publishing or limit-check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a publish step but does not explicitly compare it to sibling tools like meta_check_instagram_publishing_limit or provide conditions for when not to use. However, the context makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the either/or input constraint, which is a usage constraint rather than a behavioral disclosure, and does not mention return format or error handling, but the read-only nature is well established by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core purpose, and presents the arguments in a scannable list. The final 'Provide either ad_id or creative_id' is a necessary constraint, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, key parameters, and the mutual-exclusion constraint. There is no output schema, so a note about the response structure would have been helpful, but the description already states it generates a preview URL. Missing edge-case behavior for providing both or neither ad_id and creative_id is a minor gap, but the tool is otherwise clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only response_format has a schema description), so the description must compensate. It explains ad_id, creative_id, and ad_format, but lists only five of the seven enum values for ad_format, omitting MARKETPLACE_MOBILE and AUDIENCE_NETWORK_OUTSTREAM_VIDEO. It does not mention response_format, but that parameter already has a schema description, so overall it adds meaningful semantics for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generates' and names the resource 'preview URL for an ad or creative,' which clearly distinguishes this from sibling tools like meta_get_ad or meta_get_ad_creative that retrieve details. It also explicitly lists the two mutually exclusive identifiers, making the core function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the 'Provide either ad_id or creative_id' constraint, but this is an argument-level guideline, not a tool-selection guideline. It does not explicitly state when to prefer this tool over siblings such as meta_get_ad or meta_get_ad_creative; the intended context is implied by the word 'preview' rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the purpose of verifying pixel firing, which is useful context but does not disclose additional behavioral traits such as rate limits, default date ranges, or output structure. Given the annotations cover the main concerns, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the purpose, followed by a clear and minimal argument list. No fluff, every word earns its place. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only stats tool with no output schema, the description covers the essential aspects: what it does, key parameters, and a typical use case. It does not specify default date ranges or the exact structure of the returned data, but those are not critical for a basic call. It is nearly complete, with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only response_format has a description). The description compensates by clarifying each parameter: pixel_id is a string, start_time/end_time are ISO dates, aggregation defaults to 'event' and has options, and event provides an example ('Purchase'). This adds meaningful value beyond the schema, which lacks descriptions for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets'), a clear resource ('pixel'), and the exact output ('event volume stats'). It also adds a use case ('critical for verifying pixel is firing') that distinguishes it from sibling pixel tools like meta_get_pixel (configuration) and meta_get_pixel_events (event details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('verifying pixel is firing') but does not explicitly mention alternatives or when not to use this tool. It implies a specific scenario but leaves it to the agent to infer that other pixel tools might be better for different tasks. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds little behavioral detail beyond the listing operation itself—no pagination, ordering, or 'all labels' semantics—but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the action and scope in the first sentence, adds a brief relevant context sentence, and includes only the necessary argument documentation. No redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 one required parameter, the description provides enough to call it correctly. It lacks details about the exact shape of the returned labels (e.g., id, name) and pagination, but given the strong annotations and minimal parameter set, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section documents ad_account_id as 'Ad account ID', which fills the gap left by the schema's missing description for this required parameter. The response_format parameter is already well described in the schema with an enum and default, so the description appropriately does not repeat it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('ad labels') scoped to an ad account. This clearly differentiates it from sibling tools like meta_create_ad_label and other list tools such as meta_list_ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case—retrieve ad labels for an ad account—and gives light context ('Labels help organize campaigns, ad sets, and ads'). However, it does not explicitly state when to use this tool versus alternatives like meta_create_ad_label, or mention any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, so the mutation implied by 'Uploads' is consistent and adds little. The description adds useful context by stating the image is placed in the ad account's image library and returns an image hash for creatives, but it does not disclose side effects such as overwrites, duplicate handling, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with the core statement first followed by Args and Returns sections. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately parameterized upload tool with no output schema, the description gives enough to call it successfully: required parameters, optional name, and the returned image hash for creatives. The main gap is lack of guidance among upload alternatives, but the core invocation contract is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section documents ad_account_id, url, and name with functional descriptions, supplementing the schema where ad_account_id and name lack property descriptions. It omits response_format, but the schema fully describes that parameter with an enum, default, and description, so the omission is not harmful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Uploads an image to an ad account's image library for use in creatives.' This distinguishes it from sibling tools such as meta_list_ad_images, meta_upload_ad_video, and meta_create_ad_creative by stating exactly what artifact it creates and where it lives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for use in creatives' implies the intended use, and the return value mentions when it is needed, but there is no explicit when-to-use guidance or comparison with alternatives like meta_upload_ad_video. An agent must infer from the tool name and sibling list which upload tool to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a little context by clarifying that the result is a set of individual carousel items, but it does not describe pagination, response shape, or any other behavioral traits beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded. The purpose statement is the first sentence, and the Args block provides the only necessary parameter clarification. There is no filler, redundant phrasing, or content that merely repeats the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only, idempotent tool with only two parameters and no output schema, the description is largely complete. The only minor gap is that it does not explicitly mention the response_format default behavior in the Args block, but the schema already documents that parameter and its enum options. Overall, the description gives enough context for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves media_id undocumented, but the description compensates by stating 'media_id (string): Carousel media ID.' The other parameter, response_format, is already fully documented in the schema with enum values and a default. Together, the description and schema give sufficient semantic coverage for all parameters despite the 50% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Gets individual items in a Threads carousel post.' This clearly differentiates the tool from related siblings like threads_get_post or threads_get_replies by focusing on carousel children specifically. The title reinforces the same purpose without adding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an agent needs the individual media items inside a Threads carousel post. However, it does not explicitly state when not to use it or name alternative tools that might be better suited for related tasks such as fetching the carousel post itself or its replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context: it lists posts, supports pagination via 'after', and allows date filtering with 'since'/'until'. It does not describe the response format or error conditions, but with annotations covering core behavior, this is sufficient for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose followed by a structured Args list. The main action is front-loaded. While the Args list duplicates some schema defaults (e.g., limit min/max), it also provides new clarifications like date format. The structure is clear and does not waste words, though it could be slightly more concise by omitting redundant defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has six parameters and no output schema, so the description should cover key return and usage details. It explains the listing purpose and pagination cursor, but does not describe the response structure, how to use the 'after' cursor (e.g., from a next_page_token field), or the effect of response_format on output. Given the lack of an output schema, this is a notable gap; a more complete description would mention response format and pagination mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It does for most parameters: threads_user_id is annotated as coming from threads_get_profile, limit has range and default clarified, since/until have date format specified, and after is identified as a pagination cursor. The only omitted parameter is response_format, but that is already described in the schema. Thus the description adds value beyond the schema for previously undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Lists') and a clear resource ('the authenticated user's Threads posts'), which distinguishes it from siblings like threads_get_post (single post), threads_get_replies, and threads_get_post_insights. It also clarifies scope as the user's own posts, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing a user's posts but does not explicitly state when to prefer this over alternatives or when not to use it. It gives no guidance on exclusions (e.g., don't use for replies or insights) or conditions that would route to a sibling tool. The context is clear from the name, but explicit routing is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=false, and idempotent=true, so an agent knows this is a safe, reversible mutation. The description adds the key toggling behavior (hide vs unhide) but provides no further context about permissions, side effects, or response format. This is adequate for a simple toggle 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action, followed by a compact argument list. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter idempotent toggle, the definition covers the operation and argument semantics clearly, and annotations handle the safety profile. Missing return-value details and permission notes are minor gaps given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% because reply_id has no schema-level description. The description fills this gap by defining reply_id as 'Reply media ID' and restating the hide boolean semantics. It could go further by explaining how to find the reply_id, but the provided mapping is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Hides or unhides') and a clear target resource ('a reply on a Threads post'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like meta_hide_comment and meta_hide_instagram_comment by scoping to Threads replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: this is the tool to call when the agent wants to change the visibility state of a Threads reply. However, the description does not explicitly state when to use this over alternatives, nor does it mention any preconditions like requiring the reply to belong to the authenticated user's post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey a write operation via readOnlyHint=false and non-idempotent behavior via idempotentHint=false. The description adds useful constraints like 'lifetime_budget requires stop_time' and 'Returns the new campaign ID.' However, it doesn't mention permissions, potential side effects (e.g., ad spend), or error cases, so it adds only moderate behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line purpose, a scannable Args list, a targeted note about Advantage+ migration, and a return value statement. It is slightly redundant with the schema's parameter descriptions, but there is no fluff and the key usage note is prominent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter create tool with no output schema, the description covers all parameters, explains special requirements, states the return value, and includes the relevant Advantage+ alternate path. Minor gaps remain around permissions, error conditions, and the relationship between budgets, but overall an agent has what it needs to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so the schema already documents most parameters. The description adds meaning by explaining that special_ad_categories is required for housing, employment, and credit ads, and explicitly connects lifetime_budget to stop_time. This goes beyond the schema's basic 'compliance' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a new campaign in a Meta ad account,' which is a specific verb and resource with clear scope. This immediately distinguishes it from sibling tools like meta_get_campaign, meta_update_campaign, and meta_delete_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage path for OUTCOME_SALES: create a standard campaign first, then use meta_migrate_campaign_to_advantage_plus to convert to Advantage+. This is a concrete when-to-use/alternative routing. It doesn't broadly contrast against adset/ad creation tools, but the guidance is clear for the main alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show readOnlyHint=false, openWorldHint=false, idempotentHint=false, and destructiveHint=false, so the description carries the burden of behavioral disclosure. It adds valuable context: the audience is created but not populated, and population requires a separate Audiences API step. It also states the return value, which is useful since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a one-sentence purpose, a supported-types bullet list, an Args list, a Returns line, and a clarifying Note. Every section adds information an agent needs, and it remains readable despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description covers the return value, subtype specifics, and the important caveat that audience population is separate. It does not explain the WEBSITE and APP subtypes it lists in the Args section, and it lacks explicit routing guidance against sibling audience tools, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema: ad_account_id gets an example format ('act_123456789'), CUSTOM subtype gets the Pixel requirement, customer_file_source gets its enum values explained, and retention_days gets a 1–180 range and optional flag. It only omits response_format, but that parameter is self-explanatory and already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Creates a new custom audience in a Meta ad account.' It lists supported types and returns the new audience ID. However, it does not explicitly distinguish this from sibling tools like meta_create_saved_audience or meta_create_lookalike_audience, though the 'custom audience' wording provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the supported types list (CUSTOM, ENGAGEMENT, VIDEO) and notes that population is a separate step, which helps scope the tool. It does not explicitly say when to use this tool versus alternatives, nor does it provide exclusions or direct references to sibling audience-creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false implies mutation) and the description carries the burden, delivering meaningful context: the publish-vs-draft behavior, the ~63,206 character limit, the 10-min-to-30-day scheduling window, and the Page Publishing Authorization requirement for scheduling. No contradiction with annotations; description's 'Creates a new post' aligns with readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with purpose, prerequisite, Args, Returns, and Notes sections — front-loaded with the core intent before details. The Args list partially restates the schema, which is mildly redundant, but each entry earns its place by adding constraints (scheduling window, link preview) not present in the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations covering the behavior, the description covers the essentials: return value (Post ID), prerequisite call, constraints on scheduling, and length limits. Minor omission is unprompted error-case handling, but for a create-post tool this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable nuance beyond the schema: link 'creates a link preview', published defaulting to true with draft semantics, and scheduled_publish_time must be 10 min to 30 days out with published=false. This materially helps an agent use parameters correctly beyond the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'creates' with a specific resource ('a new post on a Facebook Page'). The sibling tools meta_create_photo_post, meta_create_video_post, and meta_create_live_video make it clear this is the general text-post variant, so an agent can distinguish it 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite ('meta_list_pages must be called first to load page tokens') and a follow-up routing if the user wants photos or videos would be handled by named siblings. However, it never explicitly says when NOT to use this tool or points to alternatives like meta_create_photo_post or meta_create_video_post, leaving the choice between post types implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-destructive, idempotent action. The description adds that the broadcast is ended immediately, but it does not explain side effects such as whether the ended video remains available or whether an already-ended broadcast can be ended again.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and uses clear section breaks. The final sentence is slightly redundant with the first, and the Args block duplicates schema information, but no irrelevant detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity action with full schema coverage and safety annotations, the description is largely complete: it names the action, the required prerequisite, and the required params. It does not describe the return value, but output schema is absent and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value by linking page_id to page-token auth and stating the meta_list_pages prerequisite. The Args list repeats schema fields, but the auth-flow context goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Ends an active live video broadcast.' This clearly distinguishes it from sibling tools like meta_create_live_video and meta_get_live_videos, so an agent can identify the correct operation without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit prerequisite: meta_list_pages must be called first to load page tokens. This gives clear context for when the tool can be invoked, though it does not name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds useful behavioral context by showing the exact output shape, providing an example, and noting that output_path saves a PNG. It does not contradict the annotations, and the readOnlyHint=false is consistent with the optional file-saving side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-sentence purpose, followed by compact Args documentation and a concrete usage example. Every part adds value, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9 parameters, nested objects, low schema coverage, and no output schema, the description is fairly complete: it documents all primary parameters with defaults and a full example. The only notable gap is not describing how response_format affects the return value, but the schema supplies that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 22%, but the description compensates by providing types, defaults, and an example for most parameters, including the nested group_a/group_b structures. It does not mention response_format, but the schema already describes that parameter with an enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it generates a side-by-side comparison chart for comparing two periods, campaigns, or A/B results. This clearly distinguishes it from generic chart tools like meta_generate_chart, though it does not explicitly name the sibling or contrast itself with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: comparing two time periods, campaigns, or A/B test results. It does not explicitly say when not to use it or name alternatives, but the use case is specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation without side effects. The description adds meaningful context beyond annotations: it names the underlying API (Business Discovery API), clarifies the auth requirement via ig_account_id, and states it returns specific profile fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: it repeats the parameter list and descriptions that already exist in the schema, wasting space. The core purpose and usage context are front-loaded, and the return-value note is useful, but the Args block duplicates structured data. This prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must specify return values—it does, listing 'Bio, follower/following counts, media count, profile picture, and recent media.' It also covers auth (ig_account_id) and the no-connection requirement. For a simple read-only lookup tool with annotations covering safety, this description gives an agent everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (ig_account_id, username, response_format) are already documented in the schema with descriptions. The description repeats the parameter list in an 'Args:' block but adds no new meaning beyond what the schema provides; for example, the schema already states username is 'without @' and ig_account_id is 'Your Instagram account ID.' Thus it meets the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Gets public profile info for any Instagram business/creator account by username.' It clearly distinguishes from sibling tools like meta_get_instagram_media or meta_get_instagram_single_media, which focus on media objects, by defining its scope to profile info. The mention of 'business/creator account' adds a specific constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context—it's for fetching public profile data and notes 'no follow/connection required,' which helps in selecting the tool when no social relationship exists. However, it does not explicitly name alternative tools or state conditions when this tool should be avoided, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds the prerequisite of needing page tokens from meta_list_pages, which is crucial context for successful invocation. It also discloses what the tool returns, giving a complete picture of the read behavior. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening sentence stating the purpose. The Args/Returns lines are a bit redundant with the schema but serve as quick reference. The content is well-structured and front-loaded; it does not waste words on fluff. Slight redundancy in repeating page_id, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and a schema that fully documents them, the description is sufficiently complete. It mentions the prerequisite call, its return content, and provides an argument list. It does not detail response structure, but the description summarizes what is returned; with no output schema, that is acceptable. Potential error scenarios are not covered, but for a read tool with annotations indicating safety, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both page_id and response_format are documented in the schema. The description only repeats page_id in its Args section and does not add any extra meaning beyond what the schema already provides. It omits response_format entirely from the description, but since the schema covers it, this is acceptable. This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the current automated messaging settings for a Facebook Page. It uses a specific verb (Gets) and resource (Facebook Page), and lists the exact settings returned (Instant reply, away message, greeting, ice breakers). This distinguishes it from sibling tools like meta_set_instant_reply, which write settings, so an agent can easily tell read from write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: 'Requires: meta_list_pages called first to load page tokens.' This gives a concrete condition for using the tool. It does not explicitly name alternatives, but the read-only nature and the sibling setter tools make it clear this is for reading settings. The absence of an explicit 'when not to use' is a minor gap, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as read-only and non-destructive, and the description does not contradict them. It adds behavioral context beyond the annotations by stating that meta_list_pages must be called first and that the return value is 'time-series data for each metric.' This gives the agent a clearer picture of dependencies and response shape than the annotations alone would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence and prerequisite are front-loaded, and the Args section is logically organized by parameter. The long metric list is justified because the schema explicitly defers to the description for the complete list; it is a reference section rather than unnecessary repetition. Some minor redundancy exists with parameter names repeating the schema, but the added metric detail earns the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no output schema, the description covers the dependency, metric vocabulary, period values, date formats, and return shape at a functional level. It does not detail the exact structure of the time-series response, but no output schema exists and the schema handles response_format. Overall, an agent has enough context to call this tool correctly for page-level analytics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers response_format, period enums, defaults, and date formats, while the description adds substantial value by enumerating the full set of 70+ valid metric names and grouping them by category. It also clarifies that page_id is 'Facebook Page ID' and gives date formats for since/until. The only parameter not mentioned in the description text is response_format, but the schema adequately describes it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool 'Gets analytics/insights for a Facebook Page,' naming a specific verb, resource, and scope. This distinguishes it from sibling insights tools aimed at Instagram, posts, ads, campaigns, or ad accounts. The extensive metric list further clarifies exactly what kind of page-level analytics are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful prerequisite: 'Requires: meta_list_pages called first.' However, it does not explicitly say when to prefer this tool over alternative insight tools, such as meta_get_post_insights or meta_get_instagram_account_insights. The intended usage is implied by the page-level resource and metric list, but exclusions and alternative routing are left to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: 'All post metrics use ''lifetime'' period (cumulative from post creation)' and the required auth flow via page_id. It also enumerates allowed metrics. This exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to the exhaustive metric list, which is necessary and well-organized by category. It is front-loaded with purpose and prerequisite, and uses clear 'Args:' formatting with bold category labels. Some redundancy exists (e.g., repeating 'post_' prefix), but the structure is effective for an agent scanning options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational details: required prior call, parameter format, metric options, and metric period. It does not mention error handling, rate limits, or output format, but the read-only annotations and the schema's response_format parameter mitigate completeness gaps. For a tool with no output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning: it explains the format of post_id (e.g., 'page_id_post_id'), breaks down metrics into categories with full option lists, and clarifies that metrics use lifetime period. The schema's metrics description merely refers back to the description, so this is essential. response_format is not addressed in the description, but it's minimally documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets performance metrics for a specific Facebook Page post.' This is a specific verb-resource pair that distinguishes it from page-level insights (meta_get_page_insights) or post retrieval (meta_get_post). The detailed metric list reinforces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a required prerequisite: 'Requires: meta_list_pages called first.' This is useful routing guidance. However, it does not explicitly contrast with sibling tools like meta_get_page_insights or meta_get_post, nor state when to avoid this tool. It gives one clear usage condition but lacks full alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating the required prior call to meta_list_pages and specifying the returned post fields (message, permalink, created time, post ID). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, a required prerequisite, a brief Args section, and a Returns section. Every part earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description clearly states what the return value contains. It also covers the prerequisite call and pagination cursor. For a simple read-only list tool with four parameters, this is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents page_id, after, and response_format, while limit has constraints. The description's Args block largely restates schema information rather than adding deeper semantics. It does not describe response_format, which the schema already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Lists posts from a Facebook Page feed.' It clearly states what the tool does and aligns with the title. However, it does not explicitly differentiate this from sibling tools like meta_get_published_posts or meta_get_visitor_posts, which also return page-related post listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'meta_list_pages called first to load page tokens,' which tells the agent when this tool can be used. It does not explicitly name alternatives or exclusion cases, so it falls short of a 5, but the context is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency by stating it returns estimated daily reach and audience size, and that optimization_goal (e.g., REACH, LINK_CLICKS, IMPRESSIONS) affects the estimate. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads a one-sentence purpose, then provides a structured args list and a return line. Every sentence earns its place with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only estimator with 4 parameters and no output schema, the description covers required parameters, optimization_goal semantics, and the return value. It does not mention pagination or rate limits (likely inapplicable) and could reference the sibling meta_get_delivery_estimate, but overall it is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, but the description supplies meaning for ad_account_id, targeting_spec (same format as ad set targeting), and optimization_goal with concrete examples. This compensates well for missing schema descriptions. response_format is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimates the potential reach for a targeting specification' with a specific verb and resource. It does not explicitly differentiate from the sibling meta_get_delivery_estimate, so it misses the full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for estimating reach for a targeting spec and provides helpful context like 'same format as ad set targeting' and examples for optimization_goal. However, it gives no explicit when-to-use guidance or exclusions relative to similar tools such as meta_get_delivery_estimate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds specific behavioral details: that it checks token status, cached tokens, API connectivity, and returns token validity, cached token count, Threads status, and reachability. This adds meaningful context beyond the annotations, though it doesn't mention any side effects, auth requirements, or rate limiting. The bar is lower with annotations present, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and then listing the specific checks and return values. No wasted words. It's clean and structured, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with one optional parameter and no output schema, the description is complete. It says what it checks and exactly what it returns. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100% (response_format with enum and default, and a clear description). The description doesn't add any parameter-specific information, but the schema already fully documents it. Baseline is 3, and since there's no gap to compensate for, a 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Checks the health of the Meta MCP server' and enumerates specific aspects (token status, cached tokens, API connectivity) and outputs. This is specific and unambiguous, and since there's no other health-check sibling, it stands alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verifying server health and status, but it doesn't explicitly state when to use it (e.g., 'before making API calls') or exclude any alternatives. There are no obvious sibling health-check tools, so the lack of explicit guidance is a minor gap, but there's really no alternative routing needed. It falls between 'clear context, no exclusions' (4) and 'implied usage' (3). Given no explicit usage context, I give a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations: the action is performed 'acting as the Page,' and the 'unlike' parameter changes the behavior from liking to removing a like. The annotations already indicate mutating, non-destructive, idempotent behavior, so the description supplements rather than repeats them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a compact Args list. The object_id line duplicates the schema's description, but the page_id and unlike explanations add value, so the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool, the description covers the operation, acting identity, and parameter semantics. It does not describe return values or error conditions, and there is no output schema, but the annotations and provided parameter details are enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description carries most of the parameter-meaning burden. It explains that object_id is a Post or Comment ID, page_id is the Page ID used for the token, and unlike controls whether the like is removed. This meaningfully compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb and resource: it likes or unlikes a page post or comment while acting as the Page. It is immediately distinguishable from all sibling tools, none of which perform this exact like/unlike action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever the agent needs to like or unlike a Page post/comment. However, it provides no explicit guidance about alternatives, prerequisites, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the constraint that exactly one of three IDs must be provided, and mentions pagination via 'after' and 'limit', which is useful. However, it does not describe output format (markdown/json) or default behavior when status_filter is omitted, leaving some behavioral ambiguity. Given annotations cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening statement followed by a structured list of parameters and a final constraint line. It avoids redundancy and is easily scannable. The only minor inefficiency is repeating 'optional' for most parameters, but it remains well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with sparse schema descriptions and no output schema, the description covers the essential invocation details: scoping, status filtering, pagination, and the requirement to provide one of three IDs. It misses mentioning the response_format parameter (though the schema covers it) and does not state default status behavior, but these are minor. The description is sufficiently complete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains six of seven parameters (excluding response_format) with meaningful details: it clarifies adset_id, campaign_id, and ad_account_id as filters, explains status_filter values, and notes limit's default (20) and 'after' as a pagination cursor. This compensates for the schema's low coverage (14%), though response_format is only documented in the schema. Overall, it adds substantial semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists ads for an ad set, campaign, or ad account' with a specific verb and resource, and distinguishes itself from sibling tools like meta_list_adsets or meta_list_campaigns by focusing on ads. It also enumerates the three scoping options, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to provide one of adset_id, campaign_id, or ad_account_id, which is essential usage guidance. It also implies when to use it (when listing ads) but does not mention alternatives or when not to use it (e.g., for fetching a single ad via meta_get_ad). It gives clear usage rules but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a usage constraint (provide either campaign_id or ad_account_id) but does not describe return structure, pagination behavior, or other behavioral details. With annotations present, a 3 is appropriate as some additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, followed by a concise bullet list of args and a final constraint. Every sentence adds value, and it is appropriately structured for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the return looks like; it does not. It also fails to mention the response_format parameter (defaulting to markdown), which could affect how the agent interprets output. The constraint on providing either campaign_id or ad_account_id is mentioned, but other contextual details like pagination behavior are omitted. Given the absence of an output schema, more context is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (3 of 6 parameters have descriptions). The description adds meaning for 'after' (pagination cursor) and 'limit' (max results default 20) which are not described in the schema. It also restates status_filter enum values. However, it omits the 'response_format' parameter entirely, which is described in the schema but not in the tool description, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ad sets, specifying the scope as 'for a campaign or ad account'. It distinguishes itself from siblings like meta_list_ads (which lists ads) and meta_get_adset (which retrieves a single ad set) by its resource and filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to provide either campaign_id or ad_account_id, giving clear selection criteria. It does not explicitly mention alternative tools but the context is sufficient to understand when to use this tool. No explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context by specifying the return data (catalog IDs, names, product counts, and verticals), which is valuable given there is no output schema. It does not contradict the annotations and provides more than just the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The argument list is slightly redundant with the schema but serves as a quick reference. There is no fluff, and the return value info is included. Minor redundancy prevents a perfect score, but it remains well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter, the description covers the essential aspects: what it does, its inputs, and its outputs. The lack of an output schema is compensated by describing the return fields. It does not mention pagination or error behavior, but the limit parameter and read-only annotations cover the main concerns. Overall, it is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all parameters, including descriptions, ranges, and defaults. The description repeats the business_id and limit info but adds no new semantic meaning beyond the schema. It does not mention response_format, but the schema fully documents it, so the baseline of 3 applies—the description neither enhances nor degrades parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists product catalogs for a Meta business, using a specific verb and resource. It distinguishes itself from siblings like meta_get_product_catalog (which implies fetching a single catalog) and meta_list_products (which lists products within a catalog). The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to list all product catalogs for a given business. However, it does not explicitly mention alternatives or when not to use this tool. Since the purpose is straightforward and the tool's name matches its function, the lack of explicit exclusions still results in a clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-idempotent mutation. The description adds meaningful behavior beyond that: it is an in-place conversion, the original campaign ID is preserved, and after migration Meta takes over audience selection and budget allocation. It does not mention reversibility or side effects, but it provides substantial behavioral context beyond the annotation flags alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by concise context about Advantage+ behavior and the important ID-preservation fact. It is appropriately sized with no filler, though the Args section partially duplicates schema descriptions and omits response_format, which is a minor structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two required parameters, the description covers the action, target, key behavioral trait (in-place conversion), and post-migration effects. Since there is no output schema, the main gap is the lack of a description of the return value or response, along with any eligibility or reversibility caveats. Overall it is reasonably complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description's Args section repeats the same text as the schema for campaign_id and ad_account_id without adding additional semantics, and it does not mention the response_format parameter at all. The schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and object: 'Migrates an existing campaign to Advantage+ Shopping.' It also clearly distinguishes this from creating a new campaign by stating it is an in-place conversion that keeps the original campaign ID, leaving no ambiguity relative to sibling tools like meta_create_campaign or meta_update_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: on an existing campaign that should be converted to Advantage+ Shopping. It also clarifies a key non-goal — it is not creating a new campaign. However, it does not explicitly name alternatives such as meta_update_campaign or state exclusion criteria, so it stops short of full when-to-use/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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds valuable behavioral context: 'Video must be hosted on a publicly accessible server' and 'FB Reels use a simpler single-step flow (no container polling needed).' This goes beyond the schema and annotations by clarifying prerequisites and the absence of a container-checking step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it leads with the purpose, then lists prerequisites, arguments, return value, and notes. Each section is brief and contributes meaning. The note about the single-step flow is a useful distinction. There is little redundancy, though the Args list repeats the schema's parameter names and descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward publish tool with no output schema, the description covers the essential operational aspects: prerequisite calls, required parameters, return type (reel/video ID), and specific notes about video hosting and flow. It does not elaborate on error handling or rate limits, but these are not critical for a single-step publish. The optional response_format parameter is documented in the schema, so no gap exists there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptions (100% coverage). The description lists the parameters and repeats their meanings without adding new semantic details (e.g., formats, constraints, examples). It does note the prerequisite 'meta_list_pages' which is a global dependency, not per-parameter. Since the description adds minimal value over the schema, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Publishes') and resource ('a Reel (short-form video) to a Facebook Page'), and explicitly distinguishes it from other publishing tools by mentioning the 'simpler single-step flow (no container polling needed)'. This differentiates it from siblings like meta_create_video_post or meta_publish_page_story.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: 'Requires: meta_list_pages must be called first to load page tokens.' This gives necessary context for use, but it does not explicitly state when not to use it or name alternatives. However, the focus on Reels and the single-step note makes the intended usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-idempotent write with no destructive hint. The description adds useful context beyond this by stating the meta_list_pages prerequisite and the success return value (story ID), though it does not cover rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action, followed by the prerequisite, args, and return value in a clear structure. The Args bullets are somewhat redundant with the schema but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish tool with no output schema, the description provides the essential return value and a critical prerequisite, while the schema covers parameter details. It does not discuss error conditions or media accessibility, but nothing critical is missing for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description's Args section mostly restates schema descriptions and omits the response_format parameter, adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Publishes a story (photo or video) to a Facebook Page,' which gives a specific verb, resource, and media type. This clearly distinguishes it from sibling tools like meta_create_post or meta_publish_page_reel by scoping it to Page stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit prerequisite: 'Requires: meta_list_pages called first to load page tokens,' which is actionable guidance for correct invocation. However, it does not explicitly compare against alternative publishing tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only generic false hints, so the description carries the behavioral burden. It reveals that the operation sends a text message, is constrained by messaging windows, requires the recipient to have messaged first, and returns a Message ID. It does not describe failure modes or rate limits, but for a simple send action this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, front-loaded with the purpose sentence, and organized into useful sections for args, constraints, and return value. The Args section is somewhat redundant with the JSON schema, but it does not bloat the description or dilute the key operational notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-required-parameter send tool, the description supplies the key operational prerequisites, states that only text is supported, and documents the return value since no output schema exists. It could mention permissions or rate limits, but an agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's Args section mostly repeats the schema text, adding at most the clarification that ig_account_id is the sender and that recipient_id is Instagram-scoped. It does not go beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource: 'Sends a text DM to an Instagram user.' It is clearly distinguishable from sibling tools such as meta_send_instagram_media_message because it specifically says text DM, and it names the sender and recipient concepts directly in the args.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note gives concrete conditions for use: only within the 24-hour human agent messaging window or 7-day standard messaging window, and only when the recipient has messaged the account first. It does not name alternative tools or state when not to use it in favor of a sibling, but it provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by disclosing the required THREADS_ACCESS_TOKEN environment variable and specifying the exact return contract. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each earning its place: one for purpose, one for return values, and one for the required environment variable. The primary action is front-loaded, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one optional parameter. The description covers the action, the required auth context, and the return fields even though there is no output schema. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, response_format, has a clear description, an enum, and a default value. The tool description does not add parameter-level meaning, but it does not need to because the schema fully documents what the parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Gets the authenticated user's Threads profile.' It also enumerates the exact returned fields (User ID, username, name, bio, and profile picture URL), which clearly distinguishes it from siblings like threads_get_post, threads_get_posts, and threads_get_user_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for the authenticated user's own profile, and it notes the THREADS_ACCESS_TOKEN requirement. However, it does not provide any explicit guidance about when to use this tool versus alternatives such as threads_get_user or threads_get_user_insights, so the usage guidance is mostly implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-idempotent operation. The description adds useful behavioral context by revealing the three-step container workflow and indicating that publishing is not a single atomic call. It does not discuss failure cleanup or rate-limit fallout, but the core side-effect profile 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with its purpose, and uses a clear numbered flow plus a brief Args list. Every sentence adds useful information without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The multi-step process is explained, but there is no output schema and the description does not state what the tool returns after publishing, such as a post ID or URL. Optional parameters like reply_control and response_format are also absent from the narrative, leaving a moderate gap for an agent relying only on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, and the description partially compensates by defining text as 'Caption text' and clarifying the structure of items. However, it omits reply_control and response_format from its Args block, so the agent still relies on the schema for those two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Publishes'), a specific resource ('a carousel post'), and a concrete constraint ('2–20 images/videos') on Threads. This clearly differentiates it from sibling single-media publishers like threads_publish_image and threads_publish_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 2–20 item range and the explicit three-step flow make it clear this tool is for multi-item carousels. It does not explicitly state exclusions or name alternatives such as single-image tools, but the context is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent operation; the description adds that it creates a new ad within an ad set, defaults status to PAUSED, and returns the new ad ID. It does not discuss auth or failure modes, but annotation coverage lowers that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One-line summary plus a compact Args block and return statement. Every line adds operational value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, it states the return value, required inputs, and default status. It leaves response_format to the schema and does not mention alternate sibling tools, but those are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, yet the Args list compensates by explaining adset_id as 'Parent ad set ID', providing provenance for creative_id, and stating status enum/default. It omits response_format, but that parameter is already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Creates a new ad within an ad set' — a specific verb, resource, and containment scope. This clearly distinguishes it from siblings like meta_update_ad, meta_list_ads, and meta_delete_ad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies its use for new-ad creation rather than modification or listing, but never explicitly contrasts with meta_update_ad or meta_list_ads. The only routing hint is 'creative_id ... from meta_list_ad_creatives or meta_create_ad_creative', which helps with prerequisites, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only set readOnlyHint=false and destructiveHint=false, leaving the description to convey behavioral details. It explains the conditional outcome based on planned_start_time (SCHEDULED_UNPUBLISHED vs LIVE_NOW) and states the return values (stream URL and live video ID). This adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: function statement, prerequisite, arg list, behavioral conditional, and return value. Every sentence adds useful information with no filler, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly includes return values. It captures the key prerequisite and behavioral nuance. However, it does not mention the response_format parameter in the arg list, and it lacks broader context like authentication or error conditions. These are minor given the schema coverage and sibling clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description enhances this by giving the conditional behavior of planned_start_time and repeating parameter purposes, but it omits the response_format parameter entirely, which the schema documents. Overall, the added value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a live video broadcast on a Facebook Page,' using a specific verb and resource. This clearly distinguishes it from siblings like meta_create_video_post (regular video) and meta_get_live_videos (reading live videos).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires: meta_list_pages called first to load page tokens') but does not explicitly state when to use this tool versus alternatives like meta_create_video_post or meta_end_live_video. The usage context is implied by the tool's purpose, but no exclusions or alternative routing are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a mutating, non-idempotent, non-destructive call. The description adds useful behavioral context by stating the feed 'automatically sync products from a URL' and by disclosing that the call 'Returns the new feed ID,' which is valuable since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a clear Args list, and a return statement. Every section serves a purpose and no filler appears.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple create operation with full schema coverage, the description covers the creation behavior, key parameters, and return value. It does not mention caveats like whether syncing begins immediately or whether the URL must be publicly accessible, but those are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description repeats the required parameters with slightly richer phrasing, such as file formats and interval examples, but does not add meaning beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates a new product feed for a catalog.' It also clarifies the purpose by saying the feed will 'automatically sync products from a URL,' which distinguishes it clearly from sibling read/list/delete feed tools like meta_list_product_feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when this tool is appropriate: when creating a new product feed that syncs from a URL. It does not explicitly name alternatives or exclusions, but the 'new' wording and sync behavior provide enough context for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide destructiveHint=true and idempotentHint=false. The description adds the word 'permanently', which reinforces irreversibility, but it does not disclose potential side effects such as what happens to ads within the ad set, permission requirements, or whether deletion can be undone. This is acceptable given the strong annotation signal, but the description itself adds limited 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the action and one short arg block. It front-loads the core purpose and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, one required parameter, and annotations that already flag destructive behavior, the description is nearly complete. It clearly states the action and the parameter. It does not describe the return value or cascade effects on child entities, but for a one-parameter delete operation this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining adset_id. It does so by labeling it as 'Ad set ID to delete', which adds meaningful semantic context beyond the bare string type in the schema. It could include a format example, but for a single simple parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Deletes'), a clear resource ('an ad set'), and an important qualifier ('permanently'). This clearly distinguishes it from sibling delete tools like meta_delete_ad, meta_delete_campaign, and meta_delete_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended usage obvious: use this tool when an ad set needs to be permanently deleted. It does not explicitly name alternatives or exclusion conditions, but the resource-specific naming and description make confusion with other delete tools unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already label this as destructive (destructiveHint=true), and the description adds that the action is permanent and irreversible, which exceeds the annotation coverage without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: the core action and irreversibility warning are in the first sentence, followed by a minimal Args list. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with full schema coverage and annotations, the description provides the necessary permanence warning and parameter format. Authentication is handled via page_id as clarified in the schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters well (100% coverage). The description adds the specific format for post_id ({page_id}_{post_id}), which is not present in the schema, and reiterates page_id's role for authentication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a post from a Facebook Page') and the specific resource, distinguishing it from create/update tools. The permanence warning reinforces its unique destructive purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare with alternatives like meta_update_post or meta_create_post, nor does it state conditions for when to use deletion. It implies usage by naming the action but lacks explicit routing away from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly=false, idempotent=true, destructive=false; the description adds value by explaining output side effects (saves PNG to a path or returns a URL), mentioning the rendering service (QuickChart/Chart.js), and noting how the output can be used. It does not discuss network dependencies or failure modes, but this is above what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured with an intro paragraph, 'Args:' block, 'Returns:' note, and an example. It is somewhat lengthy but justified given 10 parameters and a complex nested dataset object. No redundant sentences; each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with low schema coverage, the description covers nearly all parameters, return behavior, and gives an example. The only gap is that the 'response_format' parameter (markdown/json) is not mentioned in the text, and there are no caveats about the QuickChart service (e.g., rate limits, URL length). Overall, it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description carries the explanatory burden. It fully documents each parameter (chart_type, title, labels, datasets with nested structure, width, height, output_path, stacked, show_values), provides defaults, and includes a concrete example for datasets. This is far beyond the sparse schema descriptions and makes parameter meaning unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generates a chart image (PNG) from provided data' – a specific verb, resource, and output format. It distinguishes itself from the sibling meta_generate_comparison_chart by focusing on general chart creation rather than comparison-specific charts, and includes a concrete use-case ('visual reports from Meta insights data').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Perfect for creating visual reports from Meta insights data' gives clear context, but it does not explicitly state when not to use this tool or point to alternatives (e.g., meta_generate_comparison_chart). No exclusions or routing guidance beyond that single contextual sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by describing the return fields ('feed IDs, names, schedules, and latest upload status') and the nature of feeds, which enriches understanding beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a terse args block, with the core purpose front-loaded. No filler words, and every sentence earns its place. It is efficiently structured for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list operation. The description provides the return fields, the key parameters, and context about feeds. It does not discuss error conditions or pagination, but the limit parameter and read-only nature make it sufficiently complete for an agent to call correctly. It could briefly mention the response_format default, but that is in the schema. Overall, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the two primary parameters (catalog_id and limit) but does not add any new meaning beyond what the schema already provides. The schema covers limit with min/max/default, and catalog_id has a description. The description does not mention response_format, but the schema describes it. Schema coverage is 67%, but the missing limit description is self-explanatory via constraints. Overall, the description adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Lists', and a specific resource, 'product feeds for a catalog'. It also adds clarifying context by explaining what feeds are ('automated data sources that keep catalogs up-to-date'), which helps distinguish this from sibling tools like meta_list_product_catalogs (which lists catalogs) and meta_list_products (which lists products). The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to inspect feeds for a catalog) by explaining what feeds are, but it does not explicitly state when not to use it or name alternatives. It provides enough context for an agent to infer the correct scenario, though it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only readOnlyHint, openWorldHint, idempotentHint, destructiveHint, which are all false, implying a non-idempotent write operation. The description adds crucial behavioral context: the prerequisite that the container must have status FINISHED, and that it is for the two-step reels/videos flow. It does not contradict annotations and provides meaningful operational guidance beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured. It opens with the main action, then quickly provides usage criteria, and ends with an explicit args list for the required parameters. No filler or redundant statements; every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required and one optional parameter, no output schema, and minimal annotations, the description covers the core purpose, usage timing, and semantics of key parameters. It does not explain the response format or possible errors, but given the simplicity of the operation, these are not critical. The description is sufficient for an agent to correctly invoke the tool when the container is ready and the user intends to publish it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only response_format has a description). The description adds semantics for the required parameters: container_id is 'from a previous create step' and ig_account_id is 'Instagram account ID.' However, these are somewhat basic and do not fully compensate for the low schema coverage. For example, ig_account_id's description is tautological, and container_id's description only indicates provenance without explaining format or role. The optional response_format is not mentioned, but it is fully described in the schema, so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Publishes') on a specific resource ('a pre-created Instagram media container'), and distinguishes it from sibling publishing tools by noting that it is for containers created separately, as opposed to direct photo/story/reel/carousel publishing. An agent can immediately understand what this tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for use: 'Use after checking container status is FINISHED.' and 'Useful for reels/videos where container creation and publishing are done in separate steps.' It implies the tool is not for direct publishing without a container, but does not explicitly name alternative tools for those cases. Overall, the usage context is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-step creation+publishing process, scheduling behavior, format restrictions (JPEG only), rate limits (100 posts/day), and return value. Annotations provide no safeguards (all false), so the description carries full weight; it does not contradict annotations and adds significant behavioral context, though it omits error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: an introductory purpose sentence, a two-step process note, an args list, return value, scheduling, and limitations. It is front-loaded and organized; every sentence contributes, though it is somewhat long (~150 words). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with scheduling and limitations, the description thoroughly covers required params, scheduling constraints, format restrictions, rate limit, and return value. The only omission is response_format, but the schema documents it, and no output schema exists, so the return type is specified. This is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, parameters are already documented. The description adds minor extra semantics: caption supports hashtags/mentions, alt_text is for accessibility, and image_url must be publicly accessible (schema already says 'public'). For response_format (not in description), schema covers it. This aligns with the baseline 3 for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('publishes') and resource ('a single image post to an Instagram professional account'), and explicitly distinguishes from reel/story/carousel by limiting to a single image. It clearly differentiates from sibling publishing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes that this tool is for single-image posts, which implies use for that scenario, and even indirectly excludes video/reel/carousel. However, it does not explicitly mention when to use a sibling alternative or provide exclusion criteria (e.g., 'for video use meta_publish_instagram_reel'), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the description only needs to add behavioral context beyond that. It adds that the search is by name and that results are limited to products taggable in Instagram posts, which is useful. However, it does not disclose pagination, result limits, or matching behavior, so partial credit is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, the Args block is minimal and clear, and the Returns sentence conveys the key outcome. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with full schema coverage and safety annotations, the description covers the inputs, the key prerequisite, and the output intent. It lacks explicit pagination or limits, but those are minor gaps for this simple tool, and there is no output schema requiring return-value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds one valuable fact beyond the schema: catalog_id should come from meta_get_instagram_available_catalogs. It does not describe response_format, but the schema fully covers that parameter, so the added provenance hint justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: searching for products in an Instagram Shopping catalog by name. It also clarifies the practical output—matching products that can be tagged in Instagram posts—which distinguishes it from generic product listing tools like meta_list_products and tagging tools like meta_get_instagram_product_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: it tells the agent that catalog_id comes from meta_get_instagram_available_catalogs and frames the tool as a way to find products that can be tagged. It stops short of explicitly naming alternatives or saying when not to use it, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds modest context about search semantics and the returned data, but it does not mention rate limits, auth requirements, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, two bullet args, and a return statement. Every part earns its place with no filler or redundant restatement of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool, the description covers the purpose, key inputs, and return value well enough for an agent to call it correctly. Minor gaps include no mention of response_format in the prose and no pagination details, but the schema covers response_format and annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful examples for q ('yoga', 'cooking') and clarifies limit as 'Max results (default 50)', which the schema does not explain for limit. It omits response_format from the prose, but the schema fully documents that parameter with an enum and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Searches for interest-based targeting options for ad sets.' It also states the output, 'Interest IDs and names to use in ad set targeting,' which clearly distinguishes this tool from sibling targeting searches like geolocations or demographics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool for interest-targeting use cases within ad sets, so an agent can infer when to use it. It does not explicitly name alternatives such as meta_search_targeting_geolocations or meta_search_targeting_demographics, so it stops short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only, not destructive, and idempotent. The description adds the behavior of checking current subscriptions when subscribed_fields is omitted, which is valuable. However, it does not clarify whether calling with new fields replaces existing subscriptions or appends to them, which is a potential behavioral ambiguity. It leaves some operational details to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the main purpose is stated in the first sentence, followed by a brief parameter list and a usage hint. It avoids unnecessary words and is easy to scan. Every sentence adds valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple tool with 3 parameters (1 required). It covers the core action, parameter semantics, and a special usage pattern. The lack of an output schema means the description needs to convey enough for an agent to invoke it correctly, which it does. Minor omissions like the replacement behavior are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful detail to page_id (specifying it is the Facebook Page ID) and subscribed_fields (providing examples like feed, messages). The schema only gives a generic description for subscribed_fields, and page_id lacks a description, so the tool description compensates. However, it does not mention response_format at all, but the schema already explains its purpose clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (subscribes your app to receive webhook updates) and the resource (Facebook Page). It differentiates from sibling tools by focusing on webhook subscription, a unique capability among the many meta_* tools. It also mentions an additional behavior (checking current subscriptions) that adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for subscribing to webhook updates) and includes a specific usage note (calling without subscribed_fields to check current subscriptions). However, it does not explicitly mention alternatives or when not to use this tool. Given the tool's unique purpose, the guidance is adequate but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is mutating, non-destructive, and idempotent. The description adds the required pages_manage_metadata permission, which is useful authentication context beyond the annotations. It does not describe side effects like replacing the existing image or requiring a publicly accessible URL, but these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured: a one-sentence purpose, a clear Args list, and an essential permission note. Every line earns its place with no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with two required parameters, the description covers purpose, parameter meanings, and authentication requirements. A notable minor gap is the lack of any statement about the return value or expected response, especially given that no output schema exists, but this does not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes picture_url and response_format, but not page_id. The description fills that gap by identifying page_id as a Facebook Page ID and restating that picture_url is the new profile picture URL. It does not mention response_format in prose, but the schema already documents it well, so effective coverage of the required parameters is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Updates a Facebook Page's profile picture.' This clearly distinguishes the tool from sibling tools like meta_update_page_cover and meta_get_page_picture, and the title reinforces the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for updating a Page's profile picture and lists the required permission, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. Context is clear enough for a straightforward update, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, indicating this is a mutating, idempotent operation. The description adds value by explaining the effect ('Blocked users cannot post or comment') and the reversible nature via the 'unblock' parameter. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: two sentences plus a compact args list. The purpose is front-loaded, and every sentence adds essential information without unnecessary fluff. It avoids repetition and stays efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers what the tool does and its parameters, but lacks details on expected return values (e.g., success/failure response) and any permission requirements. Still, for a simple blocking operation, it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. It does: 'page_id (string): Facebook Page ID', 'user_id (string): User ID to block/unblock', and 'unblock (boolean): If true, unblocks the user instead'. This adds meaning beyond type definitions, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact operation: 'Blocks or unblocks a user from a Facebook Page.' It identifies the resource (Facebook Page) and the specific action (block/unblock user), plus the result ('Blocked users cannot post or comment'). This distinguishes it from sibling read-only tools like meta_get_blocked_users and other page management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for blocking or unblocking users but does not explicitly state when to use it versus alternatives, such as meta_get_blocked_users for listing blocked users, or when not to use it (e.g., requiring page admin permissions). There is no mention of prerequisites or exclusions, leaving some 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds concrete behavioral context: the exact quota window (24 hours), the limit amount (100 posts), and what is returned (usage and remaining quota). It consistently presents a non-mutating check with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized into purpose, args, and returns sections, with the central quota information front-loaded. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only tool with no output schema, the description covers the required parameter and the return semantics. The optional response_format parameter is already documented in the schema, so nothing essential for invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema does not describe ig_account_id, but the description supplies the needed meaning ('Instagram account ID') in the Args section. The optional response_format parameter is already documented in the schema, so the description complements rather than repeats the structured information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Checks') and resource ('Instagram publishing rate limit'), quantifies the limit as 100 API-published posts per 24 hours, and specifies the return value as current usage and quota remaining. This clearly distinguishes it from Threads rate-limit checks and generic health-check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a pre-publish quota check, but it does not explicitly state when to use this tool versus alternatives or mention any exclusion conditions. No sibling tools are referenced, leaving the agent to infer usage context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety. It adds valuable context beyond the annotations by specifying that it inspects the META_ACCESS_TOKEN from the MCP environment, and explicitly lists the output fields (type, expiry, permissions, app/user). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three sentences, with the core purpose front-loaded, followed by a concrete use case, and a closing note that no arguments are needed. Every sentence contributes value and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read‑only tool with zero required arguments and a single optional parameter fully described in the schema, the description is complete. It explains what the tool does, when to use it, and explicitly notes that it relies on the configured environment token. There is no output schema, but the description lists the information returned, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter response_format is fully documented in the schema with an enum and default, so schema coverage is 100%. The description does not add extra meaning about the parameter, but the schema already carries the full burden. Per the rubric, baseline 3 is appropriate because the description adds nothing beyond the schema, but the schema itself is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspects') and clearly states the resource (Meta access token) and the exact information it returns (type, expiry, permissions, associated app/user). It is easily distinguishable from all sibling tools, none of which are debug-dedicated, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('diagnosing permission denied errors or checking when a token expires'), giving clear context for its application. It also clarifies that no arguments are needed, which is helpful guidance. It doesn't mention when *not* to use it or list alternatives, but given the tool is unique and the use case is concrete, this is already strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description goes further by stating 'permanently' and 'This cannot be undone', adding a critical warning beyond the boolean hint. It does not contradict annotations and provides valuable behavioral context about irreversibility, satisfying the requirement to add value beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus a one-line args list. The main action and irreversible warning are front-loaded, and every word earns its place. The repetition of the arg is redundant but not bloated, and the structure is easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with a single parameter, the description covers the essential aspects: what it does, the irrevocable nature, and the parameter. The annotations handle the destructive hint, and the schema defines the parameter. No output schema is needed, and no other critical context is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for audience_id ('Custom audience ID') with 100% coverage. The description repeats the same meaning in the Args section ('Custom audience ID to delete'). This adds no new semantic information beyond what the schema already provides, so the baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Deletes' with the resource 'custom audience' and explicitly notes permanence ('permanently', 'cannot be undone'). This clearly differentiates it from sibling delete tools targeting other resources (e.g., meta_delete_post, meta_delete_instagram_media) and leaves no ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for deleting custom audiences and the permanence warning informs the decision to use it. It doesn't explicitly mention alternatives or exclusions, but given the self-contained nature and the distinct resource in the tool name, an agent can infer when to use it. A clear context is provided, though no 'when not to use' caveat is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds meaningful context beyond annotations by specifying the return value ('List of active story media objects') and the 24-hour expiry behavior, which helps the agent understand what to expect from the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a compact args list and return statement. Every sentence earns its place; there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with no output schema, the description provides the required input (ig_account_id), the output shape ('List of active story media objects'), and a domain-specific constraint (24-hour expiry). Annotations cover the safety profile, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description simply repeats the ig_account_id parameter name and description without adding any new semantics. The response_format parameter is not mentioned in the description, though the schema fully documents it. No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets'), a precise resource ('currently active stories'), and a target ('Instagram professional account'). It clearly distinguishes from sibling tools that publish or manage other media types by emphasizing 'currently active' and 'stories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by stating 'currently active stories' and 'Stories expire after 24 hours', implying it is for real-time retrieval rather than historical access. However, it does not explicitly mention when not to use this tool or name alternative tools for other media types, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description is consistent with them. It adds auth context (page_id for authentication, list_pages prerequisite) and clarifies pagination/filter behavior, though it does not cover rate limits or response specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single purpose sentence is followed by a tight argument list; each parameter line adds necessary guidance including defaults. No redundant prose or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential invocation details: required IDs, auth prerequisite, defaults, pagination, and filter choices. Lacks an explicit description of the return payload shape, and there is no output schema, but the tool's read-only nature and strong parameter coverage make that omission minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 29% schema coverage, the description compensates by explaining post_id format, page_id auth purpose, limit bounds/default, order options, after cursor, and filter semantics. Only response_format is left to the schema, which already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation—'Gets comments on a Facebook Page post'—and the parameter list names the resource and options. This distinguishes it from Instagram comment tools and post-writing/editing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a useful prerequisite ('call meta_list_pages first') and clarifies the auth role of page_id, but does not explicitly state when to choose this over alternatives such as meta_get_instagram_comments or meta_reply_post_comment. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive and idempotent, and the description adds the behavioral effect that hidden comments are only visible to the author. This goes beyond the annotations and explains the real-world outcome, which is valuable for an agent understanding the impact of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core action in the first sentence, followed by a brief explanation of visibility and moderation use, then a clean Args list. No fluff; every sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter toggle with full schema coverage and annotations covering safety and idempotency, the description provides all essential context: the action, the effect, and the intended use case. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions matching exactly what is in the tool description. The description adds no new meaning beyond the schema (e.g., format of comment_id or examples), so it meets the baseline for schema-covered parameters without additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Hides or unhides') and resource ('a comment on an Instagram media object'), and explicitly contrasts with deletion ('non-destructive alternative to deletion'), distinguishing it from sibling meta_delete_instagram_comment. 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for use ('useful for moderation') and frames it as an alternative to deletion, implying when to choose this over deletion. It does not explicitly list all non-use cases or name other siblings like meta_toggle_instagram_comments, but the moderation purpose and non-destructive nature are clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the bar. The description adds useful behavioral context: it lists accessible accounts, returns specific fields (IDs prefixed with act_, names, currency, status, spend info), and notes it is the entry point for downstream campaign/insights work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short purposeful sentences: what it does, what it returns, and when to call it. No filler or redundant repetition of the tool name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no required parameters and no output schema, the description is complete: it explains the scope ('all ad accounts accessible to the authenticated user'), the return content, and the recommended usage sequence. An agent has enough to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single response_format parameter is fully documented in the schema. The description adds no parameter-specific meaning, but none is needed; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') with a clear resource ('Meta ad accounts accessible to the authenticated user'), and distinguishes the tool's broad listing scope from siblings like meta_get_ad_account or meta_list_ads. It also states the returned fields, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first to get ad account IDs needed for campaign and insights tools,' providing clear context and sequencing. It does not name alternative tools or exclusion conditions, but the guidance is sufficient for this simple listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by stating the return contents (IDs, names, configuration) and documenting the pagination cursor ('after') and limit default/range, which clarifies the behavior of pagination and result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The structure is efficient and front-loaded: the purpose is in the first sentence, followed by a brief explanatory context, a labeled Args list, and a Returns line. The explanatory sentence about offline event sets is informative but not strictly necessary for invocation; still, it earns its place by aiding domain understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explicitly lists what is returned (IDs, names, configuration). It covers all front-line parameters (ad_account_id, limit, after) with enough detail, and response_format is documented in the schema. Annotations handle the safety/disclosure burden, leaving no obvious gaps for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, but the description compensates well: it explains ad_account_id (with example), limit (range and default), and after (pagination cursor). The only parameter not covered in the description is response_format, but the schema fully describes that. Thus the description provides essential meaning for all critical parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the verb ('Lists') and resource ('offline conversion event sets'), and scopes it to an ad account. The additional context about offline events tracking in-store purchases and phone orders distinguishes this from other list tools like meta_list_custom_conversions or meta_list_pixels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about what offline event sets are, implying when to use this tool. However, it does not explicitly mention when NOT to use it or name alternatives (e.g., meta_send_offline_event for sending events). Usage is inferred from the purpose rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the agent knows this is a write operation. The description adds the auth-related context that page_id is used for token lookup, which is helpful beyond the annotations. No contradictions with annotations were found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a compact Args list. Every line adds useful information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not state what the tool returns. It also omits permission requirements and failure modes. For a simple write operation this is acceptable, but the missing return-value information is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, but the description's Args section provides meaningful explanations for comment_id, page_id, and message, compensating for the lack of schema descriptions. It does not specify exact formats but gives enough semantic context to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Replies to a comment on a Facebook Page post.' This clearly identifies the operation and distinguishes it from siblings like meta_reply_instagram_comment, meta_get_post_comments, and meta_send_page_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for replying to a comment on a Facebook Page post. It does not explicitly mention alternatives or exclusions, but the scope is specific enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations: it requires a valid access token but not ad account ownership, and it describes return contents (ad creatives, spend ranges, impressions, demographics, targeting info). It does not mention rate limits or pagination behavior, but the read-only nature is covered. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a brief lead sentence and a clear parameter list. It is appropriately detailed for a tool with 10 parameters, but it repeats some information already present in the schema (e.g., default values) and misses response_format. No fluff, but could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 1 required), the description covers the core purpose, authentication requirements, parameter semantics (except response_format), and return value types. It does not explain parameter interactions (e.g., whether search_terms and search_page_ids are exclusive) or provide examples. The missing response_format is a significant gap for an agent that might want machine-readable output. Otherwise, quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, so the description helps fill gaps. It clarifies each parameter's purpose (e.g., 'Pagination cursor' for after, 'Max results (1–100, default 25)' for limit) and adds meaning for ad_type and ad_active_status. However, it entirely omits the response_format parameter present in the schema, leaving that parameter undocumented in the description. It does add value for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'searches' and the resource 'Meta Ad Library', and explicitly frames it as a transparency tool accessible without ad account ownership, which distinguishes it from all ad-management siblings like meta_list_ads or meta_get_ad. The scope ('any advertiser') is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (transparency, no ad account access required) and notes that it needs only a valid access token. It does not explicitly name an alternative tool or state when not to use it, but the clear separation from ad-management tools makes the usage context understandable. Exclusions are not stated, so a small deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value beyond those: the q-or-center required precondition, the ability to combine them, and the return payload (Place IDs, names, addresses, coordinates). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and organization is clear (purpose → use case → Args → Returns → note). The Args list largely restates schema defaults, which is slightly redundant, but the inline examples earn their place, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter search tool with no output schema, it is complete: it documents all major params with examples, states return fields, and clarifies the required precondition and combination semantics. The only minor gap is not documenting response_format, which the schema covers adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, above the 80% baseline threshold. The description supplements the schema with concrete examples for q ('Central Park'), center ('40.7829,-73.9654'), and categories (['FOOD_BEVERAGE', ...]), plus default and max values for limit and distance, adding genuine meaning. The one undocumented parameter, response_format, is well-described in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Searches for Facebook Places') and the two search modes (name or coordinates). It also names the downstream purpose — getting a location_id for tagging posts, Instagram photos, or Threads — which cleanly separates it from search tools like meta_search_targeting_geolocations or threads_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context ('Use this to get a location_id for tagging...') and the 'Provide at least q or center' requirement. It does not name explicit exclusions or direct alternatives, but the use-case framing is specific enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a write, non-destructive, idempotent operation. The description adds useful behavioral context beyond that: where the greeting text appears and the hard dependency on calling meta_list_pages first for page tokens. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with the core purpose stated first and the prerequisite called out. The Args section duplicates some schema information, but it is short and does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with rich schema and annotations, the description covers the essential details: purpose, prerequisite, and the two required parameters. It does not describe return values, but no output schema exists and the response_format parameter helps cover that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by tying page_id to the prerequisite of loading page tokens via meta_list_pages, clarifying where the value should come from. It omits response_format from the Args section, but the schema fully documents that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Sets the Messenger greeting text') and the exact resource ('Facebook Page'). It also explains when the greeting appears, which differentiates it from sibling tools like meta_set_instant_reply and meta_set_away_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when this tool is relevant: the greeting is shown before a user sends their first message. It also provides an explicit prerequisite ('Requires: meta_list_pages called first to load page tokens'), though it does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it requires pages_manage_metadata permission and explains the no_feed_story behavior. The annotations already indicate readOnlyHint=false and idempotentHint=true, and the description's 'Updates' aligns with these, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line and a compact Args block. Each parameter line is informative, and the mutual-exclusion and permission notes are valuable. It is slightly longer than strictly necessary because it repeats schema content, but it remains focused and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers the main calling requirements: required parameter, optional parameters, mutual exclusivity, and permission. It does not describe the return value or failure cases, but for a straightforward update operation with idempotentHint=true, the provided information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83% (5 of 6 parameters are described), and the schema already documents each parameter. The description adds a critical mutual-exclusion rule ('Provide either cover_url or photo_id') that the schema alone does not enforce. However, response_format is absent from the description, though the schema covers it with enum and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Updates a Facebook Page's cover photo.' This clearly distinguishes it from related tools like meta_update_page_picture, which would handle the profile picture, and from general page updates via meta_update_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it specifies the required page_id, explains that callers should provide either cover_url or photo_id, and states the required permission. It does not explicitly name alternative tools or when not to use this tool, but the context is clear enough for an agent to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds important behavioral constraints: demographic metrics require 100+ followers, online_followers is only available for last 30 days, and lifetime period is limited to demographic metrics. These notes go beyond static annotations and inform correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized with Args, bullet points, and notes. It front-loads the core statement and then systematically details each parameter. Given the complexity, the length is justified with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, constraints, and special notes, making it comprehensive for invoking the tool. It does not describe the response structure, but the response_format parameter offers control and the output for insights is typically self-explanatory. Minor gap: no error handling or pagination info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly documents all parameters: metric categories (Interactions, Legacy, Demographics) with their values, period options, since/until format, breakdown options, and timeframe options. It also clarifies special conditions like account_repost_count availability. With schema coverage only at 50%, the description fully compensates and adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets performance insights for an Instagram professional account, using the specific verb 'gets' and resource 'performance insights'. This distinguishes it from sibling tools like meta_get_page_insights, meta_get_post_insights, and meta_get_campaign_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the scope explicit (Instagram account insights) but does not explicitly compare to alternatives or state when not to use it. It implies usage context through the resource name, but lacks direct exclusions. Generally clear but missing explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds valuable behavior context: it enumerates metrics valid per media type, flags deprecated metrics (impressions, plays, clips_replays_count), and highlights new Reels metrics (Dec 2025) with definitions. This goes beyond annotations to inform the agent about metric availability and deprecations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with headers (Args, New Reels metrics) and bullet points in the schema, making it scannable. It is longer than minimal but every sentence provides functional detail. The front-loaded summary is clear, and the organization prevents confusion. Slight over-length is acceptable given the metric complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and a rich parameter space, the description covers all necessary aspects: exact metric lists per media type, breakdown usage, deprecated metrics, and new metrics with definitions. It also implies the dependency on meta_get_instagram_media for obtaining media_id. Nothing essential is missing for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so parameters are documented, but the description enriches semantics significantly. It lists allowed metrics per media type (Photos/Carousels, Reels/Video, Stories), provides detailed explanations for new Reels metrics, and clarifies the breakdown parameter with valid enum values. This adds meaning beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets performance metrics for a specific Instagram media object.' It identifies the verb (gets), resource (performance metrics), and scope (specific Instagram media object), which distinguishes it from account-level or page-level insights tools like meta_get_instagram_account_insights and meta_get_page_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for a specific media object and references meta_get_instagram_media as the source for media_id. However, it does not explicitly mention alternatives or state when not to use it (e.g., for account-level metrics). The context implies the usage, but no explicit exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail beyond annotations: messages are returned in reverse chronological order from the API but displayed in chronological order. It also includes pagination semantics (limit and after), which informs the agent about iterative fetching. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence for purpose, a bulleted arg list, and a one-line behavioral note. It packs essential information without verbosity. All sentences earn their place, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only message-fetching tool with 4 parameters and no output schema, the description covers the essential points: how to identify the conversation, how to control message count, and pagination. The output format is documented in the schema, so its absence from the description is acceptable. It does not describe potential errors or edge cases, but for this level of complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (limit lacks a schema description). The description fills this gap by explaining limit's range (1–100, default 20) and clarifies conversation_id's provenance ('from meta_get_instagram_conversations'). While response_format is not mentioned in the description, it has a thorough schema description and enum, so the agent is not left without guidance. The description provides meaningful semantics beyond the schema for two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets messages in an Instagram Direct Message conversation.' This is specific (verb 'gets' + resource 'messages in an Instagram DM conversation') and distinguishes it from siblings like meta_get_instagram_conversations (which fetches conversations) and meta_send_instagram_message (which sends). The mention of conversation_id sourced from meta_get_instagram_conversations further clarifies its role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting that conversation_id comes from meta_get_instagram_conversations, guiding the agent on prerequisite steps. However, it does not explicitly state when not to use this tool versus alternatives like meta_get_conversation_messages (for page messages) or other Instagram messaging tools. The context is clear enough for an agent to infer the intended use case, but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description is consistent with that. The description adds useful context beyond annotations: the token-loading prerequisite and the return content ('field values, creation time, and ad info'). It does not discuss pagination mechanics in depth, but no contradiction or safety surprise exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a one-sentence purpose followed by structured Requires, Args, and Returns sections. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with no output schema, the description covers the prerequisite, parameter meanings, and a return summary. It could be slightly more explicit about response_format and how the pagination cursor is used across calls, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema for key parameters: form_id is sourced from meta_list_leadgen_forms, page_id is used 'for authentication', limit has a range/default, and after is identified as a pagination cursor. It omits response_format, but the schema already documents that parameter with clear enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb ('Gets') and resource ('submitted leads from a lead generation form'), clearly distinguishing this tool from siblings like meta_list_leadgen_forms (which lists forms) and other page/content tools. The title also reinforces the action without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear prerequisite: 'meta_list_pages must be called first to load page tokens,' and it points to meta_list_leadgen_forms as the source of form_id. It does not explicitly name alternatives or when-not-to-use conditions, but it provides enough operational context to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context beyond annotations: it specifies a required preceding call to meta_list_pages and describes the return fields (title, status, views, creation time). It does not contradict annotations; in fact, it reinforces the read-only nature implicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a single-line purpose, a separate prerequisite line, a compact Args list, and a return summary. It is front-loaded with the primary purpose, and every sentence provides necessary information without redundancy. The format is scannable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with no output schema, the description explains the return content and the prerequisite. It covers most parameters and clarifies filtering and pagination. However, it omits the response_format parameter, which is present in the schema and affects the output shape. Also, it does not describe pagination behavior explicitly (e.g., how the 'after' cursor is used), though it is mentioned. These are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters described). The description explains page_id, broadcast_status (as a filter with allowed values), limit (as max results with range and default), and after (as pagination cursor). It adds semantic value by clarifying that limit is a max results count and broadcast_status filters results. It misses response_format, but that parameter is self-explanatory in the schema as an output format choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists live videos on a Facebook Page, using a specific verb (lists) and resource (live videos). It distinguishes from other tools like meta_create_live_video or meta_get_page_videos by explicitly focusing on live videos. The return summary adds precision about what details are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: 'Requires: meta_list_pages called first to load page tokens.' This gives clear context for when to call the tool. However, it does not name alternative tools (e.g., meta_get_page_videos for all videos) or provide explicit when-not-to-use scenarios. The usage is implied by the tool name and purpose, but there is clear context with the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the three-step container creation and publishing flow, the returned media ID, and scheduling behavior. It does not spell out all side effects such as duplicate publication risk, but the idempotentHint annotation already covers that concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose, process, args, return value, and scheduling are each in tight, relevant sections. There is no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential invocation context: required and optional parameters, media constraints, multi-step behavior, return value, and scheduling window. It does not mention response_format or prerequisites like account permissions, but the schema and annotations cover some of that, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value over the schema by specifying that URLs must be public, JPEG images or videos, clarifying the array structure, and marking caption as optional. It omits the response_format parameter, but the schema already documents that with an enum and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Publishes a carousel post (2–10 images/videos) to Instagram.' This clearly distinguishes it from sibling photo, reel, story, and container publishing tools by emphasizing the carousel format and item range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when publishing a multi-image/video carousel to Instagram. It also gives scheduling guidance. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false) and not idempotent. The description adds valuable behavioral context beyond annotations: video processing time, the need to check container readiness, and the scheduling option with time constraints. It does not contradict annotations; it complements them with workflow details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear summary line followed by an Args list, Returns, and Notes. It is concise and front-loaded with the primary purpose. The notes are relevant and non-redundant. Slightly more organization would merit a 5, but it's already well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of publishing a reel (container steps, video processing), the description covers the essential workflow: publish, check readiness, and scheduling. It does not mention rate limits or error handling, but these are not strictly required when other tools handle those. The output schema is absent but the return value is explicitly stated ('Media ID'). The description is sufficiently complete for a reasonably knowledgeable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description goes well beyond the schema, which only documents video_url and response_format. It explains every parameter in the Args list, including caption, share_to_feed, and scheduled_publish_time, adding constraints like the video being on a publicly accessible server and the scheduling time window (10 min–75 days). This significantly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Publishes a video reel') and the resource ('Instagram professional account'), distinguishing it from sibling tools like meta_publish_instagram_photo, meta_publish_instagram_story, and meta_publish_instagram_carousel by specifying the content type (reel). The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by noting the prerequisite of checking container status before publishing and explicitly referencing the companion tool meta_check_instagram_container. It also explains the scheduling option and the time window. It does not explicitly contrast with sibling publishing tools, but the name and context make the intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a mutating, non-idempotent, non-destructive operation. The description adds permission requirements and a time-window limitation, which are operational constraints beyond the structured hints. This adds meaningful context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose followed by a bulleted argument list and two constraint lines. Every sentence adds operational value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, all parameters, the required permission, and the 24-hour messaging window constraint. It lacks return-value or error semantics, but no output schema exists and the primary invocation requirements are fully addressed, making it nearly complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only recipient_id has a description). The description fills the gap by defining page_id as 'Facebook Page ID', recipient_id as 'PSID (page-scoped user ID)', and message as 'Message text', clarifying the PSID acronym and adding meaning to all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Sends a message from a Facebook Page to a user' and adds the key constraint '(in an existing conversation)'. This clearly distinguishes it from page posting tools like meta_create_post and Instagram messaging tools like meta_send_instagram_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Requires pages_messaging permission' and 'Only works within the 24-hour messaging window', giving clear conditions for appropriate use. It does not name alternative tools, but the constraints effectively guide when this tool is viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, so safety is already known. The description adds the important behavioral trait that search results are scoped to the authenticated user's content and public threads, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused elements: the main purpose, an argument list, and a scope note. It is front-loaded with the core verb and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, parameter meaning, and a key limitation. No output schema exists, and the description does not explicitly state what the return value is, but for a simple search tool this is a minor gap. Overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (q and response_format have descriptions). The description compensates for the missing threads_user_id parameter by explaining it is 'for auth context', and adds that limit is 'Max results' with a default. This meaningfully adds to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Searches Threads posts by keyword', which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like threads_get_posts or threads_get_post, which retrieve posts rather than search by keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note about results being limited to the authenticated user's content and public threads provides clear context about the tool's scope. No explicit alternative is named, but there is no other Threads search tool among siblings, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by describing the return (minimum budget per bid strategy) and the practical importance, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then a single-line usage note, then parameter list, then return summary. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description covers purpose, importance, parameter example, and return format, sufficient for an agent to call it correctly. No critical missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters, including enums and defaults for response_format. The description goes further by giving a concrete example (act_123456789) for ad_account_id, enriching the schema's sparse description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves minimum daily and lifetime budgets for an ad account, specifying the scope (currency and bid strategy) and the resource (ad account). This distinct purpose separates it from the many other meta_* tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is essential before creating ad sets and warns that below-minimum budgets cause API errors, giving clear context for when to call. It does not explicitly name alternatives, but the unique function makes the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by stating the prerequisite dependency (meta_list_pages) and describing the return payload (IDs, usernames, follower counts), which annotations do not provide. It does not cover errors or rate limits, but for a simple read-only list tool with strong annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three brief sentences: action, prerequisite, return values. No wasted words. The most important info (what it does) is first, followed by the dependency and output. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly describes the return values (IDs, usernames, follower counts). It also explains the prerequisite and the dependency of other tools on the account ID. Given the single optional parameter and read-only annotations, nothing critical is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only response_format with a clear enum description and default). The description does not add any parameter information, but the schema fully documents the single parameter. Baseline 3 is appropriate because the description does not compensate beyond schema, but no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('Instagram professional accounts linked to the user's Facebook Pages'). It clearly distinguishes this tool from the dozens of sibling Instagram tools by focusing on the listing of accounts. The return values and dependency on meta_list_pages further clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Requires: meta_list_pages must be called first', giving a clear prerequisite and establishing when this tool should be used. Also notes the account ID is needed for all other Instagram tools, which effectively tells the agent to use this before those tools. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the call sends a DM, is subject to messaging-window restrictions, and returns a Message ID, which goes beyond the sparse annotations (all false). It does not cover auth requirements, rate limits, or failure behavior, but for a send operation the key side effect and restriction are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, then uses a compact argument list and two short constraint/return sentences. Every sentence adds useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-action DM send, it covers the essential call details: sender, recipient, payload, mutual exclusion, restrictions, and return value. It leaves some contextual details implicit (e.g., public URL requirement, error conditions), but no output schema exists and none of the critical invocation data is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the description is the sole source of parameter meaning. It fully documents all four arguments with types, optionality, and the exclusive-or constraint between image_url and link_url.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific action ('Sends an image or link via Instagram Direct Message') and identifies the resource (Instagram DM). It is clearly differentiated from sibling text-message and page-message tools by title and explicit media focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives actionable guidance on selecting image_url vs link_url and explicitly warns not to provide both. It references messaging-window restrictions, but it does not explicitly name the alternative tool for text DMs or list conditions that should make an agent choose this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive write operation. The description adds value by revealing the PII hashing requirement (SHA256) and the return value (number of events received), which are critical for correct use. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a clear bullet-like 'Args' list. It packs essential details (format requirements, optional fields, return value) without fluff. Every line contributes to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no output schema, the description covers all necessary aspects: required vs optional args, hashing requirements, return contract, and typical usage scenarios. Given the tool's complexity, the description is sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), but the description enriches the `user_data` parameter by specifying the accepted fields and the mandatory hashing rule, which the schema only loosely describes as 'hashed PII.' This goes beyond the schema and helps agents correctly format the payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pairing: 'Sends an offline conversion event to a Meta offline event set.' It also names concrete use cases (in-store purchases, phone orders) that distinguish it from the sibling online conversion tool 'meta_send_conversion_event.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('Used for tracking in-store purchases, phone orders, or other offline conversions'), giving clear context. However, it does not explicitly exclude online conversions or mention the alternative 'meta_send_conversion_event,' so the when-not guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a mutating, non-idempotent, non-destructive operation, so the description is not required to restate that. It adds useful behavioral detail: budget values are in cents, lifetime_budget depends on end_time, placement_soft_opt_out can still use up to 5% of spend, and the call returns the new ad set ID. No auth or rate-limit specifics are included, but the description exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool purpose is front-loaded in one sentence, followed by a tight Args list and a one-line return value. For a 13-parameter operation with a nested targeting object, the length is justified and every line provides a constraint, example, or default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex create operation with 13 parameters, a nested targeting object, and no output schema, the description covers the required identifiers, budget rules, enums, defaults, and the return ID. The targeting example and dependency constraints are exactly the kind of context an agent needs that is not available in the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section substantially enriches the schema, which only has 54% description coverage. It adds units ('in cents'), a concrete targeting JSON example, ISO 8601 format for timestamps, the lifetime_budget/end_time dependency, explicit enum examples, and the PAUSED default. The only parameter not mentioned in the description is response_format, which is already fully documented in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a new ad set within a campaign', giving a specific verb, resource, and parent scope. This separates it from sibling creation tools like meta_create_campaign, meta_create_ad, and the update counterpart meta_update_adset even though none are named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement clearly establishes when to use it: when a new ad set must be created inside a campaign. However, it does not explicitly list alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden. It discloses the mutation (creates posts), the parallel execution with Promise.allSettled (one failing doesn't block the other), the conditional behavior (text-only yields FB only), and the return value (results from both platforms). This is thorough behavioral transparency beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Requires, Args, Logic, Returns) and front-loaded with the core purpose. It is slightly long but every sentence adds value, so it earns a high score for structure rather than being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool publishing to two platforms with multiple media types, the description covers the main behaviors and return format. It lacks precise guidance on edge cases like both image and video provided, but the core use cases are documented. Given no output schema, the described return is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: it specifies that 'message' is used as both FB post text and IG caption, that image_url creates photo posts on both, video_url creates Reels, and it explains the response_format parameter. This adds semantics well beyond the schema's one-line descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Publishes') and resource ('both a Facebook Page and Instagram simultaneously'), clearly distinguishing it from single-platform tools like meta_create_post. It also names the two platforms and the simultaneous nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite (meta_list_pages must be called first) and details the logic for image, video, and text-only inputs, which tells the agent when this tool is appropriate. However, it does not explicitly compare against alternative sibling tools for single-platform publishing, so the guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's added value is explaining the non-production test behavior and the auto-set test_event_code. This is useful context beyond the annotations, though it doesn't describe the full response or what a successful test looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary purpose, then efficiently conveys the sibling relationship and the test_event_code behavior. Every sentence earns its place with no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and clear sibling differentiation, the description covers the essential information for calling the tool correctly. The main gap is the lack of any hint about how to interpret the response, but the response_format parameter and test-oriented nature mitigate this somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by explaining that test_event_code is auto-set if not provided and that the parameter set mirrors meta_send_conversion_event, which helps the agent understand parameter relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a test operation for CAPI setup by sending a test event, and explicitly distinguishes it from meta_send_conversion_event by noting the auto-set test_event_code. The verb 'Tests' plus the resource 'CAPI setup' leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is for testing CAPI setup and that it won't affect production data, which signals when to use it versus the production-oriented sibling. It also names meta_send_conversion_event and explains the key behavioral difference, giving the agent a clear selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It goes beyond the boolean annotations by explaining the real-world effect: hidden comments are visible only to the author and their friends. It also discloses the required pages_manage_engagement permission and reinforces the non-destructive nature of the operation, which is consistent with destructiveHint=false and idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized: a purpose sentence, a behavioral consequence, a moderation context sentence, a clean Args block, and a permission note. Every line earns its place and the most important operational information appears before the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with no output schema, the description covers the action, post-condition visibility, parameter semantics, permission requirements, and relationship to deletion. No critical operational information is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves comment_id undocumented, but the description fills that gap and restates the meanings of page_id and is_hidden. Because 67% of parameters already have schema descriptions, the description's added value is mainly in defining comment_id and framing page_id for authentication, which is enough to support correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states the specific action ('Hides or unhides a comment on a Facebook Page post') with a clear verb and resource. It also distinguishes itself from deletion by calling itself 'a non-destructive alternative to deletion,' which separates it from sibling tools like meta_delete_comment and meta_reply_post_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context ('useful for moderation') and explicitly positions the tool as a non-destructive alternative to deletion, which helps an agent decide when to choose it over deleting a comment. It does not list all possible alternatives or exclusions, but the moderation use case plus the permission requirement provides solid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it reveals that the tool caches page access tokens for subsequent calls and that tokens are managed automatically. The annotations (readOnlyHint, idempotentHint, destructiveHint false) already cover safety, and the description enriches with workflow-relevant details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a clear purpose statement, an important usage note in bold, a concise list of return fields, and a helpful tip. No redundant sentences; every part earns its place, and the critical 'call first' note is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a detailed list of return fields, including the nested instagram_business_account.id. It also explains the caching behavior and the need to call it first, covering all essential aspects an agent needs to invoke it correctly. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter response_format is fully documented in the schema (coverage 100%), including its enum and default. The description does not add any extra explanation about the parameter, so it relies on the schema. Baseline 3 is appropriate since the schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists all Facebook Pages managed by the authenticated user,' using a specific verb and resource. It distinguishes itself from siblings like meta_get_page (single page) and meta_list_instagram_accounts (Instagram accounts) by explicitly covering all pages and linking to subsequent operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this tool first before any page or Instagram operations' and explains that it caches access tokens, which is crucial guidance for sequencing. It also clarifies that token management is automatic, leaving no ambiguity about when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![open-mcp-servers MCP server](https://glama.ai/mcp/servers/open-work-org/open-mcp-servers/badges/card.svg)](https://glama.ai/mcp/servers/open-work-org/open-mcp-servers)

Score Badge

Copy to your README.md:

[![open-mcp-servers MCP server](https://glama.ai/mcp/servers/open-work-org/open-mcp-servers/badges/score.svg)](https://glama.ai/mcp/servers/open-work-org/open-mcp-servers)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/open-work-org/open-mcp-servers'

If you have feedback or need assistance with the MCP directory API, please join our Discord server