meta-mcp-py

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct by platform and resource, but there is real overlap: reply_to_comment covers Facebook or Instagram while ig_reply_to_comment exists separately, and audience_overview overlaps with get_page_audience and get_ig_audience_demographics. The many publish-from-URL vs publish-from-file variants also add ambiguity despite clear descriptions.
Naming Consistency3/5
The dominant snake_case verb_noun pattern is good, but there are notable deviations: graph_get, token_permissions, token_info, account_summary, follower_growth, audience_overview, and ig_publish_* reverse the platform/verb order compared to publish_page_*. The set is readable, but not predictable enough for a high consistency score.
Tool Count1/5
56 tools is extreme for an MCP server and clearly above the 50+ threshold. Many tools are variants of the same underlying operation (URL vs local file uploads, Facebook vs Instagram replies), so the set could be significantly consolidated without losing capability.
Completeness3/5
The server covers a wide range of Facebook, Instagram, Threads, and custom-audience workflows, including publish, insights, comments, and audience management. However, notable gaps exist: no update for posts or audiences, no delete for Threads or Facebook comments, no Instagram story publishing, and graph_get is read-only so it cannot fill mutation gaps.
Average 3.4/5 across 56 of 56 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It reveals that the tool performs auto-discovery, but it does not explain behavior when no linked Instagram Business account exists, return characteristics, authentication needs, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It is appropriately brief for a simple lookup, though it sacrifices useful detail 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?
For a tool with no annotations and no parameter documentation, the description is under-specified. It does not clarify what 'lié' refers to, how page_id is used, or what happens when no account is found, so an agent lacks enough context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the page_id parameter. Page_id is left without any explanation of how it relates to the linked Instagram Business account or whether it is required for discovery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Trouve l'ID' plus a clear resource, 'compte Instagram Business lié', and adds the auto-discovery behavior. It does not fully differentiate itself from the sibling get_ig_account, but the core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives like get_ig_account. The phrase 'auto-découverte' hints at one use case, but no context, prerequisites, or exclusions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool 'details' a publication and does not mention read-only status, required Instagram access token scopes, or any constraints on the media object. This is a significant gap for a tool that likely requires page/Instagram account authorization.
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 a single, front-loaded sentence with no filler, which is concise. However, it is so terse that it omits useful context; the brevity is acceptable but not exemplary for a tool with a non-obvious parameter 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?
The tool is simple and has an output schema, but the description does not situate it among many IG-related siblings or explain prerequisites. Missing context includes how to obtain media_id, what scopes are required, and what kind of media is covered (image, video, carousel, reel).
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% and the description adds no meaning about media_id beyond its property name. No format, example, or source guidance is given, so an agent may guess whether the ID is a numeric IG media ID, a shortcode, or something else.
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 French description uses a clear verb ('Détaille') and a clear resource ('une publication Instagram'), indicating that the tool retrieves details for a single Instagram media object. It is distinguishable from siblings like list_ig_media by implying singular detail retrieval, though it does not explicitly contrast with get_ig_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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as list_ig_media or get_ig_media_insights, so an agent must infer selection solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states what statistics are returned. It does not mention permissions, data availability windows, rate limits, or whether the story_id must refer to a story owned by the authenticated account.
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 single-sentence description is efficient and front-loads the key resource and metric categories. It contains no filler, though it is more of a noun phrase than a complete verb-driven utterance, which slightly weakens clarity.
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?
Though an output schema exists, the definition lacks essential operational context, such as how to obtain a valid story_id and any prerequisites for access. For a one-parameter tool with zero schema description coverage, this leaves the agent with gaps that siblings like list_ig_stories only indirectly fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for story_id (coverage 0%), and the tool description does not compensate by explaining the expected format, how to obtain it, or whether it is an Instagram media ID. The agent must infer the semantics solely from the parameter name, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Instagram story) and the operation (returning statistics), listing representative metrics like reach, responses, and navigation. It is distinguishable from sibling tools such as get_ig_account_insights or get_ig_media_insights because it specifically targets stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as list_ig_stories to first obtain story IDs or get_ig_media_insights for broader media metrics. The context is only implied by the name and metric list, not explicitly stated.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'lists recent Threads posts.' It does not mention ordering, pagination, limit behavior, authentication requirements, or whether this is a read-only operation beyond the implication of 'list.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant information. It is front-loaded and easy to parse, though it is concise to the point of being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter listing tool with an output schema, some context is present, but the description lacks parameter semantics, usage guidance, and clarity about whose Threads posts are being listed. It is not complete enough for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the limit parameter at all. An agent must rely solely on the parameter name and default value, which is insufficient compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear action ('Liste') and resource ('publications Threads récentes'), so an agent can understand it returns recent Threads posts. It is distinguishable from siblings like get_threads_profile or publish_thread, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_page_posts, list_ig_media, or get_threads_profile. There is no mention of context, exclusions, or preferred 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only conveys 'daily evolution' and does not explain pagination, time range handling, token requirements, or whether it returns per-day deltas versus cumulative counts. The output schema may describe return fields, but the description itself adds little 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, so it is concise. However, it is under-specified rather than efficiently complete, providing only a noun phrase rather than an actionable specification.
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 two-parameter query with an output schema, the description conveys the essential topic and lets the agent infer page_id and days, making it minimally viable. But the absence of usage guidance, behavioral details, and parameter semantics leaves meaningful gaps for an agent that must choose among many insight-related sibling tools.
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 must compensate for undocumented parameters, but it only loosely implies page_id ('de la Page') and days ('quotidienne'). It does not describe the expected page_id format, the meaning or range of days, or the default behavior of 30 days.
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 the core function: daily evolution of a Facebook Page's followers, which is specific and not a tautology. It identifies the resource and metric, though it does not explicitly differentiate itself from sibling tools like get_page_insights or get_page_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 about when to choose follower_growth over the many sibling tools, such as get_page_insights, audience_overview, or account_summary. There are no stated exclusions, alternatives, or prerequisite conditions like required token permissions.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only lists profile fields and does not state read-only behavior, authentication requirements, or any side effects. The name implies a read operation, but the description never makes this explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, front-loaded phrase with no filler. It could be structured as a full sentence, but it is efficient and every word contributes meaning.
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 output schema likely covers return values, but the description still lacks parameter provenance, usage guidance, and sibling differentiation. For a tool with no annotations and a single undocumented parameter, these omissions leave an agent guessing.
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%, and the description does not clarify the ig_user_id parameter: no format, example, or way to obtain it. The parameter name is partially self-explanatory, but the description itself adds no parameter-level meaning.
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 the resource ('Profil Instagram') and the data it exposes (followers, followed accounts, publication count). It is clear enough about what the tool retrieves, but it does not explicitly differentiate it from sibling tools like get_ig_account_insights or find_instagram_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?
There is no guidance on when to use this tool versus alternatives. It does not mention that find_instagram_account might be needed to resolve the account ID, nor does it contrast itself with account insights 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that the tool performs a reply action but does not mention permissions, side effects, failure modes, or whether the reply is public, which matters for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff; it states the core action and platform scope efficiently. It lacks some content, but this dimension measures waste, and there is none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description is too thin: it does not address the relationship to ig_reply_to_comment, how a comment ID is resolved, or permission requirements. The output schema covers return values, but the missing operational context leaves an agent guessing.
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 0% schema description coverage and no parameter details in the description, the agent must infer that comment_id identifies the target and message is the reply text. The description adds minimal meaning beyond the schema titles and does not compensate for the empty parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reply) and the resource (comment), and scopes it to Facebook or Instagram. It does not explicitly differentiate from the sibling ig_reply_to_comment, which is the Instagram-specific version, so it stops short of full sibling discrimination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over ig_reply_to_comment, nor any conditions, prerequisites, or exclusions. The only contextual signal is the platform scope, which is not enough to route an agent correctly among the comment-related siblings.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists the metrics returned, which overlaps with the output schema, and does not mention authentication requirements, rate limits, or any edge-case behavior. The read-only nature is implied by 'Statistiques' and the 'get' prefix, but no explicit safety or permission context is given.
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 short sentence in French, with no fluff or repetition. It front-loads the key functional information (statistics of a Threads post) and lists examples of the returned metrics concisely. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and an output schema, the description is minimal but not entirely sufficient. It lacks usage context, such as how to obtain the thread_id, and does not clarify how this tool differs from other analytics tools in the sibling list. An agent might misselect it without additional clues.
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%, and the description does not explain what thread_id represents beyond the schema's title 'Thread Id'. It does not provide a format, example, or source for the ID, leaving the agent to infer that it is the identifier of the Threads publication. With zero schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pairing: 'Statistiques d'une publication Threads' (statistics of a Threads publication), and lists the specific metrics returned (views, likes, replies, shares). This is specific enough to distinguish it from siblings like get_threads_profile or list_threads_posts, though it does not explicitly name any sibling to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_post_insights, get_ig_media_insights, or get_threads_profile. The description gives no context on prerequisite conditions, such as requiring an Instagram/Threads account connection or specific permissions. An agent would have to infer usage purely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool replies to a comment; it does not mention permissions, whether the reply is immediately published, side effects, or any constraints around replying.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The essential action is stated directly and front-loaded.
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 and has an output schema, so full return-value documentation is not required. However, the description lacks usage conditions, parameter hints, and differentiation from sibling tools, making it insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. While 'comment_id' and 'message' are somewhat self-explanatory from their names, the description adds no additional meaning, format guidance, or source for the comment_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Répond' and names the resource 'un commentaire Instagram', making the core action clear. It does not explicitly differentiate itself from the sibling tool 'reply_to_comment', relying mostly on the 'ig' prefix in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'reply_to_comment', 'ig_delete_comment', or other Instagram comment tools. An agent is left to infer the correct context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation via 'Statistiques' but discloses nothing about rate limits, what null metrics returns, valid metric values, or authentication requirements. It is not misleading, but it adds almost nothing beyond the tool's core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded, zero-waste sentence. The core function is stated first and the parenthetical adds useful specificity without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, output schema present), so return-value documentation can be carried by the schema. However, with no annotations and no parameter descriptions, the description leaves real gaps: metrics semantics, when-to-use routing against insight siblings, and any safety profile. It is minimum viable with clear gaps.
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 must compensate, but it merely lists example stat types (reach, clicks, reactions) without explicitly tying them to the metrics parameter, explaining post_id format, or clarifying the null default. The hint is marginally useful but leaves both parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function and resource: retrieving statistics for a Facebook post, illustrated with concrete metric examples (portée, clics, réactions). Naming 'Facebook' implicitly distinguishes it from the Instagram and Threads insight siblings, but it does not explicitly differentiate from close siblings like get_post or get_page_insights, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The sibling list contains many overlapping insights tools (get_page_insights, get_ig_media_insights, get_threads_insights), and the description offers no exclusions, prerequisites, or routing hints to help an agent pick the correct one.
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 a non-obvious implementation detail: images are first uploaded unpublished, then attached to the post. With no annotations, this is helpful behavioral context. However, it does not mention that the post becomes publicly visible, what permissions are needed, or how failures are handled.
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 concise sentences with no filler. The main purpose is front-loaded, and the second sentence adds meaningful process detail without over-explaining.
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 mutating publishing tool with no annotations and zero schema descriptions, the description is too thin. It lacks usage guidance, parameter semantics, and behavioral consequences. The process note is useful but does not sufficiently equip an agent to invoke the tool correctly among many similar siblings.
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 must compensate for documenting parameters. It mentions images and 'post' vaguely, but never defines `message`, `page_id`, or the exact role of `image_urls`. It adds little beyond what the parameter names themselves already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Publie') and the resource ('un carrousel sur une Page Facebook'), and the parenthetical '(plusieurs photos)' disambiguishes it from simple photo or text posts. However, it does not explicitly differentiate this URL-based carousel from the sibling `publish_page_carousel_from_files`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives such as `publish_page_carousel_from_files` or `publish_page_photo`. The only hint is the schema's `image_urls` field, but the description itself never states conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns daily account-level stats and the expected date format, and it implies a read-only operation. However, it omits auth prerequisites, rate limits, timezone behavior, and what happens if metrics is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded and the date-format note is directly actionable.
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?
Even though an output schema exists and return values do not need to be described, the input side is under-specified: 0% schema coverage, no annotations, and no parameter explanations leave an agent guessing about required identifiers and metric options for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It helps with since/until by giving the AAAA-MM-JJ format and hints at metrics via examples, but it does not explain ig_user_id, valid metric values, the default behavior of metrics=null, or how the date range is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('compte Instagram'), the granularity ('quotidiennes'), and sample metrics (reach, profile views), which distinguishes it from story/media/audience sibling tools. It lacks an explicit verb like 'retrieves', but the tool name supplies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_ig_story_insights, get_ig_media_insights, or get_page_insights. The only usage hint is the date format, which is not a selection criterion.
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?
No annotations exist, so the description must carry the full behavioral burden. It explains what statistics are returned but does not disclose whether the operation is read-only, what permissions are required, how the optional metrics parameter behaves, or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. The resource is front-loaded and the metric examples add useful specificity without bloat.
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 that this is a Facebook/Instagram Graph API-style insights endpoint with 0% schema coverage and no annotations, the description is too thin. It omits permission requirements, media_id semantics, metrics selection behavior, and any output details, leaving an agent without enough context to invoke the tool reliably.
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 clarify both parameters. It gives examples of metric values (reach, likes, saves, shares), which helps understand the 'metrics' parameter, but it never explains 'media_id' or how metrics should be supplied or defaulted.
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 resource (a single Instagram publication) and the outcome (statistics: reach, likes, saves, shares). This distinguishes it from siblings like get_ig_account_insights and get_ig_audience_demographics, though the action verb is carried by the tool name rather than the description 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 implies usage: call this when you need per-post Instagram performance metrics. It does not explicitly say when not to use it or name alternatives, but the singular 'publication' and the listed metrics make the intended context reasonably clear relative to account or audience insight 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions image count and URL format but does not disclose the asynchronous nature of Instagram publishing, the need to check container status, rate limits, or that the carousel must be published to a valid IG user ID. The absence of annotations and output schema details leaves 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?
The description is a single concise sentence that front-loads the core purpose and key constraints. However, it could earn a 5 by including a brief mention of usage context or a link to related tools.
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 essential facts (action, object, constraints) but is incomplete for practical use. It lacks guidance on container status polling, publishing limits, and how the output schema relates to the response. Given the complexity of Instagram publishing and the absence of annotations, more context is needed for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description only clarifies the image_urls parameter (2-10 public JPEG URLs). It does not explain ig_user_id or caption beyond their names, and caption's behavior (optional, character limits, formatting) is entirely undocumented. The description partially compensates for the low coverage but leaves most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (publishes an Instagram carousel) and specifies key constraints (2 to 10 images, public JPEG URLs). It is specific enough to differentiate from ig_publish_image and ig_publish_reel, though it doesn't explicitly name 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for publishing a carousel, and the constraints on image count and URL format provide practical guidance. However, there is no explicit guidance on when to choose this tool over alternatives like ig_publish_carousel_from_files 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the list operation and does not mention pagination behavior, reply inclusion, ordering, authentication requirements, or rate-limit implications. It does not contradict annotations because none exist.
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 short, front-loaded sentence with no filler. For a simple list operation, this length is appropriate and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return-value structure, and the tool itself is a simple list operation. However, the complete lack of parameter semantics and usage guidance makes the definition only minimally viable rather than fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaningful explanation for either parameter. It does not clarify that media_id is the Instagram publication identifier or how limit affects the result, leaving the agent to rely only on parameter names and the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Liste') and a specific resource ('commentaires d'une publication Instagram'), making the operation unambiguous. The explicit 'Instagram' reference also distinguishes it from sibling tools like list_post_comments, which target Facebook page 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?
The description gives no guidance on when to use this tool versus alternatives such as list_post_comments, nor does it mention any prerequisite steps like obtaining an Instagram media_id from list_ig_media. An agent must infer usage entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the key temporal behavior (only active, 24-hour stories). However, it does not state the read-only nature, token/permission requirements, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler every word adds meaning. It is efficient, though the terseness leaves param and usage details uncovered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required param) and an output schema exists, so return-value details are covered elsewhere. The main gaps are parameter provenance and permission preconditions, which an annotation-less description should address for fully confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions ig_user_id. The parameter name is self-descriptive, but nothing explains where the ID comes from (e.g., via find_instagram_account) or what format is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (list), a clear resource (Instagram stories), and a scope qualifier (active within 24h), so an agent can tell what is returned. It is distinguishable from siblings like list_ig_media or get_ig_story_insights, though it does not explicitly name any alternative.
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 siblings such as list_ig_media or get_ig_story_insights, and no prerequisites or exclusions are mentioned. The agent must infer selection logic purely from names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states what the tool does (publishes a photo), but does not mention side effects, authentication requirements, error conditions (e.g., file not found), or the nature of the operation (e.g., that it creates a post). It lacks disclosure about potential failures or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and resource. It is efficient with no filler, though it could briefly mention parameters. Overall, it is well-structured for a short description.
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, 2 required, and an output schema, but the description provides no guidance on required inputs, expected behavior, or return value. It does not mention that page_id and file_path are required, nor how caption or published affect the outcome. This incompleteness is significant for a publishing tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. The description only references a local file, which loosely maps to file_path, but it does not explain page_id, caption, or published semantics. An agent receives no guidance on how to fill these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Publie'), a clear resource ('une photo sur une Page Facebook'), and a source ('depuis un fichier local (upload direct)'). This clearly distinguishes it from sibling tools like publish_page_photo (which likely handles URL uploads) and publish_page_video_from_file (video vs photo). The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a local file and want to upload it directly, but it does not explicitly name alternatives or state conditions like 'use publish_page_photo for URL-based uploads'. It provides context ('from a local file') but no explicit when-to-use vs. 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?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the critical destructive trait ('Action irréversible'), which is valuable, but it omits side effects, required permissions, and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary action and the irreversibility warning are both front-loaded, making the description easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with an output schema, this is a minimum viable definition: it states the action and the key risk. However, it lacks permission context, expected result details, and any usage guidance, leaving noticeable gaps.
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%, and the description does not mention post_id at all. The parameter name is self-explanatory enough to infer it identifies the post to delete, but the description adds no meaning beyond the schema field title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Supprime') and identifies the target resource ('une publication Facebook'), so an agent knows what the tool does. It doesn't explicitly distinguish this from sibling delete tools like delete_custom_audience or ig_delete_comment, but the tool name supplies that 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 given on when to use this tool versus alternatives such as list_page_posts, get_post, or other delete operations. There are no preconditions, permission requirements, or exclusions, so the agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the data returned (age/gender, country/city) and does not mention permissions, data recency, read-only behavior, rate limits, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The core subject and key qualifiers are front-loaded, making it immediately scannable for an AI agent.
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?
An output schema exists, so return-value structure does not need to be described in prose. Still, without annotations, the description omits practical context such as valid breakdown values, permission requirements, or whether the data covers a specific time period, leaving noticeable gaps for an agent deciding how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by explaining that the breakdown can use age/gender, country, or city, which adds meaning beyond the schema's bare 'breakdown' title. However, ig_user_id is not explained beyond its name and there is no explicit mapping of parameters to the described dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource—Instagram follower demographics—and specifies the main dimensions (age/gender, country or city), which distinguishes it from media/story-level insight tools. The verb is missing from the description, but the tool name supplies the 'get' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_ig_account_insigts, audience_overview, or get_page_audience. The purpose implies the use case, but no explicit or even implied comparison to sibling tools is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does communicate the relevant quota window (50 posts/24h) and clearly implies a read-only status operation, but it does not explicitly say the call is side-effect-free or describe behavior at the limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler, front-loading the core quota and limit information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the definition still lacks operational context: when to invoke the tool, what ig_user_id refers to, and any permission or scope requirements. The minimal text is enough to understand the tool's purpose but not to call it confidently in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions ig_user_id. The agent gets no guidance on what identifier to pass, its format, or how to obtain it, so the description does not compensate for the bare schema at all.
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 name and description clearly identify a specific resource: remaining Instagram publishing quota, with the concrete limit of 50 posts per 24 hours. This distinguishes it from sibling publish and insight tools, though it lacks an explicit verb like 'get' or 'check'.
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 notion of 'remaining quota' implies this should be checked before publishing on Instagram, but the description does not explicitly state when to call it, what conditions warrant it, or how it relates to publish operations such as ig_publish_image or ig_publish_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?
With no annotations, the description carries the behavioral burden. It does add useful traits beyond the tool name: results are limited to recent publications and to posts/reels/carousels. However, it does not clarify the meaning of 'recent', mention pagination/ordering, or note any authorization requirements, so it is only minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler; the verb and object come first and the parenthetical adds useful scope. It is appropriately sized for a simple list operation.
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 two-parameter tool with an output schema, this is a minimum-viable definition: an agent can likely invoke it with ig_user_id and optional limit. But missing usage alternatives, parameter explanations, and behavioral details leave clear gaps that prevent full confidence in correct selection.
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 must compensate, but it does not explain ig_user_id or limit. The tool name and schema titles make some inference possible, but the description adds no explicit meaning beyond 'Instagram publications'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and resource ('publications Instagram') and enumerates included media types (posts, reels, carrousels), so an agent can tell this is a list operation for Instagram media. It does not explicitly distinguish itself from sibling tools like get_ig_media or list_ig_stories, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool instead of the many similar Instagram siblings, and no exclusions or conditions are given. The only implied usage is that it lists recent media, which the agent must infer from the description 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?
With no annotations, the description carries the behavioral burden and does add daily granularity, date format, and default-metric behavior. But it leaves the default metric set undefined and does not mention token/authorization needs, rate limits, or the period parameter's broader behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the purpose and then add only the two operational notes an agent needs: date format and default metric behavior. No filler or 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?
For a 5-parameter tool with no schema descriptions and no annotations, the description is too thin: it omits period value semantics, the actual default metric set, and authentication or page-id context. The presence of an output schema reduces the need to describe return values, but it does not fill these invocation gaps.
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% and the schema provides only types and titles. The description usefully documents the date format for since/until and the fallback behavior of metrics, but period, page_id, and valid metric strings are left unexplained, so the description only partly compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's return subject: daily statistics for a Page (reach, engagement, followers). It is clear enough to distinguish page-level analytics from sibling tools like get_post_insights or get_ig_*_insights, though it does not explicitly name any alternative.
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 gives call-level guidance: since/until must be YYYY-MM-DD and metrics can be omitted to use a default set. However, it never states when to prefer this tool over sibling insight tools or lists exclusions for when it should not be used, so tool-selection guidance is only implied by the Page scope.
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?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that the operation retrieves a post, but does not mention required permissions, error behavior, rate limits, or any side-effect profile. This is not a contradiction, but it is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, front-loading the verb and the object. Every word contributes to the meaning, which is appropriate for a simple single-parameter fetch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, one self-explanatory required parameter, and the presence of an output schema, this is minimally viable. The clear gaps are usage guidance, permission requirements, and post_id format details, but an agent can reasonably select and invoke this tool with the available information.
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%, and the description does not mention post_id or its format. However, the single parameter is already named post_id and the phrase 'publication Facebook précise' weakly maps to the need for a specific post identifier, so minimal meaning can be inferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Récupère une publication Facebook précise' uses a specific verb and resource: it retrieves one specific Facebook post. This clearly distinguishes it from sibling tools like list_page_posts or get_post_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?
There is no guidance about when to use this tool instead of alternatives such as list_page_posts or get_post_insights. The word 'précise' weakly implies fetching a single post by ID, but no explicit context, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the resource. It does not say whether the call is read-only, what happens when no Threads profile exists, or what auth expectations apply. This adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loads the resource and scope with no filler. It is efficient, though slightly too terse since it omits a verb.
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 zero parameters and an output schema exists, the remaining context needed to invoke it is minimal. The description names the resource and token association, which is sufficient for a simple parameterless getter. The main shortfall is the lack of behavioral or usage context already penalized in other dimensions.
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 tool has zero parameters and schema coverage is effectively complete, so there is no parameter meaning for the description to add. The baseline for a zero-parameter tool is appropriate, and no information gap exists here.
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 identifies the exact resource (Threads profile) and its scope (associated with the current token). Although it lacks an explicit verb, 'Profil' combined with the tool name makes the retrieval intent clear. It is distinguishable from sibling tools like get_threads_insights or token_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?
No guidance is given on when to choose this tool over related sibling tools, and no alternatives or exclusions are mentioned. The phrase 'associé au token' defines which profile is returned but does not help the agent decide between profile, insights, or account 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?
With no annotations, the description must disclose behavioral consequences itself. It reveals a publishing mutation and an external URL dependency, but it omits auth requirements, asynchronous behavior/container status, rate limits, and other side effects relevant to a publish operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with no wasted words. It is under-specified in other dimensions, but as a concise statement of purpose it is 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?
For a five-parameter mutation tool with no annotations and no parameter descriptions, this one-liner is not complete. It does not address the publishing lifecycle hinted by ig_container_status, prerequisites for ig_user_id, or optional field meaning, forcing the agent to rely on sibling names and external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description needs to compensate. It adds meaning only for video_url (public MP4 URL); ig_user_id, caption, cover_url, and share_to_feed rely on their names/defaults 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 states a specific action ('Publie un reel Instagram') and the precise input resource ('une URL vidéo publique (MP4)'), making it clearly distinguishable from sibling tools like ig_publish_reel_from_file or ig_publish_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a public MP4 video URL is available, but it does not explicitly name alternatives or say when not to use this tool. The URL-vs-file distinction among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only states that the audience is created empty and explains the subtype values, but says nothing about required permissions, side effects, idempotency, async behavior, or what the response contains. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action and resource are front-loaded, and the subtype clarification is concise and directly useful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, and no annotations, the description is too thin. It omits the purpose of `customer_file_source`, any prerequisites like ad account permissions, and crucially lacks guidance on how `subtype` interacts with `customer_file_source`. An agent would likely need to guess for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only for `subtype` (CUSTOM vs ENGAGEMENT), which is genuinely helpful. However, it does not explain `customer_file_source`, which is obscure, and only indirectly hints at `name`. Most of the 5 parameters remain undocumented in both schema 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 the action ('Crée' / creates), the resource ('une audience personnalisée vide' / an empty custom audience), and its state ('vide, prête à être alimentée' / empty, ready to be populated). This differentiates it from siblings like create_lookalike_audience and add_users_to_audience, making the tool's specific purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'prête à être alimentée' implies this tool is for creating an empty audience that will later be populated, but it does not explicitly say when to use this over create_lookalike_audience or that add_users_to_audience should follow. Usage is implied rather than clearly stated, and no alternative tools are named or contrasted.
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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'creates' and explains ratio semantics; it does not disclose side effects, async processing time, required permissions, or what happens to the source audience. This is minimal transparency for a creation 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 compact and front-loaded: one clear action sentence followed by a concise explanation of the only non-obvious parameter. Every sentence contributes value without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus output schema is sufficient to attempt invocation: required parameters are visible in the schema and ratio is explained. However, it lacks explicit routing to alternatives, prerequisites for the origin audience, and any note about creation latency or status, so completeness is only 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?
The schema has 0% description coverage, and the description compensates only for the ratio parameter by explaining the 0.01–0.10 range and precision tradeoff. Other parameters (ad_account_id, name, country, origin_audience_id) are left entirely to their names and defaults, though those are reasonably self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it creates a lookalike ('similar') audience from an existing audience. This distinguishes it from the sibling create_custom_audience, which builds a custom audience rather than a lookalike, and the French phrasing maps directly to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of other audience tools like create_custom_audience, list_custom_audiences, or get_custom_audience. The only contextual hint is 'from an existing audience', which implies a prerequisite but does not explain when selecting 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?
With no annotations provided, the description carries the burden of conveying behavior. It states this is a listing operation and enumerates the returned aspects (message, date, link, counters), which implies read-only behavior. It does not describe ordering, pagination, token requirements, or whether unpublished posts are excluded, which would add useful behavioral context beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded French sentence conveys the primary action, the resource scope, and the expected result fields with no unnecessary words. It is concise and fits the tool's simple nature.
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 operation is simple, an output schema exists to describe the return shape, and the one-line description captures the core purpose. However, the lack of any guidance on limit semantics and the absence of explicit alternative-routing make the overall context only partially complete, especially given that annotations and parameter descriptions are absent.
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 must compensate for both parameters. It only implies page_id through 'd'une Page'; the limit parameter is not described at all, including its default behavior or meaning. The description adds little meaning beyond what the bare schema properties already expose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Liste') and resource ('publications récentes d'une Page'), with a parenthetical of fields returned. It clearly identifies a read-only listing operation, and the phrase 'd'une Page' implicitly differentiates it from siblings like get_post or list_pages. However, it does not explicitly distinguish itself from related tools such as get_post, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need recent posts of a Page. It gives no explicit alternatives or exclusions, such as 'for a single post use get_post' or 'for comments use list_post_coments'. The usage context is clear enough, but the agent is left to infer the boundary against 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?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool returns an aggregated audience overview combining countries, cities, and age groups, and that this is a single-call convenience. This is sufficient for a read-only overview tool, though it omits caveats like time range 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 two short, front-loaded sentences: the first states what the tool returns, the second adds the single-call benefit and the use case. There is no filler or repetition, and every sentence contributes useful 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 one-parameter tool with an output schema, the description covers the main output and purpose well. However, it does not clarify the platform context or what kind of page is meant, which matters given siblings for Instagram, Threads, and ad audiences. The page_id parameter semantics are also not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, page_id, and the description never mentions it or explains how to identify the audience target. Schema description coverage is 0%, so the description needed to compensate, but it does not. The phrase 'tes publications' is too vague to map clearly to the required page_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides an audience overview broken down by top countries, cities, and age ranges, and notes that it combines multiple distributions into a single call. This is specific and distinguishes it from single-breakdown sibling tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you want to understand who the publications actually address and when you want multiple breakdowns in one call. It does not explicitly state when not to use it or name alternative tools such as get_page_audience or get_ig_audience_demographics.
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?
No annotations are present, so the description carries the full burden. It reveals some response content but does not explicitly state that the operation is read-only, what permissions are required, or how errors/rate limits behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence that is front-loaded with the verb and resource, then a parenthetical list of deliverables. No filler or duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET with an output schema, the definition covers the core purpose and return highlights. It is incomplete on usage guidance and parameter provenance, but no elaborate behavior needs documenting.
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% and the description adds no meaning to audience_id beyond its name and string type. It does not explain where the ID comes from or how to obtain 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?
Uses a specific verb, 'détaille', names the resource 'audience personnalisée', and enumerates the key returned aspects (taille estimée, statut, source). This clearly distinguishes from siblings that create, delete, or list 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 this is the single-audience detail counterpart to list_custom_audiences, but it never explicitly states when to use this tool versus alternatives. No exclusions or selection criteria 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool publishes a photo; it does not mention permissions, side effects on the Page timeline, draft behavior when 'published' is false, or any other operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler and no redundant restatement of the schema. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish action with an output schema and mostly self-explanatory parameters, the description covers the core operation. However, it omits usage boundaries and behavioral context that would help an agent confidently choose and invoke it, especially given no annotations.
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 must compensate for missing parameter documentation. It clarifies that 'image_url' should be a public URL, but it does not help with 'page_id', 'caption', or 'published' beyond the bare schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Publie'), resource ('une photo sur une Page Facebook'), and source ('depuis une URL publique'). This clearly differentiates it from siblings like publish_page_photo_from_file and publish_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'depuis une URL publique' implies this tool is for publishing an image accessible via URL, which distinguishes it from file-based siblings, but the description does not explicitly state when to use it vs alternatives or mention exclusions. Usage context is implied, not 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?
With no annotations, the description carries the burden of behavioral disclosure. It does explicitly warn that the action is irreversible, which is a critical behavioral trait. However, it does not mention other aspects such as permission requirements, side effects on related data, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that state the core action and the most important warning. Every word earns its place and the key information is 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?
For a single-parameter delete operation, the description is minimally complete: it names the resource, the action, the required parameter, and warns about irreversibility. However, with no annotations or output behavior details, an agent might still lack clarity on what the response indicates or whether any implicit side effects occur.
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 only provides 'audience_id' with type 'string' and no description, so schema description coverage is 0%. The tool description implies that 'audience_id' identifies the custom audience to delete, but it adds no further detail about format, source, or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Supprime') and resource ('audience personnalisée'), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like get_custom_audience or remove_users_from_audience by clearly targeting deletion of the entire 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. It does not mention prerequisites, conditions under which deletion is appropriate, or caution against using it when only removing users is needed.
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?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses the three checks performed (token present, writes enabled, identity), which is useful and suggests a read-only diagnostic. However, it does not clarify whether this performs live API calls, whether it can fail partially, or what side effects if any exist.
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 compact sentence with no filler. It front-loads the tool's purpose and enumerates the exact diagnostic dimensions, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description is largely complete: it names the three key areas the diagnostic checks. A minor gap is that it does not state whether the check is performed live against an external API or purely reading local configuration, but this is not critical for a health-check tool with a rich 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 tool has zero parameters and schema coverage is 100% by vacuity, so there is no missing parameter documentation. Per the rubric, zero-parameter tools get a baseline of 4, and the description adds relevant context about what the health check inspects.
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 this is a configuration diagnostic that verifies token presence, write permissions, and identity. This is a clear and specific purpose that goes beyond the tool name, and it helps differentiate 'health_check' from focused tools like token_info or token_permissions by positioning it as a combined readiness check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as token_info, token_permissions, or account_summary. The word 'Diagnostic' implies a preflight or setup-verification use case, but the description does not state conditions, exclusions, or preferred contexts.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core action and media types but does not mention required permissions, side effects (creating a public post), rate limits, or what happens on failure. This is a thin profile 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?
A single, front-loaded sentence conveys the verb, platform, and content options with no wasted words. It is easily scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and has an output schema, so return values are already covered. However, for a mutation tool it lacks context on prerequisites, permission requirements, and how it differs from the many other publish tools, which an agent would need to call it confidently.
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 0%, so the description must compensate. It partially does so by indicating the content combinations: text alone or image+text, which maps to the text and image_url parameters. It does not explain URL formats or constraints, but it does clarify that image is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Publie une publication sur Threads' (publishes a publication on Threads), and specifies the supported content shapes (text, or image + text). This clearly distinguishes it from sibling publish tools aimed at Facebook Pages or Instagram.
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 naming the target platform 'Threads', which tells an agent when to choose it over Instagram/Facebook publish tools. However, it gives no explicit alternatives, exclusions, or conditions, leaving the routing partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It communicates that the tool mutates the audience by removing people and adds an important operational detail: hashing rules match `add_users_to_audience`. However, it does not disclose permissions, reversibility, failure behavior, or what happens when no users match, leaving some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. The core operation is front-loaded, and the hashing-rule reference is a useful, compact addition.
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 is not sufficiently complete for a mutation tool with three required parameters and no annotations. It lacks parameter-level guidance and relies on external knowledge via `add_users_to_audience`. The presence of an output schema reduces the need to describe return values, but the input contract remains underspecified.
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%, and the description does not explain the meaning of `schema`, `values`, or `audience_id`. The reference to hashing rules hints at how values should be prepared, but the crucial `schema` parameter is left unexplained, making it hard for an agent to construct a valid invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retire des personnes') and the resource ('audience personnalisée'), making the tool's purpose unambiguous. The operation is naturally distinguished from sibling tools like `add_users_to_audience` and `delete_custom_audience`, even if not explicitly contrasted.
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 this should be used: to remove users from a custom audience, likely as the inverse of `add_users_to_audience`. However, it does not explicitly state when to prefer this over alternatives or provide exclusion criteria, so the guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. 'Informations sur le token' implies a read-only query and the listed fields clarify what will be inspected. However, it does not explicitly state side effects, authentication expectations, or that no data is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the resource and immediately lists the key output categories. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool with an output schema, the description is largely complete: it names the resource and what information is available. The main missing piece is clarifying the relationship to token_permissions, but that gap is primarily a usage-guidance issue rather than a completeness issue for invoking the 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 tool has zero parameters, so parameter explanations are unnecessary. The description usefully enumerates the token attributes returned, and the output schema handles structural details. This matches the baseline for a no-parameter tool.
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 resource ('le token') and the specific information returned (type, expiration, application, scopes). It lacks an explicit verb like 'get' or 'retrieve', and it does not explicitly distinguish itself from the sibling 'token_permissions', so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose token_info over alternatives. In particular, the sibling tool token_permissions likely overlaps on scopes/permissions, but the description does not clarify the difference or provide any selection 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?
With no annotations, the description carries the transparency burden. It conveys a non-mutating ranking behavior and enumerates acceptable metrics, but it does not disclose whether only top-N posts are returned, any time-window constraints, required permissions, or how ties or missing metrics are handled.
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 short, front-loaded sentences: the first states the operation and the second clarifies the key parameter. There is no filler 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?
An output schema exists, so return-value documentation is not required. The description still leaves gaps that matter for correct use: no explicit time window, no note that only the top N posts are returned, and no guidance on account scope beyond the implied ig_user_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds important value for sort_by by listing the allowed values, which the schema does not provide as an enum. However, it says nothing about ig_user_id or limit, leaving those to be inferred from their names and schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Classe') and a clear resource ('publications Instagram'), and states the ranking criterion ('par performance'). It is distinguishable from siblings like list_ig_media or get_ig_media_insights, though it does not explicitly name a sibling to differentiate against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: rank Instagram posts by a selected performance metric. The listed sort_by values give concrete guidance, but the description never says when to prefer this tool over alternatives such as get_ig_media_insights or get_ig_account_insights, nor does it state 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?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the key trait that the action is irreversible ('Action irréversible'), which is important for a destructive operation. It does not mention permissions, rate limits, or cascading effects, so coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no extraneous content. It front-loads the core action and then adds the critical irreversibility warning. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with an output schema present, the description provides the essential action and a caution about irreversibility. It does not mention permissions or which specific comment types are eligible, but the core context is adequate. Missing usage and parameter guidance lower the completeness score.
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% and the description does not mention comment_id at all, so it adds no parameter-level meaning beyond the schema. The parameter name is self-explanatory, but the description fails to compensate for the low schema coverage, e.g., by noting that comment_id is the ID of the comment to be deleted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Supprime un commentaire Instagram' (deletes an Instagram comment). It clearly distinguishes this from sibling tools like list_ig_comments or ig_reply_to_comment, and from delete_page_post, by specifying the resource as an 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever an Instagram comment needs to be deleted. However, it does not explicitly state exclusions, prerequisites, or alternatives, leaving the agent to infer usage from the verb-resource pair.
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?
With no annotations, the description carries the full burden. The qualifier 'accessibles' discloses a genuine behavioral trait — the list is scoped by token access, so accounts may be omitted — and 'Liste' implies a read-only operation. But it does not state what permissions are required, whether results are paginated, or any error/edge behavior, leaving meaningful gaps for an unannotated 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?
A single sentence with zero waste: verb first, then resource, then purpose. Every word earns its place and the purpose clause adds value without bloat.
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 zero-param list tool with an output schema, the description covers the what and a hint of the why, and the output schema handles return format. However, it omits sibling routing and auth/permission expectations, and the 'audiences' context is vague about which audience-related workflow this feeds into. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%, so the schema carries all param information and nothing is missing. With 0 params the baseline is 4; the description correctly avoids inventing parameter detail that doesn't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Liste') and resource ('comptes publicitaires') and adds a purpose ('nécessaire aux audiences'). It clearly states what the tool does and orients an agent toward the ad-account domain, but it does not explicitly distinguish itself from sibling audience-related tools such as list_custom_audiences or get_page_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '(nécessaire aux audiences)' implies the tool is a prerequisite when working with audiences, providing some usage context. However, it names no alternatives, states no when-not-to-use conditions, and leaves the agent to infer the difference between ad accounts, pages, and custom audiences from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only restates the core operation and adds no information about pagination, ordering, or whether only top-level comments are returned. The term 'Liste' implies a read-only operation by convention, but no explicit behavioral traits 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 a single short French sentence with no fluff. It is front-loaded and every word contributes to the meaning, making it optimally concise for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but the description lacks guidance on pagination/limit behavior and does not explicitly contrast with list_ig_comments. It is adequate for a basic call, but an agent would benefit from knowing whether the limit is optional or how many comments are returned by default.
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%, and the description does not compensate by explaining either paramener. While 'post_id' and 'limit' are self-evident, the description never clarifies that 'limit' defaults to 50 or how it affects the result. The description adds no meaning beyond the param names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Liste') and resource ('les commentaires d'une publication Facebook'), explicitly naming Facebook to differentiate from the Instagram sibling. The tool name and description together unambiguously identify the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly specifies the context: Facebook post comments. It does not explicitly name an alternative or exclusionary condition, but the Facebook-scoping is enough to guide an agent away from the Instagram comment tool. A true 5 would mention 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?
With no annotations, the description carries the behavioral burden. It correctly discloses that this is a raw GET call, implying read-only behavior and no abstraction over response formatting. However, it does not mention authentication, error behavior, pagination, or how the raw response is returned, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence for purpose and one example. It front-loads the core function and includes a concrete usage sample without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% parameter coverage, and only an output schema as a fallback, the description is not complete enough for reliable invocation beyond simple cases. The params object, path construction rules, and failure behavior are missing, leaving significant details to inference.
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 must explain the parameters. The example clarifies path and fields semantics ('me/accounts', 'id,name'), but the params object is entirely unexplained, and path formatting rules (e.g., leading slashes, versioning) are not addressed. Two of three parameters are illustrated; the third is silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—raw GET on the Graph API—and positions itself as an escape hatch for uncovered endpoints. This clearly distinguishes graph_get from the many sibling tools that wrap specific endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'échappatoire pour un endpoint non couvert' tells the agent to use this tool when no dedicated sibling covers the needed endpoint. It is implicit rather than explicit, and it does not name alternatives, but the usage 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?
With no annotations provided, the description carries the full burden of indicating behavior. 'Vérifie l'état' conveys a read-only status-check operation and the qualifier 'en cours de traitement' narrows the scope, but the description does not disclose possible status values, polling behavior, or how errors like expired or failed containers are surfaced.
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 short sentence that conveys the core operation without waste. It is appropriately sized for a simple status-check tool and front-loads the key verb and resource.
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?
Since an output schema exists, the description does not need to detail return values. Still, the description omits the relationship to the IG publishing tools and the source of container_id, which would help an agent invoke this tool correctly in a real workflow. The simple interface and output schema prevent this from being a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by identifying container_id as an Instagram container in processing, but it does not explain where this ID comes from or the expected format, which would be important for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('vérifie') and resource ('un conteneur Instagram en cours de traitement'), clearly stating that this tool checks the status of an Instagram publishing container. This differentiates it from sibling publish and insight tools, since no other sibling specifically targets container status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'en cours de traitement' implies the tool is used to check containers that are currently being processed, which gives some contextual guidance. However, it does not explicitly say when to use this tool versus alternatives, nor does it mention that it should typically be called after ig_publish_* operations.
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?
No annotations exist, so the description carries the burden. It communicates the mutating behavior ('Publie') and adds the public-URL/JPEG constraint, which is useful context. However, it does not cover follow-up behavior such as container status checks or required publishing permissions, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds meaningful information about the action, target, and source 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?
Although an output schema exists, this is a mutating publishing tool with no annotations and a very sparse description. It omits prerequisites such as the Instagram account/linking requirement and publishing permissions, and does not explain how it differs from the file-upload sibling, so it is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It clarifies image_url as a public URL and JPEG source, but says nothing about ig_user_id or the optional caption, leaving important semantics to bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Publie') and resource ('une image sur Instagram'), and adds the method 'depuis une URL publique (JPEG)', which clearly distinguishes it from siblings like ig_publish_image_from_file and ig_publish_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?
It gives a clear usage context: use this tool when the image is available at a public URL and in JPEG format. It does not explicitly name alternatives or state when not to use it, but the source condition is enough to inform 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?
No annotations are provided, so the description carries the full behavioral burden. It discloses what the tool covers (reach, engagement, followers; Facebook + Instagram; N-day period) and implies a read-only summary operation. However, it does not mention required permissions, exact time-window semantics, or aggregation behavior, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, dense sentences with no filler. The core behavior is front-loaded, and the usage guidance is separated cleanly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter summary tool with an output schema available, this is largely complete. It states the metric categories, time scope, and recommended usage. The main gap is not explaining what page_id must refer to, but the tool name and cross-platform description make that reasonably inferable.
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 0%, so the description must compensate. It clarifies that the days parameter is an N-day window via 'sur N jours', but page_id is left implicit. Both parameter names are reasonably self-explanatory, so this is adequate though not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific deliverable: a synthesis of Facebook and Instagram over N days with scope, engagement, and follower metrics. It also positions itself as a recommended entry point for a quick overview, which helps distinguish it from the more granular sibling insights tools. A verb like 'returns' would be stronger, but noun 'Synthèse' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Point d'entré recommandé pour un bilan rapide' clearly communicates when to use this tool: as the first stop for a high-level cross-platform summary. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to route appropriately.
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?
With no annotations, the description carries the full burden. It indicates a read-style operation and names returned fields, but it does not disclose permission requirements, error behavior, or whether the linked Instagram account lookup requires extra scopes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. The action, resource, and key data points are all included without repeating the input schema.
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 a single required parameter, no nested objects, and an output schema that already covers return shape, the description is nearly sufficient. It lacks only explicit alternative-routing guidance, but an agent can use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain page_id format or meaning. However, the single parameter is self-naming, and the description clarifies that the Page being detailed is identified by this ID, providing minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Détaille') and resource ('une Page Facebook') and lists concrete fields — abonnés, description, compte Instagram lié — which distinguish it clearly from sibling tools like get_page_insights or get_page_audience.
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: call it when you need the main profile details of a specific Facebook Page. There is no explicit when-to-use guidance and no mention of alternatives such as get_page_insights or list_pages.
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?
No annotations are provided, so the description carries the burden. The verb 'Liste' implies a read-only retrieval operation, and the ad_account_id format is a useful operational detail. However, it does not disclose pagination, ordering, limit behavior, or error scenarios, though an output schema is 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?
The description is two short sentences with no filler. The first sentence clearly states what the tool does, and the second provides the essential ID format. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although simple, the definition is mostly complete: it identifies the target ad account, provides the required format, and the output schema covers return structure. It lacks explicit alternative tool guidance and pagination/limit semantics, but these are minor for a straightforward list endpoint.
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 meaningful format guidance for ad_account_id ('act_123456789'), which is not present in the schema. It does not explain the limit parameter, but the name and default of 50 make its basic purpose understandable. With 0% schema coverage, this is partial but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Liste') and the resource ('audiences personnalisées') scoped to an advertising account. This distinguishes it from singular/related tools like get_custom_audience, create_custom_audience, and delete_custom_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: list custom audiences for a given ad account. However, there is no explicit guidance on when to prefer this over get_custom_audience or how it differs from sibling tools, so the agent must infer the routing from names 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?
With no annotations, the description carries the behavioral burden and does add a useful detail: each file is uploaded unpublished and then attached to the post. However, it does not disclose side effects, required permissions, failure behavior, or limitations such as file type or size 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 compact, front-loaded with the primary action, and every sentence adds value. The sibling reference and upload workflow detail are included without fluff or repetition of schema fields.
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 enough to understand the tool's purpose and how it differs from its sibling, and the presence of an output schema covers return values. However, missing parameter semantics and the absence of annotations leave gaps around prerequisites, file requirements, and mutation side effects, so it is only minimally complete for a publishing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only clarifies that the carousel is built from local files and that the sibling uses public URLs. It does not explain what `page_id`, `file_paths`, or `message` should contain beyond their self-evident titles, nor does it specify path format, accepted file types, or cardinality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Publie un carrousel Facebook') and clarifies the mode as local file upload. It also explicitly contrasts with `publish_page_carousel`, which uses public URLs, so an agent can distinguish it from the most similar sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for publishing carousels from local files via direct upload, as an alternative to `publish_page_carousel` which requires public URLs. It does not explicitly state 'use this when...' or list exclusions, but the context is strong enough for an agent to select the right variant.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation but does not explicitly state safety, authentication requirements, or rate-limit implications. The description is truthful but minimal, offering no details about side effects or prerequisites beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. Every word contributes to meaning, 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 the tool's simplicity (no parameters) and the presence of an output schema, the description adequately covers what the tool does and what it returns. It does not mention edge cases or prerequisites, but for a simple listing operation, the provided detail is sufficient for an agent to understand the tool's role.
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 tool has zero parameters, and the schema is empty. Per the rule, a zero-parameter tool receives a baseline of 4 since there is nothing for the description to elaborate on. The description does not need to compensate for any parameter documentation 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 a specific verb ('Liste' = list), a specific resource (permissions granted to the token), and includes the result characteristic (their status). This distinguishes it from sibling tools like token_info, which likely focuses on token metadata rather than permissions.
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 token_info or other permission-related tools. It simply states what it does without any context about scenarios like checking access before a write operation or verifying token scope.
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?
With no annotations, the description carries the behavioral burden, and it does so well by disclosing the critical privacy behavior: values are normalized and hashed with SHA-256 locally, and Meta never receives plaintext data. It does not mention idempotency, error behavior, or rate limits, but the most consequential side effect and privacy guarantee are explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: purpose first, then schema hint and hashing behavior, then the GDPR guardrail. Every sentence earns its place, and there is no redundant repetition of the input schema.
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 3-parameter mutation tool with an output schema present, this description provides enough to invoke it correctly: the audience to modify, the accepted schema identifiers, and the data-handling behavior. Minor gaps, such as exact formatting rules for phone/email values and a direct statement that `values` must match `schema`, prevent a perfect score.
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 0%, so the description must compensate. It usefully enumerates the allowed `schema` values (EMAIL, PHONE, FN, LN) and implies what `values` should contain by stating those values are normalized and hashed. However, it does not describe `audience_id` or explicitly state that each value in the array must correspond to the chosen schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Ajoute des personnes à une audience personnalisée.' This clearly names the operation and distinguishes it from sibling tools like create_custom_audience, remove_users_from_audience, and audience lookup 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 intended use case is clear from the purpose statement, and the GDPR note adds a legal precondition. However, the description does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving the agent to infer comparisons from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It does so by stating the output shape: subscriber count per segment, sorted descending. It also implicitly identifies this as a read-only operation despite lacking an explicit annotation. It could add context about access-token requirements or pagination, but for a simple audience profile tool, the return behavior is clearly covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one purpose sentence, one parameter sentence, and one result sentence. Every sentence earns its place, and the most important information is front-loaded. The use of backticks for 'breakdown' is clear and low-noise.
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 only two parameters, an output schema present, and a simple read-only audience-profile operation, the description is complete enough. It explains the resource, the allowed breakdowns, the return metric, and the ordering. The output schema removes the need to document the exact return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains the 'breakdown' parameter by listing its allowed values: country, city, age_gender, or locale. The 'page_id' parameter is not explicitely described, but the opening sentence establishes it as a Facebook Page, and the schema's property title 'Page Id' provides adequate basic meaning. This is sufficient compensation for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Facebook Page subscriber audience profile. It goes beyond the tool name by specifying that it returns subscriber counts broken down by country, city, age_gender, or locale, and explicitly says results are sorted from largest to smallest. It differentiates at least from Instagram-audince tools by saying 'Page Facebook', though it doesn't explicitely distinguish from audience_overview or 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 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 Page audience-segment analysis because it states the breakdown dimensions and the returned metric ('nombre d'abonnés'). However, it provides no explicit when-to-use guidance or exclusions relative to siblings such as audience_overview, get_page_insights, or get_ig_audience_demographics. The agent must infer suitability from the breakdown options.
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?
With no annotations, the description carries the behavioral disclosure burden and does so well: it explains the two-step process of uploading each file as an unpublished Facebook Page media object via multipart upload, then reusing the CDN URL to build the carousel. This adds meaningful process transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded: the main purpose appears in the first sentence, followed by a concise explanation of the underlying mechanism. The additional detail about not needing external hosting earns its place and aids selection.
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 essential workflow and key operational detail, and an output schema exists so return values need no explanation. However, it omits prerequisites such as required Facebook/Instagram permissions, token scopes, or what happens if the linked page is not properly configured, which would matter for an agent invoking this publishing 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 0%, so the description must compensate. It clarifies that file_paths are local files and page_id is the linked Facebook Page used for the upload. However, it does not explain ig_user_id or caption beyond what their names imply, leaving part of the parameter semantics to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Publie un carrousel Instagram') with a concrete resource scope ('2 à 10 images', 'depuis des fichiers locaux'). It clearly distinguishes itself from URL-based or page-only publish tools by emphasizing the local-file workflow and the Facebook Page upload mechanism.
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 conveys when to use this tool: when publishing Instagram carousels from local files, avoiding the need to host images elsewhere. It does not explicitly name sibling alternatives like ig_publish_carousel, but the context makes the intended use case clear.
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?
With no annotations provided, the description carries the full behavioral disclosure burden. It reveals a non-obvious side effect: an intermediate unpublished video is uploaded to the Facebook Page and then deleted unless keep_fb_video=True. It also clarifies that no external hosting is needed. This goes well beyond a generic 'publish' statement.
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: the first sentence states the purpose, the second adds essential mechanism details. No redundant or filler 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 workflow and primary side effect are explained, but for a 7-parameter tool with no annotations and no schema descriptions, several parameters remain undefined and usage boundaries with sibling tools are not clarified. Adequate but 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 description coverage is 0%, so the description must compensate. It explains the roles of page_id, file_path, and keep_fb_video, but leaves ig_user_id, caption, cover_url, and share_to_feed undiscussed. This is partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an Instagram Reel from a local MP4 video file, with a specific verb and resource. It also outlines the distinctive two-step process (upload to linked Facebook Page, then ingest to Instagram), which differentiates it from siblings like ig_publish_reel and publish_page_video_from_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a local video file and want to publish a Reel without external hosting. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the boundary with ig_publish_reel or page video publishing 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?
With no annotations, the description carries the full behavioral disclosure burden. It does well by explaining the two-step process: the file is uploaded unpublished to the linked Facebook Page, producing a public CDN URL that is then reused for the Instagram publication. This reveals side effects beyond the obvious 'publish' action, though it does not mention permissions, cleanup of the unpublished Page media, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no filler. The main action is front-loaded, and the second sentence provides necessary procedural detail that would otherwise be missing. Every clause 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?
The description is substantively complete for an agent to invoke the tool: it identifies the action, the input is a local file, the role of page_id, and the internal upload-to-CDN-to-publish flow. The presence of an output schema means return-value documentation is not required. Remaining gaps are permission/error context and explicit routing to sibling tools, but these are not critical for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds real meaning for page_id ('sur la Page Facebook liée') and file_path ('depuis un fichier local', uploaded via multipart), but it does not clarify ig_user_id or caption. Those are somewhat self-explanatory from their names and types, but the description is still incomplete for all four 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 action: 'Publie une image Instagram depuis un fichier local' — publish an Instagram image from a local file. It also distinguishes this tool from siblings like ig_publish_image (which likely uses a hosted URL), ig_publish_carousel_from_files (carousel), and publish_page_photo_from_file (Facebook page photo) by specifying Instagram, single image, and local file.
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 appropriate use case: use this when you have a local image file and want to publish it to Instagram. The second sentence clarifies that no external hosting is needed because the file is uploaded to the linked Facebook Page first. It does not explicitly name alternatives like ig_publish_image, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Liste' clearly signals a read-only listing operation, and the description reveals that result entries include id, nom, and abonnés. It does not mention pagination or rate limits, but for a zero-parameter read tool the essential behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in French with no filler and the key scope information ('accessible avec ce token') and output fields are front-loaded. Every word contributes to the definition.
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 sufficiently complete for a zero-parameter read-only listing tool: it says what is listed, under what token scope, and what fields are returned. The output schema likely covers the exact return shape, so explained return details are not required; only pagination or limit behavior could be additionally useful but is not a major 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 input schema is empty, so there are no parameter semantics to document. The description adds no parameter-level details, but the baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Liste') and a specific resource ('Pages Facebook accessibles avec ce token'), and states the returned fields (id, nom, abonnés). This clearly distinguishes it from sibling tools like get_page or list_page_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 phrase 'accessibles avec ce token' implies the tool should be used when the agent needs the set of Facebook Pages available to the current token. However, it does not explicitly state when to prefer this over alternatives such as get_page or list_page_posts.
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 explains the core publish action and the scheduling behavior with time constraints. However, since no annotations are present, it does not disclose required permissions, side effects, or what happens when published defaults to true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences with the action front-loaded and scheduling details neatly appended. No filler or redundant repetition of schema 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?
With an output schema present and a moderate 5-parameter surface, the description covers the main action and the non-obvious scheduling behavior. It omits permission requirements, but the tool is otherwise adequately scoped for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining the important published/scheduled_publish_time relationship and the 10-minute-to-6-month Unix timestamp range. The other parameters are self-explanatory from names and usage 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 is specific: 'Publie un message texte (ou avec lien) sur une Page Facebook' identifies the verb, resource, and target. It clearly distinguishes this tool from photo, carousel, and video publishing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear scheduling guidance with published and scheduled_publish_time. It does not explicitly name alternatives or when not to use them, but the text/link scope makes the intended use reasonably 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?
With no annotations, the description carries the full safety/behavior burden. It adds real behavioral detail: the upload goes directly to {page_id}/videos, unpublished videos don't appear in the feed, and Meta executes scheduled publishing. However, it omits auth/permission prerequisites, upload size/format limits, and side effects of the unpublished draft flow, which is material for a mutation with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is compact and front-loaded: core purpose in the first sentence, then endpoint and behavior, then optional-parameter semantics. No sentence is wasted or redundant.
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 file-upload publish tool, it covers the key invocation details, optional parameters, and scheduling constraints; the output schema exists so return format need not be restated. The main gap is environment-level context such as required permissions or upload constraints, but the core usage story is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining description as caption, published=False semantics, and scheduled_publish_time as Unix UTC with a 10-minute-to-6-month window. The required page_id and file_path are only named, but those are self-evident from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: publishing a video to a Facebook Page from a local file. It further distinguishes itself from photo/carousel/Instagram siblings via 'vidéo' + 'Page Facebook' + 'fichier local'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete invocation contexts: direct multipart upload, published=False for pre-publication or feeding an Instagram Reel, and scheduled_publish_time for future publishing. It does not explicitly name sibling alternatives or exclusion criteria, so it falls just short of a full routing guide.
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_Business_MCP MCP server](https://glama.ai/mcp/servers/mathieubernardi/Meta_Business_MCP/badges/card.svg)](https://glama.ai/mcp/servers/mathieubernardi/Meta_Business_MCP)

Score Badge

Copy to your README.md:

[![Meta_Business_MCP MCP server](https://glama.ai/mcp/servers/mathieubernardi/Meta_Business_MCP/badges/score.svg)](https://glama.ai/mcp/servers/mathieubernardi/Meta_Business_MCP)

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/mathieubernardi/Meta_Business_MCP'

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