Meta MCP Server

Server Quality Checklist

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

Latest release: v2.0.2
Disambiguation2/5
With 200 tools, there is significant overlap, especially among content creation tools for different platforms (Facebook posts vs. reels vs. stories vs. Instagram posts vs. reels vs. stories vs. Threads posts). While descriptions are detailed, the sheer number makes it difficult for an agent to quickly distinguish the appropriate tool for a given task.
Naming Consistency4/5
Tools follow a consistent meta_verb_noun pattern (e.g., meta_list_pages, meta_create_campaign, meta_delete_post). There are minor deviations like meta_get_posts (returns list) vs. meta_list_ads, but overall the pattern is predictable and clear.
Tool Count1/5
200 tools is excessive for a single MCP server. This makes the tool set overwhelming and hard to navigate. It would be much more appropriate to split this into multiple domain-specific servers (e.g., Meta Ads, Instagram, Threads, Pages) to improve discoverability and focus.
Completeness5/5
The tool set covers an impressively broad range of Meta's APIs: Facebook Pages, Instagram, Threads, Ads Management, Pixels, Conversions, Catalog, Targeting, and more. It includes full CRUD operations, insights, moderation, and advanced features like A/B tests and automated rules.
Average 3.7/5 across 165 of 200 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 21, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description misrepresents the 'response_format' parameter, claiming values 'json' or 'text' while the schema defines 'markdown' or 'json' with a default of 'markdown'. This is a factual error that could mislead the agent. Annotations already indicate readOnly and idempotent, but the description adds no further behavioral context and introduces misinformation.
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 very short and front-loaded, but it omits critical details and contains an error. Conciseness is acceptable, but the structure could benefit from additional clarifying sentences, such as what 'details' are returned or a note about the default format.
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 relatively low schema description coverage (50%), the description should provide more context about the returned details. It fails to explain what constitutes 'details' (e.g., pixel name, ID, created time) or any usage constraints. The response_format mismatch further undermines 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 adds minimal value for 'pixel_id' (just 'Pixel ID', which is redundant) and incorrectly describes 'response_format' values. The schema covers 50% of parameters descriptively, but the description does not compensate for the missing schema descriptions and introduces a contradiction, reducing reliability.
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 Meta Pixel,' using a specific verb and resource. It distinguishes from 'meta_list_pixels' (list all) and 'meta_delete_pixel' (delete), but a slight mismatch in response_format values (description says 'json' or 'text' while schema says 'markdown' or 'json') slightly undermines clarity.
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_pixel_events' or 'meta_get_pixel_stats'. It assumes the agent infers usage from the tool name alone, which is insufficient given the large number of sibling 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 indicate readOnlyHint=true, so read-only behavior is clear. Description adds no further behavioral details (e.g., pagination with 'after' parameter, response format options, or rate limit considerations).
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?
Extremely short, but lacks essential information. Could be considered concise, but the omission of important parameters and context reduces effectiveness.
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?
Incomplete coverage of parameters and no usage context. The description does not fully inform the agent about the tool's capabilities, given the 4-parameter schema and no output schema to compensate.
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?
Only describes 2 of 4 parameters (page_id, limit). The 'after' and 'response_format' parameters are missing from the description, providing incomplete semantic guidance despite their presence 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?
Clearly states it retrieves visitor posts from a Facebook Page wall. However, it does not explicitly differentiate from similar sibling tools like 'meta_get_published_posts' or 'meta_get_posts', but the focus on 'visitor' posts provides sufficient specificity.
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_get_posts' for all posts. No prerequisites or context about required permissions (e.g., page access token).
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 the tool as read-only, non-destructive, and idempotent. The description adds no behavioral traits beyond the basic listing action, such as pagination, rate limits, or error conditions. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it omits the response_format parameter, making it incomplete. Every sentence is useful, but the missing parameter reduces its overall conciseness as a complete specification.
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 tool is simple and annotations cover safety, the description is minimally adequate but incomplete. It does not describe the return format or any additional context (e.g., label fields returned). The missing response_format parameter further detracts from 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 only documents the ad_account_id parameter (as 'Ad account ID'), missing the response_format parameter which is present in the schema with an enum and default. Schema coverage is 50%, and the description fails to compensate by adding meaning or explaining the second 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 clearly states it lists ad labels for an ad account and explains what labels do. However, it does not differentiate this list tool from sibling list tools like list_ads or list_campaigns, which also list entities by account.
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 lacks explicit context such as 'use when you need to view all labels' or 'not for searching by label name'. The only usage indicator is the tool's name itself.
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 readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds no new behavioral traits beyond stating it lists conversions, which is redundant. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two lines, but it sacrifices necessary detail. It lacks structure such as separating purpose from parameters clearly, and the parameter section is minimal.
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 tool has two parameters and no output schema, the description should explain return values, pagination, or filtering. It fails to do so, making it insufficient for an agent to fully understand 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 only mentions ad_account_id, repeating the schema without adding meaning. It omits the response_format parameter entirely, which has an enum and default value. Schema coverage is 50%, but the description does not compensate.
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 custom conversions for an ad account, using a specific verb and resource. It distinguishes from sibling tools like meta_create_custom_conversion, but could be more precise about the 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 guidance on when to use this tool versus alternatives such as meta_get_custom_conversion or other list tools. The description lacks context about prerequisites or appropriate scenarios.
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, destructiveHint=false, and idempotentHint=true, which clearly indicate a safe read operation. The description adds no additional behavioral context beyond 'gets detailed information', such as response structure, authentication needs, or rate limits. It does not contradict annotations but adds minimal value.
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 with two sentences plus an args list. However, the args list redundantly restates schema information (creative_id: string). Removing redundancy would improve conciseness. It is front-loaded but wastes space on available details.
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 tool with robust annotations, the description covers the basic purpose and mentions a creative_id parameter. However, it omits details about the return format (partially handled by response_format param) and what 'detailed information' includes. Agent can infer it returns full creative object, but additional context would ensure correct interpretation.
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 input schema covers 2 parameters, but only response_format has a description in the schema (50% coverage). The tool description merely lists creative_id as a string without clarifying its expected format or source. This adds little meaning beyond the schema. The description should compensate for schema gaps but does not.
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 'Gets' and the resource 'ad creative', specifying it retrieves detailed information for a specific creative. This distinguishes it from sibling tools like meta_list_ad_creatives, though not explicitly. The clarity is high but could be more precise about being for a single creative.
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_list_ad_creatives or other get tools. The description lacks context about prerequisites, scenarios, or when not to use it. This forces the agent to infer usage without explicit direction.
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=true. The description adds the limit range and default but omits details about pagination (the 'after' parameter) and the response_format parameter, which affect behavior. Some behavioral context is provided but incomplete.
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 but lacks important details such as pagination and output format. It is front-loaded with the main action and argument list, but the brevity sacrifices completeness.
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 relatively simple with 4 parameters and no output schema, but the description does not explain the return structure, pagination behavior, or prerequisite that a media_id must be obtained from another tool (e.g., meta_get_instagram_media). It is not complete enough for an agent to use effectively.
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%). The description adds meaning for media_id (redundant) and limit (range and default), but does not explain 'after' (pagination cursor) or 'response_format' (output format). With 25% schema coverage, 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.
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 gets comments on an Instagram media object, with a specific verb and resource. It is distinguishable from siblings like meta_get_instagram_comment_replies and meta_get_instagram_media, though it does not explicitly differentiate 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 such as meta_get_instagram_comment_replies for replies or meta_get_instagram_media for media details. It lacks any 'when to use' or 'when not to use' 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, destructiveHint, and idempotentHint. The description adds no behavioral context beyond restating the basic function. It does not disclose potential rate limits, authentication requirements, or what happens if media_id is invalid.
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 but includes a docstring-style args list that repeats schema information. It could be more concise by focusing on unique value rather than duplicating structural details.
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 minimal explanation, the description is incomplete for a tool that returns detailed data. It does not describe the return structure, error cases, or typical usage scenarios, leaving gaps for the 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?
Schema coverage is 50% (only media_id is described in the description). The description only mentions media_id without adding meaning beyond the schema, and completely omits the response_format parameter, including its purpose and default behavior.
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 title and description clearly state the tool retrieves detailed information about a single Instagram media object. The name distinguishes it from sibling tools like meta_get_instagram_media and meta_get_instagram_media_children.
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 context, constraints, or exclusions relative to other media retrieval 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?
Description aligns with readOnlyHint annotation but adds no additional behavioral context such as pagination behavior, rate limits, or auth requirements. Annotations already cover the read-only nature, so description adds minimal value.
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?
Description is short and well-structured, but omits important parameters. It is front-loaded but incomplete, which makes it less effective.
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?
Does not describe pagination ('after' parameter) or output format. Without an output schema, the description should clarify return structure (e.g., list of album objects with IDs). Incomplete for a list operation.
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?
Description only covers page_id and limit, but schema includes four parameters (missing after and response_format). Schema description coverage is low (25%), yet description fails to compensate by explaining pagination or output format 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?
Title and description clearly state the tool lists photo albums on a Facebook Page. Verb 'Lists' and resource 'photo albums on a Facebook Page' are specific and distinguish it from sibling tools like meta_get_page_photos.
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 (e.g., meta_get_page_photos for individual photos). No prerequisites mentioned beyond page_id, and pagination via 'after' parameter is omitted.
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 readOnlyHint=true and destructiveHint=false. The description does not add behavioral details like pagination (after parameter) or output format beyond what is in the schema. It adds minimal value.
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 very short but omits important parameters. It is concise but not complete, sacrificing helpfulness for brevity.
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 four parameters and no output schema, the description is incomplete. It does not explain pagination or the response_format enum, leaving the agent with insufficient context 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?
Schema description coverage is 25% (only response_format has description). The description covers only two of four parameters (ad_account_id, limit) with minimal explanation. It omits after and response_format, missing an opportunity to clarify pagination and output choices.
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 images in an ad account's image library. It distinguishes from sibling tools like meta_list_ad_creatives and meta_list_ad_videos by specifying 'images'.
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_upload_ad_image or other listing tools. The description does not mention context 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=true and destructiveHint=false, indicating safe, read-only behavior. The description adds no context beyond the name 'Lists', such as pagination behavior, rate limit implications, or what happens when there are no saved audiences.
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 concise (3 lines) and front-loaded with the purpose. However, it is too brief, missing opportunities to add key details without increasing length significantly.
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 tool has 4 parameters, no output schema, and limited annotations, the description is incomplete. It does not explain pagination parameters (limit, after), output format choices, or typical usage patterns. A more complete description would include these aspects.
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 input schema has 4 parameters, but only 25% have descriptions (response_format). The description documents only ad_account_id, repeating the schema's property name without adding meaning. It omits details for limit, after, and response_format, failing to clarify pagination or format options.
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 saved audiences (targeting presets) for an ad account.' It uses a specific verb ('Lists') and resource ('saved audiences'), and distinguishes from siblings like meta_create_saved_audience and meta_delete_saved_audience.
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 vs alternatives, such as meta_get_custom_audience or meta_search_targeting_interests. There is no mention of prerequisites, when-not-to-use, 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 indicate the tool is not read-only, destructive, idempotent, or open-world. The description adds no behavioral context beyond the schema, such as authorization needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with a clear first sentence. The parameter list in docstring style is somewhat redundant with the schema but acceptable. Could be trimmed without the 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?
The tool has 4 parameters and no output schema. The description does not explain the return value, the effect of status changes on delivery, or any post-update behavior. Important context for a mutation tool is missing.
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 only 25% schema description coverage, the description should add meaning to parameters. It merely lists ad_id, name, and status without explaining their semantics beyond what the schema already provides. The response_format parameter is not even mentioned.
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 ad's status or name. It uses a specific verb ('Updates') and resource ('existing ad'), and distinguishes itself from sibling tools like meta_create_ad or 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 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_update_adset or meta_update_campaign. No contexts, exclusions, or prerequisites 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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description aligns with these ('Updates') but adds no additional behavioral context 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 concise with a one-line summary followed by an Args list. It is well-structured and uses minimal text, though the main sentence could be more descriptive.
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 only 17% schema coverage, the description fails to explain return values, error handling, or effects of the update. It leaves significant gaps for an AI agent to infer correct 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?
Schema coverage is only 17%, but the description mainly restates parameter names and enum values already present in the schema. It adds example values for automatic_matching_fields but does not explain parameter semantics beyond repetition.
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 'Updates pixel settings' as a verb+resource pair. It distinguishes from sibling tools like meta_create_pixel or meta_get_pixel, but does not explicitly differentiate among other update 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 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 (e.g., meta_create_pixel for creating, meta_get_pixel for reading). No context or prerequisites are provided.
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=true and idempotentHint=true. The description adds that it 'browses all available categories', but does not disclose any additional behavioral traits 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 with a brief purpose line and an args section. However, the args section is somewhat redundant with the schema and could be removed or integrated better.
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 the description does not explain what the response contains or how to format it. The response_format parameter covers that, but the description omits it. Given the complexity, it is adequate but not 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 describes 2 of 3 parameters (class, response_format). The description adds meaning for the 'type' parameter by listing values, but erroneously includes 'adlanguage' which is not in the schema enum. This misleads the agent.
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 'Browses all available targeting category types for ad targeting', which is clear and specific. However, the description incorrectly includes 'adlanguage' as a valid type, which is not in the schema enum, slightly reducing clarity.
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 sibling tools like meta_search_targeting_demographics or meta_search_targeting_interests. The description does not mention alternatives or 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 indicate read-only and non-destructive behavior. The description adds the date-range scoping but lacks mention of pagination (via 'after' parameter) or rate limits. Adequate but minimal extra 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?
Extremely concise, front-loaded, and every sentence adds value. No wasted words.
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 and the description is minimal. It fails to mention pagination (after parameter) or output format options (response_format), which are important for usage 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?
Schema description coverage is 25% (only response_format). Description explains page_id and limit but omits 'after' and 'response_format'. For such low coverage, the description should compensate more fully.
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 ratings and reviews for a Facebook Page (specific verb+resource). However, among many get_page_* sibling tools, it does not differentiate itself from similar ones like get_page_insights or get_page_fan_demographics.
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. No context about 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, idempotentHint=true. The description adds no further behavioral traits (e.g., pagination, result limit, error handling). It's adequate but doesn't enhance transparency beyond what's structured.
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 with a clear arg structure. No wasted words, though the code block could be better integrated. Efficient but minimal.
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 no output schema and high sibling count, the description lacks details about return format or expected output behavior. It's adequate for a search tool but could better describe the results structure.
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 should compensate. It only loosely describes 'q' as 'Search query' and lists 'type' values, but provides no details on query syntax, limit behavior, or response_format. Two parameters (limit, response_format) are unaddressed.
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 searches for demographic targeting options and lists examples (job titles, employers, education). While it doesn't explicitly differentiate from sibling tools like meta_search_targeting_interests, the name and examples make the purpose distinct.
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 lacks context about scenarios where demographics search is appropriate compared to interests or geolocations.
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?
Beyond annotations (idempotentHint=true), the description only adds that the text is shown before first message. It does not mention side effects, overwriting behavior, or authorization needs, leaving significant behavioral 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?
Two clear sentences plus an arg list, front-loaded with purpose. Efficient with no waste, though the arg list duplicates schema content.
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?
Simple tool with annotations, but description omits response_format handling and error conditions. Prerequisite is noted, but overall completeness is adequate for a straightforward setter.
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 100%, but description merely restates schema descriptions for page_id and greeting_text, adding no new meaning. The optional response_format parameter is not mentioned in the description, failing to add 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?
Clearly states it sets the Messenger greeting text for a Facebook Page, specifying it's shown before first message. Does not differentiate from sibling tools like meta_set_away_message or meta_set_instant_reply, but the action 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?
Explicitly requires calling meta_list_pages first to load page tokens, which is good context. However, no guidance on when to use this vs alternative set tools, nor conditions when not to use.
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 a non-read-only, non-destructive write operation, but the description adds no behavioral details beyond that. No mention of rate limits, authentication, or potential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant Args list that mirrors the schema. It could be more concise by removing the list and adding usage guidance instead.
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, and description does not explain return values or outcomes. Missing parameters like reply_control are not mentioned. Sibling context shows many similar tools, but no differentiation is provided.
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 the schema already documents most parameters. The description only repeats three parameters without adding new meaning. No additional value beyond 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 title 'Publish Image Thread' and description 'Publishes an image post to Threads.' clearly state the action and resource. It distinguishes from siblings like threads_publish_text 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 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 such as threads_publish_carousel or threads_publish_link. The description only lists parameters 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 already indicate it is a write operation (readOnlyHint=false) and non-destructive. The description adds no behavioral details beyond 'publishes', such as what happens on failure, image format requirements, 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 short and front-loaded with a clear purpose sentence followed by a compact argument list. No fluff, but could be more structured (e.g., grouping required vs optional).
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 5 parameters and no output schema, the description is minimal. It does not explain return values, error handling, prerequisites (e.g., page must be managed), or how it differs from similar tools. Missing output schema increases the need for clarity.
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%). The description lists parameters with types and optionality, adding some meaning for 'caption' and 'published', but fails to explain 'page_id' or mention the 'response_format' parameter. With low coverage, the description only partially compensates.
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.' The verb 'publishes' is specific, and the resource 'photo post' distinguishes it from sibling tools like meta_create_post (general post) and meta_create_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 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 when not to use it or provide context for choosing between photo post, video post, or general post creation 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 are sparse (only readOnlyHint false, destructiveHint false, idempotentHint false). The description adds minimal behavioral context beyond stating that it creates a pixel. It does not disclose potential side effects (e.g., duplicates, permissions needed, rate limits), nor does it mention the response format or confirmation. Given the lack of annotations, the description should provide more transparency.
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: one sentence stating purpose followed by a bullet list of arguments. It is front-loaded with the primary action. However, the bullet list essentially duplicates the schema, and there is room to add more value without sacrificing brevity (e.g., noting return 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?
The tool has no output schema, so the description should explain what the tool returns (e.g., pixel ID, success status). It does not. Additionally, it mentions only two of three parameters, omitting response_format. It lacks context on how pixels relate to ad accounts or any setup requirements.
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 (33%), so the description must compensate. It lists ad_account_id and name with brief explanations ('Ad account ID', 'Pixel name'), which add basic meaning beyond parameter names. However, it does not explain format requirements (e.g., ID pattern) or constraints (e.g., name uniqueness). The response_format parameter is not mentioned in the description, despite being 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 verb ('Creates'), the resource ('a new Meta Pixel'), and the purpose ('for conversion tracking'). This distinguishes it from sibling tools like meta_get_pixel, meta_delete_pixel, etc., which operate on existing pixels.
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 prerequisites (e.g., need a valid ad account) or when not to use it (e.g., if the pixel already exists). Sibling tools like meta_update_pixel or meta_get_pixel have different usage contexts, but no comparison 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 destructiveHint: true, so the description adds no new behavioral information. It does not elaborate on consequences (e.g., permanent deletion, impact on related campaigns) or required permissions beyond what's implied by 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence plus a bullet for the argument. It is front-loaded with the action. However, the structure is minimal and lacks any formatting that aids 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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the basic operation. However, it omits important context such as error scenarios, idempotency (idempotentHint: false), and whether the audience must exist. It is minimally adequate.
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 0%, so the description should add meaning to the parameter. It only repeats the parameter name and type ('audience_id (string): Saved audience ID'), providing minimal additional context. The label 'Saved audience ID' is a slight improvement but insufficient to compensate for the lack of schema 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 the action ('Deletes') and resource ('a saved audience'). The verb+resource combination is specific and leaves no ambiguity about what the tool does, distinguishing it from siblings like create or list saved audience.
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 (e.g., meta_list_saved_audiences to find the ID, or meta_create_saved_audience to create). There is no mention of prerequisites, such as the need to have a valid audience_id, or that the action is irreversible.
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=true, destructiveHint=false, and idempotentHint=true, so the description adds no extra behavioral context. It does not contradict annotations, but also does not disclose additional traits like authentication or data freshness.
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 very short but lacks structured front-loading of key information. It could be slightly more organized, but it is not verbose.
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 tool has only two parameters and no output schema, the description should clarify what 'detailed information' includes or distinguish it from similar tools. It does not, leaving the description incomplete for effective use.
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 lists ad_id with a trivial explanation 'Ad ID,' adding no value beyond the parameter name. The response_format parameter is omitted entirely from the description, despite the schema having a useful enum description. Schema description coverage is 50%, and the description does not compensate for the uncovered 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 'Gets detailed information about a specific ad,' with a specific verb and resource. Among sibling tools like meta_get_ad_creative or meta_get_ad_insights, it uniquely identifies the purpose of retrieving ad details.
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. There is no mention of when not to use it or which sibling tools might be more appropriate for specific needs.
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, so the description's value is limited. It adds the permission requirement (instagram_manage_comments) and default limit. However, it does not explain pagination via 'after' or behavior of the tool beyond the 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 concise, front-loaded with purpose, and contains only necessary information in two sentences plus an arg list. No redundant content.
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?
No output schema exists, but the description does not explain the output structure. Pagination via 'after' is unexplained. The tool is simple but could be more complete given the absence of 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 description coverage is only 25% (only response_format described). The description adds minimal value for ig_account_id and limit, but omits 'after' and response_format entirely. Given low coverage, the description insufficiently compensates.
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 retrieves media where the Instagram account was @mentioned, using a specific verb ('Gets') and resource ('media where mentioned'). It distinguishes from siblings like meta_get_instagram_media but does not explicitly differentiate from all sibling 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 mentions required permission but provides no guidance on when to use this tool versus alternatives like meta_get_instagram_media or meta_get_instagram_comments. No when-not-to-use criteria 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, destructiveHint, and idempotentHint, so the description adds limited behavioral context beyond 'via insights'. It does not disclose important traits like pagination behavior, rate limits, or the fact that the response_format parameter controls output type. 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 brief with two sentences and a list of arguments. No unnecessary information, though the structure could be improved by separating the argument list more clearly or adding a note about the optional response_format parameter.
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 three parameters but the description omits the response_format parameter entirely, which is crucial for controlling output. No output schema exists, so the description should clarify return values or behavior. Given the complexity and low schema coverage, the description is incomplete.
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 33% with only response_format described. The description adds meaning for page_id and metric by explaining their purpose and listing metric values, but it fails to mention response_format or its defaults. It partially compensates for missing schema descriptions but leaves a notable 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 clearly states the tool gets fan/follower demographic breakdowns for a Facebook Page, specifying the verb 'gets' and the resource 'fan/follower demographic breakdowns'. It lists specific metric options, distinguishing it from general page insights tools, though it could more explicitly differentiate from siblings like 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 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., meta_get_page_insights or other demographic tools). The description does not mention prerequisites, exclusions, or context for selection, relying solely on implicit understanding of the metric names.
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 write operation (readOnlyHint=false) but not destructive. The description adds context about deduplication via event_id but does not disclose rate limits, error handling, or authentication needs. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a list format for parameters, which is structured, but it is somewhat lengthy. Each line adds information, but the overall length could be reduced without losing clarity. It is acceptable but not optimally 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 10 parameters including nested objects, and no output schema. The description fails to explain the return value or response format (despite a response_format parameter in the schema). It does not cover error handling or success indicators, leaving agents without critical usage 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?
Schema coverage is 100%, so baseline is 3. The description adds critical constraints not in the schema, such as 'at minimum one of: em, ph, fbc, fbp, client_ip_address, client_user_agent, external_id' for user_data, and lists standard event names. This compensates for the schema's lack of requirement specification.
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 sends a server-side conversion event via the Conversions API, with a specific verb and resource. The title adds context. However, it does not explicitly differentiate from sibling tools like meta_send_offline_event or meta_test_conversion_events, 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?
No guidance on when to use this tool versus alternatives such as meta_send_offline_event or meta_test_conversion_events. The description does not include when to use, when not to use, or prerequisites, which is a significant gap for an agent selecting 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 indicate idempotency and non-destructiveness. The description only adds 'Returns confirmation of the update' but doesn't disclose potential side effects, authorization needs, or rate limits. Minimal added value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two short paragraphs. It front-loads the purpose and then lists parameters efficiently. No wasted words.
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 8 parameters and no output schema, the description covers the basics but lacks details like validation rules, defaults, and response structure. 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?
Schema coverage is 100%, so the schema already documents all parameters. The description lists the optional fields but adds no new meaning (e.g., formats, constraints). 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 it updates a product's details, specifying the resource (product) and action (update). However, it does not distinguish it from other sibling update tools like meta_update_ad or meta_update_campaign, which share a similar pattern.
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., meta_create_product for new products) or prerequisites (e.g., product must exist). The description lacks 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, placing the burden on the description. The description omits the response_format parameter (present in schema) and does not describe what the tool returns (e.g., label ID). It provides minimal behavioral context beyond 'creates a label.'
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 very concise, but it is inconsistent: it lists two parameters in a non-standard format while the schema has three. This omission and format choice detract from clarity and completeness.
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 nature of a create tool, the description is insufficiently complete. It does not mention output format, permissions, or the fact that labels are used to organize ad objects. The response behavior is completely undocumented. For a tool with no output schema and sparse annotations, more context is 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?
With only 33% schema description coverage, the description adds value by briefly defining ad_account_id as 'Ad account ID' and name as 'Label name.' However, it fails to mention the response_format parameter, which has a schema description. Overall, it compensates for the schema gaps to a reasonable degree.
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 'Creates' and the resource 'label for organizing ads, ad sets, or campaigns,' distinguishing it from sibling tools like meta_list_ad_labels. The purpose 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?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or distinctions from other create tools. It simply states the function without any contextual recommendations.
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 hints (all false), and description only says 'Creates' but does not disclose if it overwrites existing conversions, permission requirements, rate limits, or that it is a write operation beyond creation.
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?
Short paragraph plus list, no fluff, front-loaded purpose. Could be slightly more structured for parameter descriptions but overall 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?
Adequately describes creation and parameters, but lacks mention of return value (no output schema), prerequisites (e.g., existing pixel), or error conditions. Example for rule is helpful.
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?
Description adds some value beyond schema: lists enum values for custom_event_type, provides example for rule. However, it does not explain the meaning of ad_account_id or pixel_id. Schema has 33% description coverage, so description partially compensates.
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 verb+resource: 'Creates a custom conversion for tracking specific actions.' Distinguishes from sibling tools like 'meta_list_custom_conversions'.
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 or prerequisites. Does not mention that a pixel must exist first or that a custom conversion is used for ad tracking.
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 destructiveHint=false, implying mutation. The description confirms creation, which is consistent. However, it does not disclose side effects (e.g., overwriting existing audience names) or any rate limits. The description adds minimal 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 efficient: one sentence for purpose followed by a parameter list. It is front-loaded and contains no filler. However, the parameter list could be omitted since the schema covers the same information, but it's not harmful.
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 details about return values, error handling, or what constitutes a successful creation. The targeting object is complex but not explained. Given no output schema, this is a gap. The description is minimal and relies on the user knowing the API.
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 50%, with only response_format and targeting having descriptions. The description repeats parameter names and types without adding meaning: 'ad_account_id (string): Ad account ID' is tautological. It provides no guidance on how to construct the targeting object, which is a complex 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 it creates a saved audience (reusable targeting preset) for an ad account. The verb 'creates' and resource 'saved audience' are specific, and it distinguishes from sibling tools like meta_create_custom_audience or meta_create_lookalike_audience.
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_create_custom_audience or meta_create_lookalike_audience. No mention of prerequisites, such as requiring an ad account ID or the need for admin permissions.
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 provide destructiveHint=true, so description adds 'permanently' which is consistent but adds little beyond annotations. Does not disclose additional traits like cascading effects or confirmation 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?
Extremely concise, no wasted words. However, brevity comes at the cost of completeness, sacrificing useful detail.
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?
Tool is simple with one param and no output schema, but description lacks return value information, idempotency warning (annotations show idempotentHint=false), and any context about potential side effects or success criteria.
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?
Description restates parameter name and type from schema ('ad_id (string): Ad ID to delete') but adds no semantic meaning beyond the obvious. Schema coverage is 0%, so description should compensate but 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?
Description clearly states 'Deletes an ad permanently' – specific verb (deletes) and resource (ad), easily distinguished from sibling tools like meta_update_ad or other delete 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?
No guidance on when to use vs alternatives, no prerequisites or conditions mentioned. Sibling delete tools exist but no differentiation provided.
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, destructiveHint=false, and idempotentHint=true, indicating safe, read-only behavior. The description confirms 'gets' but adds no additional behavioral details (e.g., return format, pagination). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, clearly stating the purpose upfront. The 'Args' section repeats information already in the schema but is brief. No unnecessary content.
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 basic purpose and one parameter hint. For a simple read-only tool with good annotations, it is minimally adequate. However, given many sibling tools, more context about return format or typical fields would improve completeness. Output schema is absent.
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 mentions 'adset_id' as 'Ad set ID', adding meaning to a parameter that lacks a schema description. However, it ignores 'response_format', which is documented in the schema. With 50% schema coverage, the description partially compensates but is incomplete.
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 'Gets detailed information about a specific ad set,' which is a clear verb+resource combination. However, it does not differentiate from sibling tools like meta_get_adset_insights, which could cause confusion about which tool to use for what 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 alternatives, such as meta_get_adset_insights or meta_list_adsets. The description lacks context about prerequisites or appropriate scenarios for invocation.
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=true and destructiveHint=false, so the description's statement 'Gets' is consistent. The description adds some value by listing the return metrics (spend, impressions, etc.), but it does not disclose other behavioral aspects like rate limits, required permissions, or data freshness. It relies on annotations for safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an Args list and a return statement. It is relatively concise (about 12 lines) and front-loads the purpose. A few minor redundancies exist (e.g., repeating schema info), but overall it is well-organized and 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 tool with 7 parameters and no output schema, the description covers the core functionality and return fields. However, it lacks context on sorting, pagination, error handling, or the exact meaning of metrics. Given the complexity and sibling differentiation needed, it is acceptable but not fully 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 input schema has 7 parameters with 57% description coverage. The description provides brief parameter descriptions and enumerates example breakdowns, adding some meaning beyond the schema. However, some parameters like 'since' and 'until' lack format explanation, and the schema already covers enums for date_preset and breakdowns. The baseline is 3 due to moderate 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 that it gets performance insights for campaigns, and the parameter list aligns with campaign-level metrics. However, it does not explicitly distinguish itself from sibling tools like meta_get_account_insights or meta_get_ad_insights, which are similar but for different levels.
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. For example, it does not explain that this is for campaign-level insights, whereas meta_get_ad_insights is for ad-level insights. The optional campaign_id parameter implies filtering, but no explicit when-to-use advice is 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?
The tool already has annotations indicating it is read-only, non-destructive, and idempotent. The description adds minimal value by noting it is 'for debugging', which reinforces safety but does not provide new behavioral details about data limits or other constraints.
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—and front-loaded with the action and purpose. Every word adds value, and there is no unnecessary text.
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 tool has two parameters and no output schema, the description is incomplete. It does not explain the response_format parameter or clarify the time window for 'recent' events. The brevity leaves an agent unsure about usage details beyond the required pixel ID.
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%; only the required pixel_id is described in the description (with redundant 'Pixel ID'). The optional response_format parameter is not mentioned, and the description does not add meaning beyond the schema for pixel_id. It fails to compensate for the missing parameter guidance.
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 retrieves 'recent events' for a pixel and specifies the purpose 'for debugging'. This distinguishes it from sibling tools like meta_get_pixel (getting pixel details) and meta_get_pixel_stats, though it could be more precise about what 'recent' means.
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 context by stating 'for debugging', but it does not explicitly guide when to use this tool versus alternatives like meta_test_conversion_events or meta_send_conversion_event. No exclusions or when-not scenarios 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=true, destructiveHint=false, and idempotentHint=true, so the agent knows it is a safe read operation. The description adds the specific reaction types but does not disclose any additional behavioral traits (e.g., permission requirements, rate limits, or output structure). 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 very concise at one sentence plus an args list. It front-loads the action. However, it lacks structured formatting (e.g., bullet points) and could better separate the main action from parameter details.
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 simple but has no output schema. The description does not explain the return format (e.g., structure of reaction counts). It also omits the response_format parameter entirely, leaving ambiguity for the agent. Annotations provide safety info, but behavioral details are insufficient for a fully autonomous 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 coverage is 50%: the description only mentions post_id and omits the response_format parameter entirely. It does not add meaning beyond the schema for post_id, and fails to explain the response_format parameter's purpose, defaults, or effects. The description falls short given the moderate 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 retrieves reaction counts (like, love, haha, wow, sad, angry) on a post. It specifies the exact verb and resource, and the listed reaction types distinguish it from sibling tools like meta_get_post or meta_get_post_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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or contrast with related tools. Users must infer 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 indicate readOnlyHint=true, so the description doesn't need to restate safety. However, it fails to mention pagination behavior (e.g., use of 'after' for cursors) or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. However, it omits some detail but still maintains a compact 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?
Despite having 4 parameters and no output schema, the description does not explain pagination, the 'after' cursor, or how results are returned. It lacks completeness for a listing 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?
Description covers only ad_account_id and limit (2 of 4 parameters) with minimal explanations. The 'after' and 'response_format' parameters are omitted entirely. Schema description coverage is low (25%), yet the description does not compensate.
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 videos in an ad account's video library with a specific verb and resource. It distinguishes itself from sibling tools like meta_list_ad_creatives or meta_list_ad_images by focusing on the video library.
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., listing ad creatives or images). No mention of prerequisites or context where this tool is appropriate.
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 merely restates the action, adding no behavioral context beyond the annotations. It does not disclose permissions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and to the point, with args listed. Could be improved with structured formatting, but no wasted words.
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 action with no output schema, the description covers the basic action and key parameters but misses response_format and return value info. 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 adds meaning for 3 of 4 parameters (explaining comment_id, page_id for token lookup, message as reply text), compensating for the low schema coverage (25%). However, it omits the response_format parameter entirely.
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 'Replies to a comment on a Facebook Page post,' providing a specific verb+resource. It distinguishes from siblings like meta_reply_instagram_comment and meta_delete_comment.
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, prerequisites, or when not to use it. The description lacks context for 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?
Annotations provide no safety hints and description adds minimal behavioral context beyond stating it creates something. No mention of side effects, idempotency, or authentication needs. The description does not contradict annotations but adds little 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 front-loaded with purpose, concise with a brief paragraph and a clean arg list. However, the arg list largely repeats schema information, which could be seen as redundant.
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?
While it notes the return value (the new lookalike audience ID), it lacks prerequisites, error conditions, or performance considerations. Given no output schema, the description could provide more context on expected outcomes and constraints.
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 explanations for parameters with missing or brief schema descriptions, especially 'ad_account_id' and 'name' lacking schema descriptions. It enriches 'origin_audience_id', 'country', and 'ratio' with more specific details. Only 'response_format' is not mentioned, but it has a full schema 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 the verb ('creates') and resource ('lookalike audience') with a specific basis ('based on an existing custom audience or page'). It distinguishes from sibling tools like meta_create_custom_audience and meta_create_saved_audience.
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 does not explain use cases, prerequisites, or trade-offs compared to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description confirms deletion. However, it adds no extra behavioral context like irreversibility, auth requirements, or side effects. With annotations present, the bar is lower, but the description should ideally provide more.
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 one sentence and a parameter list. Every word is necessary, and it is well-structured for quick scanning.
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 delete tool with one parameter, the description is functional but minimal. It lacks context about consequences, permissions, or what happens to associated data. Given the destructive nature, more completeness would be beneficial.
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 0%, so the description must compensate. It lists the parameter 'pixel_id' with type and purpose, which adds basic meaning. However, it doesn't provide any additional constraints or format details beyond what the schema 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 clearly states 'Deletes a Meta Pixel,' with a specific verb and resource. It distinguishes itself from sibling tools like meta_create_pixel, meta_get_pixel, and meta_update_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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It lacks context for appropriate use cases.
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 'immediately' but fails to disclose important behavioral traits like whether the broadcast recording persists, if viewers are notified, or if the operation is reversible. Annotations do not contradict but offer little help.
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 at 5 lines, with clear sections (title, prerequisite, args). No superfluous information, though it could be more compact.
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 does not mention the return value, error handling, or confirmation of success. This is a significant gap for a mutation 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 description coverage is 100%, so the description adds minimal value beyond repeating parameter names. It does provide context that page_id is needed for auth, but overall the parameter info is redundant.
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 ('Ends') and the resource ('active live video broadcast'), distinguishing it from sibling tools like meta_create_live_video and meta_get_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 specifies a prerequisite (calling meta_list_pages first) but does not provide guidance on when to avoid using this tool or mention alternatives. The context is implied but 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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral traits (e.g., what happens if page_id is invalid), but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) and gets straight to the point. It is front-loaded with the purpose and then lists args. No wasted words, though it could be more structured.
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 lack of output schema, the description should inform about the return format or pagination. It does not mention what the tool returns (e.g., list of user IDs or details), making it incomplete for agent decision-making.
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%, with page_id lacking description in schema. The description adds a brief description for page_id ('Facebook Page ID'), supplementing the schema. However, response_format is already described in schema, so overall value is moderate.
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 explicitly states 'Lists users blocked by the Facebook Page,' clearly identifying the action (list) and the resource (blocked users), distinguishing it from sibling tools like 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 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, nor any mention of context or prerequisites. The description is purely declarative without 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?
The description discloses that the tool returns estimated daily outcomes (reach, impressions, actions) and bid suggestion, which adds value beyond the readOnlyHint annotation. There is 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 includes a bullet list for arguments, making it easy to scan. It could be slightly more concise by removing the 'Args:' header, but overall it is clear.
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 and a well-defined schema, the description adequately covers what the tool does and what it returns. It does not include output schema, but the return value is described in plain terms.
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 the adset_id parameter's type and role, which is already implied by its name. The response_format parameter has a description in the schema but is not covered in the tool description, so the description adds minimal meaning beyond what the schema provides.
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 a delivery estimate for an existing ad set. However, it does not explicitly differentiate from the sibling tool meta_get_reach_estimate, which is similar in name and 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 is provided on when to use this tool versus alternatives like meta_get_reach_estimate or meta_get_adset_insights. There are no exclusions or context for use.
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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the prerequisite 'Requires Instagram Shopping' which offers some behavioral context not in annotations, but doesn't explain other behaviors like rate limits or errors.
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?
Description is short and front-loaded with purpose. However, it lists only one of two parameters in 'Args', missing response_format, which detracts from completeness but maintains conciseness.
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 getter with no output schema, the description covers essential purpose and one parameter but does not describe output format or optional parameter. Somewhat adequate but lacks 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?
Schema description coverage is 50% (media_id lacks description). The description provides a description for media_id, filling the gap. However, it omits response_format parameter entirely, which already has a description in schema but could be reiterated for completeness.
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 clearly states it gets product tags on Instagram media and mentions a prerequisite. However, it could be more specific about what constitutes product tags, slightly reducing clarity.
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 among many sibling tools. Only a prerequisite is mentioned, but no when-not-to or 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 indicate readOnlyHint=true and destructiveHint=false, which align with the description 'Lists'. The description adds context about the type parameter and default limit but does not disclose pagination behavior (cursor-based via 'after' parameter) or any other traits 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 concise: two sentences followed by a bullet list of arguments. It front-loads the main action. The bullet list could be more structured (e.g., markdown formatting), but it is clear and 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?
Given 5 parameters, no output schema, and low schema coverage, the description is incomplete. It fails to mention pagination ('after'), response format options, or what the returned data contains (e.g., photo IDs, URLs). Without output schema, these details are necessary for proper use.
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 20% (only response_format described). The description adds meaning for page_id, type, and limit with brief explanations, covering 3 of 5 parameters. However, it omits 'after' (pagination cursor) and 'response_format', leaving gaps despite partially compensating 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 purpose: 'Lists photos uploaded to a Facebook Page.' It specifies the type parameter to distinguish between 'uploaded' and 'tagged', which is a key differentiator. However, it does not explicitly compare to siblings like meta_get_page_tagged, which overlaps with the 'tagged' option.
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 the type parameter as 'uploaded (by page) or tagged (photos page is tagged in)', giving context on when to use each. However, it does not mention alternatives or when not to use this tool, such as for only tagged photos without other page data, nor does it compare to similar tools like meta_get_page_tagged.
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 clear. The description adds no extra behavioral context beyond stating it gets posts. No mention of pagination, rate limits, or the nature of the returned 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?
Very concise: two sentences with no fluff. However, it could have included more detail (e.g., pagination) without losing conciseness.
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 and the presence of annotations, the description covers the basic purpose but lacks details on pagination (after parameter), output format options, and the important distinction that these are posts made by others tagging the page.
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 tool description mentions page_id and limit but adds no meaning beyond the schema's type constraints. It omits after and response_format entirely. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets posts that tag this Facebook Page' which specifies the verb (gets), resource (posts), and scope (tagging this page). This distinguishes it from sibling tools like get_posts or 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 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 does not explain that this is for posts from other users tagging the page, nor does it mention when get_posts or get_visitor_posts might 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=true and destructiveHint=false, so the agent knows it's safe. The description adds minimal behavioral context beyond stating it lists videos. No disclosure of pagination behavior or other traits.
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 one sentence and a brief parameter list. It is front-loaded with the main action, but could be more structured by including all parameters, especially 'after' for pagination.
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 tool with four parameters and no output schema, the description lacks explanation of pagination ('after') and output format ('response_format'). Given the number of sibling tools, more context about how this fits in would be helpful.
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 25% (only response_format has description). The tool description explains page_id and limit but omits 'after' (pagination cursor) and 'response_format'. While it adds some value, it 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 clearly states the tool lists videos uploaded to a Facebook Page, using a specific verb and resource. It distinguishes from sibling tools like meta_get_page_photos (photos) and meta_get_page_albums (albums).
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_get_live_videos or meta_create_video_post. The description lacks context about when not to use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. Description adds no extra behavioral context beyond listing pixels, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with purpose, no unnecessary words. Efficient and clear.
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 and no description of return format or pagination behavior. For a list-all operation, this omission reduces 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?
Only one parameter (ad_account_id) is briefly described in the description as 'Ad account ID', which adds little beyond the schema. The response_format parameter has a schema description but is not mentioned in the description. With 50% schema coverage, the description does not compensate.
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 states 'Lists all Meta Pixels for an ad account' with a specific verb and resource, clearly distinguishing from sibling tools like meta_get_pixel (single pixel) and meta_create_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?
No when-to-use or when-not-to-use guidance provided. Does not mention alternatives like meta_get_pixel for individual pixel details.
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, placing full burden on the description. However, the description merely states the action without disclosing side effects, reversibility, permissions needed, or whether the share can be revoked. This minimal disclosure is insufficient for a complete behavioral understanding.
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 with two sentences and a parameter list. It is front-loaded with the core purpose and wastes no words. Every element serves a purpose.
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?
There is no output schema, so the description should explain return values or success indicators, but it does not. The optional 'response_format' parameter is not mentioned in the description. The description is incomplete for a share action, lacking context on what happens after sharing.
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 tool description adds brief labels (e.g., 'Pixel ID') but does not explain parameter formats, constraints, or usage details beyond what the schema already provides. This does not adequately compensate for 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 clearly states 'Shares a pixel with another ad account,' which is a specific verb+resource+target action. This distinguishes it from sibling tools like meta_get_pixel, meta_create_pixel, etc., which handle other pixel operations.
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 needing to grant another ad account access to a pixel, but it lacks explicit guidance on when not to use this tool, prerequisites (e.g., admin permissions), or alternative methods. No exclusions are provided.
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, destructiveHint=false, idempotentHint=true. The description adds that it is for carousel items but does not elaborate on behavior like rate limits or response details. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with purpose. Could list both parameters explicitly, but is efficient overall.
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?
Lacks description of return value or fields. No output schema, so description should explain what each item contains. Does not mention pagination or additional context.
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 description, media_id does not). The description adds meaning for media_id ('Carousel media ID') but not for response_format. Partially compensates for missing schema 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 clearly states that the tool gets individual items in a Threads carousel post, using a specific verb and resource. It distinguishes from siblings like threads_get_post which gets a single 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?
No guidance on when to use this tool vs. alternatives. Does not mention prerequisites, such as needing a carousel media ID from a parent post, 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 and destructiveHint, so the safe read nature is clear. The description adds the specific context of @mentions. However, it does not disclose any further behavioral details such as pagination or authentication 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 description is brief and to the point, but it sacrifices useful information for brevity. It could be improved by including context about the response_format parameter or usage 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?
The description covers the core purpose but omits the optional response_format parameter, which is defined in the schema but not explained in the description. For a tool with no output schema, the agent might benefit from knowing the response format options. Overall, the description is somewhat 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?
The description only mentions the required parameter threads_user_id with a trivial label, while the optional response_format parameter is described in the schema but not in the description. With 50% schema coverage, the description should add more context but fails to do so.
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 retrieves posts where the authenticated user was @mentioned, using a specific verb and resource. It is distinct from sibling tools like threads_get_posts and threads_get_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?
The description provides no usage guidelines, such as when to use this tool instead of threads_get_posts or threads_get_replies. The agent would need to infer based on the purpose.
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, destructiveHint, idempotentHint. Description adds no additional behavioral context (e.g., rate limits, authentication, error handling). 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?
Very short and front-loaded with purpose, but the Args list is presented in a compact docstring style. Could be slightly more structured but overall 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?
No output schema, yet description only says 'details' without specifying return content or the importance of response_format parameter. Adequate for a simple GET but leaves important context for the AI 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?
Description only mentions media_id in the Args list, omitting response_format parameter entirely. Schema coverage is 50% and description fails to add meaning for the undocumented parameter or provide examples for media_id.
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 clearly states 'Gets details for a single Threads post by ID', specifying exact verb and resource. Distinguishes from sibling tools like threads_get_posts and threads_get_post_insights by focusing on a single 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?
No guidance on when to use this tool vs alternatives like threads_get_posts or threads_get_post_insights. No mention of 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 provide little info (readOnlyHint=false, destructiveHint=false), so the description should disclose more. It mentions the two-step flow and returns a media ID, but lacks details on side effects, rate limits, or authentication needs.
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: 3 sentences plus a parameter list. It front-loads the purpose and includes the two-step flow. However, the parameter list is somewhat 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?
Given no output schema, the description mentions the return value (media ID). However, it does not explain the two-step flow in detail, and omits optional parameters. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, but the description lists only 4 of 7 parameters, omitting reply_control, location_id, and response_format. The description adds minimal value beyond the schema, and missing parameters reduce completeness.
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 text-only post to Threads, distinguishing it from siblings like threads_publish_image or threads_publish_video by specifying 'text-only'. It also mentions the two-step flow.
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 provide guidance on when to use this tool versus alternatives (e.g., other publish tools). It mentions a two-step flow but no context on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false) but not destructive. The description adds little beyond stating it's a share action; it does not disclose behavioral traits like permissions needed, rate limits, or potential side effects like duplicate shares. With minimal annotations, the description should provide more 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 purpose followed by two bullet points for arguments. No extraneous words, well front-loaded with the core action.
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 tool with two required parameters and no output schema, the description covers the basic action. However, it lacks detail on error conditions (e.g., invalid media ID, permission failures) and does not explain the response format parameter, which is only documented in the schema. It is minimally 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?
Schema description coverage is 67% (media_id and response_format have descriptions; threads_user_id lacks one). The tool description adds the missing description for threads_user_id ('Your Threads user ID'), compensating slightly. However, it does not explain the relationship between parameters or provide additional constraints, so only marginal value added.
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 'Reposts (shares) an existing thread to your profile' with a specific verb and resource. It distinguishes from sibling publishing tools that create new content rather than sharing existing threads.
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 threads_publish_text. The description does not mention when not to use or any prerequisites such as ownership or permissions required to repost.
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. The description does not add behavioral context beyond the shallow annotation values. It does not mention side effects, permissions, or response behavior, leaving the agent with minimal insight.
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 starts with the core action. The parameter list is slightly redundant with the schema but adds readability. No wasted sentences.
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?
Despite having 8 parameters and no output schema, the description omits return value, error handling, and necessary permissions. It assumes the agent knows Facebook API context, which is insufficient for a complete decision.
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 clear, human-readable explanations for all parameters (page_id, name, start_time, end_time, description, place, ticket_uri), compensating for the schema's low 25% coverage. Each parameter is explained with type and purpose.
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 'Creates an event on a Facebook Page', using a specific verb and resource. This distinguishes it from sibling tools like meta_create_post or meta_create_ad.
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 are many create tools, and the description does not mention when to choose this one over others, nor any prerequisites or limitations.
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 the description aligns by stating 'Deletes.' However, it adds no extra behavioral details such as whether deletion is permanent, whether it affects running ads using the rule, or what the response looks like (no output schema). The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines including an Args section. It avoids unnecessary words and is front-loaded with the main action. Minor improvement: could be more structured for 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 simple delete operation with one parameter and an output schema, the description is minimal but functional. It lacks details about post-deletion effects (e.g., irreversible, impact on campaigns) and does not leverage the schema or annotations to enrich context.
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 0% schema description coverage, the description provides 'Ad rule ID' which adds some meaning over the bare schema. However, it does not specify the format of the rule_id (e.g., numeric, string from API) or how to obtain it (e.g., from list_ad_rules).
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 clearly identifies the resource as 'automated ad rule.' It distinguishes from sibling tools like meta_create_ad_rule (creates), meta_get_ad_rule (gets), and meta_list_ad_rules (lists).
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. For example, it does not mention prerequisites (rule must exist) or that meta_delete_ad_rule is for rules, not ads. The description lacks any context about proper invocation.
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 annotations (readOnlyHint=true, destructiveHint=false) by using 'gets,' but it does not add behavioral details beyond what annotations convey. It lacks information about response format, pagination, or permission requirements, but the annotations already cover the safety profile adequately.
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 followed by a list of parameters. Every sentence is useful, and it is front-loaded with the main action. No extraneous content.
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 five parameters and lack of output schema, the description is thin. It does not explain what the activity log contains, how to interpret it, or any critical context like permission requirements. With many sibling tools, more detail would help the agent select appropriately.
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 20% schema description coverage, the description adds moderate value by clarifying the date format for 'since' and 'until' and stating defaults. However, it omits the 'response_format' parameter (which has a schema description) and provides only minimal info for others, partially compensating for 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 clearly states 'Gets the activity/change log for an ad account,' specifying the verb, resource, and scope. It distinguishes itself from sibling tools that retrieve other types of ad account data, such as meta_get_ad_account or meta_get_ad_insights.
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 when not to use it, prerequisites, or provide context for selecting this tool over other log or audit tools among the many siblings.
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, destructiveHint=false, idempotentHint=true. Description adds 'detailed information' but provides no further behavioral context (e.g., requires campaign ownership, what fields are returned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus arg list is concise and front-loaded. No unnecessary words, but the arg list could be integrated into the description.
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 operation with two parameters and no output schema, the description is minimally adequate. However, it doesn't clarify what 'detailed information' includes or any pagination/format details.
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 are described in the schema. The description mentions campaign_id but adds no additional meaning beyond the schema; response_format is omitted from 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 uses 'Gets detailed information about a specific campaign' which is a specific verb and resource, and clearly distinguishes from sibling tools like update, delete, create, and list operations.
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., meta_get_campaign_insights or meta_list_campaigns). Does not specify prerequisites or 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 read-only, non-destructive, and idempotent behavior. The description adds only 'details' without specifying what that entails (e.g., fields returned, pagination, authentication requirements). No additional behavioral traits 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 very short (two sentences) with no redundant information. It is front-loaded with the purpose. However, it could be slightly more structured to include parameter details.
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 is adequate for a simple read tool with rich annotations and schema coverage, but it lacks information about return values or output format (no output schema). It does not compensate for missing details in the response.
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, so baseline is 3. The description repeats the audience_id parameter without adding new meaning, and does not mention the response_format parameter or 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 'Gets details about a specific custom audience,' using a specific verb and resource. It distinguishes from sibling tools like 'meta_list_custom_audiences' which lists all 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 usage when you need details of a specific audience by ID, but it does not explicitly state when to use this tool versus alternatives (e.g., listing or searching). No exclusions or alternative tool names are provided.
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. The description adds no extra behavioral context beyond stating it gets replies. No mention of rate limits, authentication, or pagination.
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?
Very concise with one sentence plus bullet list, front-loading the purpose. However, the structure could be slightly improved by separating the description from parameter docs more clearly.
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?
No output schema provided, and description does not describe the return format or any behavioral constraints. Lacks completeness for a tool that could return a list of replies.
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 (33%, only response_format described in schema). The description adds descriptions for comment_id and limit, but misses response_format. Partially compensates but incomplete.
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 'Gets replies' and the resource 'a specific Instagram comment'. It distinguishes from sibling tools like meta_get_instagram_comments and meta_reply_instagram_comment.
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 or when not to use it. Missing context that would help an agent decide between related 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. The description confirms read-only behavior ('Gets') but adds no additional behavioral traits beyond annotations, such as rate limits or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action. No extraneous words or 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?
The description is adequate for a simple read operation with good annotations, but it omits any hint of return structure or pagination. Since there is no output schema, the agent might benefit from more detail about what data is returned.
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 50% (only response_format has description). The description merely repeats the parameter name 'ig_account_id' without clarifying its format or usage. It adds minimal value over the schema's structural 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 clearly states it gets live video broadcasts from an Instagram account, with a specific verb and resource. It distinguishes from sibling tools like meta_get_instagram_media or meta_get_live_videos by specifying 'live video broadcasts' for Instagram.
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 like meta_get_live_videos or meta_get_instagram_media. No context on prerequisites 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, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds minimal behavioral context beyond stating it lists location pages. Without additional details on pagination or data freshness, 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 brief and front-loaded with purpose. The Args list is minimal but clear. It could be more efficient by integrating parameter descriptions, but it is not wasteful.
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 information about the output format and does not explain two of the three parameters. Without details on limit and response_format, the agent may misuse the tool. The description is not sufficient given the tool's complexity.
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 documents page_id as 'Parent Facebook Page ID', while limit and response_format are not described in the description. Schema coverage is 33%, and the description fails to cover the remaining parameters. This leaves the agent with incomplete 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 uses the specific verb 'lists' and clearly identifies the resource as 'location pages for a business with multiple locations.' This distinguishes it from sibling tools like meta_get_page and other page-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for businesses with multiple locations, but does not provide explicit guidance on when to use this tool versus alternatives like meta_get_page or other location-related tools. No exclusions or when-not-to-use 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 indicate read-only, non-destructive, idempotent behavior. The description adds return value details (IDs, names, filters, counts) but does not disclose any additional behavioral traits like pagination or rate limits. Adequate but not enriched.
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 very short, front-loading the purpose. However, it omits one parameter (response_format), so it is incomplete rather than appropriately concise.
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 low complexity and no output schema, the description covers basic return values. But the missing parameter (response_format) and lack of pagination details make it less complete. Adequate for a simple list tool but with a clear gap.
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 100%, so the schema documents all three parameters (catalog_id, limit, response_format). However, the description omits the response_format parameter entirely, which is important for output handling. This gap reduces usefulness 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 explicitly states 'Lists product sets (subgroups) in a catalog.' This clearly identifies the tool's action (list) and resource (product sets), distinguishing it from related siblings like meta_list_products or meta_list_product_catalogs.
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 or when not to use this tool versus alternatives. However, the purpose is clear from the name, so an agent could infer usage. Minimum viable.
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 hints (readOnlyHint=false, destructiveHint=false). Description states it publishes a story (write operation) and returns the story ID. Lacks details on potential side effects, limitations, or when the story appears.
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?
Short and to the point with a clear list of parameters. The prerequisite is clearly stated. Could be slightly more structured but overall 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?
Covers basic purpose, prerequisite, and return value. However, for a mutation tool with no output schema and many similar siblings, more context about use cases or differences would improve completeness.
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 schema already describes parameters. Description repeats some (page_id, media_url, media_type) but adds minimal extra meaning (e.g., 'Public URL'). The response_format parameter is not mentioned in 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?
Clearly states it publishes a story (photo or video) to a Facebook Page. The verb 'publishes' and resource 'story' are specific. However, it does not explicitly distinguish from sibling tools like meta_create_photo_post or meta_publish_page_reel.
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?
Mentions a prerequisite (meta_list_pages to load page tokens) which helps usage. But no guidance on when to use this tool versus alternatives like meta_create_photo_post (for feed posts) or meta_publish_page_reel.
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 and destructiveHint=false. The description adds that the tool returns an image hash for use in creatives, but does not disclose rate limits, authorization requirements, or behavior on duplicate uploads. With annotations present, the description provides minimal extra 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 concise with a clear purpose statement, bulleted args, and return value. It front-loads the key action. The 'Args:' section is somewhat redundant with the schema but still efficient, with no wasted words.
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 no output schema, the description includes the return value. It explains the tool's purpose and basic parameters, but misses the response_format parameter and does not address authentication or potential errors. For a simple upload tool, it is mostly adequate but has 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 adds meaning for ad_account_id and name, which lack schema descriptions, and clarifies that the return value is an image hash. However, it omits the response_format parameter entirely, despite the schema defining it with an enum and default. Schema coverage is 50%, and the description partially compensates but is incomplete.
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 uploads an image to an ad account's image library for use in creatives, using a specific verb and resource. It distinguishes from sibling tools like meta_upload_ad_video and meta_list_ad_images by focusing on image upload.
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 an image already exists or when to use list_ad_images. No prerequisites 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?
The description indicates a write operation ('Uploads') which aligns with readOnlyHint=false, but does not disclose any additional behavioral traits such as side effects, file size limits, or overwrite behavior. With minimal annotations, the description adds little beyond the fact that it creates a resource.
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 at two sentences with a clear verb and front-loaded action. However, the parameter list is redundant with the schema and does not add unique value, slightly reducing efficiency.
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 information about the return value or output (e.g., video ID, status). Since there is no output schema, the description should provide this context for a creation tool, but it does not.
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 but adds no semantic meaning beyond their names; for example, it does not explain what constitutes a valid file_url or constraints on title. Additionally, the 'response_format' parameter is omitted from the description despite being in the schema. With schema description coverage at 20%, the description fails to compensate for missing parameter details.
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 with a specific verb ('Uploads') and resource ('video to an ad account's video library for use in creatives'), which distinguishes it from sibling tools like meta_upload_ad_image and meta_list_ad_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 implies the tool should be used to upload videos for creatives but does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites 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?
The description mentions the return value (Poll/message ID) but does not disclose behavioral traits such as required permissions, side effects, error conditions, or the fact that the channel must exist. Since annotations are minimal (no destructiveHint, etc.), the description could have provided more 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 purpose, a bullet-style list for parameters, and a return line. It is front-loaded and contains no extraneous 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?
For a simple tool with 3 parameters and no output schema, the description covers the main action and inputs. However, it lacks details on error handling, prerequisites (e.g., needing an existing broadcast channel), and the exact format of the return value, leaving some 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 input schema has 100% coverage with descriptions for each parameter. The description repeats this information in a condensed form but adds no new semantic meaning beyond what the schema already provides, so the baseline score 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 action (creates) and the resource (a poll in an Instagram broadcast channel). It is specific and distinguishes from sibling tools that create other types of content or objects.
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 versus alternatives, nor does it mention prerequisites or when not to use it. The context is implied by the specific resource, but no direct guidance 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 mark this as a non-read, non-destructive operation. The description adds no additional behavioral context such as permission requirements, idempotency, or side effects (e.g., overwriting existing posts). The term 'publishes' implies a write, but this is already evident from 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 a single sentence followed by a concise bullet list of arguments. Every piece of information is relevant, and there is no redundancy or fluff. The structure is front-loaded with the purpose, making it efficient for an AI 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 the purpose and lists all parameters with brief descriptions. However, it lacks information about return values (e.g., post ID or status), prerequisites (e.g., page access token), and constraints (e.g., video file size, supported formats). Given the absence of an output schema, these details would be helpful for an agent to use 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?
With schema description coverage at 40%, the description compensates by adding meaningful descriptions for page_id, title, and description (3 out of 5 parameters). For file_url, both schema and description provide similar info. The description omits response_format, which is documented in the schema with enum and default. Overall, it provides additional context beyond the schema 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 'Publishes a video post to a Facebook Page' uses a specific verb and resource, clearly distinguishing it from sibling tools like meta_create_photo_post, meta_create_post, and meta_create_live_video. The verb 'publishes' indicates a write operation, and the resource 'video post' is precise.
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 states what the tool does without providing guidance on when to use it versus alternatives. For example, it does not clarify that it is for pre-recorded videos (not live) or distinguish from meta_create_post which may also handle video. No prerequisites or alternative behaviors 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 provide destructiveHint=true. The description adds 'This cannot be undone,' reinforcing irreversibility. However, it does not disclose any other behaviors (e.g., effect on ads/adsets, permission requirements). The added value is marginal but present.
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?
Extremely concise: two sentences and a bullet for the argument. The key action is front-loaded. Every sentence is essential.
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 is adequate for a simple destructive tool with annotations. It mentions irreversibility but lacks details on output (no output schema), error conditions, or required permissions. Given the low complexity, it is functional but not fully informative.
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 baseline is 3. The description repeats the parameter name and type but adds only 'to delete,' which is redundant. No additional semantics 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 action: 'Deletes (archives) a campaign.' It uses a specific verb and resource, and the title matches. Among siblings like meta_update_campaign or meta_create_campaign, this tool's purpose is distinct.
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. There is no mention of prerequisites (e.g., campaign state) or comparison to related tools like meta_update_campaign for deactivating. The description only states the action 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 already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context. It does not disclose what 'detailed information' includes or any edge cases like pagination 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?
Extremely concise: two brief lines plus an arg list. The first sentence immediately states the purpose. Every word contributes.
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 lacks an output schema and the description does not explain what 'detailed information' includes (e.g., fields like name, balance, status). For a get tool, more detail on response structure would aid agent decision-making.
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 a helpful example for ad_account_id ('act_123456789') beyond the schema, which only defines type. For response_format, the schema already provides full semantics. With 50% schema coverage, this fills a key 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 'gets detailed information about a specific ad account', which is a specific verb+resource. It distinguishes from siblings like meta_get_ad or meta_get_adset by focusing on the ad account itself.
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_list_ad_accounts (for listing accounts) or meta_get_ad_account_activity. The description does not mention exclusions or prerequisites.
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, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds no further behavioral context (e.g., permissions, side effects), but 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?
The description is extremely concise with two sentences and a bullet list. Every part is meaningful, and the key action is front-loaded. No redundant or unclear phrasing.
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 tool without an output schema, the description is adequate but could improve by mentioning the response format or typical usage context. The agent knows what it does but lacks details on what 'details' entails.
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%, with response_format undocumented in description. The description clarifies rule_id as 'Ad rule ID,' adding marginal value beyond schema. However, the missing response_format description limits agent 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 uses the specific verb 'gets' and identifies the resource as 'details for a specific automated ad rule.' This clearly distinguishes it from sibling tools like meta_list_ad_rules, which lists rules, and meta_get_ad, which gets ad details.
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 (e.g., meta_list_ad_rules for a list). It fails to state prerequisites, exclusions, or typical contexts, relying solely on the parameter requirement.
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, destructiveHint, and idempotentHint. The description adds return field specifics (Channel IDs, names, etc.) but does not disclose additional behavioral traits like pagination, rate limits, or authentication beyond what annotations imply. It adequately supplements annotations without 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 concise and well-structured: purpose statement first, then context, then parameters, then returns. Every sentence adds value with no repetition or fluff.
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 basic purpose and return fields but lacks details on pagination, ordering, error conditions, or behavior when the account has no channels. With no output schema, some completeness is lost, but the tool is relatively simple.
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. The description only mentions 'ig_account_id' in the Args section, omitting 'response_format' which is documented in the schema. It adds no extra meaning beyond the schema definitions.
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 broadcast channels for an Instagram professional account' with a specific verb ('Lists') and resource ('broadcast channels'). It distinguishes from siblings like 'meta_get_broadcast_channel_messages' by focusing on the channels themselves rather than 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 explicit guidance on when to use this tool versus alternatives like 'meta_create_broadcast_channel_poll' or 'meta_send_broadcast_channel_message'. The description does not provide context for when not to use it or mention any prerequisites.
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 carries a lower burden. It adds a behavioral detail: messages are returned reverse chronological from the API and displayed chronologically. No other behavioral traits (rate limits, auth needs) are disclosed, but the safety profile is 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 (3 sentences) and front-loaded with the purpose. The 'Args:' section is slightly redundant with the input schema but still clear. No unnecessary fluff. Every sentence serves a purpose.
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 return values. It only mentions message ordering but not the structure or fields of messages. Annotations cover safety but not completeness. For a retrieval tool, missing output details is a significant gap, especially given the complexity of Instagram DM message objects.
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% (3 of 4 parameters have descriptions). The description lists parameters in a docstring but adds minimal new information beyond what the schema provides (e.g., the note about 'after' being optional and limit default is already in the schema). It does not compensate for the undocumented response_format parameter, which has enum descriptions 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 title 'Get Instagram DM Messages' and description 'Gets messages in an Instagram Direct Message conversation' clearly state the verb (Get) and resource (Instagram DM messages). The tool name distinguishes it from siblings like meta_get_conversation_messages (for page messages) and threads_get_conversation (for Threads). The scope is precise.
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 retrieving Instagram DM messages given a conversation_id. However, it does not explicitly state when to use this tool over siblings, nor does it provide prerequisites or when-not-to-use guidance. The context is clear but 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=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it lists events, but does not disclose additional behavior like pagination limits, rate limits, or authentication requirements. With annotations covering the safety profile, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the main purpose and uses a clear Args list format. Every sentence is 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?
The tool has no output schema, so the description could have explained the return format or structure, but it does not. Given the moderate complexity of listing events and the partial parameter documentation, the description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 25% (only response_format has a description). The description explicitly explains page_id (string), limit (max results 1–100, default 20), and time_filter (enum: 'upcoming' or 'past'), adding meaning beyond the schema. However, response_format is not mentioned in the description, though it has a schema description. Overall, the description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists events created by a Facebook Page,' using a specific verb and resource. It distinguishes itself from sibling tools like meta_create_event (creation) and meta_get_page (page info).
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 provide guidance on when to use this tool versus alternatives, such as other listing tools for page data (e.g., meta_get_page_photos). No context on prerequisites or appropriate scenarios.
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=true, so description adds limited value. It does not mention behavior like pagination or output format 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?
Concise and front-loaded with essential info, but could be slightly more comprehensive without losing brevity.
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?
Incomplete for a tool with 4 parameters and no output schema. Lacks details on pagination, output format, and the exact eligibility criteria for posts.
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?
Describes page_id and limit with default value but omits after and response_format parameters. With only 25% schema coverage, description should compensate more.
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 the tool gets posts eligible for boosting/promotion on a Facebook Page, distinguishing it from other post retrieval 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?
Implies usage for promotable posts but provides no explicit guidance on when to use this tool versus alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by detailing return fields (campaign names, objectives, status, budget info) and pagination support with 'after' parameter. Annotations already indicate read-only, non-destructive behavior, and the description aligns without 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?
Concise, front-loaded with purpose, and lists parameters clearly. Could be more structured with formatting (e.g., bullet points) but effectively communicates essential details without 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 list operation, the description adequately covers inputs, outputs, and pagination. Lacks mention of rate limits or permissions, but annotations address safety. No output schema, yet return fields are summarized.
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 high (80%), but the description covers 3 of 4 documented parameters with additional context (e.g., example ad_account_id, default value for limit). Missing description for 'response_format' parameter, which is in schema but not in 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?
Clearly states it lists campaigns for a Meta ad account, specifying the input parameters and return fields. Differentiates from single-campaign tools like meta_get_campaign but does not explicitly differentiate from other list tools like meta_list_ads or meta_list_adsets.
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 such as meta_get_campaign for a single campaign or meta_get_campaign_insights for performance data. Does not mention prerequisites like having a valid ad_account_id.
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 description carries full burden. It notes the return value but does not disclose rate limits, idempotency, or consequences of publishing (e.g., overwriting existing stories). Minimal behavioral context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose sentence, followed by bulleted Args. Some redundancy with schema but efficient. No 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?
Covers purpose, main parameters, and return value. Missing response_format parameter and error handling or prerequisites (e.g., professional account requirement). Adequate for a simple publish tool with no 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 already describes 3 of 4 parameters (media_url, media_type, response_format). Description adds ig_account_id with a brief description and repeats others. Missing response_format parameter in description. Marginal added value; baseline 3 due to 75% 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?
Description clearly states action ('Publishes'), resource ('image or video story'), and target ('Instagram professional account'). It distinguishes from siblings like meta_publish_instagram_photo and meta_publish_instagram_reel by specifying 'story'.
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?
Implied usage context (for stories to professional accounts) but no explicit when-to-use or comparison with other Instagram publish tools like reels, photos, or carousels. Missing '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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds minimal behavioral context. It does not explain potential side effects (e.g., duplicate messages) 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 with a single action sentence and a brief Args list. However, it redundantly restates schema information, making it slightly less 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 tool's simplicity and the lack of an output schema, the description provides the essential information: what it does and the return value (Message ID). It could include more context on timing or limits, but it 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?
Schema coverage is 100%; the description repeats parameter names and types without adding meaning beyond the schema. For example, it doesn't clarify the formatting or behavior of the optional '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 description clearly states the action (sends), the resource (message), and the target (Instagram broadcast channel). It distinguishes this tool from siblings like 'meta_get_broadcast_channel_messages' and 'meta_create_broadcast_channel_poll'.
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_send_instagram_message' or 'meta_send_page_message'. It lacks context on prerequisites or scenarios where this tool is 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 destructiveHint=true and readOnlyHint=false. The description adds 'permanently', reinforcing irreversibility, but no extra context about authentication, rate limits, or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and a clean args list. No wasted words, and the essential 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?
For a simple deletion tool with one required parameter and clear annotations, the description is complete. It states the permanent nature and parameter, which is sufficient 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% with parameter description 'Threads media ID'. The tool description repeats this almost verbatim, adding no extra meaning beyond what the schema provides.
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 'Deletes' and resource 'Threads post', and the permanent nature distinguishes it from non-destructive operations. However, it does not differentiate from sibling delete tools like meta_delete_post, though the Threads prefix helps.
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 (e.g., threads_hide_reply), nor does it mention prerequisites or restrictions. It only describes the action itself.
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=true, so the description's 'gets' is consistent. However, the description adds no further behavioral context like response format, pagination, or rate limits. It provides minimal added value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus an args list. Every sentence earns its place, with no extraneous words. Structure is clear with an args section.
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 no output schema and only three parameters, the description covers the core purpose but omits details about the return format (response_format parameter is missing), pagination, or potential errors. It is adequate but not 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 33% (only response_format has a description). The tool description adds meaning for 'reverse' (reverse chronological order) and mentions 'media_id' as a Threads media ID, but ignores 'response_format' entirely, leaving it undocumented in the description. It partially compensates but misses a 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 it 'Gets replies to a Threads post,' using a specific verb and resource. This distinguishes it from sibling tools like 'threads_get_post' or 'threads_get_conversation.'
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 vs. alternatives, such as 'threads_get_conversation' which might also return replies. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no behavioral hints. Description states 'publishes' which indicates creation but lacks details on side effects, idempotency, or error conditions. Minimal beyond schema.
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?
Description is short and front-loaded with purpose. Arg list is clear. Slightly underspecified but earns its place without verbosity.
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 discussion of return values, authentication requirements, rate limits, or expected behavior after publishing. Incomplete for a tool that creates content on a social platform.
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?
Description briefly explains 'text' and 'link_attachment' but ignores optional parameters 'reply_control' and 'response_format'. Schema descriptions cover 60% of parameters; description adds marginal value by linking text to URL inclusion.
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 uses specific verb 'publishes' and resource 'thread post with a link attachment,' clearly distinguishing it from sibling tools like threads_publish_text, threads_publish_image, etc.
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 vs alternatives. Usage is implied (for link posts) but no exclusions or comparisons provided.
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 correctly indicates a write operation (creates) and specifies the return value (study ID). With annotations not providing behavioral hints, the description carries the burden, and it adequately discloses the creation action. However, it does not detail side effects or permissions needed.
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 front-loaded with a clear purpose sentence, but the subsequent Args section is lengthy and duplicates schema content. It could be more concise by omitting redundant parameter descriptions and focusing on usage 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?
Given the tool's complexity (9 parameters, nested cells array), the description covers all required and optional fields and states the return value. It is sufficient for an agent to understand the tool's purpose and parameters, though it could benefit from an example or edge case note.
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 repeats parameter details from the schema almost verbatim, adding minimal new meaning. It does not provide context on how parameters interact or examples of valid values beyond what the schema offers.
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 creates an A/B test (ad study) to compare campaigns or ad sets. The verb 'creates' is specific and the resource 'A/B test (ad study)' is well-defined. While it distinguishes from siblings by naming the specific study type, it does not explicitly highlight what makes this tool unique among other 'create' 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 creating A/B tests but does not provide explicit guidance on when to use this tool versus alternatives like meta_create_campaign or meta_create_adset. It lacks context on prerequisites, best practices, 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, destructiveHint, and idempotentHint. The description adds that it returns 'roles', but does not disclose other behavioral traits like pagination, authentication, or error handling. With annotations, the bar is lower, so 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 brief (two sentences plus arg list) and front-loaded with the action. The arg list uses 'Args:' which is efficient but less structured than bullet points. Overall, 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?
For a simple read-only tool with annotations, the description covers the essential behavior (listing users with roles). However, it does not mention output format or pagination. Given low complexity, it is mostly 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 coverage is 50%: only 'ad_account_id' is described in the tool description (with an example), while 'response_format' is documented only in the input schema. The description adds minimal meaning beyond the schema for the covered parameter and ignores the other 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 it lists users with roles for an ad account, using a specific verb ('Lists') and resource ('users who have access to an ad account'). This distinguishes it from siblings like 'meta_get_ad_account' or 'meta_list_ad_accounts'.
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 context (getting users of an ad account) but does not explicitly state when to use versus alternatives or when not to use. No usage guidance beyond the basic purpose.
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, destructiveHint=false, idempotentHint=true. The description adds that it returns 'a list of studies with name, type, status, dates, and results,' which provides context about the output but does not disclose additional behavioral traits beyond what annotations 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 extremely concise: a one-line purpose, followed by bulleted arguments and a returns line. Every sentence adds value, with no wasted words. It is front-loaded 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?
For a simple list tool, the description covers the core operation, required parameter, and return fields. However, it fails to mention the response_format parameter, which is part of the input schema. Given no output schema, the returns description partially compensates, but missing parameter documentation reduces completeness.
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 67%, with ad_account_id and response_format described in schema. The tool description adds a description for limit (missing from schema), but omits response_format. Thus it adds some meaning but not complete over existing schema info.
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 A/B tests (ad studies) for a Meta ad account.' This is a specific verb-resource combination, and the title 'List A/B Tests' aligns perfectly. Among siblings, it is distinct from meta_create_ad_study and meta_get_ad_study_results.
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. For example, it does not mention that meta_get_ad_study_results is for retrieving results of a specific study. No when-not-to-use or prerequisite information is 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 readOnlyHint=true and destructiveHint=false. The description adds that it returns paginated results via the 'after' parameter, but does not disclose other behaviors like error handling, rate limits, or response format variants. With annotations covering safety, the description adds minimal extra 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, a structured list of arguments, and a return description. Every sentence serves a purpose with no redundancy. The most critical information 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 tool with annotations and high schema coverage, the description covers the main functionality. However, it omits the response_format parameter, which is important for output control, and does not explain pagination behavior beyond the 'after' parameter. Slightly incomplete for a tool with 4 parameters and no 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 coverage is 75% (3 of 4 parameters described in schema). The description repeats the schema's parameter descriptions for channel_id, limit, and after, but omits the response_format parameter entirely. Since schema coverage is high, baseline is 3; the description adds no new semantic information 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 'Gets messages in an Instagram broadcast channel', specifying the verb and resource. It distinguishes from sibling tools like meta_get_instagram_broadcast_channels (which retrieves channels) and meta_send_broadcast_channel_message (which sends 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 provided on when to use this tool versus alternatives, prerequisites (like channel ownership or permissions), or any limitations. The description is purely functional and offers no contextual usage advice.
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 read-only, non-destructive, idempotent behavior. Description adds no new behavioral context beyond restating 'Gets'. However, 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?
The description is extremely concise with a single clear sentence and a minimal args list. No extraneous 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 retrieval tool with strong annotations and no output schema, the description is fairly complete. It could benefit from mentioning what the returned CTA data contains, but it 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 coverage is 50% (only response_format has a description). The description helps by labeling page_id as 'Facebook Page ID', but does not explain its format or provide additional details for either 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 tool gets the call-to-action button on a Facebook Page, which is a specific verb+resource. Among many 'get_page_*' sibling tools, this one is uniquely identified by its focus on the CTA.
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 other page retrieval tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 no new behavioral specifics (e.g., return format details, rate limits), but does not contradict annotations. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no extraneous words. Every sentence serves a purpose.
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, and the description does not explain the structure of the 'detailed information' returned. For a read tool on a complex API, this is a significant gap, especially with many sibling 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?
Schema coverage is 50% (response_format described). The description includes an Args section specifying the format for post_id ({page_id}_{post_id}), which adds meaning beyond the schema's type-only definition. This compensates for the missing schema 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 'gets detailed information about a specific Facebook post,' which identifies the action and resource. It distinguishes from sibling tools like meta_get_posts (list) and meta_get_post_insights (analytics).
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 (e.g., meta_get_posts for multiple posts, meta_get_post_insights for metrics). The description does not mention exclusions or prerequisites.
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=true and destructiveHint=false. The description adds the return format (list of posts with message, permalink, etc.), which is helpful but not substantially beyond annotations. No behavioral traits like auth requirements or rate limits are disclosed.
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, well-structured with bullet points for parameters and return values, and front-loaded with purpose and prerequisite. Every sentence adds value.
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 lack of output schema, the description provides a clear return type. It also covers prerequisites and pagination. For a read-only list tool with good annotations, this is adequately complete, though possible extra context like error handling is absent.
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% (missing limit description). The description adds value for limit (max, range, default) but misses the response_format parameter entirely. Overall, it provides some additional meaning but with a notable 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 clearly states it lists posts from a Facebook Page feed. However, among many sibling tools like meta_get_post, meta_get_promotable_posts, etc., it doesn't differentiate itself, which limits clarity for tool selection.
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 mentions a prerequisite (calling meta_list_pages first) and explains pagination, but it does not provide explicit guidance on when to use this tool versus other post-retrieval tools, 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.
Behavior3/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 the 'scheduled (unpublished)' context but does not disclose pagination behavior, rate limits, or response format details beyond the implicit parameters.
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 one clear sentence and bulleted args, but it could be more efficient by including all parameters and still remaining brief.
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 listing tool with 4 parameters and no output schema, the description is somewhat incomplete, missing pagination and response format details, but it provides adequate basics for typical use.
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%), and the description adds value for page_id and limit via brief explanations, but it omits the 'after' and 'response_format' parameters, leaving them fully undocumented.
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 defines the tool's action as listing scheduled (unpublished) posts for a Facebook Page, using specific verbs and resource identification that distinguishes it from sibling tools like meta_get_published_posts.
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 scheduled posts but lacks explicit guidance on when to use this over alternatives like meta_get_posts or meta_get_promotable_posts, and provides no 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 and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the return format ('Event set IDs, names, and configuration'), but does not elaborate on behavioral details like rate limits or authentication requirements beyond what annotations 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 concise and well-structured with a brief intro followed by a bullet-style args list. Every sentence adds value, and the key purpose is front-loaded. No extraneous information 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?
Given the tool has 4 parameters and no output schema, the description adequately explains the resource, all parameters (except response_format), and return. It covers pagination via the 'after' cursor and explicitly states the returned fields. Minor omission of response_format prevents a 5.
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 25% (only response_format has a description). The description covers 3 of 4 parameters (ad_account_id, limit, after) with brief explanations (e.g., 'Ad account ID (e.g., act_123456789)'), adding meaning beyond the schema. However, it omits the response_format parameter entirely, which is important for output control.
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 offline conversion event sets for an ad account,' specifying the verb (list), resource (offline event sets), and scope (ad account). It also explains what offline event sets are, making the purpose distinct and differentiating from sibling tools like meta_get_pixel or meta_list_custom_conversions.
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_send_offline_event or other list tools. It lacks explicit context on prerequisites or exclusions, leaving the agent without decision criteria for tool 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?
The description adds some context beyond annotations (e.g., return fields like product IDs, names, prices), but annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description does not explicitly note that it is read-only or idempotent, but it is consistent. 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 very concise: one sentence for purpose and a brief parameter list. No wasted words, and the essential information is front-loaded. It meets the standard of every sentence earning 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?
Given the tool has 5 parameters, 100% schema coverage, and no output schema, the description adequately covers the core functionality and return fields. However, it omits mention of pagination behavior beyond the 'after' cursor and does not reference the 'response_format' parameter. The description is complete for most use cases but has minor 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?
Schema description coverage is 100%, so baseline is 3. The description's 'Args' section repeats schema parameter descriptions without adding new semantics. It does not explain the 'response_format' parameter, which is present in the schema but omitted from the 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 'lists products in a product catalog,' which is a specific verb and resource. This distinguishes it from sibling tools like 'meta_list_product_catalogs' (lists catalogs) and 'meta_get_product' (single product).
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 provide any guidance on when to use this tool versus alternatives. It lacks information about prerequisites, when not to use it, or explicit references to sibling tools like 'meta_list_product_catalogs' for catalogs or 'meta_get_product' for individual products.
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 migration is an in-place conversion keeping the original ID, adding context beyond annotations (destructiveHint=false, readOnlyHint=false). However, it does not discuss rate limits, permissions, or potential side effects, so it earns a moderate score.
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 title, explanation, and Args section. It is fairly concise, though the explanation of Advantage+ benefits could be trimmed. Front-loaded with purpose.
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 explains the key aspect (keep original ID) but does not mention output or error handling. No output schema exists, so more detail on return format or failure scenarios would improve completeness.
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 descriptions for all three parameters. The description repeats parameter info in the 'Args' section, adding no extra meaning beyond what the schema already provides. 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 it migrates a campaign to Advantage+ Shopping with specific verb 'migrates' and resource 'campaign to Advantage+ Shopping'. It distinguishes from siblings like meta_create_campaign and meta_update_campaign by specifying this is a conversion, not a new 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 description provides context about Advantage+ Shopping's AI benefits but does not explicitly state when to use this tool versus alternatives like meta_create_campaign or meta_update_campaign. It implies usage for existing campaigns needing AI optimization but lacks 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?
The description aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but adds no additional behavioral context beyond what annotations imply. No mention of permissions, side effects, or rate limits. With annotations already covering safety, the description provides minimal extra transparency.
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?
Extremely concise: two sentences and an argument list. Front-loaded with the main purpose. 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?
For a simple tool with two parameters and no output schema, the description combined with schema and annotations provides sufficient context. Could slightly improve by explicitly stating it toggles comments for a specific media object, but it is already clear.
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 both parameters described in the schema. The description does not add extra meaning or format details 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 the action ('Enables or disables comments') and the target ('Instagram media object'). It uses the specific verb 'toggle' and resource 'media object', distinguishing it from other Instagram comment tools like meta_hide_instagram_comment or meta_delete_instagram_comment.
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 doesn't mention prerequisites, exclusion conditions, or differentiate from sibling tools like meta_hide_instagram_comment (hides individual comments) or meta_delete_instagram_comment (deletes comments).
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 idempotentHint=true and non-destructive nature. The description adds minimal context beyond the toggle behavior, but no contradictions. It does not explain side effects like whether hiding affects notifications or is reversible, but annotations cover core safety.
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?
Extremely concise: two sentences plus an arg list. Every element is necessary and front-loaded with the purpose. 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?
Despite no output schema, the tool is simple (2 required params, toggle operation). The description covers purpose and basic arg semantics adequately. However, it could mention the expected return (e.g., success status).
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% (the 'hide' parameter has a description). The tool description restates the 'hide' parameter's meaning but adds no new semantics for 'reply_id', which lacks description in the schema. Thus, minimal 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 the verb 'Hides or unhides' and the resource 'a reply on a Threads post', making the tool's purpose unambiguous. It differentiates from sibling tools like meta_hide_comment or meta_hide_instagram_comment by specifying Threads context.
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 hiding comments on Instagram or Facebook. The description does not mention prerequisites, limitations, or when to prefer this over threads_delete_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 indicate readOnlyHint=true and destructiveHint=false, aligning with the read-only nature. Description adds that it returns 'Current usage and quota remaining,' which is useful but minimal. 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 extremely concise: three short sentences covering purpose, parameters, and return value. Every sentence is necessary and front-loaded with the most critical information. No unnecessary 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?
For a simple read-only check tool with a single required parameter and no output schema, the description adequately covers purpose, parameters, and return value. It does not detail potential error cases or response format, but given the tool's simplicity, it is sufficiently 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 50% (response_format has description in schema). The description repeats the parameter name and type for ig_account_id without adding new details. For response_format, the schema already describes the values. The description adds no semantic 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 clearly states the tool checks the Instagram publishing rate limit, specifying the exact limit (100 API-published posts per 24 hours) and the resource. This unambiguous description distinguishes it from sibling tools, as no other sibling explicitly checks publishing limits.
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 checking the current usage against a 24-hour limit, but lacks explicit guidance on when to use it (e.g., before publishing a post) or when not to use it (e.g., for other rate limits). No explicit alternatives are 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 indicate a write operation (readOnlyHint=false, destructiveHint=false). The description only adds that it returns the new ad ID, lacking details on side effects, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, uses a clear bullet-like structure, and every sentence adds value without unnecessary words.
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 create tool with no output schema, the description covers essential parameters and return value, but lacks details on prerequisites, error handling, or whether creation is immediate.
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 the purpose of five parameters (ad_account_id, adset_id, name, creative_id, status) beyond the schema, referencing sibling tools for creative_id. However, it omits the response_format parameter entirely.
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 'Creates a new ad within an ad set' with a specific verb and resource, distinguishing it from other creation tools like meta_create_ad_creative or meta_create_adset.
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 hints at using creative_id from meta_list_ad_creatives or meta_create_ad_creative, but does not explicitly state when to use this tool versus alternatives like update 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 destructiveHint: true, so the description's addition of 'This is permanent' adds minimal value. No further behavioral details (e.g., permissions, side effects on replies) are provided, but for a simple deletion tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a simple Args list. No wasted words, well-structured for quick comprehension.
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 deletion tool with one parameter and no output schema, the description is complete. It clearly states the action, permanence, and the required parameter. No additional context is necessary.
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% coverage for the single parameter comment_id. The description repeats the same info in the Args section without adding new meaning beyond what the schema provides. 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 (deletes), resource (comment on Instagram media object), and permanence. It distinguishes from sibling tools like meta_delete_comment or meta_hide_instagram_comment by specifying 'Instagram comment' and 'media object'.
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 provide any guidance on when to use this tool versus alternatives such as meta_hide_instagram_comment or other comment management tools. No when-to-use or when-not-to-use 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?
Adds critical information beyond annotations: deletion is permanent and applies to specific media types. Annotation destructiveHint=true is confirmed and enhanced with explicit permanence warning.
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?
Extremely concise: two sentences plus parameter listing. Every word adds value. Front-loaded with action and permanence warning.
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?
Adequate for a simple destructive tool, but lacks return value description (e.g., success indication). With no output schema, the description should hint at what 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?
Input schema already provides 100% coverage with description for media_id. The description repeats the schema info without adding new meaning, 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?
Clearly states it deletes Instagram media objects (post, reel, story) and highlights permanence. Distinguishes from siblings like meta_delete_post and meta_delete_instagram_comment by specifying Instagram media 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_delete_post (Facebook posts) or meta_delete_instagram_comment. Lacks context about prerequisites or when not to use.
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 value beyond annotations by explicitly stating 'This action is permanent and cannot be undone,' reinforcing the destructiveHint. It doesn't cover authorization or side effects but aligns well with the annotation.
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 two sentences and an Args list. It front-loads the action. The Args section is slightly redundant given 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 tool with one parameter, no output schema, and good annotations, the description adequately covers the core action, parameter, and permanence. It is complete enough for this complexity.
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 one parameter. The description repeats the parameter name and type in an 'Args' section, adding no additional meaning beyond what the schema already provides. 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 it 'Deletes a product from a catalog,' which is a specific verb+resource. However, it does not explicitly differentiate from sibling delete tools like meta_delete_ad or meta_delete_campaign, though the resource is distinct.
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 mentions the action is permanent and cannot be undone, which implies when to use it (for permanent deletion). But it does not provide explicit guidance on when not to use it or alternatives like meta_update_product for modification.
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. The description adds parameter behavior like limit range and pagination cursor, but does not disclose additional traits such as rate limits or output format 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 with a single sentence stating purpose followed by a clear bullet list of arguments. No fluff, front-loaded, and every sentence is valuable.
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 input parameters well but lacks details on output content and pagination behavior. No output schema exists, so the description should compensate, but it does not explain what fields the media list contains or how pagination works beyond the cursor parameter.
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 ig_account_id (source function) and limit (range and default). It clarifies pagination with 'after'. However, response_format is documented only in the schema, not in the description. Overall, it enriches understanding of the 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 lists media (posts, reels, stories) from an Instagram professional account, providing a specific verb and resource. This distinguishes it from sibling tools like meta_get_instagram_single_media or meta_get_instagram_media_insights.
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. Prerequisites are hinted at (ig_account_id from meta_list_instagram_accounts), but no exclusions or comparative context 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 provide readOnlyHint=true and destructiveHint=false. The description adds context that it retrieves from a carousel, but does not disclose any additional behavioral traits such as error handling for non-carousel media 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 very concise, with one sentence and a parameter list. However, it could be slightly more informative about the return value without becoming 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?
For a simple retrieval tool with two parameters and no output schema, the description covers the basic action and required parameter. However, it lacks information on what the response contains (e.g., media item details) and does not address edge cases such as invalid carousel IDs.
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 lists the parameter names without adding significant meaning beyond the schema. The required 'media_id' parameter lacks description in both schema and description (only 'Carousel media ID'), and the optional 'response_format' is already 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 uses a specific verb ('Gets') and resource ('individual media items in a carousel/album post'), making the tool's purpose clear. It distinguishes from siblings like meta_get_instagram_media by specifying carousel context.
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 when you have a carousel media ID and need its child items. However, it lacks explicit guidance on when not to use this tool or mention of alternative tools for non-carousel media.
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. Description adds that it returns page details including specific fields, which is helpful for understanding output. No mention of permissions or rate limits, but for a read-only tool, the annotations cover safety.
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?
Description is short and front-loaded with the purpose. It includes an 'Args' section and return details. However, the argument listing is redundant with the schema, slightly reducing efficiency. Still concise overall.
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 good annotations and full schema coverage, the description covers the essentials. No output schema exists, but description lists key return fields. For a simple retrieval tool, this 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?
Schema description coverage is 100%, so baseline is 3. The description mentions page_id but does not add meaning beyond the schema. It omits the response_format parameter entirely, but schema already describes it fully. No added 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?
Clearly states 'Gets detailed information about a specific Facebook Page' with specific verb+resource. Distinguishes from sibling tools like meta_list_pages (which lists pages) and meta_get_page_insights (which returns analytics). The listed return fields (name, category, description, follower counts, linked Instagram account) further clarify 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 guidance on when to use this tool versus alternatives. Does not mention when not to use, prerequisites (e.g., page access token), or differentiation from similar tools like meta_get_page_insights or meta_get_page_albums.
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 idempotentHint=true, so the agent knows it's safe and idempotent. The description adds no extra behavioral context beyond 'lists', which is sufficient for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the main purpose. The 'Args' section is clear but could be more structured. It avoids unnecessary 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?
Given the tool's simplicity, annotations covering safety, and no output schema needed, the description provides complete functional context. No additional behavioral or return details are necessary.
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 a description for page_id (missing in schema) and clarifies its role. Schema already documents response_format with an enum. Overall, the description compensates for schema gaps, though response_format is already well-described.
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 clearly states 'Lists custom tabs on a Facebook Page' with a specific verb and resource, distinguishing it from sibling tools like meta_get_page (page details) and meta_get_page_albums.
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. With many page-related sibling tools, the description should clarify that this is specifically for custom tabs, but it does not provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 understands it is a safe read operation. The description adds that it returns creative IDs, names, and page post IDs, which is useful but does not elaborate on pagination behavior or other traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and includes a structured Args list. However, it repeats information that could be more streamlined, and the Args block could be integrated more naturally.
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, annotations, and no output schema, the description adequately covers the return values and key parameters. It mentions pagination and the returned fields, which is sufficient for a list 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 coverage is only 25%, but the description compensates by listing and briefly describing three of four parameters (ad_account_id, limit, after). While descriptions are minimal, they add meaning beyond what the schema provides for those 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 lists ad creatives for an ad account, using specific verb and resource. It distinguishes itself from sibling tools like meta_get_ad_creative (retrieve one) and meta_create_ad_creative (create).
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 use meta_get_ad_creative or other list tools. It simply states what it does without exclusions or 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 indicate read-only and idempotent behavior; description adds return format details and default limit, providing additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description front-loaded with purpose, followed by succinct parameter list; no wasted words.
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?
Adequate for a simple listing tool but missing guidance on Business Manager context and omission of response_format parameter.
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 75%; description adds meaning for 'limit' (max results) but omits 'response_format' 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 tool lists assets (pages, ad accounts, Instagram accounts, pixels) for a Business Manager, with a specific verb and resource 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 vs alternatives like meta_list_pages or meta_list_ad_accounts.
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, destructiveHint, and idempotentHint, covering safety. The description adds that feeds keep catalogs up-to-date and lists return fields (IDs, names, schedules, status), adding some value but not deep 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 purpose, a brief explanation of feeds, and a bullet list of args. Every sentence adds value, and it is front-loaded with the core action.
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 annotations, the description covers the return format and arg types. It misses response_format in the text, but the schema handles it. Overall, it provides enough context for an agent to use the 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?
Schema description coverage is 67%. The description repeats catalog_id and limit with no extra meaning beyond the schema, and omits response_format entirely. Thus it adds little value 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?
The description clearly states 'Lists product feeds for a catalog.' It uses a specific verb and resource, distinguishing it from sibling tools like meta_create_product_feed (create) and other list tools (e.g., meta_list_products).
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: to list feeds for a catalog. However, it does not specify when to use this tool over alternatives or provide exclusion criteria. No explicit guidance on prerequisites or 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 show readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that results can be used for tagging, but provides no additional behavioral details 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 concise: one clear sentence followed by a structured Args list and Returns note. No extraneous words; front-loaded with purpose.
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?
No output schema; the Returns line provides basic context but lacks detail on pagination or result limits. For a search tool, it is adequate but not exhaustive.
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 description adds only minimal extra meaning (e.g., catalog_id source). The Args section largely duplicates schema descriptions, resulting in a baseline 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 'Searches for products in an Instagram Shopping catalog by name' with a specific verb and resource. It clearly distinguishes from sibling tools like meta_search_instagram_hashtag or meta_search_ad_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 mentions the catalog_id comes from meta_get_instagram_available_catalogs, implying a prerequisite, but lacks explicit when-to-use or when-not-to-use guidance compared 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?
The description transparently states that only provided fields are changed, implying partial update behavior. However, it does not disclose error conditions, validation rules, or implications of setting status to ARCHIVED. Annotations provide no additional cues.
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 summary sentence followed by a clear argument list. No redundant or irrelevant 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?
While the description covers core usage and parameters, it lacks information about return values (no output schema) and potential errors. For a mutation tool with 7 parameters, this 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?
The description adds meaning to most parameters beyond the schema, such as specifying daily_budget in cents and end_time as ISO 8601. Schema coverage is low (29%), so description compensates well. However, response_format is omitted.
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 tool name and description clearly state it updates an existing ad set, specifying that only provided fields are changed. This distinguishes it from related tools like meta_create_adset and meta_delete_adset.
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 lacks explicit guidance on when to use this tool versus alternatives such as creating a new ad set or deleting and recreating. It does not mention prerequisites or conditions under which updates are not allowed, leaving potential for misuse.
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?
Adds behavioral context beyond annotations by noting the scope limitation (authenticated user's content and public threads). Annotations already declare read-only and non-destructive, so this is additive.
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?
Extremely concise: two sentences and an Args block. Every sentence earns its place with no wasted words.
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 main constraints but lacks detail on response_format parameter and expected output format. With no output schema, more detail on return values would improve completeness.
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 has 50% description coverage (q and response_format have descriptions). The description adds context for threads_user_id ('for auth context') and limit ('Max results default 20'), but omits response_format parameter. Provides marginal additional 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 'Searches Threads posts by keyword', providing a specific verb and resource. It distinguishes itself from sibling tools like threads_get_posts, but does not explicitly differentiate from other search 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 note about results being limited to authenticated user's content and public threads gives context but does not explicitly state when to use this tool versus alternatives or provide 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?
Annotations indicate a write operation (readOnlyHint=false), consistent with 'creates'. The description adds that the output is the creative ID but lacks details on side effects, rate limits, or required page permissions. It provides adequate but not comprehensive behavioral 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 concise, using a clear 'Args:' list structure front-loaded with purpose. Each sentence serves a purpose, though it could be slightly more compact. No waste.
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 moderate complexity (9 parameters, no output schema), the description covers the primary purpose and param details but lacks guidance on dependencies (e.g., creative ID needed for meta_create_ad) and does not clarify fallback logic when object_story_id is omitted. It is adequate but not fully comprehensive.
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 33% (only page_id and object_story_id described). The description lists all parameters with inline descriptions, adding meaning (e.g., object_story_id format, parameter types). However, it omits the 'response_format' parameter included in the schema, which is a 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 'Creates an ad creative from an existing Facebook Page post', specifying the verb (creates), resource (ad creative), and source (existing post). It distinguishes from siblings like meta_create_ad (creates an ad, not a creative) and meta_create_adset.
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 creating an ad creative from a post but does not explicitly state when to use this tool vs alternatives (e.g., meta_create_ad which might also create a creative inlined). No when-not-to-use or context about prerequisites like page permissions.
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 destructiveHint=true, indicating a destructive operation. The description adds 'permanently' to emphasize irreversibility, but does not disclose other potential side effects (e.g., associated ads or campaigns). This adds some value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences and a parameter list. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one required parameter, the description is fairly complete. It explains the action and the input. However, it could mention any constraints (e.g., cannot delete if ad set is active) or return value 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?
The schema provides only the type 'string' for adset_id with 0% description coverage. The description explicitly documents the parameter as 'Ad set ID to delete', adding necessary meaning that the schema alone does not provide.
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 deletes an ad set permanently. It distinguishes from sibling tools like meta_delete_ad and meta_delete_campaign by specifically targeting ad sets.
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 pausing or updating an ad set. The description does not mention prerequisites or scenarios where deletion is 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 indicate destructiveHint=true. The description adds 'permanently' and 'cannot be undone', which are explicit behavioral traits beyond the annotation. 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 extremely concise: two sentences and one argument. It is front-loaded and contains no extraneous 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 single-parameter delete tool with no output schema, the description covers the core behavior and permanence. It could mention error conditions or success indicators, but the complexity is low enough that this 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 input schema already covers the parameter with a description. The description repeats 'Custom audience ID to delete', adding no new meaning. Schema coverage is 100%, 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 description clearly states the action ('Deletes') and the resource ('custom audience'), and emphasizes permanence. It is specific and distinct from other delete 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 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 (e.g., other delete tools or disabling an audience). No prerequisites or conditions 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 indicate readOnlyHint=true, so the description adds value by disclosing the 30-search-per-7-days limitation and clarifying that it returns recent searches. This provides context beyond the annotations without any contradictions.
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 sentences, front-loading the main purpose and briefly covering parameters and limitations. It is well-structured and avoids 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?
Given no output schema, the description explains what is returned (recent searches) and a key limitation, but lacks details on output format or structure (e.g., whether hashtags are strings or objects). It is adequate for a simple read tool but could be more 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 coverage is 50% (only response_format has a description). The description partially compensates by documenting ig_account_id as 'Instagram account ID', but omits details on response_format. This adds some clarity but not enough to fully cover 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 it retrieves hashtags recently searched by the Instagram account, using a specific verb ('Gets') and resource ('recently searched hashtags'). It distinguishes from siblings like meta_search_instagram_hashtag, which searches for hashtag content rather than retrieving search history.
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 mentions a limitation of 30 unique hashtag searches per 7 days, providing some guidance on usage constraints. However, it does not explicitly state when to use this tool versus alternatives like meta_search_instagram_hashtag, nor does it mention any prerequisites or precautions.
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 and destructiveHint=false. The description adds the behavioral trait of requiring 'pages_messaging permission', which is beyond annotations. However, it lacks details on pagination behavior, rate limits, or response structure, which would enhance transparency.
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, using two sentences and a brief Args list. It is front-loaded with the purpose, and every sentence adds value. No unnecessary information is present.
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 lacks an output schema, so the description should explain return values or response format. It does not mention the response_format parameter (defined in schema) or describe the structure of the returned conversation list. This omission leaves the agent underinformed for a list 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 description coverage is low (25%), with only response_format having a schema description. The tool description provides basic context for page_id, limit (default 20), and after (pagination cursor), but largely repeats schema info. It does not fully compensate for the missing schema descriptions of other 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 lists conversations in a Facebook Page inbox. The verb 'lists' and resource 'conversations' are specific, and the scope 'Facebook Page inbox' distinguishes it from similar tools like meta_get_conversation_messages or meta_get_instagram_conversations.
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 mentions the required permission 'pages_messaging', providing a prerequisite. However, it does not explicitly state when to use this tool versus alternatives or provide any 'when not to use' guidance. The usage context is implied but not detailed.
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=true and idempotentHint=true. The description adds that it returns specific fields but does not disclose authorization needs or side effects beyond what annotations 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 with two sentences and an args line, no unnecessary words, and front-loads the main 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?
The tool has no output schema, but the description lists the return fields (catalog name, etc.), providing good context. However, it omits the effect of the optional response_format parameter.
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 mentions catalog_id and the return fields but adds no additional 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 'Gets details for a single product catalog', specifying the verb and resource. It distinguishes from sibling tool meta_list_product_catalogs which lists all catalogs.
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 a single catalog by requiring catalog_id, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives are not 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=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds that the tool returns estimated daily reach and audience size, which is helpful but does not disclose additional behavioral traits 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, front-loaded with the purpose, and efficiently lists arguments and returns. It is well-structured without 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?
Given the presence of a nested object (targeting_spec), optional parameters, and no output schema, the description provides the essential information to use the tool. However, it does not explain the 'response_format' parameter's purpose or behavior, which is a 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 description adds meaning to the parameters: 'ad_account_id' as 'Ad account ID', 'targeting_spec' as 'Targeting specification (same format as ad set targeting)', and 'optimization_goal' with examples. The 'response_format' parameter is not mentioned, but schema description covers it partially. Overall, the description adds 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 title and description clearly state the tool estimates potential reach for a targeting specification, using a specific verb ('Estimates') and resource ('reach'). It is distinct from sibling tools like meta_get_delivery_estimate.
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 states the tool estimates potential reach for a targeting specification but provides no explicit guidance on when to use this tool versus alternatives like meta_get_delivery_estimate. Usage context is implied but not detailed.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=false, indicating a safe read operation. The description adds parameter details but does not disclose any additional behavioral traits like pagination or rate limits. With annotations covering safety, the description provides minimal extra 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 two short sentences. It is front-loaded with the purpose and includes the parameter list in a clear format. No unnecessary 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?
For a simple list tool, the description covers the basic purpose and parameter. Annotations provide safety context. It could mention that it returns a list, but that is implied. With no output schema, the description is fairly complete for its 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?
The description adds a description for ad_account_id that was missing in the schema (only response_format had a description). Schema coverage is 50%, and the description compensates by explaining ad_account_id as 'Ad account ID'. This improves clarity for the 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 'lists' and the resource 'automated rules for an ad account'. It distinguishes from sibling tools like meta_get_ad_rule (single rule) and meta_create_ad_rule (create) by specifying 'list'.
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. For instance, it does not mention that meta_get_ad_rule retrieves a single rule, nor does it provide any context on prerequisites or limitations.
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 mutating but non-destructive operation. The description adds the crucial behavior of requiring the container status to be FINISHED. However, it does not disclose potential errors (e.g., if container already published) or success/failure responses, leaving gaps despite annotations providing some baseline.
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 (4 lines) and well-structured: a main sentence, a usage note, and an Args list. It is front-loaded with purpose. The sentence 'Useful for reels/videos...' adds context but could be omitted for even greater conciseness; still effective.
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 no output schema, the description lacks return value information. It mentions checking container status but not how to obtain it. Error handling and permissions are absent. With 3 parameters and low schema coverage, the description is adequate but not fully complete for a publish action.
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 33%, with only response_format described. The description adds brief context for ig_account_id and container_id, notably that container_id comes 'from a previous create step'. This adds moderate value but does not fully compensate for the low coverage, especially since ig_account_id is merely restated.
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 ('Publishes') and the resource ('pre-created Instagram media container'), and specifies the prerequisite of checking container status is FINISHED. It distinguishes from sibling tools like meta_create_photo_post or meta_publish_instagram_photo by focusing on container-based publishing for reels/videos.
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 users to 'Use after checking container status is FINISHED', providing clear context. It mentions reels/videos as use cases but does not list alternatives or when not to use, which keeps it slightly from a perfect score.
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 idempotent and non-destructive behavior. The description adds the permission requirement, but lacks details on side effects, result format, or whether updates are incremental.
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 purpose, followed by a clear bullet list of arguments. Every sentence is necessary, and it includes an example for the nested hours 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?
Covers parameters and permissions well, but lacks information on return value (no output schema) and behavior for partial updates. For a tool with 10 params and nested objects, more context on outcome would improve completeness.
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 40% schema coverage, the description compensates by documenting all 10 parameters with types, constraints (e.g., max 255 chars for about), and an example for hours, providing 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 it 'Updates a Facebook Page's profile information,' using a specific verb and resource. It distinguishes from sibling tools that update specific elements like cover or picture.
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 other update tools (e.g., meta_update_page_cover, meta_update_page_picture). The description does not mention alternatives 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 provide idempotentHint=true and destructiveHint=false. The description adds that the tool updates message text, consistent with annotations. No contradiction, but no extra behavioral context like rate limits or 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 extremely concise, front-loaded with action, and uses a clear 'Args:' list format. Every word serves a purpose with no 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 update tool with annotations, the description is adequate. It explains the core function and parameters but doesn't cover return values or permission requirements. Given low complexity, it's mostly 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 25% (only response_format described). The description repeats parameter names and types, adding minimal context like '(for token)' for page_id. It partially compensates for low coverage but does not fully explain 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 clearly states the tool updates an existing Facebook Page post's message text. It uses a specific verb 'Updates' and identifies the resource as a 'Facebook Page post'. It distinguishes from sibling tools like meta_create_post or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks 'when-to-use' or 'when-not-to-use' instructions. However, the simple update purpose is clear.
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 read-only and non-destructive. Description adds return content (user IDs, usernames, profile pictures) but does not disclose pagination behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: single purpose sentence, then compact arg list, then return summary. 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?
Covers purpose, parameters, and return values. However, lacks explanation of pagination cursor semantics and authentication 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?
Schema descriptions cover only 25% of parameters. The description provides meaningful explanations for all parameters, especially 'after' which lacks schema 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?
Clearly states it lists accounts the authenticated user is following, which distinguishes it from siblings like 'threads_get_followers' that lists 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?
No explicit guidance on when to use this tool vs alternative tools like 'threads_get_followers' or 'threads_get_profile'.
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 read-only and non-destructive behavior. The description adds no extra behavioral context beyond 'Lists...', missing details like rate limits, ordering, or data freshness.
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 paragraph with clear argument list. Every sentence adds 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?
All parameters are explained. Lacks details on return format, pagination behavior, or ordering, but overall adequate for a list tool without 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?
Schema description coverage is low (33%). The description adds meaningful context for each param: provenance for threads_user_id, range/default for limit, date format for since/until, and purpose for after (pagination cursor).
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 the authenticated user's Threads posts', using a specific verb and resource. It distinguishes from sibling tools like threads_get_post (single post) and threads_get_replies (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 description provides parameter details but no explicit when-to-use vs alternatives. It implies usage for listing all posts but lacks guidance on when to filter or paginate.
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 no behavioral hints, so the description carries full burden. It discloses that video processing may take time and that the tool polls for up to 60 seconds, which is valuable. However, it does not describe the return value or state after polling.
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 only four lines to convey purpose, arguments, and a behavioral note. Every sentence is necessary and front-loaded with the most important 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 tool has 6 parameters, no output schema, and moderate complexity. The description covers core functionality and the polling timeout, but lacks details on return values, how to handle polling results, and leaves three parameters undocumented. 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?
The description only covers 3 of 6 parameters (threads_user_id, video_url, text), omitting reply_control, location_id, and response_format. It adds no additional meaning beyond the schema, which already describes those omitted parameters. Schema coverage is 67%, so baseline is 3, but omission reduces 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 clearly states 'Publishes a video post to Threads,' specifying the verb (Publishes), resource (video post), and platform (Threads). This distinguishes it from sibling tools like threads_publish_image or threads_publish_text.
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 lists required arguments and includes a note about video processing time, but does not explicitly guide when to use this tool versus alternatives or mention prerequisites. The note about polling is helpful but not a full usage guideline.
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, destructiveHint, and idempotentHint as true, indicating safe, read-only behavior. The description adds context about processing delays for reels/videos but does not discuss rate limits or other behaviors. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose. It includes an Args section for clarity but could be slightly more concise. Overall, it is well-structured 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 status check tool, the description covers the main purpose and return values (status_code with enum list). It lacks explicit mention of idempotency (though annotations cover it) and does not explain output format options. Still, it is mostly 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 coverage is 50%, with only response_format having a description. The description explains container_id as coming from a publish step, which adds value. However, it does not describe response_format or its enum values, leaving some ambiguity.
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 checks the publishing status of an Instagram media container, specifically for reels/videos that need processing. The verb 'Checks' and resource 'publishing status' are precise, and it distinguishes from sibling publish/get 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 implies usage after a publish step by specifying container_id from a publish step. It does not explicitly state when not to use or list alternatives, but the context is clear enough given sibling tools like meta_check_instagram_publishing_limit.
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 and destructiveHint=false, so the bar is lower. The description does not add behavioral context beyond the basic purpose, such as whether rules can be paused or what happens on trigger. It is adequate but not enhanced.
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 an args list and inline examples, but it could be slightly more concise. However, every sentence adds value, and the examples are 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?
The description covers all parameters with examples, but it lacks information about the return value or output format, which is not covered by an output schema. Given the tool's complexity (nested objects, 6 params), this gap reduces completeness.
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?
Despite low schema coverage (17%), the description provides detailed explanations and JSON examples for each parameter, including nested objects like evaluation_spec and execution_spec. This adds significant meaning beyond 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 clearly states 'Creates an automated rule for managing ads, ad sets, or campaigns,' which is a specific verb+resource. It distinguishes this tool from sibling tools like meta_create_ad or meta_create_campaign by targeting 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 description explains what the rule does but does not explicitly state when to use this tool versus alternatives like meta_create_ad or meta_update_ad. No when-not or alternative tool mentions are provided.
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. The description adds value by explicitly stating 'Permanent action,' reinforcing the irreversible nature. However, it does not disclose additional behavioral details like authentication requirements beyond the page_id 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?
Extremely concise: two sentences and an args list. The key information is front-loaded ('Deletes a comment... Permanent action'). 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?
For a simple delete operation, the description covers the purpose, permanence, and required parameters. It lacks an explanation of response behavior (no output schema) and permissions, but given annotations and schema, it is mostly adequate.
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 input schema has 2 parameters with 50% description coverage (only page_id described). The main description lists the args but provides no explanation for comment_id (e.g., format, how to obtain). It adds minimal 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 verb ('Deletes') and resource ('comment on a Facebook Page post'), and distinguishes it from sibling tools like hide or delete post. The addition of 'Permanent action' adds crucial context.
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 permanent deletion but provides no explicit guidance on when to use it over alternatives like meta_hide_comment. No prerequisites or conditions are mentioned, leaving the agent to infer from the 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 and destructiveHint=false. The description adds behavioral context through parameter usage instructions, but does not disclose side effects, rate limits, or data freshness beyond the annotations. The added value is minimal, resulting in a score of 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 concise and well-structured, with a clear heading followed by a bulleted parameter list. It is front-loaded with the main purpose and contains no extraneous information. Every sentence serves a purpose.
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?
Without an output schema, the description should clarify return format or data structure. It mentions response_format in the schema (markdown/json) but not in the description. It also lacks details on pagination, result limits, or error handling, leaving gaps for a complex 8-parameter 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 low (38%). The description compensates by explaining the purpose of each parameter (e.g., 'Ad account ID (use for all ad sets)', 'Custom date range YYYY-MM-DD') and clarifying that breakdowns include dimensions like age, gender, country. This adds significant meaning beyond the schema's property names and enums.
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 insights for ad sets' with a specific verb and resource. It distinguishes from sibling tools like meta_get_ad_insights and meta_get_campaign_insights by focusing on ad sets. The parameter guidance further clarifies the tool's scope.
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 advises to provide ad_account_id or campaign_id or adset_id, offering basic usage guidance. However, it fails to explicitly differentiate when to use this tool over other insight tools like meta_get_ad_insights or meta_get_account_insights, lacking exclusion criteria or alternative recommendations.
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, destructiveHint=false, and idempotentHint=true, covering safety. The description adds minimal behavioral context beyond stating it gets 'event volume stats'. No mention of permissions, rate limits, or behavior when data is missing, but annotations reduce 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear purpose statement and a bullet list of arguments. No unnecessary words or repetition. Front-loaded with the tool's critical use case.
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 6 parameters and no output schema, the description fails to explain the return format or content of the stats. It does not mention pagination, date range limits, or any edge cases. Annotations provide safety context, but for a data-returning tool, more output details are 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?
Schema coverage is low (17%), but the description adds meaningful explanations for 5 of 6 parameters (e.g., ISO date formats, default aggregation). It omits the response_format parameter, but that parameter's schema already has a description. Overall, the description compensates well 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 verb 'gets' and the resource 'event volume stats for a pixel', with additional context about being critical for verifying pixel firing. It distinguishes itself from sibling tools like meta_get_pixel and meta_get_pixel_events by focusing on stats, not general info or raw events.
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 verifying pixel firing but does not explicitly state when to use this tool over alternatives like meta_get_pixel_events or meta_get_pixel. No exclusions or comparative guidance is provided, which is a gap given the number of similar 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 declare readOnlyHint=true and destructiveHint=false, so the tool's non-destructive read nature is clear. The description adds value by specifying that it retrieves the full conversation tree (all nested replies), which goes beyond annotations. 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?
The description is extremely concise: two short sentences that precisely convey the tool's purpose and parameters. Every word earns its place. No fluff 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?
Given the tool has 3 parameters and returns a conversation tree, the description provides the core idea but lacks details about the return format or structure (e.g., what fields are in each reply). There is no output schema, so the description could hint at the response shape. However, it covers essential usage, so 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 input schema covers 3 parameters, but only 'response_format' has a description. The description adds brief explanations for media_id ('Root thread media ID') and reverse ('Reverse chronological order'), which are helpful. However, it omits any explanation of the 'response_format' parameter, which is partially covered in the schema. With only 33% schema coverage, the description compensates somewhat 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 'Gets the full conversation tree (all replies at all levels) for a Threads post.' This specifies the verb (Gets), resource (full conversation tree), and scope (all replies at all levels). It distinguishes from sibling tools like threads_get_post (single post) or threads_get_replies (likely just direct 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 description implies usage: when you need the complete threaded conversation for a post. However, it does not explicitly state when NOT to use it or mention alternatives. For example, if a user only needs the root post, they should use threads_get_post. The description lacks such 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?
Describes the three-step flow (create item containers, create carousel container, publish), which adds valuable context beyond the schema and annotations. However, it does not disclose side effects, authentication, or potential errors. Annotations are all false, so description carries the full 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?
Extremely concise (90 words) with a clear structure: purpose sentence, flow step list, parameter listing. No redundant information, all sentences earn their 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?
Covers the main procedure and key parameters, but lacks information on return values (no output schema), error handling, or prerequisites (e.g., URL accessibility). For a multi-step mutation tool, this is a 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 description lists 'threads_user_id', 'items' (with url and type details), and 'text' (optional), covering 3 of 5 parameters. Schema coverage is 40% (2 params described), so description compensates somewhat but misses 'reply_control' and 'response_format'. Adds meaning for 'items' but not for others.
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 publishes a carousel post (2–20 images/videos) to Threads, which differentiates it from sibling tools like threads_publish_image and threads_publish_video. The verb 'Publishes' and resource 'carousel post' are specific.
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?
Implicitly tells when to use (for carousel with 2-20 items), but does not explicitly contrast with alternatives like publishing a single image/video. No when-not or prerequisite conditions 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 indicate readOnlyHint=false and destructiveHint=false, aligning with the creation action. The description adds that it returns the created product ID, providing useful behavioral 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose but then becomes verbose by listing all parameters in a bullet list, which largely duplicates the input schema. It could be more 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?
Given the 12 parameters, 8 required, and no output schema, the description covers all inputs and states the return value (product ID). It is functionally complete but lacks context on prerequisites or error handling.
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 baseline is 3. The description repeats parameter details already in the schema without adding new meaning or clarifying relationships between 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 'Adds a product to a catalog.' This is a specific verb+resource combination that distinguishes it from sibling tools like meta_create_ad or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to add a product to a catalog, which is clear. However, it does not explicitly state when not to use it or mention alternatives like meta_update_product for updates.
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?
Description adds behavioral context beyond annotations: it states the feed will 'automatically sync products from a URL', revealing the ongoing behavior. The return of the new feed ID is disclosed. Annotations already indicate it's not read-only (correct) and not destructive; description aligns and adds 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?
Extremely concise: 4 lines, no fluff. Action, parameters listed, return value stated. Every sentence adds value.
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 creation tool with no output schema, description adequately covers purpose, parameters, and return value. Missing some guidance on prerequisites (e.g., catalog existence), but overall 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?
Schema description coverage is 100%, so baseline 3 applies. The description repeats schema info for all 4 required parameters, adding only minor clarifications (e.g., 'CSV, TSV, XML' for schedule_url). It does not mention the optional response_format parameter, but schema fully covers 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?
Description clearly states the tool creates a new product feed for a catalog, with specific verb 'Creates' and resource 'product feed'. It distinguishes from siblings like meta_create_product (creates a product) and meta_list_product_feeds (lists feeds) by specifying the action and scope.
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: use when you want to create a product feed. No explicit when-to-use or when-not-to-use guidance, nor mention of alternatives. Siblings exist (e.g., meta_create_product) but no comparative context is provided.
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 read-only and non-destructive behavior. The description adds significant value by enumerating the exact metrics returned (performance, cost, engagement, conversions, video, quality), which goes beyond the schema and annotations. It does not disclose any side effects or permission requirements, but the read-only annotation covers the main behavioral trait.
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: a one-line purpose, a clear parameter list with explanations, and a bulleted list of return metric categories. While it is relatively long, the structure and front-loading of purpose make it easy to parse. Every section serves a purpose.
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?
Given the tool's complexity (6 parameters, no output schema, many sibling tools), the description thoroughly covers all parameters and provides an exhaustive list of return metrics by category. It compensates for the lack of output schema by detailing response content. The description is complete for an agent to understand inputs, outputs, and scope.
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 input schema for ad_account_id (provides example format) and breakdowns (lists available options). For date_preset, schema already provides full enum. With schema coverage at 83%, the description compensates for the missing schema description on ad_account_id and enriches understanding of breakdowns.
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 explicitly states it 'Gets performance insights for a Meta ad account,' which is a clear and specific verb–resource pair. The tool name itself differentiates it from similar tools like meta_get_ad_insights and meta_get_campaign_insights, and the description reinforces this by detailing the 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 provides no guidance on when to use this tool versus alternatives like meta_get_ad_insights or meta_get_campaign_insights. It does not mention prerequisites, context, or exclusions. The usage is implied but not explicitly 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, so the description adds limited behavioral context beyond confirming it's a read operation. It describes the filtering behavior (mutually exclusive identifiers) but does not disclose permissions, rate limits, or pagination. The overall transparency is adequate given the annotations, but no extra value is added.
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, using a short paragraph followed by a bullet-like list of parameters. It front-loads the purpose and uses clear shorthand for optional vs. mutually exclusive parameters. It could be slightly more structured (e.g., grouping required vs. optional), but it is efficient with no wasted words.
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 does not specify the output format or what data is returned, and there is no output schema. For a data retrieval tool with optional breakdowns, this is a notable gap. The annotations (readOnlyHint) and parameter explanations provide partial context, but agents need to infer the return structure. It is minimally adequate but could be more 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 adds meaning to several parameters beyond the schema: ad_account_id, campaign_id, adset_id, ad_id, date_preset, since/until, and breakdowns. It explains their scope (e.g., 'All ads in account'). However, it omits the 'response_format' parameter, which is present in the schema. Since schema description coverage is only 33%, the description compensates well for most key 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 performance insights at the individual ad level.' It specifies the resource (ad insights) and scope (individual ad), and implies differentiation from sibling tools for other levels (account, campaign, adset). The explanation of mutually exclusive identifier parameters further clarifies its specific functionality.
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 guidance on parameter selection: 'Provide one of: ad_id, adset_id, campaign_id, or ad_account_id.' It also explains the context for each optional parameter (e.g., 'All ads in account'). However, it does not explicitly contrast this tool with similar sibling tools like meta_get_adset_insights or meta_get_campaign_insights, leaving some ambiguity when multiple levels could apply.
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 read-only, idempotent, non-destructive behavior. The description adds that the tool returns detailed results including winner, confidence, and per-cell metrics, which informs the agent about the data shape. No contradictions with annotations. The response_format parameter is explained, adding 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 concise and well-structured: a single sentence stating purpose, followed by clear Args and Returns sections. Every element earns its place, and the main purpose is front-loaded. No unnecessary 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 read tool with two parameters and no output schema, the description is fairly complete. It explains the return content (winner, confidence, per-cell metrics) and the optional response_format. However, it could mention that the study must exist and be completed, but this is implied by 'detailed results' and the 'get' verb. Overall adequate.
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% (both parameters described), so baseline is 3. The description's Args section reiterates schema info without new details, but the Returns section adds meaning by explaining what the study_id parameter will retrieve (winner, confidence, per-cell metrics). This helps the agent understand the tool's output 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 detailed results of a specific A/B test (ad study). It specifies the resource (results) and distinguishes from siblings like meta_get_ad_studies (list studies) and meta_get_ad_insights (general insights). The verb 'Gets' is appropriate, and the description includes return details (winner, confidence, per-cell metrics) for clarity.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., meta_get_ad_studies to find available studies), nor does it mention prerequisites or when not to use. This is a significant gap for an agent to select the tool 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's statement 'Gets messages' is consistent but does not add new behavioral details beyond parameter hints. No discussion of pagination, rate limits, or auth requirements beyond page_id.
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 stating purpose followed by a bullet list for parameters. No extraneous information, front-loaded with main action. Every sentence serves a 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 simple get-messages tool, the description covers the essential parameters and usage context. However, it does not mention pagination ('after') or the output format ('response_format') which are part of the schema. Overall, it is adequate but not exhaustive.
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 20% (response_format only). The description adds meaningful context for 3 of 5 parameters: page_id (for auth), conversation_id (source), limit (range and default). However, it omits 'after' (pagination) and 'response_format'. Despite these omissions, the provided param descriptions significantly enhance 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 clearly states the verb 'gets', resource 'messages', and scope 'from a specific Page conversation'. It distinguishes from sibling tools like meta_get_page_conversations which get conversations, not messages.
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 by noting that conversation_id comes from meta_get_page_conversations, but does not explicitly state when to use this tool versus alternatives like meta_get_broadcast_channel_messages or meta_send_page_message. No exclusions or when-not guidance is provided.
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 and idempotentHint. The description adds the specific permission requirement and return details (Catalog IDs and names), which is valuable 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?
Very concise three sentences. Purpose, args, returns, and requires are clearly separated and front-loaded. No superfluous 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 covers purpose, required permission, and return format. No output schema exists, so the return mention is helpful. It is sufficient for a simple list operation, though pagination or limits are not mentioned.
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 clear parameter descriptions. The description does not add much beyond the schema for parameters, but does mention return values, which indirectly aids 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 clearly states the action ('Lists'), the resource ('product catalogs available for Instagram Shopping'), and the required entity ('professional account'). It differentiates from sibling tools like meta_get_product_catalog by specifying 'available for Instagram Shopping'.
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 mentions the required permission ('instagram_shopping_tag_products') but does not provide explicit guidance on when to use this tool versus alternatives like meta_get_product_catalog or meta_search_instagram_catalog_products.
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 read-only, non-destructive, idempotent behavior. The description adds useful context: stories expire after 24 hours, and returns a list of active story media objects. 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 short, front-loaded with the main action, and uses bullet points for args/returns. Every sentence adds value with no 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 explains the return type (list of active story media objects) and mentions expiration. Given the tool's simple read-only nature and lack of output schema, it 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 coverage is 100% and already describes both parameters well. The description repeats the ig_account_id definition but does not mention response_format, adding little extra 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 'currently active stories' for an Instagram professional account, using a specific verb ('gets') and resource. It distinguishes itself from siblings like meta_get_instagram_media or meta_get_instagram_live_media by focusing on stories.
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 retrieving active stories but does not explicitly state when to use it versus alternatives like meta_get_instagram_media or meta_get_instagram_live_media. There is no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 correctly aligns by stating 'Gets'. It adds that the return is a URL, but doesn't disclose potential issues like rate limits or required permissions. This is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three brief sentences including the argument list. Every word adds value, no fluff, and the information 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?
The description states it returns a URL, which is the primary output. There is no output schema, so this is sufficient. It covers the core functionality, though additional details about the URL structure or error handling could be provided.
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 response_format has a description). The description adds descriptions for page_id and size, including the enum values and default for size, improving semantics. However, it omits description for response_format, which is covered 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 the profile picture URL for a Facebook Page, using specific verb and resource. Among siblings like meta_get_page and meta_update_page_picture, it uniquely focuses on the profile picture 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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the tool's function is straightforward (get a picture), so usage is implied. 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.
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 value by listing returned fields (price, availability, etc.). 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?
The description is brief, front-loaded, and uses clear structure with purpose, Args, and Returns. Every sentence is informative without waste.
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 simple tool, rich schema, and annotations, the description provides enough context: purpose and return fields. Missing potential details like error handling or prerequisites, but adequate for the complexity.
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 baseline is 3. The description repeats product_id but adds no extra meaning; response_format is omitted entirely. No additional parameter context 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 clearly states it gets details for a single product, using a specific verb and resource. It distinguishes itself from siblings like meta_list_products by specifying 'single product'.
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 when/when-not or alternatives are mentioned. Usage is implied from the purpose, but the description lacks guidance on when to choose this over other get 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=false, destructiveHint=false, idempotentHint=true. The description adds 'acting as the Page' and parameter details, but does not clarify behavior on repeated calls (e.g., liking an already-liked post) or rate limits. Some additional context is provided but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear purpose sentence followed by bullet-style parameter definitions. No unnecessary 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?
For a simple toggle action with no output schema, the description covers inputs and behavior adequately. It mentions acting as Page, which is important context. Could be improved by noting the return value or error cases, but overall 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% (only object_id described). The description compensates by providing clear explanations for all three parameters (object_id, page_id, unlike), adding significant 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 clearly states the action (like/unlike) and the resource (page post or comment), distinguishing it from sibling tools like create_post or delete_comment. The title also reinforces this.
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 (to like/unlike a post/comment as a Page) but does not explicitly provide when-not-to-use or alternatives. No exclusionary guidance 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, destructiveHint=false, idempotentHint=true. Description adds return field details and user accessibility scope, which is useful but not extensive. No behavioral 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?
Three concise sentences: purpose, output details, usage guidance. Front-loaded with no superfluous 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 simple list tool with one optional parameter, the description provides sufficient context including return fields and usage as a prerequisite. Could mention pagination or limits, but not critical given sibling tools exist.
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 one parameter (response_format) fully described via enum and default. Description does not add extra meaning, but baseline of 3 is appropriate as schema carries the details.
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 all Meta ad accounts accessible to the user, with specific fields returned (IDs, names, currency, status, spend info). It distinguishes from siblings like meta_get_ad_account (single account) and meta_list_business_assets.
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 says 'Call this first to get ad account IDs needed for campaign and insights tools,' providing clear context for when to use it. Does not mention when not to use, but the sibling set covers many get/list 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 indicate readOnlyHint=true and destructiveHint=false, so the tool is safe for reads. The description adds that it returns audience details and is paginated, but doesn't disclose rate limits or authorization needs beyond what annotations 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 very concise: two sentences plus a bulleted arg list. No redundant information, front-loaded with the core 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?
Given no output schema, the description usefully lists return fields (names, types, size estimates, delivery status). It covers pagination and required parameter. The only gap is omission of the response_format parameter.
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 ad_account_id, limit (with range and default), and after (as pagination cursor). This adds meaning beyond the schema for these parameters. However, it misses the response_format parameter, which is present 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 uses a clear verb 'Lists' with a specific resource 'custom audiences'. It distinguishes from sibling list tools (e.g., meta_list_ad_accounts, meta_list_campaigns) by targeting custom audiences 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?
No explicit guidance on when to use this tool versus alternatives. The context implies it's for listing custom audiences, but no exclusions or comparisons to other list tools are provided.
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 readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value by specifying the return fields (catalog IDs, names, product counts, and verticals), which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (4 lines), front-loaded with the purpose, and every sentence serves a clear function. 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?
With no output schema, the description compensates by listing return fields. It covers key information for a simple list tool, though pagination details could be added.
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 schema already explains parameters. The description repeats parameter info briefly but does not add significant new meaning; 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 verb 'Lists' and the resource 'product catalogs' with scope 'for a Meta business'. It distinguishes itself from sibling list tools (e.g., meta_list_ad_accounts) by specifically targeting product catalogs.
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 versus alternatives, nor does it provide when-not-to-use guidance. However, the tool name and context imply its purpose, so it is minimally adequate.
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 consistently indicates a write operation (replies) and adds that it returns the comment ID of the reply. Annotations already signal it's not read-only, so the description reinforces and adds value. 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 extremely concise with a clear structured Args format. Every sentence is purposeful; 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?
For a tool with 4 parameters and no output schema, the description covers the main purpose, required parameters, and return value. It lacks explanation of the optional response_format parameter, but the schema covers it. Could include error handling or permission info, but acceptable.
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 context for media_id (not the comment ID) and comment_id (if replying to a specific comment). However, it omits the response_format parameter entirely. Since schema coverage is 100%, the baseline is 3, and the description adds some value but is incomplete.
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. It distinguishes from siblings like meta_reply_post_comment (for Facebook) and other Instagram comment tools by specifying 'Instagram' and mentioning media_id and comment_id.
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 for replying to Instagram comments but does not explicitly state when to use this tool versus alternatives like meta_hide_instagram_comment or meta_delete_instagram_comment. No exclusion criteria or prerequisites 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns interest IDs and names, which is useful 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 concise with a single sentence for purpose, followed by structured args and returns. No unnecessary words, front-loaded with the core action.
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 search tool with simple parameters and good annotations, the description adequately explains what it does and what it returns. It does not mention pagination or result limits, but overall it is complete enough 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 67% (2 of 3 params described in schema). The description adds examples for 'q' and restates default for 'limit', but does not address 'response_format'. This provides marginal value over 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 it searches for interest-based targeting options for ad sets, with a specific verb ('searches') and resource. This distinguishes it from sibling tools like meta_search_targeting_demographics or meta_browse_targeting_categories.
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 interest targeting but provides no explicit guidance on when to use this tool versus alternatives like demographic or geographic searches. The sibling tools are numerous, but no comparison or exclusion is 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 are all false, so the description must carry behavioral disclosure. It states 'Sends' (write operation) and returns a Message ID, but lacks details on authentication, error handling, or rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a short paragraph and clear bullet-style parameter list. Every sentence provides necessary information without 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?
The description includes return value and constraints, but lacks information on prerequisites, error scenarios, or rate limits. The major gap is the mismatch between described parameters and empty schema, which could confuse agents.
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?
Although the input schema is empty, the description fully defines all four parameters with types, roles, and mutual exclusivity. This adds significant meaning beyond the schema, compensating for its lack of structure.
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 sends an image or link via Instagram DM, distinguishing it from text DM tools like meta_send_instagram_message. However, the schema mismatch (empty properties vs. described parameters) slightly clouds 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?
Specifies that either image_url or link_url should be provided (not both) and mentions the same messaging window restrictions as text DMs. Provides clear usage context but does not explicitly contrast with 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 provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false; the description adds that the message is shown when the page is away mode and mentions a prerequisite, but does not disclose additional behavioral traits beyond these.
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 two sentences and a bullet list, front-loading the purpose and avoiding any unnecessary 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 annotations and schema, the description adequately covers purpose, prerequisite, and basic parameter semantics; however, it could clarify the relationship between the 'enabled' parameter and away mode activation.
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 parameters are well-documented in the schema; the description lists three parameters but omits 'response_format', which slightly reduces added 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 the verb 'Sets' and the resource 'away message for a Facebook Page', distinguishing it from sibling tools like meta_set_greeting and meta_set_instant_reply.
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 a prerequisite ('Requires: meta_list_pages called first to load page tokens'), providing clear context for when to use the tool, but does not explicitly state when not to use it or mention 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 set idempotentHint=true, which matches the tool's nature. The description adds the prerequisite but does not disclose additional behavioral traits beyond what annotations already provide. For a non-destructive, read-only-like operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It uses a clear bullet list for arguments and front-loads the purpose. Every sentence serves a 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 simple set operation, the description provides the prerequisite and parameter details. However, it does not explain the response_format parameter or what the output looks like, which could be useful given no output schema. It is mostly complete but missing response 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 description coverage is 100%, so the schema already documents all parameters. The description lists args with brief explanations, but these largely mirror the schema descriptions. No additional semantic value 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 clearly states the verb 'Sets' and the resource 'instant reply message for a Facebook Page'. It distinguishes from sibling tools like meta_set_away_message and meta_set_greeting by specifying the exact function.
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 provides clear usage context. However, it does not mention alternatives or 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 already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the return includes 'current usage and limit quota (250 posts per 24 hours),' which informs the agent of the exact limit and output scope.
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, one for purpose and one for parameters/returns. It is front-loaded with the core action and includes structured Args and Returns sections, with no wasted words.
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 tool with no output schema, the description covers the required parameter and return value but omits the optional 'response_format' parameter. This gap makes it partially incomplete, though the core functionality is adequately described.
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 50% (only 1 of 2 parameters described in the description). The description merely restates the schema for 'threads_user_id' without additional semantics, and completely omits 'response_format.' With low coverage, the description fails to compensate.
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 'Checks the current publishing rate limit usage for Threads.' The verb 'checks' and the specific resource 'publishing rate limit usage' uniquely identify the tool's function. Among sibling tools, none other checks Threads rate limits, so it is well-distinguished.
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 the tool is used to monitor rate limit usage before posting, but it does not explicitly state when to use it or suggest alternatives. Given the self-explanatory nature of a rate limit check and no competing sibling tool, the guidance is 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 indicate read-only and non-destructive. The description adds value by noting that follower_demographics requires 100+ followers and that 'since' is required for time-series metrics. However, it does not disclose rate limits, data freshness, or authentication scope beyond the implied 'authenticated' user.
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 with a one-line summary followed by a clear parameter list. Every sentence adds necessary detail without repetition. No unnecessary fluff.
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 has no output schema, the description does not explain the return value structure (e.g., format of metrics data). It also omits pagination or data limits. While parameters are well-covered, the missing output specification reduces completeness for an insights tool.
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 significantly augments the input schema, which has only 33% coverage. It enumerates allowed metrics (time-series and demographics), explains the conditions for follower_demographics, clarifies that 'since' is required for time-series, and lists valid breakdown values. This goes well beyond the schema's minimal 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 account-level metrics for the authenticated Threads user', using a specific verb and resource. It distinguishes from sibling tools like threads_get_post_insights (post-level) and other Meta account insights 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 vs alternatives (e.g., threads_get_post_insights for post metrics, meta_get_account_insights for Facebook). It lacks explicit when/when-not criteria or usage context beyond the operational steps.
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 non-read-only and non-destructive, which align with creation. The description adds context such as default status PAUSED, placement soft opt-out behavior, and budget constraints. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with Args: and Returns sections. It is clear and organized, though slightly lengthy due to including all parameters. Important info 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 tool with 13 parameters and no output schema, the description covers key details: required params, budget requirements, default status, placement opt-out. It mentions the return value (new ad set ID). Could mention potential errors or permissions, but adequate.
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 54%, but the description provides detailed explanations with examples (e.g., daily_budget in cents, targeting spec example, billing_event enum values). This adds significant meaning beyond the schema's short 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 'Creates a new ad set within a campaign.' It uses a specific verb (creates) and resource (ad set), and distinguishes it from siblings like meta_create_ad or 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 description mentions parameter dependencies (e.g., lifetime_budget requires end_time) but does not provide explicit guidance on when to use this tool over alternatives like meta_update_adset or meta_list_adsets. No when-to-use or when-not-to-use advice.
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 read-only and non-destructive behavior. The description adds parameter-level details (e.g., post_id format, pagination via 'after'), but does not disclose additional behavioral constraints like rate limits or authentication requirements 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 as a parameter list with inline comments. It is concise and focused, though slightly verbose with formatting (e.g., parentheses, default values). No unnecessary 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?
Given the tool's complexity (7 parameters, 2 required) and lack of output schema, the description covers all necessary parameter information, authentication prerequisites, and pagination. Minor gap: response_format is in schema but not 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 coverage is low (29%), but the description compensates by explaining all parameters: post_id format, page_id purpose, limit range, order and filter enumerations, and after pagination. It adds significant 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 clearly states 'Gets comments on a Facebook Page post,' specifying the verb and resource. It is unambiguous and distinct from sibling tools like meta_get_post_reactions or meta_get_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful guidance, such as calling meta_list_pages first to get page_id, and explains parameter defaults and formats. However, it does not explicitly compare to alternative tools for Instagram comments or other comment-related endpoints.
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, which aligns with the 'Lists' verb. The description adds behavioral context beyond annotations by detailing pagination (limit, after) and status_filter options. No contradictions are present, and the description provides useful information for expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the main purpose. The argument list is structured as a bullet-like list, making it easy to parse. Every sentence adds value, though there is minor redundancy in the first sentence. Overall, it is efficient but not perfectly concise.
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 tool's operation well, including filtering and pagination. However, there is no output schema, and the description does not explain the return format (e.g., what fields each ad includes). Since the tool is read-only and returns a list, some output details would improve completeness. The description is adequate but not fully comprehensive.
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 has low description coverage (14%), with only response_format described. The description compensates fully by explaining the meaning of each parameter: adset_id (filter by ad set), campaign_id (filter by campaign), ad_account_id (list all ads in account), status_filter (with enum values), limit (max results default 20), after (pagination cursor). It also clarifies the requirement to provide one of the first three parameters, adding critical context.
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.' This is a specific verb+resource combination. It distinguishes itself from siblings like meta_get_ad (single ad) and meta_list_adsets (ad sets) by specifying the parent entities it can filter by. The description also lists filter 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the available filters (adset_id, campaign_id, ad_account_id) and requires one of them. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks (e.g., meta_get_ad for a single ad). This limits the guidance for an AI agent to choose between 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 indicate readOnlyHint=true and destructiveHint=false, so the description does not need to repeat that. The description adds some context like pagination via 'after' cursor, but does not explain behavior like rate limits or confirmation of results. It adds marginal value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with bullet-like arg listing, front-loads the purpose, and every sentence adds value. No unnecessary words.
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 lacks information about return format (despite response_format parameter in schema) and pagination details beyond the cursor. For a list tool without output schema, these are gaps. The description is adequate but incomplete.
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 by clarifying the relationship between campaign_id and ad_account_id ('Provide either'), and lists status_filter enum values. However, it misses the response_format parameter which is in the schema. With 50% schema coverage, the description compensates well but not completely.
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 ad sets, with the specific context of filtering by campaign or ad account. This distinguishes it from sibling tools like meta_list_ads or meta_get_adset.
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 explains the key usage rule: provide either campaign_id or ad_account_id. It also lists optional filters. However, it does not explicitly state when not to use this tool (e.g., for a single ad set use meta_get_adset) or mention 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?
Annotations are neutral (readOnlyHint=false, destructiveHint=false). The description adds behavioral context such as the messaging window restrictions and that the recipient must have messaged first. It also states the return value (Message ID). This adequately informs the agent of the tool's effects.
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: a single sentence stating the action, followed by a bulleted list of arguments and a note on constraints. No unnecessary 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 tool's purpose, required parameters, usage constraints, and return value. It lacks an example or mention of error handling, but for a straightforward send operation, it is sufficiently 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 coverage is 100% with parameter descriptions. The description adds minimal extra meaning (e.g., '(sender)' for ig_account_id) but omits the optional 'response_format' parameter entirely. This omission reduces the value 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 clearly states 'Sends a text DM to an Instagram user,' using a specific verb and resource. It distinguishes from sibling tools like 'meta_send_instagram_media_message' by specifying 'text DM.'
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 important usage constraints: only works within specified messaging windows (24-hour or 7-day) and requires the recipient to have messaged first. It does not explicitly mention when not to use or compare to alternatives, but the context is clear.
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 (readOnlyHint false, etc.), so the description must bear the transparency burden. It correctly implies mutation ('updates') and explains migration behavior. However, it does not disclose potential side effects, authorization needs, or what happens to unmodified fields, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two opening sentences then clear bullet points. It front-loads the main purpose and uses a structured Args list that is easy to parse. No wasted words.
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 has 7 parameters and no output schema, the description covers core parameters and migration behavior. However, it does not indicate the return value (e.g., updated campaign object), which is a completeness gap for an update tool. The missing response_format parameter is minor but noted.
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 schema coverage at 43%, the description adds significant meaning: it specifies budget units (cents), provides enum options for status, and explains migration behavior. The response_format parameter is omitted from the description, but the schema already describes it well. Overall, the description compensates 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 clearly states the tool updates an existing campaign, with a specific verb and resource. It distinguishes from siblings like meta_create_campaign and meta_delete_campaign by focusing on modification. The migration capability adds specificity.
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 indicates partial updates ('Only provided fields are changed') and special migration usage ('Can also migrate...'). It provides clear context but could explicitly state when to use this tool over create or delete. No direct exclusions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds limited behavioral context beyond the schema, such as the permission requirement and the mutual exclusivity of cover_url and photo_id. It does not describe side effects or additional behavior, but the annotations cover the safety profile adequately.
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 one-sentence purpose, a structured list of parameters with clear types and descriptions, and a final usage note. No redundant information. The essential information is front-loaded 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?
Given 6 parameters with 1 required and no output schema, the description adequately covers input semantics and usage. However, it does not describe the return value or success/failure indicators. For a mutation tool, this omission leaves the agent guessing about the response format, which could hinder correct invocation handling.
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 by clarifying the page_id parameter (which lacks a schema description) as 'Facebook Page ID' and by explicitly stating the constraint 'Provide either cover_url or photo_id'. This helps the agent understand parameter relationships. With 83% schema coverage, the description compensates for the missing page_id 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 title and description clearly state the tool updates a Facebook Page's cover photo. It distinguishes itself from the sibling meta_update_page_picture (which updates the profile picture) by specifying 'cover photo'. The description also notes the requirement to provide either cover_url or photo_id, reinforcing the specific action.
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 the required permission ('pages_manage_metadata') and the constraint that either cover_url or photo_id must be provided. However, it does not mention when not to use this tool or provide alternatives, such as using meta_update_page_picture for profile photos.
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 idempotentHint=true and readOnlyHint=false. The description adds the permission requirement and confirms the update nature. No contradictions. It does not detail side effects (e.g., previous picture overwritten) but this is inherent and acceptable for a 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 extremely concise: two sentences plus a short list of arguments. The purpose is front-loaded, and every sentence provides necessary information (action, arguments, permission). No fluff.
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 tool with no output schema, the description covers purpose and required permissions. However, it does not mention what the function returns (e.g., success confirmation or error) or any post-update behavior. This could be improved.
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 67% (2 of 3 params have descriptions). The tool description lists page_id and picture_url and adds a short description, but the schema already provides similar info for picture_url. The response_format parameter is not mentioned in the description. The added value is marginal.
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 ('Updates') and the specific resource ('Facebook Page's profile picture'), differentiating it from sibling tools like meta_get_page_picture (read) and meta_update_page_cover (cover photo). The verb+resource combination is specific.
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 prerequisite ('Requires pages_manage_metadata permission') and implicitly indicates when to use (updating profile picture). While it does not explicitly mention when not to use or alternative tools, the context is clear and no identical sibling exists.
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, destructiveHint=false. Description adds context about scope requirement and follower visibility, which goes beyond annotations. However, it could mention pagination behavior or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded, with structured arg list and note. Every sentence provides value. Loses a point for not fully integrating the undocumented 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?
Given low complexity and existing annotations, the description adequately covers scope, visibility, return fields, and pagination cursor. Could mention error cases or rate limits, but sufficient for a read-only list 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?
Description explains three of four parameters (threads_user_id, limit, after) with default and optional info, partially compensating for low schema coverage (25%). However, it omits response_format, creating a gap. Return values are described, which is helpful.
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 clearly states the verb 'lists' and resource 'followers of the authenticated Threads user', distinguishing it from sibling tools like threads_get_following (lists who the user follows). The purpose 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?
Description indicates when to use (to list followers) and provides prerequisites (threads_basic scope, visible followers). While it doesn't explicitly state when not to use or compare to alternatives, the context is clear enough for an agent.
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, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral context beyond stating that it returns metrics. It could disclose authentication needs or restrictions about the media_id being from the user's own account, but the annotations carry 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main purpose in the first sentence, followed by structured Args/Returns sections. Every word is informative, and there is no redundant or extraneous 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?
Given the tool's low complexity (3 parameters, no output schema, annotations covering safety), the description is mostly adequate. However, it fails to describe the structure of the return value ('Metric values for the post' is vague), and it does not mention the response_format parameter, which controls output style. This leaves some ambiguity for the 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 67% (2 of 3 parameters have descriptions in schema). The description adds value by listing the available metrics options (views, likes, etc.) for the 'metrics' parameter, which is not fully detailed in the schema. It also clarifies that media_id is a 'Threads media ID'. However, it omits mention of the response_format parameter, which is 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?
The description starts with 'Gets performance metrics for a specific Threads post', clearly stating the verb (Gets), the resource (performance metrics), and the scope (specific Threads post). It effectively distinguishes from sibling tools like threads_get_post (post content) and threads_get_user_insights (user metrics).
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 by stating the tool's purpose upfront. While it doesn't explicitly mention when not to use it or list alternatives, the specific verb and resource make the intended usage obvious. The sibling tools have distinct names, so confusion is unlikely.
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=true, destructiveHint=false, idempotentHint=true. Description adds return fields but no behavioral traits beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, return fields, requirement. No filler, front-loaded with key action. Every sentence serves a purpose.
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 one parameter, complete annotations, and no output schema, the description fully covers what the tool does, its prerequisites, and its output fields. No 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 single parameter 'response_format' has full schema coverage (100%) with enum and description. Description does not add meaning beyond what the schema provides; 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?
Description explicitly states 'Gets the authenticated user's Threads profile.' It clearly identifies the verb (gets), resource (Threads profile), and scope (authenticated user). Among siblings, it uniquely references profile retrieval, distinguishing from other threads_* 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?
States requirement for THREADS_ACCESS_TOKEN environment variable, providing a clear prerequisite. Implies usage when needing the authenticated user's profile data. No explicit alternatives or when-not-to-use, but context is sufficient for a straightforward 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 indicate a non-read-only, non-destructive creation. The description adds important behavioral context: it only creates the container, not populates it. No contradiction with annotations. Missing details on authorization or rate limits, but still strong.
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?
Well-organized with bullet points for types and structured args. Every sentence adds information; no fluff. Concise yet comprehensive.
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?
Mentions return value (audience ID) despite no output schema. Covers prerequisites and separate population step. Could include error handling or common pitfalls, but overall sufficient for a creation 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 coverage is 57% but the description adds meaning beyond enums (e.g., example for ad_account_id, explanations for subtype, customer_file_source requirement, retention_days range). Adds value while not repeating all schema details.
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 creates a custom audience in a Meta ad account, lists supported types (CUSTOM, ENGAGEMENT, VIDEO) with specific context, and distinguishes from sibling tools like lookalike or saved 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 provides context on when to use each subtype (e.g., CUSTOM requires Pixel, etc.) and notes that populating the audience is separate, but lacks explicit guidance on when not to use this tool versus alternatives like meta_create_lookalike_audience or meta_create_saved_audience.
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 adds that the action is 'permanent and cannot be undone', reinforcing destructive nature. It also notes authentication via page_id in the Args section. 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?
Two-sentence description plus Args list: first sentence states purpose and permanence, second introduces Args. No wasted words, front-loaded with key 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 delete tool with full annotations and schema, the description adequately covers purpose, permanence, and parameter usage. Could mention consequences like deletion of associated comments, but not essential for basic use.
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 covers both parameters with descriptions (post_id: get from meta_get_posts, page_id: for token). Description repeats these in Args without adding new meaning. With 100% schema coverage, baseline is 3; description adds minimal extra 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?
Description clearly states the tool deletes a Facebook Page post, using specific verb 'Deletes' and resource 'post from a Facebook Page'. It distinguishes itself from sibling delete tools (e.g., meta_delete_ad, meta_delete_comment) by specifying the target is a page 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?
While it warns 'this action is permanent and cannot be undone', it does not explicitly compare with alternative deletion methods or specify when not to use it. The context of deleting a page post is clear but lacks explicit when-not 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, destructiveHint=false, and idempotentHint=true, so the description adds minimal behavioral context beyond stating it generates a URL. It does not contradict annotations or provide additional disclosures like permissions or URL lifespan.
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 a clear opening sentence and a structured parameter list. Every sentence adds value, and it is appropriately sized for the tool's complexity.
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 could detail the response format (e.g., markdown link vs. JSON). However, the default response_format parameter hints at the output type. For a simple preview tool, the description is nearly complete, lacking only explicit return value 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?
The description adds meaning to ad_id and creative_id by noting optionality and mutual exclusivity. It lists some ad_format values but omits two (MARKETPLACE_MOBILE, AUDIENCE_NETWORK_OUTSTREAM_VIDEO). response_format is not mentioned, though it has a schema description. Overall, the description compensates for the 25% 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 clearly states it generates a preview URL for an ad or creative. The tool name and title are consistent, and the purpose is distinct from sibling tools that create, update, or retrieve ads without previewing.
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 specifies to provide either ad_id or creative_id, indicating mutual exclusivity. While it doesn't explicitly contrast with similar tools like meta_get_ad, the context implies it's for previewing rather than fetching ad data. More explicit when-to-use guidance would improve clarity.
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 mark readOnlyHint true and destructiveHint false; the description adds beyond this by disclosing constraints like account_repost_count only available from Dec 2025, demographic metrics needing 100+ followers, and online_followers limited to last 30 days. No contradictions found.
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 an Args list and notes, front-loading the purpose. It is slightly verbose due to repeating metric options present in the schema, but overall clear and organized.
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?
Given the complexity of 8 parameters, no output schema, and minimal annotations, the description fully covers all parameters, constraints, and behavioral notes. It explains metric categories, period options, and limitations (e.g., demographics need followers). It is comprehensive 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (some params have descriptions); the description compensates by listing all parameters with their options, including metric groups and notes. This adds significant meaning beyond the schema, though some parameter documentation is redundant.
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 insights for an Instagram professional account,' specifying the verb 'Gets' and the resource 'Instagram professional account insights.' This distinguishes it from sibling tools like meta_get_media_insights or meta_get_account_insights for Facebook.
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?
While the description details parameters and constraints (e.g., demographics require 100+ followers, online_followers limited to last 30 days), it does not explicitly compare to alternatives like meta_get_account_insights for Facebook or meta_get_instagram_media_insights. Usage context is implied but not contrasted with 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 already indicate readOnlyHint=true. Description adds value by specifying auth requirements (permission and token type) and parameter details (folder, limit range, pagination).
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?
Description is concise, front-loaded with purpose, and uses a clear 'Args' section. Every sentence is essential; 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?
Covers purpose, auth, required params, folder options, pagination, and limit. Lacks explanation of return format (beyond response_format param), but overall complete enough given 5 params and no 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 coverage is 80%; description adds context for folder, limit, and after (pagination), but omits response_format. It complements schema without being redundant.
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 Instagram DM conversations. It distinguishes from related tools like meta_get_page_conversations and meta_get_conversation_messages, and the verb 'list' is specific.
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 required permission (instagram_manage_messages) and token type (user token, not page token). Though it doesn't explicitly say when not to use, this context guides correct invocation.
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. Description adds value by listing deprecated metrics and new Reels metrics with dates, providing 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?
Description is lengthy but well-structured with clear sections and bullet points. Front-loads core purpose. Could be slightly trimmed, but complexity justifies 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?
Covers all parameters and usage context. Lacks explicit description of return data structure (no output schema), but provides response_format option and metric names imply response fields. Adequate for the tool's complexity.
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 description adds substantial meaning: explains media_id reference, enumerates metrics per media type with deprecation notes, describes breakdown enum values, and specifies response_format outputs. Greatly enhances 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?
Clearly states 'Gets performance metrics for a specific Instagram media object.' Distinguishes from sibling tools like meta_get_instagram_media (media data) and meta_get_instagram_account_insights (account-level) by specifying resource and 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?
Provides extensive details on metrics per media type and optional breakdown parameter, but does not explicitly state when to use this tool versus alternatives. Usage is implied by the detailed metric lists.
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 read-only behavior. The description adds context that it returns 'lead data including field values, creation time, and ad info.' No contradictions. It does not disclose rate limits or pagination details beyond the cursor param.
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: main purpose first, then prerequisite, then parameter list. Every sentence provides necessary information without 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?
Given no output schema, the description explains return values. It covers all required parameters, pagination, and limit. The response_format parameter is only in the schema, which is acceptable as it's optional. Overall, it is complete for a read-only 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 coverage is 60% (3 of 5 params described). The description adds meaning: it clarifies that form_id comes from meta_list_leadgen_forms, page_id is for authentication, and limit has a range/default. It also describes return data, compensating for the absence of an output 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 'Gets submitted leads from a lead generation form,' specifying the verb (gets), resource (leads), and source (from a lead gen form). It distinguishes itself from sibling tools by targeting a specific entity.
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 lists a prerequisite: 'Requires: meta_list_pages must be called first to load page tokens.' It provides param details but does not explicitly state when to avoid this tool or alternatives. However, it implies correct usage by specifying dependencies.
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 read-only and idempotent. Description adds context about prerequisites and return content. 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?
Concise, front-loaded purpose, then prerequisite, args, returns. 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?
Explains return values (instant reply, away message, etc.) and prerequisite. No output schema, so 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 coverage is 100%, so description adds little beyond schema. Mentions page_id but not response_format.
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 'Gets the current automated messaging settings for a Facebook Page.' Differentiates from sibling setters (e.g., 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?
Explicitly states prerequisite (need to call meta_list_pages first). Could mention when to use vs setters, but context is clear.
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 read-only behavior; description adds that it retrieves only page-published posts, providing context beyond 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?
Extremely concise: one sentence with a purpose statement and an args list. No wasted words, front-loaded.
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?
Describes core functionality and exclusion of visitor posts, but lacks details on pagination (after parameter) and output format options. With no output schema, additional context about return structure would improve 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?
Schema coverage is only 25%; description explains page_id and limit but omits after (pagination) and response_format. Does not fully compensate for 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?
Clearly states it gets posts published by the Page itself and distinguishes from visitor posts via the feed edge. Verb 'gets' with specific resource and exclusion criteria.
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 notes that this tool excludes visitor posts, contrasting with the feed edge. This helps differentiate from siblings like meta_get_visitor_posts or meta_get_posts.
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 read-only and non-destructive behavior. The description adds value by specifying what is checked (token status, cached tokens, API connectivity) and the return values. However, it does not disclose potential network calls or rate limiting, which is acceptable given the simpler nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes a succinct list of return values. No extraneous 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 simplicity and the presence of annotations, the description adequately covers what the tool does and returns. Minor gap: it could mention that this tool is suitable for pre-checking server status before other operations, but it is not 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 coverage is 100% for the single parameter, with description in the schema. The tool description does not add any information about the parameter beyond the schema, so 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 clearly states the tool's purpose: 'Checks the health of the Meta MCP server', listing specific aspects like token status, cached tokens, and API connectivity. This is specific and distinct from sibling tools, which are primarily CRUD or utility 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 implies diagnostic use (health check) but does not explicitly state when to use this tool versus alternatives. Since no sibling tool provides similar functionality, the context is clear, but exclusions or prerequisites are missing.
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 value beyond annotations by explaining visibility implications (hidden comments only visible to author and friends) and confirming non-destructive nature. Annotations already cover idempotency and non-destructiveness, so the description provides complementary 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 concise, well-organized with a summary, behavioral note, and parameter list. Every sentence is informative with no 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 toggle tool with no output schema, the description covers purpose, behavioral context, parameter details, and permissions. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description repeats parameter info with brief clarifications (e.g., page_id for auth). The comment_id parameter lacks detailed explanation beyond its name, but overall the description adds modest value over 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 verb (hide/unhide) and resource (comment), and distinguishes from siblings like meta_delete_comment by noting it is non-destructive.
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 positions this as a non-destructive alternative to deletion, guiding when to use it. It also mentions required permission, though it could be more explicit about 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 indicate readOnlyHint=true and destructiveHint=false, meaning it's a safe read operation. The description adds that it returns form IDs, names, status, and creation times, and mentions the prerequisite call, providing useful behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with short paragraphs, and front-loaded with the core purpose. Every sentence adds value without 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 is fairly complete for a read-only list tool. It explains the prerequisite, the purpose, and what is returned. It could mention pagination via 'after', but overall it covers the essential context.
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 explains page_id and limit, but does not mention 'after' (pagination) or 'response_format' parameters. The schema already describes some parameters, so the description adds value but not fully comprehensive. With 50% schema coverage, the description partially compensates.
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 lead generation forms for a Facebook Page, and explains the context of OUTCOME_LEADS campaigns. It is specific and distinct among sibling tools, many of which list other entities.
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 must be called first to load page tokens. It also explains the use case for lead forms. It does not explicitly state when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior, and the description confirms read-only retrieval. It adds useful context about the two-step process and rate limit. 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 concise and well-structured: a clear purpose sentence, a note on two-step process, a bulleted args list, and a rate-limit note. No 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 complexity and number of siblings, the description covers the main actions, parameters, and constraints. It lacks a description of the return value format, but the response_format parameter addresses that. Additional details on error handling or edge cases could improve 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?
The description adds meaning for 4 of 5 parameters (ig_account_id, hashtag, edge, limit) beyond the schema, which only documents 2. The response_format parameter is omitted from the description but covered in schema. Overall, it compensates for 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 clearly states the tool searches for a hashtag, retrieves its ID, and fetches top or recent media. This distinguishes it from other Instagram tools that retrieve media by ID or other criteria.
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 rate limit note (30 per 7 days) but does not explicitly state when to use this tool versus alternatives like meta_get_instagram_recent_hashtags or other search tools. Usage context is implied but not 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing what is returned (Place IDs, names, addresses, coordinates) and constraints (distance max, limit range, requirement of q or center). This goes 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 and bullet-like parameter listings. It is concise without omitting critical details. A minor point: the response_format parameter is only in the schema, not mentioned in the description, but overall structure is good.
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?
No output schema exists, but the description lists what is returned. There are 6 parameters, but only 5 are described in the text (missing response_format). The description is adequate for a search tool, but the omission of response_format—a useful output formatting option—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 coverage is high (83%), but the description enriches parameter meanings with examples ('Central Park', '40.7829,-73.9654'), default/max values (distance=1000, max=50000), and category examples ('FOOD_BEVERAGE'). This adds significant 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 clearly states 'Searches for Facebook Places (locations) by name or coordinates.' and specifies the use case (getting location_id for tagging). This distinguishes it from sibling search tools like meta_search_ad_library or 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 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 it (for location_id) and includes a note about providing at least q or center. It does not explicitly state when not to use it, but the sibling context makes it clear. No alternative tools are named.
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, so the description does not need to reiterate safety. It adds behavioral context by stating it returns 'Location keys to use in ad set targeting', clarifying the read-only, non-destructive nature. 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?
Very concise; uses a single sentence for purpose and bullet-style Args/Returns. Every sentence is informative without redundancy. Front-loaded with the primary action.
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 4 parameters and no output schema, the description sufficiently explains the return value conceptually ('Location keys to use in ad set targeting'). It covers the required parameter and two optional ones. Could mention response_format behavior but schema handles that.
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 (25%), but the description compensates by explaining the purpose of 'q' with examples, enumerating values for 'type', and specifying default and max for 'limit'. The undocumented 'response_format' parameter has its description in the schema, so 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?
Clearly states it searches for geographic targeting options, listing examples of location types (countries, regions, cities, zip codes). Distinguishes from sibling tools like meta_search_targeting_demographics and meta_search_targeting_interests by specifying 'geographic'.
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 geographic targeting in ad sets, but does not explicitly state when to use this tool versus similar search tools (e.g., for demographics or interests). It provides the return value context but lacks explicit guidance on alternatives 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 confirms a write operation (sends a message) consistent with readOnlyHint=false. It adds specific behavioral constraints (24-hour window, permission) beyond 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?
Extremely concise: one paragraph with clear bullet-like args. Every sentence adds value (purpose, args, permission, window). 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?
Covers purpose, parameters, requirements, and limitations. No output schema needed. Could mention idempotency or response format, but not critical for this 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?
Schema description coverage is low (33%), so the description compensates by listing parameters with brief explanations (e.g., 'PSID' for recipient_id). However, it lacks details like minLength for message or format hints, leaving some 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 the action (sends a message), the resource (from a Facebook Page to a user), and the context (in an existing conversation). It distinguishes from siblings like meta_send_instagram_message by specifying 'Facebook Page' and 'existing conversation'.
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 mentions the 24-hour messaging window restriction and required pages_messaging permission, providing clear context for when to use. It does not explicitly mention when not to use or alternatives, but the constraints are well-articulated.
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 limited behavioral context (no readOnly or destructive hints). The description adds the two-step publishing flow and return of Media ID, but does not cover authentication requirements, rate limits, or side effects beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear two-line intro followed by an Args section and return statement. No superfluous information; every sentence adds value.
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 6 parameters and no output schema, the description adequately explains the process and expected result. It does not cover error cases or rate limits, but the essential workflow is 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?
The description lists all parameters with clear summaries, echoing the schema descriptions but adding context like the two-step flow and return value. With 83% schema coverage, the description adds useful structure without significant duplication.
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, and mentions a two-step flow. This distinguishes it from sibling tools like threads_publish_image or threads_publish_video, which handle other media types.
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 implicitly guides when to use this tool by specifying it is for GIF posts via GIPHY. However, it lacks explicit guidance on when not to use or alternatives, leaving the agent to infer from 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 declare idempotentHint=true, which matches the tool's behavior (blocking an already blocked user is a no-op). The description adds the consequence that blocked users cannot post or comment, going beyond annotations to explain the practical effect. 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 concise with a one-line summary followed by a clear bullet-style list of parameters. Every sentence adds value, and the structure is 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 block/unblock tool with 3 parameters and no output schema, the description adequately covers the action and parameters. It could optionally mention permissions or rate limits, but it is sufficient for an agent to select and use the tool.
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 0% schema description coverage, the description fully compensates by listing all three parameters with explanations: page_id, user_id, and unblock (with default and meaning). This adds significant meaning beyond the schema's type definitions.
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 ('Blocks or unblocks') and the resource ('a user from a Facebook Page'), with a specific consequence ('Blocked users cannot post or comment'). It distinguishes from siblings like 'meta_get_blocked_users' by focusing on the mutating 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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when to block vs unblock. However, the parameter 'unblock' clarifies the duality, and the context of blocking users is implied.
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 idempotent and non-destructive behavior. The description adds transparency by explaining the output (chart URL or file path), that the chart is saved as PNG, and that it can be inserted into docs or presentations. It does not mention the external QuickChart dependency but overall 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a use-case paragraph, parameter list, return info, and example. It is informative but slightly lengthy; minor trimming could improve conciseness.
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?
Considering the tool's complexity (10 parameters, 3 required) and lack of output schema, the description covers all parameters, defaults, return values, and provides a concrete example. It is complete enough for an AI agent to use 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 low (20%), but the description provides a detailed 'Args:' section explaining each parameter, defaults, and the structure of datasets. It includes an example with ad performance data, greatly supplementing 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 generates a chart image (PNG) from data using QuickChart/Chart.js, and distinguishes it from the sibling 'meta_generate_comparison_chart' by focusing on standard charts. The use case for Meta insights reports is explicitly mentioned.
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 an implied usage 'Perfect for creating visual reports from Meta insights data' but does not explicitly state when to use this tool vs alternatives like 'meta_generate_comparison_chart'. No exclusion criteria or when-not-to-use guidance is 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 and idempotentHint=true, so the tool is clearly a safe read. The description adds that it returns minimum budget requirements per bid strategy, which is useful but not critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs: purpose, usage note, then args and returns. Every sentence adds value, no redundancy. Front-loaded with the main action and critical usage context.
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 2-parameter read tool with annotations, the description covers purpose, prerequisite, argument with example, return type, and confidentiality (no output schema needed). Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage (only response_format described). The description provides an example for ad_account_id and explains the return structure, adding meaning beyond the schema. Response_format is fully described in schema, so no bonus 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 the verb 'Gets', the resource 'minimum budgets for an ad account', and the scope 'by currency and bid strategy'. It differentiates from siblings by specifying it's essential before creating ad sets.
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 that this tool is essential to check before creating ad sets to avoid API errors, providing clear when-to-use context. No explicit exclusions or alternatives, but the guidance is strong.
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 non-destructive (destructiveHint=false) and idempotent (idempotentHint=true). The description adds context about comment visibility post-hide, which is valuable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a short introductory sentence, a clarifying sentence about visibility, then an args list. No wasted words; front-loaded with purpose.
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 sufficiently explains the action, its effect, and the parameters. Context about visibility and non-destructive nature completes the picture for a simple toggle 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%, and the description repeats the parameter descriptions from the schema without adding new meaning. Baseline score of 3 is appropriate as the schema already documents parameters 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 clearly states the tool hides or unhides an Instagram comment, and explains the effect (only visible to author). It distinguishes from deletion (sibling meta_delete_instagram_comment) by calling it a non-destructive alternative.
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 says it's a non-destructive alternative to deletion and useful for moderation, indicating when to use it. Does not explicitly state when not to use it, but the guidance 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool caches page access tokens, a behavioral side effect. 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 front-loaded with the core purpose, uses an important note in caps, lists return fields, and ends with a tip. Every sentence contributes value with 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 simple listing tool with one parameter and no output schema, the description covers purpose, usage order, return fields, and caching behavior, making it 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 coverage is 100%, so baseline 3. The parameter 'response_format' is explained in the schema description; the tool description adds no additional 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 clearly states 'Lists all Facebook Pages managed by the authenticated user,' providing a specific verb and resource. It distinguishes from siblings like meta_get_page (singular) and other list 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?
Explicitly instructs to 'Call this tool first before any page or Instagram operations' and explains token caching. Does not explicitly mention when not to use it or name alternatives, but the guidance is strong.
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, and the description reinforces this by describing the tool as a transparency tool. It adds context by noting that a valid access token is required but not ad account ownership, and describes the return values.
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 clear opening sentence followed by a structured parameter list. It is concise but includes all necessary details; could be slightly shorter but 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?
Despite no output schema, the description summarizes what the tool returns (ad creatives, spend ranges, impressions, etc.), which is sufficient for an agent. The note about the access token requirement adds useful context. With 10 parameters, the description covers key aspects 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?
The description enhances the 60% schema coverage by listing all parameters with concise explanations, including enum values and defaults. It clarifies the required country codes and optional filters like date range and pagination, adding 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 explicitly states it searches the Meta Ad Library for ads from any advertiser, clearly identifying it as a transparency tool without requiring ad account access. This distinguishes it from sibling tools that typically require ad account credentials.
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 clarifies that no ad account is needed, providing a key differentiator from many sibling tools that require ad account access. It outlines parameters but does not explicitly name alternative 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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds value by stating the test event 'won't affect production data' (consistent with destructiveHint=false) and that it 'auto-sets a test_event_code if not provided.' 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 concise: two sentences plus a line about arguments. It front-loads the purpose and provides essential guidance without 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?
The tool has no output schema. While the description covers purpose and usage, it does not explain the return value or response format. The response_format parameter is documented in schema, but the description could be more complete about what the agent will receive after sending the test event.
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 detailed parameter descriptions. The description does not add new parameter semantics beyond stating 'Same args as meta_send_conversion_event.' Baseline 3 is appropriate given 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 the tool's purpose: 'Tests CAPI setup by sending a test event that won't affect production data.' It specifies the verb (test) and the resource (CAPI setup via test event), and distinguishes it from the sibling tool meta_send_conversion_event by indicating it's for testing.
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 tells when to use this tool (for testing CAPI setup) and references the alternative: 'Same args as meta_send_conversion_event but auto-sets a test_event_code if not provided. Use the test_event_code from Events Manager > Test Events tab.' This guides the agent to choose the right 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 already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds valuable behavioral details: it uses Promise.allSettled to handle partial failure, and for text-only content, only Facebook receives a post (Instagram doesn't support text-only).
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 with bullet points and clear sections. It is front-loaded with the main purpose, and every sentence adds value. No unnecessary 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 has 6 parameters, 3 required, and no output schema, the description adequately explains the return behavior (results from both platforms with success/failure) and the prerequisite. It could mention error handling for invalid URLs or auth issues, but it is sufficient for selection and 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 100%, so baseline is 3. The description adds significant extra semantics by explaining how parameters interact: if image_url is provided, both platforms get photo posts; if video_url, both get Reels; if text only, only Facebook gets a text post. This goes beyond the 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 tool's name and title clearly indicate cross-posting to Facebook and Instagram. The description explicitly states 'Publishes the same content to both a Facebook Page and Instagram simultaneously.' This distinguishes it from siblings like meta_create_photo_post and meta_publish_instagram_photo, which are single-platform.
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 must be called first to load page tokens.' It also explains the logic for different media types (image, video, text-only). While it doesn't explicitly state when not to use it, the context is clear enough for an agent to decide.
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, destructiveHint=false, idlepotentHint=true. The description adds useful context that the tool uses the Business Discovery API and requires no follow/connection, enhancing behavioral understanding 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 extremely concise with three short paragraphs: purpose, API context, and parameters. Every sentence adds value, and the key information is front-loaded in the first sentence.
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 3 parameters and no output schema, the description adequately covers what is returned (bio, counts, media, picture). It could mention potential failure conditions, but overall it's sufficient for an agent to understand the tool's capabilities.
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% (all parameters documented). The description adds value by clarifying ig_account_id as 'for auth' and specifying username format 'without @', improving semantic clarity beyond the schema alone.
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 explicitly states 'Gets public profile info for any Instagram business/creator account by username,' clearly indicating the verb (Gets), resource (public profile info), and scope (by username). This distinguishes it from sibling 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Uses the Business Discovery API — no follow/connection required,' providing context for when to use this tool. However, it doesn't explicitly state when not to use it or list alternatives, though the purpose is clear enough among 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 already indicate read-only, non-destructive, idempotent behavior. The description adds the prerequisite requirement and declares return fields, which provides useful context beyond 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?
Concise and well-structured: one sentence for purpose, one for prerequisite, then bullet-style parameter descriptions. No unnecessary words, and it is front-loaded with key 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?
Covers purpose, prerequisite, parameters, and return fields. The missing response_format parameter is a minor gap, but overall the description is nearly complete for a read-only list 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 adds the prerequisite context for page_id and enumerates broadcast_status enum values, which goes beyond the schema descriptions. However, it omits the response_format parameter. With 80% schema coverage, the description adds moderate 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 it lists live videos on a Facebook Page. The name and title make the purpose unambiguous, and the description distinguishes it from related tools like meta_get_page_videos (all videos) and meta_create_live_video (creation).
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 the prerequisite that meta_list_pages must be called first to load page tokens. This provides clear context for when to use the tool. However, it does not mention when not to use it or compare with alternative 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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by stating that all metrics use the 'lifetime' period (cumulative from post creation). This goes beyond what annotations provide, though it doesn't cover aspects like rate limits or authentication details beyond page_id.
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: a one-line purpose, a prerequisite line, and a bulleted 'Args' section. Every sentence adds value, and the information is front-loaded. No wasted words.
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?
While the description covers the metrics and period well, it lacks explicit information about the return format. There is no output schema, and the description doesn't specify whether the tool returns a JSON object, markdown table, etc. The response_format parameter gives options, but the structure of the output data (e.g., metric names as keys, values as numbers) is not described, which could leave agents uncertain.
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 significantly enhances understanding, especially for the 'metrics' parameter. It lists all available metrics grouped by category (Performance, Engagement, Reactions, etc.), which is far more informative than the schema's default array and short description. This empowers the agent to select appropriate metrics.
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 Facebook Page post', specifying the verb 'Gets' and the resource 'performance metrics for a specific Facebook Page post'. Among siblings like meta_get_post (which gets post content) and meta_get_page_insights (which gets page-level insights), this tool is uniquely distinguished.
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 lists a prerequisite: 'Requires: meta_list_pages called first.' It also provides guidance on metric categories and the lifetime period. While it doesn't explicitly state when not to use this tool or suggest alternatives, the context is clear enough for an agent to understand when to invoke 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?
Discloses the three-step internal process, return value (Media ID), and scheduling option. Annotations indicate mutation; description adds process detail. No contradictions with annotations. Lacks mention of rate limits or authentication, but annotations do not require those.
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?
Well-structured with clear sections: purpose, three-step process, args, returns, scheduling. Approximately 10 lines, no unnecessary words. Each 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?
Given the tool has 5 parameters and no output schema, the description covers the process, parameters, return value, and scheduling. Could mention error scenarios or additional constraints, but it is sufficiently complete for an agent to select and invoke 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?
Explains ig_account_id, items (with structure and limits), optional caption, and scheduling. The schema covers items and scheduled_publish_time partially, but description adds context for all parameters except response_format, which is omitted. Overall adds 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?
Clearly states the tool publishes a carousel post to Instagram, specifying the range of 2–10 items. Distinguishes itself from sibling tools like meta_publish_instagram_photo and meta_publish_instagram_reel by explicitly mentioning 'carousel' and describing the multi-step process.
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 (for carousel posts) and mentions scheduling capability. It does not explicitly state when not to use it or compare directly to siblings, but the context of siblings like single-photo or reel tools makes the usage clear.
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 write operation but not destructive. The description adds context: prerequisites (public URL), processing time (not immediate), and scheduling behavior. This adds 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 well-organized with clear sections (summary, Args, Returns, Notes). It is concise yet informative, 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?
Given the tool's complexity (6 params, no output schema), the description covers the return value (Media ID) and key behavioral notes. It could mention error conditions or rate limits, but overall 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?
The description covers key parameters (ig_account_id, video_url, caption, share_to_feed) and mentions scheduled_publish_time in notes, adding meaning beyond the schema. The response_format parameter is not mentioned, but the description 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 'Publishes a video reel to an Instagram professional account.' It uses a specific verb and resource, distinguishing it from sibling tools like meta_publish_instagram_photo or meta_publish_instagram_carousel.
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 good guidance: video must be public, check container status, use sibling meta_check_instagram_container for readiness, and scheduling details. However, it lacks explicit when-not-to-use scenarios.
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 all false (no hints), so the description carries the burden. It adds that the flow is single-step (no polling) and that the video must be publicly accessible. It also states the return value. This provides useful behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections: main action, requires, args, returns, notes. Every sentence is informative and 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?
Given no output schema and low annotation coverage, the description covers purpose, prerequisites, parameters, return value, and a key behavioral note. It lacks details on error responses or response_format usage, but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 context for video_url (must be publicly accessible) and clarifies optional parameters. The note about video hosting adds meaning beyond the schema's property 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 the exact action: 'Publishes a Reel (short-form video) to a Facebook Page.' It clearly distinguishes from sibling tools like meta_publish_instagram_reel and meta_create_video_post by specifying 'Reel' and mentioning the simpler single-step flow.
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 requires calling meta_list_pages first to load page tokens, providing a clear prerequisite. It does not explicitly list when not to use or alternative tools, but the context and naming effectively differentiate 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 indicate idempotentHint=true and no destructive/write-only flags. The description adds behavioral nuance: it explains the dual mode (subscribe or check), which is beyond what annotations provide. 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 concise (two sentences plus arg list), front-loaded with the primary purpose, and well-structured. Every sentence adds value without 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 the main functionality and the dual-use scenario. It does not detail return values or error handling, but given the tool's simplicity and the presence of a response_format parameter, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the main parameters and provides examples for subscribed_fields (e.g., feed, messages). It also explains the special behavior of calling without subscribed_fields. This adds meaning beyond the schema, which only has a brief description for subscribed_fields. Schema coverage is 67% but description compensates well.
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 ('subscribes') and resource ('webhook updates for a Facebook Page'). It is specific and distinct from sibling tools, which primarily focus on reading, creating, or updating other resources.
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 the tool (to subscribe or check subscriptions). It includes a usage note: 'Call without subscribed_fields to check current subscriptions.' However, it does not explicitly exclude scenarios or mention alternatives, but given the sibling set, this is the only webhook subscription 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?
The description discloses behavioral traits beyond annotations, such as return value (new campaign ID), parameter constraints (lifetime budget requires stop_time), and the migration alternative. Annotations indicate non-destructive write, which aligns with creation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured, starting with purpose and listing arguments. Each sentence adds value, though the list format could be slightly more compact.
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 (9 parameters, 3 required, no output schema), the description covers purpose, parameters, usage, and return value adequately. It lacks error handling or rate limit details but is sufficient for a creation 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?
The description adds meaning beyond the input schema by explaining common values for objective and clarifying the relationship between lifetime_budget and stop_time. Schema coverage is high (89%), but the description still provides useful context.
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 creates a new campaign in a Meta ad account, using specific verbs and resources. It differentiates from sibling tool meta_migrate_campaign_to_advantage_plus by noting the migration path for Advantage+ Shopping campaigns.
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 provides explicit guidance on when to use this tool for standard campaigns and when to use alternative tools (e.g., for Advantage+ campaigns). It also notes special requirements for special_ad_categories in certain verticals.
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 all false, so the description carries the burden. It clearly states that if planned_start_time is provided, the broadcast is created as SCHEDULED_UNPUBLISHED; otherwise it goes LIVE_NOW. It also mentions the return values (stream URL and live video ID). 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 concise (3 sentences) and front-loaded: it starts with the main purpose, then prerequisites, then a bulleted arg list, then conditional behavior. Every sentence adds value without unnecessary detail.
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?
Given the tool has 5 parameters (2 required) and rich schema coverage, the description covers prerequisites, conditional behavior, and return values. No output schema exists, but the description states what is returned, making it complete for an agent to understand and use the tool properly.
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 value by explaining the conditional effect of planned_start_time and listing the required args. It does not merely repeat schema definitions; it provides behavioral context beyond parameter names and types.
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 creates a live video broadcast on a Facebook Page, using a specific verb (creates) and resource (live video). It distinguishes itself from sibling tools like meta_create_post or meta_create_video_post by being specific to live 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 description explicitly mentions a prerequisite: 'Requires: meta_list_pages called first to load page tokens.' It also explains the conditional behavior based on planned_start_time, guiding when to use this tool. However, it does not explicitly mention when not to use it or suggest alternatives, but the prerequisite provides good context.
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 additional context beyond annotations (readOnlyHint, destructiveHint, idempotentHint) by specifying what information the inspection reveals (type, expiry, permissions, app/user) and that it uses the META_ACCESS_TOKEN environment variable. This enriches the agent's understanding of the tool's behavior without repeating annotation content.
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 sentences with no wasted words. The purpose is stated in the first sentence, followed by usage guidance and a note about no arguments. Every sentence earns its place, making it efficient and 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 diagnostic tool with one optional parameter and no output schema, the description is complete. It explains what the tool does, when to use it, and that it requires no arguments. The user is fully informed about the tool's functionality and expected output (type, expiry, permissions, app/user).
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 one optional parameter (response_format) with a clear description and enum. Schema coverage is 100%, so the baseline is 3. The description adds 'no arguments needed', which reinforces that the parameter is optional but does not add new semantic meaning 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 clearly states the tool inspects the Meta access token to show its type, expiry, permissions, and associated app/user. This specific verb ('inspects') and resource ('Meta access token') clearly distinguishes it from sibling tools which are primarily for creating, reading, updating, or deleting entities.
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 mentions it is useful for diagnosing 'permission denied' errors and checking when a token expires. It also notes that no arguments are needed, providing clear usage context. However, it does not explicitly state when not to use this tool or list alternatives, which could further aid agent decision-making.
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 behavioral context: it returns time-series data, and the args section clarifies what data is fetched. 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?
Well-structured: summary, prerequisite, args with details, return statement. The metric list is long but necessary for completeness. Could be slightly more concise, but justified.
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?
Despite no output schema, the description explains the return as 'time-series data for each metric.' All essential aspects (prerequisite, parameters, behavior) are covered. Highly complete for a tools of this complexity.
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 significant value beyond the input schema, especially for the 'metrics' parameter, which lists 70+ options organized by category. This goes far beyond the schema's default list 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 clearly states it gets analytics/insights for a Facebook Page (specific verb+resource). It distinguishes from siblings like meta_get_page (which gets page info) and meta_get_account_insights (for ad accounts), as seen 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 prerequisite: 'Requires: meta_list_pages called first.' This guides the agent on proper use. It does not explicitly mention when not to use, but the context of sibling tools provides implicit differentiation.
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, destructiveHint=false, idempotentHint=true. The description adds the prerequisite requirement and return value details, providing additional behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences covering purpose, prerequisite, and return values. Every sentence is essential, and it is front-loaded with the core action.
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 list tool with one optional parameter and read-only annotations, the description provides all necessary context: what it does, the required predecessor, and the utility of its 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 coverage for the single 'response_format' parameter is 100%, so the schema fully documents it. The description does not add extra meaning for this parameter, meeting the baseline of 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 'Lists all Instagram professional accounts linked to the user's Facebook Pages,' using a specific verb and resource, and it distinguishes itself from sibling tools that list other entities.
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 the prerequisite 'Requires: meta_list_pages must be called first' and explains the return values and why they are needed for subsequent Instagram tools, guiding the agent on when 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 are minimal, so the description carries the burden. It discloses the two-step process, scheduling, and limitations. However, it does not mention error handling or edge cases (e.g., what happens if container creation fails). This is a minor gap given the detail otherwise.
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 with paragraphs and bullet points, front-loaded with purpose. No unnecessary sentences; every part adds value. Approximately 150 words, appropriate for the complexity.
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 (7 parameters, two-step process, scheduling), the description covers the main points thoroughly, including limitations and return value. Lacks some detail on error handling or rate limiting, but is largely complete for an agent to use.
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%, and the description adds significant meaning: image_url must be public JPEG, caption supports hashtags, alt_text for accessibility, location_id is Facebook Place ID, scheduled_publish_time has a specific range (10 min – 75 days). This goes well beyond the 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 clearly states it publishes a single image post to an Instagram professional account, and the two-step process is explained. It distinguishes from sibling tools like meta_publish_instagram_carousel or meta_publish_instagram_reel by specifying 'single image 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 when to use (single image post) and provides limitations (JPEG only, max 100 posts, public URL), but does not explicitly contrast with sibling tools or state when not to use. It gives context about scheduling but lacks explicit 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?
Adds detail beyond annotations: describes chart type defaults, optional output path for saving PNG, and example inputs. Annotations already indicate idempotent and open world; description adds behavioral context without 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?
Well-organized with an Args section and example. Front-loads purpose, every sentence adds value. 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?
Given 9 parameters, nested objects, and no output schema, the description is complete: it documents all parameters, provides defaults, and an example. No missing information for a chart generation tool.
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 22% schema description coverage, the description compensates fully by listing all parameters with types, defaults, and a detailed example explaining the meaning of group_a and group_b 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 clearly states it generates a side-by-side comparison chart, with specific use cases (comparing time periods, campaigns, A/B tests). It distinguishes itself from the sibling 'meta_generate_chart' by focusing on comparison scenarios.
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 on when to use (comparing two periods, campaigns, A/B tests). Does not explicitly mention when not to use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description accurately portrays a write operation with no destructive side effects. It adds details like maximum character count, scheduling requirements, and the need for Page Publishing Authorization, which go 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, prerequisites, parameter list, return value, and notes. It is concise and front-loaded with essential info.
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 post creation tool with no output schema, the description adequately covers return value (Post ID), parameters, constraints, and prerequisites. No gaps identified.
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 baseline is 3. The description adds significant value by explaining the prerequisites for page_id, the behavior of link (creates preview), the draft vs publish distinction for published, and the scheduling constraints for scheduled_publish_time. However, response_format is not elaborated in 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 'Creates a new post on a Facebook Page' and details the parameters and behavior. It distinguishes itself from sibling tools like meta_create_photo_post and meta_create_video_post by focusing on text/link 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 explicitly requires calling meta_list_pages first for tokens and notes scheduling constraints and authorization. It implies usage for text/link posts but does not explicitly exclude other scenarios or compare with similar siblings.
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?
Discloses that PII must be SHA256 hashed, describes return value (number of events received), and aligns with annotations (readOnlyHint=false indicates writes, no contradiction). Provides behavioral 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?
Front-loaded purpose with clear parameter list. Brief but covers all necessary details. Could combine some sentences but overall efficient.
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?
Comprehensive for a complex tool with nested objects and no output schema. Covers usage, parameter details, hashing requirement, and return value. Leaves no major gaps given sibling context.
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?
Adds critical meaning beyond schema: specifies required fields in user_data (email, phone, etc.), notes hashing requirement, and enumerates custom_data fields. Schema coverage is high (86%), but description still enhances usability.
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 the verb 'sends', resource 'offline conversion event to a Meta offline event set', and provides usage examples (in-store purchases, phone orders). Distinguishes from siblings like meta_send_conversion_event for online events.
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 when to use ('for tracking in-store purchases, phone orders, or other offline conversions') and implies differentiation from online event tools. Does not explicitly exclude alternatives, but context is clear.
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:

[![meta-mcp-server MCP server](https://glama.ai/mcp/servers/oliverames/meta-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/oliverames/meta-mcp-server)

Score Badge

Copy to your README.md:

[![meta-mcp-server MCP server](https://glama.ai/mcp/servers/oliverames/meta-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/oliverames/meta-mcp-server)

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/oliverames/meta-mcp-server'

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