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 action and source but does not mention permissions, that the post is published immediately, failure conditions, URL reachability requirements, or any side effects beyond the obvious publish action.

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

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

One direct sentence, front-loaded with the action and target, with no filler or repetition of schema details.

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

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

The tool is simple and all parameters are documented, but with no annotations or output schema, the description does not explain return values, required page context/authentication, or whether the post is immediate rather than scheduled. Basic but not fully self-sufficient.

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

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

Schema coverage is 100%, so the schema already documents image_url and caption. The description adds only the notion that the image is sourced from a URL, which mirrors image_url's schema description without adding new meaning.

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

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

The description uses a specific verb ('Publish'), a clear resource ('photo post'), and the required source ('image URL'), which is enough to distinguish it from sibling tools like fb_create_text_post and fb_create_video_post.

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

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

The wording implies this is the correct tool when publishing a photo from a URL, but it never explicitly contrasts it with fb_create_text_post, fb_create_video_post, or fb_schedule_post. An agent must infer usage from the tool name and sibling names.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the core effect (a post is published to the feed) but omits important contextual traits such as public visibility, irreversibility, required Page permissions, rate limits, or the kind of response returned. This is a significant gap for a mutating tool.

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

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

A single sentence that leads with the action, specifies the object, includes the optional-link qualifier, and names the destination. Every phrase earns its place; there is no redundancy or filler.

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

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

For a two-parameter tool, the core calling context is present and the schema covers parameters well. However, with no annotations and no output schema, the description leaves behavioral consequences and sibling-tool routing to inference. It is adequate but not fully complete for safe, correct selection.

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

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

The input schema already documents both parameters completely, including the required `message` and the optional URI-format `link`. The description's 'optionally with a link' restates schema information without adding new semantic detail, so it stays at the baseline expected for full schema coverage.

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

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

The description states a specific verb ('Publish'), a specific resource ('a text post'), and a clear destination ('the connected Facebook Page's feed'). The qualifier 'text post' distinguishes it from photo/video posting siblings, and 'publish' implies immediate posting rather than scheduling.

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

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

The context is clear: use this to publish text posts to a Facebook Page. However, the description does not explicitly guide an agent to fb_schedule_post for scheduled posts or to fb_create_photo_post/fb_create_video_post for media posts. Usage guidance is implied by the noun 'text post' rather than stated as alternative routing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the mutation ('upload and publish') without covering prerequisites, permissions, post visibility, processing delays, supported video formats, or failure behavior. It is not misleading, but it is nearly silent on side effects.

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

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

The description is a single efficient sentence with the core action front-loaded and no filler. It earns its place, although it sacrifices behavioral detail for brevity.

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

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

For a mutating tool with no annotations and no output schema, this description is too thin to fully support correct invocation. It omits expected return value, confirmation behavior, whether the post is immediately published, and any constraints on the video URL. It is minimally adequate for identifying the tool but not for confident execution.

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

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

The input schema covers both parameters at 100%, so the schema already documents them. The description adds minimal semantic context by indicating the video comes from a URL, but it does not provide any extra format, constraint, or usage detail beyond the schema.

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

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

The description names a specific verb ('Upload and publish'), a clear resource ('video to the Facebook Page'), and the input source ('video URL'). It clearly distinguishes this tool from the sibling text/photo post tools by media type, so an agent can tell what it does at a glance.

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

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

Usage is implied by the description: use it when posting a video from a URL. However, it gives no explicit guidance about when not to use it, no mention of alternatives like fb_schedule_post or fb_create_photo_post, and no clarification of how it differs from the Instagram video tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly reveals the destructive and irreversible nature of the operation, which is the most important behavioral trait for an AI agent to understand before invoking the tool.

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

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

Two concise sentences with the key action and the critical irreversibility warning front-loaded. Every word adds value there is no redundant or unclear content.

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

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

For a one-parameter destructive tool, the description includes the essential context: the action, the target platform/resource, and permanence. It could mention permissions or return behavior, but those are less critical given the simple schema and clear irreversible warning.

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

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

Schema description coverage is 0%, so the description must compensate, but it adds no detail about what exactly post_id refers to or its expected format. The property name and required marker in the schema carry almost all the meaning.

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

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

The description states a specific verb and resource: 'Permanently delete a post from the Facebook Page.' It clearly identifies the tool's function and differentiates it from sibling creation, listing, and retrieval tools.

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

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

The intended use is implied through 'delete a post', and the warning 'cannot be undone' conveys caution. However, it does not explicitly state when to prefer this over alternatives or mention exclusions, even though no sibling provides deletion.

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

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

There are no annotations, so the description carries the burden. 'List' signals a read-only operation, which is transparent. However, it does not disclose pagination behavior, ordering, whether replies are included, or any other behavioral traits an agent might need to know.

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

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

A single sentence that is front-loaded and contains no filler. It gets straight to the verb and resource while remaining appropriately sized for a simple read-only tool.

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

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

For a two-parameter list tool this is minimally usable: the agent can infer it needs a post_id and returns comments. Yet with no output schema and no annotations, the lack of details about limit semantics and the exact return shape leaves noticeable gaps.

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

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

Schema description coverage is 0%, and the description adds little parameter meaning. It maps 'post' to the required post_id concept, but the limit parameter is entirely undocumented in the description and the schema only gives it a type and default.

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

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

The description uses a specific verb ('List') and resource ('comments on a Facebook post'), making the tool's primary function immediately clear. It also disambiguates from sibling tools like ig_get_comments by specifying 'Facebook', and from fb_get_post by indicating comments rather than the post itself.

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

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

The description implies the tool should be used when a Facebook post's comments are needed, but it gives no explicit guidance about when to use this over alternatives, no exclusions, and no mention of related tools such as fb_get_post or fb_reply_to_comment.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it only states that the tool gets metrics. It does not disclose how the target page is identified given that the input schema has no page_id parameter, nor what defaults apply when since/until are omitted, nor any limitations on metric availability.

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

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

The description is a single front-loaded sentence with no filler, and the examples reinforce the most important parameter. It is concise, though slightly too terse to carry the full selection and usage context an agent needs.

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

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

For an insights tool with no annotations and no output schema, the description is too thin. It does not explain that the tool operates on an authenticated Page, what date defaults exist, or how this differs from graph_api_request or ig_get_account_insights, leaving the agent with incomplete context for a correct call.

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

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

The description adds concrete example metric values that align with the metrics parameter default, which is helpful. However, since and until already have schema descriptions, and period is an explicit enum, the description adds only marginal semantic value beyond the schema.

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

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

The description uses a specific verb ('Get') and names the exact resource ('Facebook Page insight metrics') with representative metric names. This clearly distinguishes it from sibling tools like ig_get_account_insights, fb_list_posts, or graph_api_request.

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

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

The description provides no guidance on when to use this tool versus alternatives such as graph_api_request or ig_get_account_insights. There are no explicit contexts, exclusions, or sibling references, so the agent must infer the appropriate choice 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.

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 states that the tool retrieves post details, but it does not mention what fields or structure will be returned, whether authorization is required, how errors are handled, or any side effects. For a read operation this is minimal but still leaves the agent guessing about observable behavior.

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

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

The description is a single clear sentence with no filler words. It conveys the core operation and selection criterion immediately, earning its place without wasted content.

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

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

For a one-parameter retrieval tool, the description is minimally adequate: the schema already marks post_id as required, and the description identifies the operation. However, with no output schema and no annotations, the absence of any mention of return shape or failure behavior makes the definition only partially complete for an agent deciding whether and how to invoke it.

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

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

Schema description coverage is 0%, and the description only repeats the concept of 'by ID' without explaining the expected format, source, or constraints of post_id. The parameter name itself already conveys most of the meaning, so the description adds almost no semantic value beyond the schema.

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

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

The description uses a specific verb ('Get') and names the exact resource ('details of a single Facebook post') selected by ID. This clearly distinguishes the tool from siblings like fb_list_posts, fb_create_text_post, and fb_delete_post without requiring schema inspection.

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

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

The description implies the tool is for retrieving one specific post when you already have its post_id, which is clear enough from the phrase 'by ID.' However, it does not explicitly contrast with alternatives such as fb_list_posts for fetching multiple posts or fb_get_comments for related data, so usage guidance is mostly implicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List recent posts' and adds no detail about pagination, return format, ordering guarantees, or whether unpublished/scheduled posts are included. The behavior is not misleading, but it is minimally disclosed beyond the tool's name.

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

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

The description is one concise sentence with no filler. It front-loads the key facts: the operation, the resource, and the scope.

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

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

For a simple optional-limit list operation, the description is mostly adequate, but with no output schema it does not explain the return shape or pagination behavior. Adding a note about what the returned post objects contain or how 'recent' is determined would make it complete.

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

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

Schema description coverage is 0%, and the description does not mention the only parameter, `limit`. The schema's default/min/max constraints and the parameter name provide enough to invoke the tool, but the description itself adds no semantic value for the parameter.

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

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

The description clearly states a specific verb ('List'), resource ('posts'), and scope ('from the Facebook Page'). It distinguishes this tool from siblings like fb_get_post (single post) and creation/deletion tools, so an agent can tell it apart.

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

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

The description implies this is for listing recent page posts, but it does not explicitly state when to use it versus fb_get_post or the creation tools. The usage context is inferable from the description and sibling names, but no explicit when-not or alternatives are given.

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

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

No annotations are present, so the description carries full behavioral burden. It indicates a write-like action but does not disclose whether the reply is published immediately, whether special permissions are required, whether it can reply to any comment or only those on the page's posts, or what the response looks like. This is a significant gap for a mutation tool.

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

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

The description is a single sentence with no filler or redundant phrasing. It is front-loaded and appropriately sized for a simple tool, though it leaves out semantic detail that other dimensions penalize.

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

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

This is a mutation tool with no annotations, no output schema, and zero schema description coverage, so the description needed to provide substantially more context. It lacks parameter semantics, usage guidance, permission requirements, and any sense of side effects, making it incomplete for an agent that needs to invoke it reliably.

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

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

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names comment_id and message. It does not clarify that comment_id identifies the Facebook comment to reply to, that message is the reply text, or any constraints such as length limits. The description fails to compensate for the absent schema documentation.

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

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

The description states a specific action (reply) on a specific resource (a comment on a Facebook post), which is clear and minimally distinguishes it from sibling tools like ig_reply_to_comment. It could go further by indicating whether this creates a new comment or sends a direct reply, but the basic purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as fb_get_comments, fb_create_text_post, or ig_reply_to_comment. The description only implies usage through the verb 'reply' and the resource 'Facebook post', but no explicit when-to-use or when-not-to-use conditions are provided.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully reveals the scheduling behavior and time restriction, but it does not mention expected results, side effects, prerequisites, or what happens if the publish_at constraint is violated.

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

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

A single, front-loaded sentence conveys the core action, resource, and key time constraint with no redundancy. Every element earns its place.

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

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

The description is adequate for a simple scheduling operation, but it lacks explicit routing away from immediate post creation and does not mention return values or failure modes. Given no output schema and no annotations, a slightly more complete description would include a sibling reference or expected result.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by specifying the exact publish_at validity range ('10 minutes to 6 months out'), which the schema does not state. It does not add further detail about link, but the schema already documents all parameters adequately.

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

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

The description uses a specific verb ('Schedule') and resource ('a text post... on the Facebook Page'), with a clear temporal scope ('future time', '10 minutes to 6 months out'). This distinguishes it from immediate publishing siblings like fb_create_text_post.

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

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

The description implies scheduling use cases by specifying a future-time window, but it does not explicitly state that fb_create_text_post should be used for immediate publishing. An agent must infer the when-not-to-use boundary from the sibling names rather than from the description.

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

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

No annotations exist, so the description carries the full behavioral disclosure burden. It does state that calls are 'raw' and use a pre-configured access token, implying direct and potentially destructive operations depending on method. However, it does not mention side effects, rate-limit exposure, or the lack of endpoint-specific response validation, leaving some ambiguity for such a powerful escape-hatch tool.

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

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

Two compact sentences deliver the tool's purpose and usage guidance with zero filler. The 'Advanced/escape hatch' label is front-loaded, immediately setting expectations, and the second sentence gives a crisp selection rule.

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

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

For a deliberately generic raw-call tool, the combination of description and schema covers what an agent needs to invoke it: the method, path, and params are all specified, and the auth model is disclosed. The absence of an output schema is acceptable because the response is inherently endpoint-dependent; a more verbose description would not meaningfully improve correctness.

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

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

The schema already documents the path format and params semantics ('Query params (GET) or form fields (POST)'), and the method enum is self-explanatory. The description adds no parameter-level detail beyond framing the tool as a raw call to 'any' endpoint, so it neither significantly improves nor degrades the schema's coverage.

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

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

The description clearly states a specific verb and resource: 'make a raw call to any Meta Graph API endpoint' with a 'configured access token.' It immediately distinguishes itself from the high-level FB/IG sibling tools by labeling itself an 'Advanced/escape hatch.'

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

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

The description explicitly directs the agent to use this tool for 'anything the other tools don't cover yet,' which effectively establishes a when-to-use rule. It doesn't enumerate specific sibling alternatives, but the blanket fallback framing is clear enough for an agent to prioritize specialized tools first.

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

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

There are no annotations, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description does not disclose output details, permissions, error behavior, or whether the operation is scoped only to the authenticated account. This is minimal transparency.

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

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

The description is a single concise sentence with no filler or redundancy. It is somewhat under-specified for broader context, but as a concise statement of the primary purpose it is appropriately sized.

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

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

For a zero-parameter read-only tool, the description is minimally viable: it states what the tool returns. However, with no output schema and no mention of response contents or relationship to sibling insight/media tools, an agent may still need to infer important context.

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

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

The tool has zero parameters and the schema is fully covered, so there is nothing for the description to document. The mention of the 'connected Instagram account' clarifies the implicit authentication scope, adding a small amount of value beyond the empty schema.

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

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

The description gives a specific verb and resource: 'Get profile info' for the 'connected Instagram account.' It is clear and not a tautology. However, it does not distinguish itself from the sibling ig_get_account_insights, and 'profile info' is somewhat open-ended.

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

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

No guidance is provided about when to use this tool versus alternatives like ig_get_account_insights or ig_list_media. The phrase 'connected account' implies scope but does not give explicit conditions, exclusions, or alternative routing.

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

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

No annotations are provided, so the description carries full responsibility. It only says 'Get... metrics' and lists examples, but does not disclose that this likely requires an Instagram business account, that metrics may be limited by period, that data may be delayed, or what the response structure looks like. The read-only nature is implied by 'Get', but the description adds no behavioral depth beyond that.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action, the resource, the level, and gives examples. It is concise but not under-specified to the point of harm. However, it lacks any structured breakdown (e.g., parameter hints), which prevents a higher score.

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

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

With no output schema, no annotations, and 0% parameter descriptions, the agent is left without key information: possible period values, supported metric strings, whether the account must be linked to a Facebook page, or what the response contains. The description covers only the basic 'what', not the 'how' or 'what to expect'. This is a clear gap for a simple but non-trivial API call.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions example metrics (reach, impressions, profile_views), which helps clarify the metrics parameter, but it says nothing about the period parameter (day, week, days_28) or how metrics should be formatted as an array. With two parameters and no schema descriptions, the description only partially clarifies what each parameter means.

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

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

The description states a clear verb and resource: 'Get account-level Instagram insight metrics'. The 'account-level' qualifier directly distinguishes it from sibling tools like ig_get_media_insights, and the example metrics (reach, impressions, profile_views) give concrete meaning. This is specific enough for an agent to select it correctly.

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

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

The phrase 'account-level' implies this is for account-wide insights rather than per-media insights, which offers some guidance. However, the description does not explicitly state when to prefer this over ig_get_media_insights or fb_get_page_insights, nor does it mention any prerequisites (e.g., business account). Usage context is implied but not explicit.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a read operation, but the description does not disclose pagination behavior, ordering, rate-limit considerations, or any side effects. Beyond the basic read intent, behavioral transparency is minimal.

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

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

The description is a single clear sentence with no filler. It is front-loaded and easy to parse, though it could arguably include a bit more contextual detail without becoming verbose.

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

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

For a tool with no annotations, no output schema, and minimal parameter documentation, the description leaves significant gaps. An agent does not learn what the response contains, how pagination works, or how this differs from similar comment-related tools. The basic purpose is clear, but the information needed for correct invocation is incomplete.

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

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

Schema description coverage is 0%, so the description must explain parameter meaning. It gives context for media_id by saying 'on an Instagram media item,' but it does not clarify the limit parameter, its default, maximum, or how pagination works. This is only partial compensation for the missing schema descriptions.

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

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

The description uses a specific verb ('List') with a clear resource ('comments on an Instagram media item'). It explicitly names Instagram, distinguishing it from sibling tools like fb_get_comments, so an agent can tell what it operates on.

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

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

The description gives no guidance on when to choose this tool over alternatives such as ig_reply_to_comment or fb_get_comments. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage entirely from the name and schema.

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

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

With no annotations, the description carries the burden of behavioral disclosure. 'Get' strongly implies a read-only, non-destructive operation, which is helpful. But it does not mention required permissions, ownership constraints, or that insights may be unavailable for some media types or accounts, leaving some uncertainty.

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

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

A single, information-dense sentence. It front-loads the core action and resource, then gives illustrative examples. No filler or repetition of schema fields.

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

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

For a simple read-only tool with two parameters and no output schema, the description provides enough to select and invoke the tool correctly. It could be slightly richer by mentioning that media_id typically comes from ig_list_media or by expanding the metric examples, but the current text is adequate for straightforward use.

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

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

Schema description coverage is 0%, so the description must add meaning. It does clarify that metrics refers to insight metrics like reach, likes, comments, and saved, and that media_id identifies the target media item. However, it does not specify accepted metric values or the expected format/source of media_id beyond what the schema's default array already implies.

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

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

The description uses a clear verb ('Get') and a specific resource ('insight metrics for a specific Instagram media item'), with concrete metric examples. It also implicitly distinguishes itself from account-level tools like ig_get_account_insights and from media listing tools like ig_list_media.

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

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

The phrase 'for a specific Instagram media item' clearly sets the scope as single-media, not account-level or list-level. However, it does not explicitly name alternatives or state when not to use it, though the contrast with sibling account-insights tools is easy to infer.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('list') but does not cover authentication needs, ordering, pagination, or return format. The term 'recent' is ambiguous and no additional 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.

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

The description is a single, tightly packed sentence that front-loads the verb and resource. There is no filler or redundant information, making it an efficient and well-structured description.

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

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

With no output schema and no annotations, the description leaves key context undefined: the exact return format, the ordering of results, and the effect of the 'limit' parameter. For a simple list tool, the description is too minimal to fully prepare an agent for correct invocation and result interpretation.

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

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

Schema description coverage is 0% for the single 'limit' parameter, and the description does not mention 'limit' at all. The agent must rely solely on the parameter name and constraints in the schema, with no supplementary meaning provided in the description.

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

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

The description states a specific verb ('list'), a resource ('recent media posts'), and a source ('connected Instagram account'). It is clearly distinct from sibling tools, none of which provide IG media listing functionality, so there is no ambiguity about what this tool does.

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

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

The description implies usage when the agent needs recent media posts, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The usage context is inferred from the sibling set rather than explicitly documented.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates that the tool 'publishes', which implies a side-effectful action, but it does not mention authentication requirements, error behavior, whether existing posts get replaced, or any other behavioral traits. This is a significant gap 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.

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

The description is a single sentence with no filler or redundant information. It is front-loaded with the core purpose and key constraint. Every word contributes value.

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

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

For a tool with only two parameters and no output schema, the description gives the essential action and the image-count constraint. However, with no annotations, it lacks crucial context such as expected media URL formats, side effects, or any preconditions. It is minimally adequate but not complete.

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

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

Schema description coverage is 0%, yet the description provides no extra meaning for the parameters. It mentions '2-10 images', which merely echoes the minItems/maxItems constraints already present in the schema, and it does not describe the caption parameter at all. The agent must infer caption's purpose from the property name alone.

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

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

The description uses a specific verb ('publish'), a clear resource ('multi-image carousel post'), and target platform ('Instagram'). The '2-10 images' detail distinguishes it from single-image or video publishing siblings like ig_publish_photo and ig_publish_video.

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

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

The description implies its usage: you use this when publishing a carousel with multiple images. However, it provides no explicit guidance on when not to use it or which sibling tool would be more appropriate for other post types. Usage is understandable but not actively guided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Publish' and the connected account, but does not explain side effects, permissions, rate limits, async behavior, or what happens on failure. This is a minimal mutation description with little operational transparency.

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

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

The description is one sentence with active voice, no filler, and the core action is front-loaded. Every word contributes to the meaning, making it concise and easy to parse.

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

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

For a two-parameter tool, this is near-minimal but missing meaningful operational context: no mention of what the call returns, no note about asynchronous media processing, and no acknowledgement of the optional caption. The image_url requirement is covered by the schema, so the description is adequate but not fully complete.

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

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

Schema description coverage is only 50%: image_url has a schema-level description, but caption is completely undocumented. The tool description adds no parameter-level meaning beyond the schema, so the optional caption parameter remains unclear for an agent. With half the schema undocumented, 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.

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

The description uses a specific verb ('Publish'), a precise resource ('a single photo'), and a target ('the connected Instagram Business account'). This clearly differentiates the tool from siblings like ig_publish_video and ig_publish_carousel while keeping the Instagram Business scope explicit.

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

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

The description implies use for publishing a single photo, but it does not explicitly state when to use this tool instead of alternatives such as ig_publish_video or ig_publish_carousel. There are no conditions, exclusions, or sibling tool references, leaving the agent to infer the appropriate selection context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Publish a video' and gives no detail on side effects, permissions, rate limits, processing behavior, or response. This is a significant gap for a mutating tool.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, target, and possible modes. Every word earns its place.

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

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

For a relatively simple tool (3 flat parameters, 1 required), the description is minimally viable: it states the purpose and lists the media types, and the schema covers the required URL. However, with no annotations and no output schema, an agent still lacks information about response behavior, side effects, and account prerequisites beyond 'connected'.

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

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

Schema description coverage is only 33% (only video_url has a schema description). The description adds minimal parameter meaning by listing the three media types, which roughly maps to the media_type enum, but it does not clarify the caption parameter or add any semantics beyond what the enum and video_url schema already provide.

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

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

The description uses a specific verb ('Publish') with a clear resource ('a video') and target ('connected Instagram account'), and explicitly names the three output modes ('Reel, feed video, or Story'). This clearly distinguishes it from siblings like ig_publish_photo and ig_publish_carousel by the resource type, and from fb_* tools by the platform.

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

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

The description implies its usage: publish a video to Instagram in one of three formats. However, it does not state when to prefer this tool over alternatives (e.g., ig_publish_photo, graph_api_request), provide exclusions, or mention prerequisites such as the account being connected.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It signals a write operation but does not mention authentication requirements, visibility of the reply, irreversibility, or rate limits. It adds little beyond the obvious meaning of 'reply'.

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

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

The description is a single clear sentence with no filler or redundant wording. It is concise and front-loaded, though it could have used the available space to add usage or parameter context.

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

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

For a write operation with no annotations and no output schema, the description is too thin. It lacks prerequisite context, platform-specific constraints, and any indication of what the response returns, making it barely adequate for reliable invocation.

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

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

Schema description coverage is 0% and the description provides no parameter-level meaning. It does not explain how to obtain comment_id, what message should contain, or how the two parameters relate to the action.

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

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

The description clearly states the specific action ('Reply') and resource ('a comment on an Instagram media item'), distinguishing it from siblings like ig_get_comments and fb_reply_to_comment. The platform and action are unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as ig_get_comments or fb_reply_to_comment. The description only defines the action, leaving the agent to infer prerequisites like needing a valid comment_id.

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