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

The description discloses that the Page token is used by default and that the 'as' parameter can switch to the Instagram token, which is useful context. It does not warn about the potential side effects of using POST or DELETE methods, nor does it mention response formats or error handling, which is a gap for a generic endpoint caller.

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 compact, two sentences, with the core purpose front-loaded and the caveat about the lack of a complete catalogue following logically. It avoids redundancy and uses precise language, making it easy to parse quickly.

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

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

For a generic tool with no output schema, it covers the essential how (path relative, token default) and when (catch-all for uncovered endpoints). It omits important contextual cautions regarding destructive methods (POST/DELETE) and the expected shape of the query parameter, which an agent invoking a raw endpoint would benefit from knowing.

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 50% (path and as have descriptions; query and method do not). The description adds meaning by clarifying that paths are relative to the Graph host and version, and by touching on token selection, but it does not elaborate on the 'query' object structure or the implications of the method parameter, leaving some parameter behavior under-explained.

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

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

The description clearly states the tool calls any Graph API endpoint directly, with the Page token by default, positioning it as the generic fallback. It distinguishes itself from the specific sibling tools by noting it is the way to 'reach the rest' of the API, making its purpose unmistakable.

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?

It implicitly indicates usage when no dedicated tool is available by stating 'this is how you reach the rest of it', given the siblings cover common endpoints. However, it does not explicitly say 'prefer specific tools when available' or provide examples of when to choose this over a sibling, leaving some ambiguity.

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 to carry safety or behavioral context, the description discloses the most important behaviors: the post is immediately public, there is no draft state, and Meta fetches media server-side from a public URL. The explicit warning that a local path can never work prevents a common and costly invocation error.

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

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

The description is two short sentences with no filler. The first sentence states the core action, and the second sentence front-loads the critical technical constraint. The line break cleanly separates the behavioral summary from the upload limitation.

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 covers the central gotcha and privacy behavior, but it does not explain the role of ig_user_id, whether one of image_url or video_url must be supplied, or how wait_seconds interacts with the request. With no output schema and no annotations, an agent still has meaningful gaps for executing the tool correctly.

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

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

The description adds significant meaning to image_url and video_url by explaining why the URL must be public and why local files are impossible. However, caption and ig_user_id receive no semantic guidance, and with 60% schema coverage the description only partially compensates for undocumented parameters.

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

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

The opening sentence, "Publish to Instagram," names a specific verb and resource, and the phrase "Immediately public, no draft state" clarifies that this is a live publishing action. This clearly distinguishes it from siblings like meta_create_page_post and meta_create_post_comment.

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 makes the intended use clear: publish media to Instagram, with no draft or preview state. It also provides a key prerequisite (media must be publicly reachable via http(s)), but it does not explicitly name alternatives or state when-not-to-use cases, so it stops short of a 5.

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

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

The description discloses critical side effects: 'Immediately public — there is no draft state here, and the only undo is deleting it.' This informs the agent that the action is irreversible and has immediate visibility consequences, which is exactly the kind of behavioral transparency needed.

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 two sentences, concise and free of extraneous detail. The key information—the action and its consequences—is presented efficiently without redundancy.

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

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

The description covers the essential outcome (public post, no draft, deletion only undo) and the primary inputs (message, link, page). It does not mention any required permissions or return values, but given the simple tool and absence of output schema, this is acceptable. A slight deduction for not clarifying the purpose of page_id.

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 includes descriptions for link and message, but page_id has no description. The overall coverage is 67%, which is not high enough to assume all parameters are self-explanatory. While link and message are clearly defined, page_id's omission leaves ambiguity about its purpose and format.

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 action: 'Post to a Facebook Page,' which is a specific verb and object. This distinguishes it from sibling tools like meta_get_page (read) or meta_create_post_comment (comment).

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 does not provide explicit guidance on when to use this tool versus alternatives. It implies the purpose for creating a post but lacks direct 'use this when' or 'instead of' instructions. The reader must infer the appropriate context from the action name and 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?

With no annotations, the description carries the behavioral transparency burden and does so well by warning that a successful call is the only confirmation and that reading comments back is not possible with a standard app. This is significant non-obvious behavior. It does not mention permissions or other side effects, but the key verification limitation is 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 two sentences with no filler. The primary purpose is stated immediately, and the critical no-verification warning earns its place. Every word adds value.

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

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

For a simple two-parameter create tool with no output schema and no annotations, the description provides the essential behavioral context including the unverifiable-success caveat. It is complete enough for selection and invocation, though explicit parameter descriptions and auth prerequisites would make it fully robust.

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 for the two undocumented parameters. It does provide meaningful context: 'Page post' clarifies post_id, and 'outbound link in the first comment' implies message content. However, it does not explicitly map parameters or explain their formats, leaving some inference required.

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: 'Comment on a Page post'. It also clearly distinguishes the tool from the post-body workflow by emphasizing 'first comment rather than the post body', which separates it from sibling tools like meta_create_page_post and the Instagram tools.

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

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

The description gives clear context for when to use this tool: when you want to place an outbound link in the first comment rather than the post body. It does not explicitly name an alternative tool or provide a when-not-to-use statement, but the context is strong enough that an agent can infer the intended use case.

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, but it only describes an object, not an action. It does not mention whether the operation is read-only, what it returns, whether authentication is needed, or any side effects. This leaves the agent completely uninformed.

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

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

The description is extremely short, but it is under-specified rather than appropriately concise. The single fragment adds no actionable information and does not earn its place, similar to a bare placeholder.

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

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

The tool has two undocumented parameters, no annotations, and no output schema. The description is a vague fragment that does not explain return values, parameter usage, or the linked-account context. It is wholly inadequate for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 0% for the two parameters ('fields', 'ig_user_id'), and the description does not mention either parameter. It offers no compensation for the missing schema documentation, so an agent cannot infer how to fill the parameters correctly.

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

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

The description is a noun phrase ('The linked Instagram Business account') with no explicit verb. It identifies the resource but does not state what the tool does with it, though the tool name implies retrieval. It fails to distinguish itself from siblings like meta_get_page or meta_create_instagram_post.

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

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

The description provides no guidance on when to use this tool, what prerequisites apply, or how it relates to alternatives. There is no mention of linked account requirements or when another sibling would be more appropriate.

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

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

There are no annotations to describe side effects or read-only behavior. The phrase 'details' weakly implies a read operation, but the description does not disclose response format, errors, authentication, or whether any state changes occur.

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

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

The description is extremely short and free of irrelevant detail, making it easy to parse. It could be slightly more informative by adding a verb and scope, but it does not waste words.

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

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

For a simple getter, the description gives a general idea but omits critical context such as what details are returned, how fields affects output, and any prerequisites. An agent would need to infer too much from the tool name and schema.

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?

Only 'fields' has a minimal schema description ('Comma-separated. Defaults to id,name,fan_count.'), while 'page_id' has no description. The tool description adds no explanation of page_id or how the parameters interact, leaving an agent to guess from the parameter name.

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 indicates the resource is a Facebook Page's details, and the tool name includes 'get', so an agent can infer retrieval. However, it is a noun phrase without an explicit verb, and it does not clearly distinguish the scope from related tools like meta_create_page_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?

No guidance is provided about when to use this tool versus alternative tools. Sibling names imply this is for reading Page details while others create posts/comments or fetch Instagram accounts, but the description itself does not state this.

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