facebook-automata-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct Graph API resource and action, with clear boundaries even for similar pairs like get_my_profile vs get_user_profile or get_page_posts vs get_page_feed. The descriptions precisely define the scope of each tool.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (set_, get_, publish_, delete_, etc.) with uniform resource naming. There are no mixed conventions or vague names.
Tool Count2/5
At 38 tools, the server is overly large for its purpose. Many specific tools (e.g., get_post_comments, get_post_likes) duplicate functionality already covered by the generic graph_api_get/post/delete tools, exceeding the reasonable size for a focused toolset.
Completeness4/5
The toolset covers core Facebook automation workflows: credentials, profile, pages, posts, comments, likes, and media upload. Minor gaps like explicit update operations (edit post/comment) and event creation exist, but generic Graph API tools provide fallbacks.
Average 3.6/5 across 38 of 38 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the HTTP method (POST) but does not disclose that it mutates data, whether it requires specific authentication (like page access token), rate limits, or what the response contains (though an output schema exists). For a write operation with zero annotations, it should be more explicit about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with an explicit endpoint hint (POST /{comment-id}/comments) is concise and front-loaded. The verb and resource are clear. Though sparse, it has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks critical context for a mutation tool: it doesn't mention authentication requirements, that a page access token is likely needed, the relationship to publish_comment vs reply_to_comment, any content limitations (e.g., message length), or error handling. With an output schema present, it can omit return details, but it still misses important usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not explain what 'message' should contain (text, format, length limits) or what 'comment_id' refers to (the parent comment's ID). The vague parameter names in the schema leave ambiguity that the description does not resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Reply') and resource ('existing comment'), matching the resource pattern of sibling tools like get_comment_replies, publish_comment, and delete_comment. However, it lacks differentiation from publish_comment, which likely also creates a comment (just a top-level one vs a nested reply). The endpoint hint helps clarify but is still minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of publish_comment, get_comment_replies, or reply_to_comment vs other write tools. It does not mention any prerequisites (like needing a valid comment_id or that it creates a nested comment rather than a top-level one). An agent could confuse this with publish_comment.
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 reveals the API endpoint and that it's a read operation (GET), but does not disclose pagination behavior (beyond 'after' and 'limit' params), rate limits, or what happens if no events exist. It does not contradict annotations since 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the core purpose, and includes the endpoint URL for clarity. It is concise and efficient, but lacks any elaboration on usage or parameters, which is a minor shortfall given the low schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is insufficient. It does not explain parameter semantics, pagination, or error cases, and there are no annotations. The missing information is essential for correct invocation, particularly for 'after' which is a pagination cursor.
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 explain any parameters. The schema itself has 3 parameters with defaults but no descriptions, leaving agent with no semantic meaning for 'after', 'limit', or 'page_id' beyond names. The description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List events hosted by the Page' with a clear verb and resource, distinguishing it from page posts, feed, and other content tools. However, it does not explicitly differentiate from siblings like get_page_posts or get_page_insights, though the resource (events) is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no comment on prerequisites (e.g., needing credentials or a valid page_id). The context signals show no annotations either, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds no context beyond the core listing action—no mention of authentication requirements, pagination, semantics of 'tagged' posts, or interactions with parameters. The parenthetical endpoint is helpful but does not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with a useful endpoint reference. It is front-loaded with the action and contains no fluff, but it is so brief that it omits necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and schema descriptions, the description is incomplete for an agent to call the tool correctly. It does not explain parameter relationships, the need for page_id, or the nature of the returned data. The endpoint reference provides a small amount of context, but overall it is insufficient.
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% for 4 parameters, and the description does not compensate at all. No parameter is explained; the meaning of 'after', 'limit', 'fields', and 'page_id' is left entirely to the schema's bare names and types. The description fails to clarify that 'page_id' identifies the Page whose tagged posts are listed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('List'), a resource ('posts the Page has been tagged in'), and the corresponding endpoint, making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like get_page_posts and get_page_feed by specifying 'tagged in' rather than posts authored by the page.
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 offers no explicit guidance on when to use this tool versus the sibling page-listing tools. It only states its core function; there are no exclusions, conditions, or alternatives mentioned. The agent must infer use cases solely from the name and the phrase 'tagged in'.
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 states a read-only listing operation but fails to mention pagination behavior (implied by 'after' and 'limit' parameters), any required permissions, potential rate limits, or the shape of the response beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the operation and the endpoint. Every word earns its place, with no 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 tool with three parameters and no annotations, the description is too sparse. It does not explain pagination, return details, error conditions, or any behavior that would help an agent call it correctly. The presence of an output schema is noted but the description does not leverage it.
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. It indirectly clarifies 'page_id' through the endpoint placeholder, but 'after' and 'limit' are not described at all. The description adds minimal value over the schema's default values and parameter names.
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 ('List') and the resource ('videos posted by the Page'), and includes the endpoint. It implicitly distinguishes from sibling tools that list other resources (posts, photos, albums) because it is specifically about videos, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_page_posts or upload_page_video. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden, but it only provides the HTTP method and path. It does not mention read-only behavior, error handling, field filtering semantics, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core operation and resource, though it omits supporting details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks usage guidance and parameter semantics. Even with an output schema available, an agent would not know how to use the fields parameter or when to choose this tool over its 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%, and the description does not explain either parameter. It implies comment_id is the identifier but gives no format or usage detail for fields, which has a default value and could control the response shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (get details), the resource (a single comment), and the identifier method (by ID). It is easily distinguished from siblings like get_post_comments and get_comment_replies because it targets a single comment directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There are no conditions, exclusions, or explicit mentions of sibling tools, leaving the agent to infer the appropriate selection from the tool name and schema 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?
With no annotations provided, the description bears the full burden of behavioral disclosure. It mentions the default page_id fallback as a specific behavior, but does not explicitly state that this is a read-only operation, does not describe authentication requirements (beyond referencing set_facebook_credentials), and does not mention error handling or side effects. The output schema covers return structure, but other behavioral aspects remain undisclosed.
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 the purpose front-loaded and a necessary note about the default page_id following. Every word earns its place; no fluff or redundancy. It is appropriately sized and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional parameters, output schema present), the description covers the core purpose and the default behavior. The output schema defines return values, so that is handled. However, it omits an explanation of the fields parameter and does not explicitly state that credentials must be set beforehand, though that is implied by the default reference. It is adequate but not thorough, especially given the many 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. It explains page_id's default behavior (fallback to stored credentials) but does not explain the fields parameter at all. The fields parameter's purpose and how it controls the returned data are left solely to the schema's default string, which is not self-explanatory. Thus, it only partially covers parameter semantics and fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details about a Facebook Page' with specific examples (name, about, category, fan_count), establishing a clear verb and resource. It is not explicitly differentiated from sibling tools like get_page_posts, but the focus on metadata fields implies it is for page info, not content. The 'etc.' broadens scope appropriately without being vague.
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 get_page_insights or get_page_posts. The only usage note is about the default page_id fallback, which is a parameter behavior, not a usage context. It neither states when to use this tool nor when not to, leaving the agent to infer from the tool name and examples.
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 disclosing behavior, and it only conveys 'this mutates.' There is no mention that deletion is irreversible on Graph API edges, that Facebook credentials must be set (via set_facebook_credentials), what side effects or downstream resources are affected, or what errors/failure modes can occur. For a destructive, high-privilege operation this is a serious gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words: it states the operation, the scope, and provides an embedded example. It is appropriately compact, though it leans so broad that its brevity edges toward under-specification, which is a completeness issue more than a conciseness flaw.
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 lacks essential contextual detail: when the generic delete should be preferred over specialized siblings, how the edge string is formed for non-post entities, and what preconditions apply. Because it is a generalized, flexible deletion tool with a dangerous option, the missing operational context leaves an agent exposed to the wrong edge or unintended data loss, without escalation under covered.
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 fill the gap. It does add meaning to the required 'edge' parameter by explaining it is a Graph API edge with a concrete example ('{post-id}'), which goes beyond the schema's bare 'Edge' label. However, the optional 'params' parameter is given no coverage in either the schema or description; an agent cannot reason about how, say, when params is a real JSON payload vs null, so the compensation is only partial.
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 is a single sentence with a specific verb ('DELETE') and a defined resource ('any Graph API edge'), and the example shows the shape of the edge value. It communicates that this is a generic catch-all deletion tool, which partially distinguishes it from targeted siblings like delete_post or delete_comment. However, it does not explicitly name those alternatives, so the differentiation from purpose-built destroyers is only implied, not stated.
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 generic delete versus delete_post or delete_comment, or whether this should be a last-resort fallback only. The example edge="{post-id}" hints at a common case but is not guidance about when to reach for the tool; there is no explicit use case, precondition, or why-this-one condition.
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 disclosing behavior. It conveys a destructive HTTP DELETE operation but does not mention permanence, side effects on replies, permission requirements, or reversibility. The description adds the endpoint but little else 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and includes the endpoint. Every word earns its place with 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?
For a simple one-parameter delete tool with an output schema, the description covers the basic call pattern. However, it omits behavioral and usage context such as irreversibility and permission needs, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the comment_id parameter. It only says 'by ID' and embeds '{comment-id}' in the endpoint, which does little to explain the parameter's format, origin, or constraints beyond what the schema title already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a comment by ID' with an explicit HTTP DELETE pattern. This clearly distinguishes it from sibling tools like delete_post and hide_comment 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as hide_comment or graph_api_delete. There are no exclusions, prerequisites, or context clues beyond the verb 'delete', so the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add meaningful context: the endpoint path, valid order values (chronological/reverse_chronological), filter semantics, and the 'from' field shape in output. However, it's silent on pagination behavior (after/limit interplay), default ordering behavior, and any rate-limit or error characteristics. The additions are relevant but partial; this is a solid middle-of-the-road effort with no annotations to help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly packed lines: a purpose sentence, two parameter docs, and one output-shape note. Every sentence contributes, the parameter docs are formatted as scannable label/value pairs, and there's no fluff or repetition. A half-point deduction for output 'from' note being slightly terse (could clarify id/name visibility rules).
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 an output schema is present, the description doesn't need to enumerate return values — and it wisely documents only the non-obvious output detail ('from'). However, pagination semantics for `after`/`limit` are underexplained for a listing tool, and there's no mention of how `filter=stream` interacts with ordering or limits. Adequate for straightforward calls but leaves an agent guessing on multi-page or streaming scenarios.
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 — and it does document semantics for the two least obvious params (order and filter). However, after, limit, post_id, and fields receive no described meaning beyond their self-evident names, and the default fields list in the schema (like comment_count, permalink_url) does some implicit work. Meaningful for the ambiguous params, but with 6 total params, substantial room remains.
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?
Clear verb+resource: 'List comments on a post' with the endpoint specified as (GET /{post-id}/comments). The description conveys this is a collection-listing operation, distinct from get_comment and get_comment_replies. Loses a point for not explicitly differentiating itself from those siblings, particularly given get_comment_replies overlaps with the 'stream' filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or mention of alternatives. The 'filter' param description (toplevel vs stream) implies a decision between flat and nested comment output, but the description never says 'use get_comment_replies for X' or when not to use this tool. The endpoint and param docs emerge from parameter documentation, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose that this is a read-only GET operation returning reactors and reaction types. However, it does not mention pagination behavior, filtering by reaction_type, ordering, or any access requirements. The existing output schema covers return value structure, so this is a partial but not complete disclosure.
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 the core action, resource, and endpoint front-loaded. Every word earns its place; there is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, zero annotation coverage, and zero schema description coverage, yet the description is minimal. It omits pagination semantics, the meaning of reaction_type, and guidance on when to use this over sibling reaction/like tools. The output schema fills in return values, but the input-side context is insufficient.
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 four parameters. It only clarifies comment_id through the URL template '/{comment-id}/reactions'. The 'how' phrase vaguely hints at reaction type, but after, limit, and reaction_type are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('List') and a specific resource ('reactions on a comment'), and clarifies the data returned ('who reacted and how'). The endpoint template further reinforces the scope. This clearly distinguishes it from siblings like get_comment_likes or get_post_reactions.
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 get_comment_likes or get_post_reactions. There are no stated exclusions, filter recommendations, or context hints beyond the tool name.
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 the HTTP method (GET), the specific page-scoped resource, and the accepted since/until timestamp formats, which is useful behavioral context. However, no annotations exist, so the description carries the full burden; it does not mention auth requirements, pagination via 'after', rate limits, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and each sentence earns its place. The timestamp-format note is a valuable addition and the example makes it concrete without adding 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?
For a tool with 6 parameters, no annotations, and no schema descriptions, this is incomplete. The output schema may explain return values, but an agent still lacks critical invocation details such as how to set page_id, pagination semantics, and field-selection behavior. It is minimally viable at best.
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 all parameters, but it only explains since and until. It does not explain after as a pagination cursor, limit behavior, the fields selector, or how page_id is used, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List posts published BY a Page', and reinforces it with the exact endpoint GET /{page-id}/posts. The phrase 'published BY a Page' plus the endpoint helps disambiguate this from siblings like get_page_feed and get_page_tagged_posts without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as get_page_feed or get_page_tagged_posts. The only hint is the phrase 'published BY a Page', which implies a scoped use case, but no exclusions, conditions, or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes 'GET /{post-id}', which usefully signals that this is a read-only operation and matches a standard HTTP endpoint. With no annotations, the description still carries the disclosure burden, but it does not mention error behavior, the fact that returned fields are customizable, or that the default field list may limit what 'full details' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and resource, then adds the HTTP endpoint in parentheses. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return structure is documented elsewhere. Still, the description leaves uncertainty about the fields parameter and does not clarify how this tool relates to the many post-related sibling tools, so the agent may not be fully prepared to invoke it optimally.
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 by explaining parameters. It indirectly covers post_id via 'by its ID', but it does not mention the fields parameter, which is optional, has a default, and directly affects what data is returned. This is a meaningful gap given the absent schema descriptions.
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 ('Get full details') and resource ('a single post by its ID'), which distinguishes it from list-oriented tools like get_page_posts and from sub-resource tools like get_post_comments. However, it does not explicitly name any sibling alternative, so the differentiation is implied rather than stated.
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 'single post by its ID' implies when to use this tool: when you already have a post ID and need that post's details. It does not state when not to use it or mention alternatives such as get_post_comments or get_post_likes, so the usage context is only implicit.
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. It reveals the operation is a POST (implying mutation) but does not disclose side effects, permissions, required authentication, error behavior, or response format. This is a significant gap for a tool that can act on any edge.
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 sentence with an example, no filler. The generic scope is front-loaded and the example grounds the abstract 'edge' parameter. Every word contributes.
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 generic mutation tool with no annotations and no param-level descriptions, this is too thin. It omits how to authenticate, what edge formats are valid, what data should look like, and what side effects to expect. An output schema exists, so return values are covered, but the operational context needed to call it correctly is largely 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. It provides an example for 'edge' ('{id}/feed'), which gives some format guidance, but says nothing about 'data' – what it should contain, how it maps to the edge, or optionality beyond the schema default. The agent is left to guess the payload structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (POST) and resource (any Graph API edge), with an example. The word 'generic' clearly distinguishes it from the specific POST operations among the siblings, and the sibling graph_api_get/graph_api_delete are differentiated by the HTTP verb.
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 catch-all for Graph API POST operations, but does not explicitly state when to prefer it over specific tools like publish_page_post. There are no exclusions or alternative routing instructions, so usage context is only implied.
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 states the action and HTTP method but does not disclose important traits such as idempotency (what happens if the like doesn't exist), error handling, authentication requirements, or reversibility. For a mutation operation, this is a significant 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 extremely concise—a single sentence that front-loads the core action and HTTP method. There is no wasted wording, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema but no annotations, the description should provide additional context about expected outcomes, error scenarios, or object types it applies to (posts, comments, etc.). It currently lacks this, making it incomplete for an agent deciding whether to use it and how to interpret results.
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 description coverage is 0%, meaning the description must compensate by explaining the parameter. It does not explain what object_id refers to (e.g., a post ID, comment ID) or how to obtain it. The description only shows the path template, which is not sufficient for an agent to correctly populate the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove') and a specific resource ('a previously placed like'), and it includes the HTTP method and path (DELETE /{object-id}/likes). This clearly distinguishes it from sibling like_object, which adds a like, so an agent can tell the two apart without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the counterpart to like_object, but it does not explicitly name alternatives or provide conditions for when to use this tool versus like_object or other like-related tools. It only states what it does, leaving the when-to-use 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 carries the full behavioral disclosure burden. The words 'List' and 'GET' convey that this is a read-only call, which is genuinely useful, but the description stops there: it does not expose pagination semantics (how 'after' works, whether the reply list is recursive), permission requirements, or the shape of the response beyond what the separate output schema covers.
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, instruction-sized sentence that front-loads the exact operation ('List...') followed by the endpoint. Every token contributes meaning; there is no filler or repetition of what a schema already provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered, and the tool is a fairly simple list operation. Still, the description omits important contextual pieces a caller needs correctly: how pagination tokens are produced and consumed, whether hidden or nested replies are included, and any access/precondition requirements for the comment path.
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 mentions no parameters. The required 'comment_id' is inferable from the endpoint and tool name, and 'fields' self-explains via its long default value, but 'after' (an opaque pagination cursor) and 'limit' behavior are left undefined for the agent, creating real ambiguity for a paginated workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific verb and resource ('List replies to a comment') and includes the underlying endpoint, (GET /{comment-id}/comments), which disambiguates it from sibling tools such as get_post_comments (top-level post comments) or get_comment (a single comment). An agent reading this description alone can tell exactly which operation is exposed.
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 choose this tool over its siblings. The description never says 'use this for replying to comments' or explicitly rejects top-level comments/posts; an agent simply has to infer from the path and the tool's name, which is not reliable for routing between so many related endpoints.
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. The words 'List' and 'GET' imply a read-only operation, and the response contents (id/name) are mentioned. However, pagination behavior and the role of the 'after' parameter are not disclosed, which is a meaningful omission given the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with no filler. The endpoint is added parenthetically without disrupting flow, and the core action and outcome are 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?
The tool has a required post_id and optional pagination parameters, and an output schema exists to cover return values. However, the description omits pagination context (what 'after' does) and any authentication notes, leaving some gaps for an agent invoking the tool with more than the default parameters.
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 implicitly identifies post_id via the endpoint '/{post-id}/likes', but it does not explain the optional 'after' and 'limit' parameters. The agent is left to infer their semantics from type and 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 verb ('List') and resource ('people who liked a post'), and includes the exact endpoint. It clearly distinguishes this from sibling tools like get_post_reactions and get_comment_likes by specifying the post context and the nature of the data (people who liked).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as get_post_reactions or get_comment_likes. The description only states the action without naming any exclusions or preferred conditions, leaving the selection to inference.
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 burden of behavioral disclosure. It adds valuable context about Graph API restrictions, stating that only public fields are typically returned without specific permissions. This informs the agent about possible limited output, though it does not cover other behavioral aspects like rate limits or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose in the first sentence. The additional note is relevant and kept brief. It is slightly verbose with the line break and 'Note:' but every sentence contributes meaning.
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 an output schema exists and the tool is a simple read operation, the description covers the core purpose and a key limitation. However, it lacks usage guidance for this tool versus its numerous siblings, and the absence of annotations leaves some behavioral gaps. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter meanings. It explains that user_id refers to a Facebook user or page ID, and it gives examples of fields ('id, name, picture'). However, it does not explain the exact format of the fields parameter (e.g., comma-separated) or clarify the optionality, leaving some ambiguity.
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 ('Get') and resource ('public profile info') for a given Facebook user or page ID. It is clear and distinguishes the tool's general scope, but it does not differentiate it from sibling tools like get_page_info or get_my_profile, which could also retrieve profile-like 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 provided on when to use this tool versus alternatives. The note about API restrictions is about behavior, not usage context, and the description does not mention any exclusions or conditions that would select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions it includes own posts and others' posts, which is a behavioral detail beyond a simple 'list feed'. However, it doesn't disclose pagination behavior, rate limits, or access token requirements, but it references the endpoint which helps. Given no annotations, this is acceptable but not extensive.
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 sentence, no fluff, and provides the key distinction (own + others) and the endpoint reference. Well 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?
The output schema exists (context signal) but not provided, so we can't rely on it. With 0% schema description coverage and no annotations, the description could do more to explain response structure or pagination. However, for a list endpoint, this might suffice, but typical hidden aspects like pagination (since 'after' exists) aren't addressed. Slightly under-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't explain any parameters explicitly beyond the endpoint. It implicitly covers 'page_id' via 'Page's feed', but doesn't explain 'after', 'limit', 'fields'. However, defaults are given in schema, and the description mentions the endpoint which hints at context. Baseline is 3 due to low coverage, but description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: lists the Page's feed, including own posts and posts/links from others, with reference to the Graph API endpoint. It distinguishes from siblings like get_page_posts and get_page_tagged_posts by mentioning 'feed' which combines both, but doesn't explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a Page's feed, and distinguishing from get_page_posts and get_page_tagged_posts is implicit through the term 'feed', but no explicit guidance on when to choose this over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the burden. The description notes a precondition ('public video URL') and implies it makes a POST request, indicating a mutating action. However, it does not disclose other behaviors such as whether it returns the video ID, whether it publishes immediately, or if it requires prior authentication (which is likely given sibling credential tools exist). The mention of 'public' hints at a constraint but is not exhaustive. Given lack of annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and endpoint. It wastes no words, but it is short enough that it could be slightly more informative without losing conformance. The structure is clear and readable.
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 potentially complex operation like video upload, the description provides minimal context. An output schema exists, so return format is covered, but the tool likely requires authentication, a page token, and a publicly accessible video URL, none of which are mentioned. The sibling set includes credential tools, suggesting auth is needed, but that is not noted. The description should mention prerequisites or caveats, so it is missing critical context.
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 clarify parameters. The description itself only references 'video_url' implicitly ('public video URL'), and does not explain 'title', 'description', or 'page_id'. The parameter names are self-explanatory somewhat, but the description adds no meaning beyond them. It does not specify that 'page_id' is optional or how it defaults, which is a gap given coverage is zero.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is stated with a specific verb ('Upload'), a clear resource (video to a Page), and the method/endpoint (POST /{page-id}/videos). This clearly distinguishes from the sibling tools like publish_page_post, upload_page_photo, and graph_api_post. The presence of sibling upload_page_photo contrasts the specific resource. The noun phrase 'a Page' and 'public video URL' make the target precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when one wants to upload a video to a Page, but it does not provide explicit context on when to use it versus alternatives, nor when not to use it. It does not mention that the video must be publicly accessible online, which is a key constraint. Sibling tools like upload_page_photo are similar, so more differentiation would help, but the verb+resource is clear enough to infer a primary use case.
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?
There are no annotations, so the description must carry the behavioral burden. It does convey that this is a read-only listing operation scoped to the current user token and that each item contains an access_token. However, it does not mention pagination behavior, auth failure implications, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the core action and resource, adds a practical use case, and contains no filler. It is 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?
The description covers the core purpose and the most important return value nuance, and an output schema exists. But without annotations, the missing semantics for pagination parameters and auth-dependent behavior leave meaningful gaps for an agent that needs to call this tool beyond the default 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 provides no explanation for the 'after' or 'limit' parameters. The mention of access_token only clarifies output, not input parameters, so the description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('Facebook Pages managed by the current user token'), and even includes the endpoint GET /me/accounts. This clearly distinguishes the tool from siblings like get_page_info or search_pages.
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 states a concrete use case: discovering page_id values and page-scoped access tokens. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to select it 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 behavior disclosure; it indicates a read-only, public-data search, which is a meaningful safety signal. However, it does not mention authentication requirements, pagination behavior, or rate-limit implications.
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 clean sentence with the endpoint appended; no filler. It is appropriately short for a simple search 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 read-only search with an output schema, the core invocation is clear and the required parameter is documented. The gap is in pagination parameters and guidance on when to use this versus page-by-ID 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 coverage is 0%, so the description must compensate. It explains only query (the search term), leaving after and limit undocumented; after in particular is opaque without a pagination note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific action (Search), the resource (public Facebook Pages), and the lookup semantics (by name/keyword), plus the underlying endpoint. This clearly differentiates it from get_page_info (by ID) and page content 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?
It implies this tool is for discovery by keyword rather than fetching a known page, but it never states when to choose it over get_page_info or get_my_accounts. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the destructive action ('Delete') and the ownership permission requirement, but it does not address reversibility, cascading side effects (deletion of comments, reactions, or insights tied to the post), or failure behavior. Adequate for a simple operation but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the action and resource front-loaded and zero filler. The HTTP endpoint and permission note each earn their place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with an output schema, the essentials (action, endpoint, permission) are present. But with zero annotations, the lack of side-effect, reversibility, and error-return notes leaves noticeable gaps an agent would need to invoke 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% and the schema only carries a title 'Post Id'. The description's 'by ID' maps to post_id and the DELETE /{post-id} endpoint clarifies the parameter's role, adding marginal meaning. However, it gives no guidance on where to obtain the ID (e.g., from get_post or get_page_posts) or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) plus resource (a post by ID) and the exact HTTP endpoint DELETE /{post-id}. Clearly distinguishable from siblings like get_post (a read), delete_comment (deletes a comment, not a post), and graph_api_delete (a generic raw deletion).
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?
Adds the ownership-permissions requirement, which gives useful implicit context for when the tool can legally be used. However, it provides no explicit when/when-not guidance and never routes the agent to alternatives such as graph_api_delete for raw deletions or delete_comment for comment-level deletion, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that this is a read-only GET operation via the endpoint path, but it does not mention authentication, permissions, rate limits, or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the verb, resource, and endpoint. There is no filler or repetition, and every element contributes to understanding the 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?
For a simple list operation with an output schema, the description covers the core action, but it omits usage context such as how pagination works via 'after' and 'limit' and any authentication expectations. It is adequate but not fully self-sufficient.
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. The path template clarifies that comment_id is the comment identifier, but the after and limit parameters are not explained at all in the description, leaving their semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'List people who liked a comment' and reinforces it with the endpoint pattern 'GET /{comment-id}/likes'. This clearly distinguishes it from siblings like get_post_likes and get_comment_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to list likes on a comment. It does not explicitly name alternatives or exclusions, but the resource and action are unambiguous, so an agent can infer when to choose 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?
No annotations are provided, so the description carries the full behavioral burden. It signals a read-only list operation via GET, which is non-destructive, but it does not mention authentication needs, pagination behavior, or error cases. Minimal but not misleading.
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 short sentence front-loads the core purpose and adds the endpoint in parentheses 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?
For a simple list operation with an output schema, the core action is stated and return structure is presumably covered by the output schema. However, with no annotations and minimal parameter documentation, authentication, pagination, and how to supply page_id remain implicit. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not document any of the three parameters. The endpoint path hints at page_id, but after and limit are left entirely unexplained aside from their titles and defaults. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a specific resource ('photo albums'), and scoping ('on the Page'), plus the exact GET endpoint. This clearly distinguishes it from sibling tools like get_page_photos and get_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to list photo albums on a Page. It does not explicitly name alternatives or exclusions, but the use case is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral disclosure. It does convey that this is a mutating toggle operation (hide/unhide) and shows the HTTP method and endpoint, which helps. But it does not explicitly state side effects (e.g., whether hiding removes the comment from public view, whether it is reversible beyond toggling), authorization needs beyond 'your Page's post', or any rate-limit considerations. The disclosure is adequate for a simple toggle but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. It efficiently combines the action, resource, and the endpoint reference, making it easy to scan and understand. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter toggle tool with an output schema, the description is nearly complete: it states the action, the resource, and the endpoint pattern. The main omission is explicit routing guidance (when to use this vs. siblings) and any note on permissions, but those are secondary given the straightforward nature of the tool and the presence of an output schema for return values.
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. The endpoint pattern 'POST /{comment-id}?is_hidden=...' provides a strong hint that comment_id maps to the comment path variable and hide likely maps to the is_hidden query parameter. The phrase 'Hide or unhide' implies the boolean hide parameter controls the toggle. However, the description does not explicitly document that hide=true means hide and hide=false means unhide, nor does it define comment_id format beyond the endpoint. Some meaning is added, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Hide or unhide') applied to a specific resource ('a comment on your Page's post'). It also includes the exact API endpoint pattern, which distinguishes this from siblings like delete_comment, get_comment, and publish_comment. An agent can identify what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you would call this when you want to change the visibility state of a comment on your Page's post. However, it offers no explicit guidance about when to choose this over alternatives (e.g., delete_comment for permanent removal, publish_comment for adding a new comment), and no exclusions or conditions are given. Usage context is present but not fully elaborated.
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 present, so the description carries the disclosure burden. It correctly identifies this as a POST mutation performed as the current identity, but it does not mention idempotency, required permissions, or behavior on duplicate likes. This is minimal but acceptable for a straightforward like 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 one compact sentence that front-loads the action and target, and it includes an endpoint hint without unnecessary elaboration. 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?
Given the simplicity of the tool—one required parameter and an output schema—the description covers the core invocation details well. It lacks discussion of side effects or idempotency, but those are less critical for this minimal like action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines object_id as a string with no description, so the description adds value by indicating the ID refers to a post, comment, or object. However, it does not specify ID format or the full range of acceptable object types, leaving some ambiguity for edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Like a post/comment/object' as the current identity, and even includes the endpoint pattern 'POST /{object-id}/likes'. This is specific enough to distinguish it from siblings like unlike_object and get_post_likes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the action and actor ('as current identity') and implies when to use it, but it does not explicitly mention alternatives such as unlike_object or clarify when not to use it. An agent can infer the intended use, but the guidance is not fully 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?
No annotations are present, so the description carries the behavioral transparency burden. It communicates that this is a POST/create operation and that the image URL must be publicly accessible, which is useful. However, it does not disclose permission requirements, side effects such as the published default, or behavior when page_id is null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action, gives the key constraint, and includes the endpoint. Every element adds value and there is no redundancy 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 output schema reduces the need to describe return values. Still, with no annotations and a nullable page_id, an agent may not know whether page_id is effectively required, what null means, or what the default published=true implies. The description is adequate but not complete 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 explain the parameters. It clarifies image_url as a public image URL and references page_id in the endpoint, but it does not explain caption, published behavior, or the meaning of a null page_id. Several parameters remain semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Upload a photo to a Page'), the input source ('a public image URL'), and the Graph API endpoint ('POST /{page-id}/photos'). This distinguishes it clearly from sibling tools like upload_page_video or the generic graph_api_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: uploading a photo from a public URL. It does not explicitly state when not to use it or name alternatives such as upload_page_video, but the source constraint and endpoint make the intended use reasonably unambiguous.
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. The explicit 'GET' method signals a non-mutating read, and 'type=uploaded' clarifies that only uploaded photos are returned. It does not mention pagination behavior or credential requirements, but these are partly inferable from parameters and the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the primary action front-loaded and the endpoint in parentheses. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool, the endpoint string and self-explanatory parameter names provide sufficient invocation detail, and the presence of an output schema covers return values. It lacks explicit credential or prerequisite notes, but that is a minor gap for this straightforward GET endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps page_id to the URL path '{page-id}', but limit and after are left unexplained; their semantics (page size, pagination cursor) are only guessed from their names. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List photos posted by the Page', and further clarifies via the endpoint 'GET /{page-id}/photos?type=uploaded'. This distinguishes it from sibling tools like get_page_videos or get_page_albums.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The resource name 'photos' implies the use case, and 'type=uploaded' narrows scope, but the description does not state when to prefer this over get_page_albums or get_page_videos, nor any 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 (no readOnlyHint, destructiveHint, etc.), the description must carry the full burden. It tells us it's a POST (mutation) of a comment. However, it doesn't disclose expectations like authentication requirements, visibility settings, or what a successful response contains (though an output schema exists). The behavioral trait of 'creates a comment' is clear, but other important context is left out, so a 3 is the fair baseline since the output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise, and front-loaded with the purpose. It includes the useful endpoint reference that adds value without bloat. 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 simple mutation tool with only 2 self-explanatory parameters and an output schema present, the description is quite complete. It clearly defines the action, the resource, and the endpoint. The only gap is the lack of explicit behavioral caveats (e.g., requiring authorization) and being only one of many similar-looking tools, but given the simplicity, the state is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters, both required, but 0% schema description coverage. The description doesn't elaborate on what 'message' or 'post_id' mean beyond their trivial names. However, 'post_id' is self-explanatory, and 'message' means the text of the comment. It adds minimal value beyond the schema, but the schema already provides enough via names. The lack of further documentation on format or constraints (e.g., length limits) leaves it at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does a great job: 'Post a new top-level comment on a post' clearly specifies the verb (post), the resource (a comment), and the scope (top-level, on a post). It even embeds the HTTP endpoint, which clearly distinguishes it from sibling tools like 'reply_to_comment' (which handles replies) and 'publish_page_post' (which posts the page's own post). This removes all ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description doesn't explicitly say 'use this instead of reply_to_comment when you want a top-level comment', the term 'top-level' does imply the usage context, contrasting it with 'reply_to_comment' which is for nested replies. The portal-level clarity is good, but it doesn't explicitly mention when not to use it or reference any specific alternative by name, so there is a small gap in proactive routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses a local read-only-style check, no network I/O, and that the result is only an existence report. It does not speculate about validation or side effects beyond those statements.
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 states the action, the object, and the key differentiator (no network call). There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, local status check with an output schema, the description is nearly complete. The only minor gap is not explicitly naming 'Facebook' credentials, though the sibling tools make that context clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4; there is nothing for the description to add about argument meaning. The input schema is empty and fully consistent with the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific action 'report' and the resource 'whether credentials exist on disk,' making the tool's scope unmistakable. 'Without any network call' distinguishes it from a credential validation/check sibling, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The local 'on disk' and 'without any network call' wording implies this is for a quick presence check, but the description never explicitly says when to prefer it over check_facebook_credentials or the set/clear variants. Usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that omitting reaction_type returns all types, and that each item includes a 'type' field, adding meaningful response behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the action and resource. The second paragraph earns its place by documenting filter values and output behavior without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with an output schema, the description covers the essential selection and filtering behavior. It lacks explicit pagination semantics for after/limit, but the schema defaults and parameter names provide reasonable guidance.
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%, and the description compensates well for reaction_type by enumerating valid values and explaining omission behavior. However, after and limit are not explained, and post_id is just the required resource identifier. Compensation is partial, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List reactions on a post with who reacted and how.' It clearly distinguishes this from sibling tools like get_post_comments and get_post_likes by focusing on reactions and the per-reaction type field.
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 intended use is clear: retrieve reactions on a post, optionally filtered by reaction_type. It does not explicitly name alternatives or state when not to use it, but the context makes the appropriate scenario obvious.
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 full burden of behavioral disclosure. It explains a non-obvious behavior: scheduling via published=False and scheduled_publish_time as a future Unix timestamp. It also includes the underlying endpoint. It does not cover side effects like visibility or error behavior, but the key behavioral nuance 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?
Two concise sentences deliver the essential information: the tool's core function and the critical exception for scheduling. No filler words. The structure front-loads the primary purpose and follows with necessary caveat, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of moderate complexity with one required parameter and an output schema available, the description covers the key operational detail (scheduling) and the primary action. It omits details like required permissions or response format, but those are less critical given the presence of an output schema and the tool's straightforward nature. The description is complete enough for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter explanations. It successfully explains the relationship between 'published' and 'scheduled_publish_time', which is non-trivial. However, it does not add any context for 'message', 'link', or 'page_id', leaving those to be inferred from their names and types. It partially compensates for the lack of schema descriptions but not completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Publish a new post on a Page', and supplements with the exact HTTP endpoint. It clearly differentiates from sibling tools like publish_comment or upload_page_photo by focusing on page posts and scheduling behavior. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scheduling instructions provide clear context on when to use this tool with specific parameter combinations. However, it does not explicitly guide against using it for comments or media uploads, nor does it reference alternative tools. The context is clear and focused, but exclusions and alternatives are not named.
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 burden of behavioral disclosure. It precisely specifies the file path, the exact operation ('Delete'), and the resulting state (credential file removed). This gives the agent clear expectations about the tool's side effects, which is adequate for a simple file deletion.
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, action-first sentence that directly states the verb and the resource. There is no filler or redundant text; every word contributes to understanding. It is perfectly sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, no annotations, and is a straightforward file deletion, the description covers all necessary operational details: what is deleted and where. While it could mention the impact on subsequent operations (e.g., requiring re-authentication), that is not essential for calling it correctly. The description is complete enough for the agent to execute the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is effectively empty. The description adds necessary context by explaining what the tool operates on (the credentials file path). Since there are no parameters to document, the description provides the only semantic information available, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (stored credentials file), and its exact location (~/.facebook-automata-mcp/credentials.json). It is specific and unambiguous, and clearly distinguishes this tool from credential-setting and checking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description unequivocally indicates the tool's purpose (deleting credentials), it does not explicitly state when to use it relative to alternatives like set_facebook_credentials or check_facebook_credentials. There is no guidance on prerequisites (e.g., must be authenticated) or when deletion is appropriate, but the action is self-evident enough that the lack of explicit guidance is acceptable.
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 makes the read-only nature clear via 'GET' and explains useful behavior: params are passed through as query parameters and access_token must not be included. However, with no annotations, it does not fully carry the burden of behavioral disclosure—auth assumptions, pagination, and error behavior are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place. The core purpose is front-loaded, and the usage guidance and token warning are packed in without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic catch-all tool, this is nearly complete: edge syntax, params behavior, token handling, and selection criteria are all covered. The output schema handles return shape, and the credential-related sibling tools imply the auth setup. Minor gaps around explicit auth requirements and pagination prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains `params` as pass-through query parameters and gives a concrete example for `edge` ('{id}/comments'). It could add more about edge formatting or accepted query parameter values, but it conveys the essential meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Generic GET against any Graph API edge.' It also explicitly positions itself as the catch-all for endpoints without a dedicated tool, which clearly separates it from the many 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly says 'Use this for any endpoint not covered by a dedicated tool.' This tells the agent exactly when to choose it over siblings and 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does it well. It discloses the credential sources (~/.facebook-automata-mcp/credentials.json and FACEBOOK_MCP_* environment variables), the exact Facebook API calls made, and the conditional /debug_token behavior depending on whether app credentials are configured.
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 the primary purpose front-loaded. The second sentence provides concrete technical detail without fluff, earning its place by explaining the validation mechanism and conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a zero-parameter, read-only check tool: it names credential sources, validation endpoints, conditional behavior, and the kind of information reported (scopes, expiry, validity). Since an output schema exists, explaining the return value shape is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so a baseline of 4 applies. The description correctly implies that the tool needs no arguments and instead reads from pre-existing configuration, which is all an agent needs to know.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Check whether Facebook credentials are configured and still valid,' which is a specific verb plus clear resource and goal. It further explains the exact validation flow (GET /me and /debug_token), making the purpose concrete and distinguishable from credential-setting or profile-fetching siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever an agent needs to verify that Facebook credentials exist and are still valid. However, it does not explicitly contrast itself with the similar sibling get_credentials_status or state when one should be preferred over the other.
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 full disclosure burden. It explains the critical caveat about Facebook's field restrictions for personal tokens and the behavior for page tokens, which is exactly the kind of behavioral nuance an agent needs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, immediately states the endpoint, and front-loads the purpose. The caveat sentence is essential and well-placed. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers the key contextual caveat about token types. The output schema presumably documents the return shape. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'fields' parameter but the description only mentions that fields are restricted, not how to format or use the parameter. Given schema coverage is 0% in the description, adding an example like 'fields=id,name' would help. Baseline 3 because the schema itself documents the parameter with a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the profile of the authenticated token's identity and maps it to the Graph API endpoint GET /me. Sibling tools like get_user_profile and get_page_info are distinguishable because this tool specifically targets the token owner's identity, not a specified user or page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for the authenticated identity and implicitly contrasts with page tokens, but it does not explicitly say when not to use it or point to alternatives like get_user_profile or get_page_info for other identities. The token-based scoping is clear, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are none, so the description carries full responsibility for behavioral disclosure. It reveals the permission requirement (read_insights), the exact endpoint used (GET /{page-id}/insights), and the structure of the metric parameter. It also implies that since and until are date boundaries for filtering the data. No annotations exist to contradict, but the description goes beyond basic info by clarifying prerequisites and parameter formatting, which is critical for an API call that might otherwise fail due to insufficient permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose in the first line and the necessary usage details in the following lines. It is front-loaded with the action and resource. One minor issue is that the permission requirement is placed after the endpoint, but it is still early enough. The example metric list is valuable and not redundant. Overall, it is well-structured and efficient, though not perfectly minimal.
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 moderate complexity (5 parameters, all optional, no schema descriptions) and the presence of an output schema (which covers return values), the description is largely complete. It covers prerequisites, metric formatting, period options, and the date range concept. The only gap is that it does not explicitly state default values or that all parameters are optional, but the schema shows defaults, so that is not a major issue. Thus, it is complete for effective use without excessive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage (0%) for the five parameters, so the description must compensate. It explicitly documents the metric parameter (comma-separated list, with examples) and the period parameter (allowed values: day, week, days_28, month, lifetime). It also implicitly explains since and until as date range filters via the endpoint path. It does not explain page_id, but that is a common identifier likely understood by the agent; overall, it covers the most complex parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Get Page analytics/insights (GET /{page-id}/insights)', specifying a verb (get), resource (Page analytics/insights), and the specific HTTP endpoint. It also provides concrete examples of metrics and periods, making the purpose unmistakable. While there are many sibling tools for page data, this one is uniquely about insights/analytics, so no confusion with siblings like get_page_posts or get_page_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: it requires a Page access token with read_insights permission, and it explains how to format the 'metric' parameter (comma-separated list) and lists acceptable values for 'period'. It does not explicitly state when not to use it or mention alternatives, but the guidance is clear for common use cases. The context signals show no schema descriptions for any parameters, so this guidance is essential and well-placed.
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?
No annotations are provided, so the description carries the full burden. It discloses several critical behaviors: where credentials are saved (file path), that saving is merged with existing fields (non-destructive overwrite), that validation happens immediately via a specific API call, and the security property that app_secret is never sent elsewhere. These go beyond a simple 'store credentials' statement and include state-change and validation behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with intro, purpose, and parameter breakdown. It is appropriately sized for the complexity of the tool. The header sentence is front-loaded and each parameter line earns its place by adding unique information. Minor redundancy exists (e.g., repeating 'optional' in prose and schema), but the structure is efficient for a setup tool with security nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and a moderately complex setup/validation flow. The description covers storage location, merge behavior, validation call, parameter roles, and security boundaries. An output schema exists for the response, so return-value explanation isn't required. For a setup tool with security and validation aspects, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. It does this thoroughly: each parameter has a purpose, optionality/requirement status, and even usage notes (e.g., long-lived tokens recommended, app_secret never sent except to graph.facebook.com). The API version default is also specified in text, compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Store'), a specific resource ('Facebook Graph API credentials'), and the immediate validation behavior. It clearly distinguishes this tool from siblings like check_facebook_credentials, get_credentials_status, and others by establishing it as the setup/prerequisite step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this once before using any other tool', which provides clear usage timing. However, it doesn't explicitly exclude or compare against sibling tools that might also handle credentials (e.g., get_credentials_status), though the context is clear enough for an agent to infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![Facebook-Automata-MCP MCP server](https://glama.ai/mcp/servers/ICWR-TEAM/Facebook-Automata-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ICWR-TEAM/Facebook-Automata-MCP)

Score Badge

Copy to your README.md:

[![Facebook-Automata-MCP MCP server](https://glama.ai/mcp/servers/ICWR-TEAM/Facebook-Automata-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ICWR-TEAM/Facebook-Automata-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/ICWR-TEAM/Facebook-Automata-MCP'

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