Facebook Scraper3 MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear distinctions for major categories like pages, groups, profiles, and search, but there is significant overlap within categories that could cause confusion. For example, 'comments' and 'comments_2' have ambiguous boundaries, and multiple search tools (e.g., 'search_post', 'search_video', 'search_hashtag') might be misselected due to similar purposes. Descriptions help clarify some differences, but the overlap is notable.
Naming Consistency4/5
Most tools follow a consistent verb_noun or noun_verb pattern with underscores, such as 'browse_games', 'get_group_details', and 'search_events'. There are minor deviations like 'page_id' (noun_noun) and 'reshares' (noun only), but overall the naming is predictable and readable across the set.
Tool Count2/5
With 40 tools, the count is excessive for a scraper server, leading to potential bloat and complexity. While Facebook has many data types, this many tools suggests over-fragmentation rather than a well-scoped set, making it harder for agents to navigate efficiently. A more consolidated approach with 15-25 tools would be more appropriate.
Completeness4/5
The tool surface covers a wide range of Facebook entities comprehensively, including pages, groups, profiles, events, posts, comments, and various search functions. Minor gaps exist, such as limited update or delete operations (expected for scraping), but agents can perform most data retrieval tasks without significant dead ends in the core workflows.
Average 2.9/5 across 40 of 40 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Searches people' gives no insight into whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination, sorting), or any rate limits. For a tool with zero annotation coverage, this is a critical gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Searches people' is brief, it is under-specified rather than concise. The single sentence fails to convey essential details about the tool's purpose or behavior, making it inefficient in communicating value. True conciseness balances brevity with clarity, which this description lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (search functionality often involves parameters like query terms, filters, or pagination), the description is woefully incomplete. With no annotations, no output schema, and a vague description, it fails to provide enough context for an agent to understand how to use the tool effectively or what to expect in return.
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 0 parameters with 100% description coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema already provides (i.e., no parameters). A baseline score of 4 is appropriate as the description doesn't contradict the schema and the schema fully covers the parameter landscape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Searches people' is a tautology that merely restates the tool name without adding specificity. It doesn't clarify what resource is being searched (e.g., a database, directory, or platform) or what 'people' means in this context. While it identifies the basic action, it lacks the verb+resource specificity needed to distinguish it from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'search' or 'profiles_details_by_id' that might serve similar purposes. This leaves the agent with no information to make an informed selection among available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails to describe any traits: it doesn't specify if this is a read-only or mutating operation, what the search scope or limitations are, authentication needs, rate limits, or output format. This leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise ('Searches group for posts') but under-specified, not efficiently front-loaded with useful information. While it avoids verbosity, it fails to earn its place by adding value beyond the tool name, making it inefficient rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'search' functionality, lack of annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'search' means, how results are returned, or differentiate from similar tools, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is acceptable here. A baseline of 4 is appropriate as the schema fully handles the parameter semantics without requiring compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Searches group for posts' restates the tool name 'search_groups_posts' almost verbatim, making it tautological. It lacks specificity about what 'search' entails (e.g., keyword-based, filter-based) and doesn't differentiate from sibling tools like 'get_group_posts' or 'search_post', leaving the purpose vague beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With sibling tools like 'get_group_posts' (likely for listing) and 'search_post' (likely broader search), the description offers no context, exclusions, or prerequisites, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get events details' implies a read-only operation but doesn't specify authentication requirements, rate limits, error conditions, or what format/details are returned. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get events details') but under-specified rather than efficiently informative. While it's brief, it fails to provide necessary context about what 'events' means or how this differs from similar tools, making it more of an incomplete placeholder than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and multiple sibling tools with similar names, the description is inadequate. It doesn't explain what 'events' refers to, what details are returned, or how this differs from 'events_details_by_id' or 'search_events'. For a tool in this context, more specificity is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so there's no parameter information needed in the description. The baseline for zero parameters is 4, as the description doesn't need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get events details' is a tautology that essentially restates the tool name 'events_details_by_url' without adding meaningful clarification. It doesn't specify what 'events' refers to in this context or what kind of details are retrieved, nor does it differentiate from sibling tools like 'events_details_by_id' or 'search_events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With sibling tools like 'events_details_by_id' and 'search_events' available, there's no indication whether this tool is for retrieving events by URL specifically, what context it applies to, or any prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('Getting') but doesn't specify whether authentication is needed, rate limits apply, or what the output format might be. The description is too vague to provide meaningful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Getting group facebook id'), which is efficient but under-specified. It lacks structure and fails to provide necessary context, making it more of an under-description than an example of good conciseness.
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 simplicity (0 parameters, no output schema), the description is incomplete. It doesn't explain what a 'group facebook id' is, how it's retrieved, or what the result looks like, leaving significant gaps for an agent to understand and use the tool effectively.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, but with no parameters, a baseline score of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Getting group facebook id' restates the tool name 'get_group_id' with minimal variation, making it tautological. It specifies the resource ('group facebook id') but lacks a clear verb beyond the implied 'get' from the name, and doesn't differentiate from sibling tools like 'get_group_details' or 'page_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites, context, or exclusions, leaving the agent with no information on appropriate usage scenarios compared to similar tools in the sibling list.
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. 'Get group summary' implies a read operation, but it doesn't specify whether this requires authentication, what format the summary returns, whether there are rate limits, or what happens if the group doesn't exist. For a tool with zero annotation coverage, this minimal description leaves critical behavioral traits undocumented.
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 at just three words. There's no wasted language or unnecessary elaboration. While it's under-specified in terms of content, it's perfectly efficient in terms of word count and structure. Every word earns its place, making it a model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (0 parameters, no output schema), the description is still inadequate. 'Get group summary' doesn't explain what a 'group summary' contains, how it differs from other group-related tools, or what the agent can expect as a result. With no annotations and no output schema, the description should provide more context about the tool's behavior and output to be complete enough for effective use.
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 0 parameters with 100% schema description coverage, so the schema fully documents the parameter requirements. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. The baseline for 0 parameters with complete schema coverage is 4, as there's no parameter semantics burden on the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get group summary' is a tautology that essentially restates the tool name 'get_group_details'. It doesn't specify what constitutes a 'group summary' or differentiate this tool from sibling tools like 'get_group_future_events', 'get_group_posts', or 'get_group_id'. The purpose is vague and lacks specificity about what resource or information is actually retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With multiple sibling tools related to groups (get_group_future_events, get_group_posts, get_group_id), there's no indication of what distinguishes this tool's purpose or when it should be selected over those other group-related tools. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Get listing details' implies a read-only operation, but it does not specify permissions, rate limits, error conditions, or the format of returned details. This is inadequate for a tool with no annotation coverage, as critical behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for a tool with no parameters, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (implied by sibling tools suggesting data retrieval) and lack of annotations and output schema, the description is incomplete. It does not explain what a 'listing' is, what details are returned, or how it differs from similar tools, leaving significant gaps for an agent to understand its full context and use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is acceptable given the schema's completeness. A baseline of 4 is appropriate as the description does not compensate for any gaps, but none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get listing details' restates the tool name 'listing_details' with minimal elaboration, making it tautological. It specifies a verb ('Get') and resource ('listing details') but lacks specificity about what a 'listing' refers to in this context or what details are retrieved, failing to distinguish it from sibling tools like 'page_details' or 'profile_details_by_url'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With sibling tools like 'page_details', 'profile_details_by_url', and 'search', the description offers no context, prerequisites, or exclusions, leaving the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Read page details' implies a read-only operation but doesn't specify what 'details' include, whether authentication is required, rate limits, error conditions, or how pages are identified. This leaves significant behavioral gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action ('Read page details'). There's no wasted language or unnecessary elaboration, making it efficient for quick scanning.
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 complexity of sibling tools and lack of annotations or output schema, the description is insufficient. It doesn't explain what 'page details' entail, how pages are selected, or what the return format looks like. For a tool in a crowded namespace with no structured output documentation, more context is needed to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps, and it correctly implies no required inputs by not mentioning any. This meets the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read page details' is a tautology that restates the tool name 'page_details' with a generic verb. It doesn't specify what kind of page, what details are returned, or how this differs from sibling tools like 'page_id', 'page_posts', or 'page_events'. The purpose is vague and lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With many sibling tools like 'page_id', 'page_posts', and 'page_events' that might retrieve specific aspects of pages, there's no indication of what makes this tool distinct or when it should be preferred over others.
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 mentions pagination ('Use cursor to get next page'), which is useful context, but doesn't cover other critical aspects like authentication needs, rate limits, error handling, or what the search results look like. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences: 'Search marketplace. Use cursor to get next page.' Every word earns its place—the first states the purpose, and the second adds crucial behavioral context. It's front-loaded and wastes no space, making it highly efficient.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'marketplace' entails, how results are returned, or any limitations. The pagination hint is helpful, but overall, it lacks sufficient detail for an AI agent to use the tool effectively without guesswork.
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 0 parameters with 100% coverage, so there are no parameters to document. The description adds value by mentioning the cursor for pagination, which is a behavioral aspect not covered by the schema. This compensates well for the lack of parameters, earning a score above the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search marketplace' states the action (search) and target (marketplace), but it's vague about what 'marketplace' refers to in this context. It doesn't distinguish from many sibling tools like 'search_events', 'search_groups_posts', 'search_pages', etc., which all perform searches but on different resources. The description is too generic to clearly differentiate this tool's specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling search tools (e.g., 'search_events', 'search_pages', 'search_people'), there's no indication of what makes 'search' different—whether it's a general search across all resources or specific to marketplace items. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving data ('Get page reels') but doesn't specify whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination, format), or any rate limits. The phrase 'use reels_page_id now' hints at a parameter requirement, but this contradicts the input schema which has no parameters, creating confusion about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two short phrases, but it's not well-structured or front-loaded. The first part 'Get page reels by page id' is clear, but the second part 'use reels_page_id now' is ambiguous and doesn't add value, reducing conciseness. It could be more streamlined by removing the confusing second phrase.
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 no input parameters and no output schema, the description should fully explain what the tool does and what it returns. It states the purpose but lacks details on behavioral aspects like data format, pagination, or error handling. The confusing additional phrase further undermines completeness, making it inadequate for a tool that might return complex data like 'reels'.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add any parameter information beyond what the schema provides, which is appropriate here. However, the phrase 'use reels_page_id now' could be misinterpreted as a parameter hint, but since there are no parameters, this doesn't detract significantly from the baseline score of 4 for zero-parameter tools.
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 the tool's purpose as 'Get page reels by page id', which is a clear verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'profile_reels' or 'page_videos', leaving ambiguity about what specifically differentiates 'page reels' from other reel or video retrieval tools. The phrase 'use reels_page_id now' is confusing and doesn't clarify the purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'profile_reels' or 'page_videos', nor does it specify any prerequisites, contexts, or exclusions for usage. The vague directive 'use reels_page_id now' adds confusion rather than clarity, failing to offer meaningful usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Search for fb place' implies a read-only operation but doesn't specify any behavioral traits such as authentication needs, rate limits, result format, or pagination. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action ('Search') and target ('fb place'). There is no wasted language, making it efficient for quick comprehension.
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, no output schema, and zero parameters, the description is incomplete. It doesn't explain what 'fb place' entails, how results are returned, or any usage constraints, leaving significant gaps for the agent to operate effectively.
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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, a baseline score of 4 is appropriate as no compensation is needed for schema gaps.
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 'Search for fb place' clearly indicates a search operation targeting Facebook places, which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling search tools like 'search_events', 'search_pages', or 'search_people', leaving ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling search tools (e.g., search_events, search_pages), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without any details on how the search works (e.g., pagination, rate limits, authentication needs, or what the output looks like). For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly. Every word earns its place by stating the core function.
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 complexity of a search operation, lack of annotations, no output schema, and many similar sibling tools, the description is incomplete. It doesn't explain what the search returns, how results are filtered, or behavioral aspects like performance or errors. For a tool in this context, more detail is needed to be fully helpful.
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 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add param info, but since there are no params, a baseline of 4 is appropriate as it doesn't need to compensate for any gaps. It's sufficient for a parameterless tool.
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 'Performs facebook posts search' states the action (search) and resource (facebook posts), which is clear but vague. It doesn't specify what kind of search (e.g., keyword-based, filtered by date, etc.) or how it differs from sibling tools like 'search', 'search_groups_posts', or 'search_hashtag', which also search Facebook content. This lack of differentiation keeps it at a basic level.
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. With many sibling tools like 'search', 'search_groups_posts', and 'search_hashtag' that also perform searches, the description offers no context, prerequisites, or exclusions to help an agent choose appropriately. This omission leaves usage unclear.
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 mentions 'legacy fb id' as a requirement, which hints at authentication or input needs, but doesn't disclose behavioral traits like rate limits, pagination, or what 'nested' entails (e.g., depth levels). This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with two sentences: one stating the purpose and another noting a requirement. There's no unnecessary fluff, and it's front-loaded with the main action. However, it could be more structured by explicitly separating purpose from prerequisites.
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 complexity of fetching nested comments and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'nested' means, the return format, or error handling. For a tool with potential depth and data richness, more context is needed to guide effective use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by implying a requirement ('legacy fb id'), though it's not formalized in the schema. This compensates slightly for the lack of structured parameters, earning a baseline score above 3.
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 the tool 'Get nested comments' which provides a clear verb ('Get') and resource ('nested comments'), but it doesn't specify what resource these comments belong to (e.g., posts, videos) or distinguish it from sibling tools like 'comment_by_id' or 'post_reactions'. The mention of 'legacy fb id' adds some specificity but doesn't fully clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'comment_by_id' or 'post_reactions', nor does it specify prerequisites such as needing a Facebook ID. Without context, an agent might struggle to choose between this and other comment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description reveals this is a read operation ('Get'), but provides no information about authentication needs, rate limits, pagination, error conditions, or what format the videos are returned in. For a tool with zero annotation coverage, this leaves the agent with insufficient behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that both add value. The first states the purpose, the second provides a critical warning. There's no wasted language, though the ALL-CAPS emphasis could be considered slightly excessive stylistically.
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 complexity of video retrieval operations and the lack of both annotations and output schema, the description is incomplete. It doesn't explain what 'videos' means in this context (metadata, URLs, thumbnails?), how results are structured, whether there are limitations on what videos can be accessed, or any error conditions. For a tool in a crowded namespace with no structured support, this leaves too many questions unanswered.
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 0 parameters with 100% coverage, so the baseline is 4. The description adds value by clarifying that the tool operates on 'page delegate id' and specifically warns against using 'page id', which is helpful semantic context even though no formal parameters exist in the schema.
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 the tool's purpose ('Get page videos by page delegate id'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from its many sibling tools (like 'page_reels', 'pages_photos', or 'search_video'), leaving the agent to guess when this specific video-fetching operation is appropriate versus 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?
The description provides no guidance on when to use this tool versus alternatives. While it warns 'YOU NEED TO USE DELEGATE ID, NOT PAGE ID', this is a parameter usage note rather than contextual guidance about when this tool is appropriate. With 30+ sibling tools including other video-related ones, the absence of when/when-not instructions is a significant gap.
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 mentions the tool reads posts and specifies 'if public', which hints at access constraints, but fails to disclose critical behavioral traits such as rate limits, authentication needs, pagination, error handling, or what 'recent' means. This leaves significant gaps for safe and effective tool invocation.
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, efficient sentence that front-loads the core action ('Read profile posts') with qualifying details ('from recent', 'if public'). There is no wasted text, making it appropriately concise for a simple tool, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is incomplete. It lacks details on return values (e.g., format, fields), error conditions, or behavioral constraints like rate limits. For a read operation with potential access issues ('if public'), more context is needed to ensure reliable use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it doesn't contradict the schema. A baseline of 4 is appropriate as the description compensates by not introducing unnecessary complexity.
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 the tool reads profile posts and specifies they are 'from recent' and 'if public', which provides some scope. However, it doesn't clearly distinguish this tool from siblings like 'profiles_details_by_id', 'get_group_posts', or 'pages_posts', leaving ambiguity about what makes this tool unique. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by implying usage for recent, public profile posts, but it doesn't explicitly state when to use this tool versus alternatives like 'profile_details_by_url' or 'search_post'. No exclusions, prerequisites, or clear context for tool selection are provided, leaving the agent with little direction.
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 only states the action ('Get') without details on permissions, rate limits, error handling, or response format. This leaves significant gaps for a tool that likely involves data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise ('Get profiles details by id'), consisting of a single, direct sentence with no wasted words. It is front-loaded and efficient, though it could benefit from slightly more detail to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include, how IDs are formatted, or what the return values look like, leaving the agent with insufficient context for effective use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but this is acceptable given the schema's completeness, aligning with the baseline for zero parameters.
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 the tool's purpose ('Get profiles details by id'), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'profile_details_by_url' or 'profile_id', making it somewhat vague about its specific scope compared to 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 'profile_details_by_url' or 'profile_id'. The description lacks context about prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get', implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the return format might be. This leaves significant gaps for a tool that likely interacts with user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Get comment by comment id'), front-loaded with the core purpose. There's zero wasted text, making it efficient and easy to parse, though this conciseness comes at the cost of detail in other dimensions.
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 complexity of retrieving a comment (likely involving user data and potential privacy considerations), no annotations, no output schema, and a sparse description, this is incomplete. The description doesn't explain what a 'comment' is in this system, what data is returned, or any behavioral traits, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate here, earning a baseline score of 4 as it doesn't need to compensate for any schema gaps.
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 'Get comment by comment id' clearly states the verb ('Get') and resource ('comment'), but it's vague about scope and doesn't distinguish from sibling tools like 'comments' or 'comments_2'. It specifies retrieval by ID but lacks detail on what a 'comment' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'comments' (which might list multiple comments) or other comment-related tools. The description implies it's for retrieving a specific comment by ID, but there's no explicit mention of prerequisites, exclusions, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying safety, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'details' includes. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but vague purpose, the description is incomplete. It doesn't explain what 'details' includes, potential response formats, or error cases, leaving the agent with insufficient context for reliable use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying 'by event id', which clarifies the implicit context for retrieval, though it doesn't detail how the ID is provided (e.g., in URL or headers). Baseline is 4 for zero parameters.
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 'Get events details by event id' clearly states the verb ('Get') and resource ('events details'), but it's vague about what 'details' entails and doesn't differentiate from siblings like 'events_details_by_url' or 'search_events'. It's functional but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'events_details_by_url' or 'search_events'. The description implies usage by event ID but doesn't specify prerequisites, exclusions, or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read operation, but it doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or what happens if no reactions exist. This is inadequate for a tool with zero annotation coverage.
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—just three words—and front-loaded with the core action. There's no wasted language, making it easy to parse quickly, though this conciseness comes at the cost of detail in other dimensions.
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 output schema, the description is incomplete. It doesn't explain what 'post reactions' entails (e.g., types, format) or the return values, leaving significant gaps for the agent to infer behavior in a context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's acceptable here—it implies the tool requires no inputs, which aligns with the schema. Baseline is 4 for 0 parameters.
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 'Get post reactions' states a clear verb ('Get') and resource ('post reactions'), but it's vague about scope—does it get reactions for a specific post, all posts, or something else? It doesn't distinguish from siblings like 'get_post_details' or 'comments', which might also involve post-related data.
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. With siblings like 'get_post_details', 'comments', and 'search_post', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get') but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'profile details' includes (e.g., fields, format). This leaves significant gaps for a tool that likely fetches user data.
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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it highly concise and well-structured for its 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'profile details' returns, potential errors, or behavioral traits like data freshness or access restrictions. For a tool that likely interacts with user profiles, this leaves the agent under-informed.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds minimal context by implying a URL-based lookup, but since there are no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for schema gaps.
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 'Get profile details by url' states the action (get) and resource (profile details) but is vague about what 'profile details' entails and doesn't differentiate from siblings like 'profile_id' or 'profiles_details_by_id'. It's functional but lacks specificity about scope or content.
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 'profile_id' or 'profiles_details_by_id'. The description implies usage by URL but doesn't clarify prerequisites, exclusions, or comparative contexts with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('searches') without detailing behavioral traits such as authentication requirements, rate limits, pagination, or what the search returns (e.g., list of events, error handling). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized for a tool with no parameters, front-loading the core action ('searches') and resource ('facebook events'). Every part of the description earns its place by conveying the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a search tool with no parameters but no output schema) and the lack of annotations, the description is incomplete. It does not explain what the tool returns (e.g., event details, error messages) or any behavioral context like search criteria or limitations. Without an output schema or rich annotations, the description should provide more context to be fully helpful.
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 0 parameters with 100% coverage, meaning there are no parameters to document. The description does not need to add parameter semantics beyond the schema. A baseline score of 4 is appropriate as the schema fully covers the parameter information (or lack thereof), and the description does not contradict it.
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 'Searches for facebook events' clearly states the verb ('searches') and resource ('facebook events'), providing a basic purpose. However, it lacks specificity about what constitutes a search (e.g., by keyword, date, location) and does not distinguish it from sibling tools like 'page_events', 'get_group_future_events', or 'search' (which might overlap in functionality). This makes it vague in scope compared to 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. The description does not mention any context, prerequisites, or exclusions, and it fails to reference sibling tools like 'page_events' or 'search' that might serve similar purposes. This leaves the agent without direction on selecting the appropriate tool for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the action 'search' without any details on permissions, rate limits, output format, or other behavioral traits, making it insufficient for a tool with potential complexity.
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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it highly concise and well-structured for its 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'posts' entail, how results are returned, or any constraints, leaving significant gaps for a search tool that might involve complex behavior or data structures.
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 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The description appropriately doesn't add unnecessary details, earning a high baseline score for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'posts with hashtag', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_post', 'search_video', or other search variants, which would require more specificity to reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_post' or 'search_video'. The description only states what it does, not the context or exclusions for its use, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Performs facebook videos search') without any details on permissions, rate limits, output format, or other behavioral traits. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Performs facebook videos search', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.
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 complexity of a search tool with no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what the search returns, how results are formatted, or any behavioral aspects, making it inadequate for an agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the description doesn't need to compensate for missing parameter information.
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 'Performs facebook videos search' clearly states the action (search) and resource (Facebook videos), which meets the basic requirement for purpose clarity. However, it lacks specificity about what kind of search it performs (e.g., by keyword, user, date) and doesn't distinguish it from sibling tools like 'search' or 'page_videos', making it somewhat 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. It doesn't mention any context, prerequisites, or exclusions, and with sibling tools like 'search' and 'page_videos' available, there's no indication of how this tool differs or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get post comments' implies a read-only operation, but it doesn't disclose behavioral traits like whether it requires authentication, rate limits, pagination, error conditions, or what format the comments are returned in. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, making it front-loaded and efficient. However, the second sentence 'Use comment_id from post' is somewhat ambiguous and could be clarified, slightly reducing effectiveness. Overall, it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is incomplete. It doesn't explain what 'Get post comments' returns (e.g., list of comments, their structure, or how to handle the 'comment_id' dependency). For a tool with zero structured data, more detail on behavior and output is needed to be fully helpful.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds value by implying a dependency on 'comment_id from post', which suggests context or prerequisites not captured in the schema. This compensates for the parameter-less design, earning a baseline above 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get post comments' specifies the verb (get) and resource (comments). It distinguishes from sibling 'comment_by_id' by implying it retrieves multiple comments rather than a single one. However, it doesn't explicitly differentiate from the sibling tool 'comments' which appears to have a similar name and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Use comment_id from post' suggests a prerequisite or context but doesn't explain when to use this tool versus alternatives like 'comment_by_id' or 'comments'. No explicit when/when-not instructions or comparison to sibling tools are provided, leaving usage unclear.
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 mentions that results can be 'strange' and suggests query adjustments, which adds some context about potential issues. However, it lacks details on authentication needs, rate limits, error handling, or what the output looks like, leaving significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's function and usage tips. It's front-loaded with the main purpose and avoids unnecessary details, though it could be slightly more structured by separating purpose from troubleshooting advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is incomplete. It explains the purpose and offers query tips but fails to cover behavioral aspects like response format, error cases, or integration with sibling tools, making it inadequate for full agent understanding.
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 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, but since there are no parameters, this is acceptable, and it provides query tips that could be considered implicit parameter guidance.
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 the purpose is to search for Facebook location IDs, which is a clear verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'search_place' or 'search', leaving ambiguity about when to use this specific location search versus other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by suggesting to add a country or remove diacritics for better results, which hints at when to adjust queries. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_place' or general 'search', nor does it define 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 provided, the description carries full burden for behavioral disclosure. It mentions pagination ('Use cursor to get next page'), which adds some context about data retrieval behavior. However, it doesn't address critical aspects like rate limits, authentication requirements, error conditions, or what constitutes a 'page review' versus other content types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short sentences that each serve distinct purposes: stating the core function and providing pagination guidance. There's zero wasted text, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic functionality and pagination context. However, for a data retrieval tool, it should ideally clarify what 'reviews' means in this context and what format/scope the data returns, especially with many sibling tools that might overlap in functionality.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds value by mentioning cursor-based pagination, which provides context about how to navigate results even though no explicit parameters exist in the schema.
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 the tool's purpose as 'Get page reviews', which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'page_details' or 'page_posts', leaving ambiguity about what specifically distinguishes this tool from other page-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Use cursor to get next page', which hints at pagination usage but doesn't explain when to use this tool versus alternatives like 'page_details' or 'page_posts'. No explicit when/when-not guidance or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination behavior ('Use cursor to get next page'), which is useful, but lacks details on authentication needs, rate limits, error handling, or what 'game live videos' entails (e.g., format, availability). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 two short sentences with zero wasted words, front-loading the core purpose. It efficiently conveys key information, though it could be slightly more structured by separating purpose from behavioral notes. Every sentence earns its place, making it appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate. It states the purpose and hints at pagination behavior, but lacks details on return values, error cases, or integration context. For a tool fetching 'game live videos', more context on what constitutes such videos or how they differ from other video types would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by mentioning 'Use cursor to get next page', which implies a cursor-based pagination mechanism not evident from the schema. This provides useful semantic context beyond the empty schema, justifying a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'game live videos', making the purpose understandable. It distinguishes from siblings like 'page_videos' or 'profile_reels' by specifying 'game live' content, though it doesn't explicitly contrast with all similar tools. The purpose is specific but could be more precise about what distinguishes it from other video-fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'page_videos', 'profile_reels', or 'search_video'. It mentions pagination with 'Use cursor to get next page', which implies usage for sequential data retrieval, but offers no context on prerequisites, exclusions, or comparative scenarios with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals little about behavior. It states it 'gets' events (implying read-only) but doesn't disclose pagination, rate limits, authentication requirements, error conditions, or what 'created by page' precisely means. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple sibling tools with overlapping functions, the description is incomplete. It doesn't explain what data is returned, how events are filtered or sorted, or how this tool differs from other event-related tools. For a tool in this context, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable since there are no parameters to explain. Baseline 4 is appropriate for zero-parameter tools.
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') and resource ('future events created by page'), making the purpose understandable. It distinguishes from sibling 'page_past_events' by specifying 'future' events, but doesn't differentiate from 'events_details_by_id' or 'search_events' which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'page_past_events', 'events_details_by_id', or 'search_events'. It mentions 'future events' but doesn't specify if this is the primary tool for event retrieval or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('get') but doesn't describe what 'get' entails—e.g., whether it's a read-only operation, if it requires authentication, rate limits, or error handling. For a tool with zero annotation coverage, this is a significant gap, as it leaves the agent guessing about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('get page id from url')—just four words—with zero wasted language. It's front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
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 simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and many sibling tools, it lacks completeness in usage guidelines and behavioral context. For a tool that likely involves network calls or data retrieval, more detail on behavior would be helpful, making it incomplete in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description implies the input ('from url') but doesn't add semantics beyond the schema, which is fine here. Baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps.
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 'get page id from url' clearly states the verb ('get') and resource ('page id'), with the input ('from url') implied. It distinguishes from siblings like 'page_details' or 'profile_id' by specifying the resource type. However, it doesn't explicitly differentiate from 'get_group_id' or 'profile_id', which serve similar purposes for other resources, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with many sibling tools (e.g., 'page_details', 'profile_id'), there's no indication of when this specific tool is appropriate. The implied usage is minimal, lacking explicit alternatives or constraints.
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 mentions 'Read' and 'from recent', implying a read-only operation with a recency filter, but lacks details on permissions, rate limits, pagination, or return format. This is inadequate for a tool with zero annotation coverage.
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, efficient phrase with no wasted words. It is front-loaded with the core purpose ('Read page posts') and includes a useful qualifier ('from recent'), making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is minimal. It states the basic action but lacks essential context like what 'recent' means, how results are returned, or error handling. This is insufficient for a tool in a complex environment with many siblings.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it implies a recency constraint not reflected in the schema, slightly enhancing context. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read page posts (from recent)' clearly states the action (read) and resource (page posts), with the qualifier '(from recent)' adding specificity about recency. However, it does not explicitly distinguish this tool from sibling tools like 'get_group_posts' or 'profile_posts', which limits differentiation.
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. With many sibling tools (e.g., 'get_group_posts', 'profile_posts', 'search_pages'), there is no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
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 tool 'Get's data, implying a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the return value looks like (e.g., format, potential null cases). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the key action and resource. Every word earns its place, making it efficient and easy to parse without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'profile id' means in this context, how it's derived from the URL, or what the return value includes (e.g., a string, object, or error cases). For a tool with no structured support, more detail is needed to guide effective use.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description implies the tool uses a URL as input contextually, but since no parameters are defined, this doesn't add or detract from the schema. A baseline of 4 is appropriate as the schema fully handles the parameter aspect.
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') and resource ('profile id'), specifying it operates 'by url'. However, it doesn't distinguish itself from sibling tools like 'profile_details_by_url' or 'profiles_details_by_id', which might offer similar or overlapping functionality, leaving some ambiguity about its unique role.
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. With siblings like 'profile_details_by_url' and 'profiles_details_by_id', the description lacks any indication of prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get post reshares' implies a read operation, but it doesn't specify whether this requires authentication, how results are returned (e.g., pagination, format), or any rate limits. This leaves significant gaps for an agent to understand how to invoke it effectively.
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 at three words ('Get post reshares'), front-loaded with the core action, and has no wasted words. Every element earns its place by clearly stating the purpose without unnecessary 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 output schema, the description is incomplete for a tool that likely returns data (e.g., reshare lists). It doesn't explain what 'reshares' entails (e.g., users, counts, timestamps) or the return format, leaving the agent with insufficient context to handle the output effectively.
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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since there are none. It adds no semantic value beyond the schema, but with zero parameters, the baseline score is 4 as it doesn't need to compensate for missing information.
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 'Get post reshares' clearly states the verb ('Get') and resource ('post reshares'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'post_reactions' or 'get_post_details', which also operate on posts, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. With siblings like 'post_reactions' and 'get_post_details' that might overlap in context, there's no indication of when this specific tool is appropriate or what distinguishes it from other post-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Searches for facebook pages' implies a read-only operation, but provides no information about authentication requirements, rate limits, result format, pagination, or search criteria. For a search tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and gets straight to the point without unnecessary elaboration.
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 apparent simplicity (0 parameters, no output schema), the description is incomplete. It doesn't explain what constitutes a successful search, what format results are returned in, or how the search is conducted. For a search tool among many similar search siblings, more context about scope and behavior would be helpful.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps, and the baseline for this situation is 4. The description appropriately doesn't mention parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('searches') and resource ('facebook pages'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search', 'search_people', or 'search_place', which all perform similar search operations on different resource types, so it doesn't reach the highest clarity level.
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. With multiple sibling search tools available (search, search_people, search_place, etc.), there's no indication of what makes this tool specifically for pages or when it should be preferred over other search options.
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 mentions the input logic ('If both are set, post id is used'), which adds some context, but fails to describe key behaviors such as what 'post details' includes, error handling, or any rate limits or permissions needed. This leaves significant gaps for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a clarifying rule. Every word earns its place with no redundancy or waste, making it highly efficient and easy to parse.
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 output schema, the description is incomplete. It explains input logic but doesn't cover what 'post details' returns, potential errors, or other behavioral aspects. For a tool in this context, more information is needed to fully guide an AI agent, especially with many sibling tools available.
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 0 parameters with 100% coverage, so no parameters are documented in the schema. The description compensates by explaining the input options ('by url or post id') and their precedence ('post id is used'), adding meaningful semantics beyond the empty schema. This is appropriate for a tool with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get post details by url or post id.' It specifies the verb ('Get') and resource ('post details'), and mentions the input options. However, it doesn't explicitly differentiate from sibling tools like 'post_reactions' or 'search_post', which slightly limits its clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'If both are set, post id is used,' which helps prioritize inputs. However, it lacks explicit when-to-use advice compared to alternatives (e.g., when to use this vs. 'search_post' or 'post_reactions'), and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination behavior ('Use cursor to get next page of results'), which is useful, but lacks details on permissions, rate limits, error handling, or what 'recent' means (e.g., time frame). This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly convey the tool's purpose and key behavioral trait (pagination). Every word earns its place, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and pagination, but lacks details on return values (e.g., photo format, metadata) and other contextual factors like authentication or limits, which are important for a read operation.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the cursor-based pagination mechanism, which compensates for the lack of parameters in the schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Read') and resource ('page photos'), and specifies the scope ('from recent'). However, it doesn't explicitly differentiate from sibling tools like 'profiles_photos' or 'pages_posts', which might handle similar photo-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for paginated reading of recent photos via cursor-based navigation, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'profiles_photos' or 'page_reels'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a dependency on another endpoint for 'reels_profile_id', which adds some behavioral context, but fails to disclose critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part earns its place by stating the purpose and providing a key usage note, making it efficient and well-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 has 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and a usage hint, but for a tool with no annotations, it should ideally include more about behavioral aspects like response format or error handling to be fully complete, leaving room for improvement.
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 0 parameters, and schema description coverage is 100%, so the schema fully documents the lack of inputs. The description adds value by explaining that 'reels_profile_id' should be obtained from another endpoint, providing context beyond the schema, though this is more about usage than parameter semantics specifically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'profile reels', making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'page_reels' or 'profile_posts', which might also retrieve reels or related content, leaving some ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning to get 'reels_profile_id' from another endpoint, suggesting a prerequisite or context for when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like 'page_reels' or provide clear exclusions, relying on implied context rather than direct 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 provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the scope ('from recent') and pagination behavior ('Use cursor to get next page of results'), which are not obvious from the tool name alone. However, it lacks details on permissions, rate limits, or response format, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly address purpose and pagination. Every word earns its place, and it's front-loaded with the core functionality, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and pagination, but for a read operation with no structured output details, it could benefit from clarifying what 'profiles photos' entails (e.g., user avatars, uploaded images) or example use cases.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, earning a baseline score of 4 for not adding unnecessary information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Read profiles photos (from recent)', which specifies the verb (read), resource (profiles photos), and scope (from recent). However, it doesn't explicitly differentiate from sibling tools like 'pages_photos' or 'profile_details_by_url', which might handle similar resources differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pagination with 'Use cursor to get next page of results', but this is a behavioral detail rather than usage context. There's no mention of prerequisites, exclusions, or comparisons to sibling tools like 'pages_photos' or 'profile_posts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits like the public-group requirement and pagination via cursor, but lacks details on rate limits, authentication needs, or error handling. The information is helpful but incomplete for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and key constraints in three concise sentences. Each sentence adds useful information (purpose, access rule, pagination), with no wasted words, though minor improvements in flow could make it a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description covers essential aspects like purpose, access rules, and pagination. However, it lacks details on return values, error cases, or performance limits, making it adequate but with clear gaps for a tool that might handle complex event data.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by mentioning the cursor for pagination, which is an implied parameter not in the schema, earning a score above the baseline of 3.
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 the tool's purpose as 'Get group future events,' which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'page_events' or 'search_events,' leaving ambiguity about when to use this specific tool versus alternatives.
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 explicit usage guidance: 'Only PUBLIC groups can be scrapped! If there are no post response, check if group is not private.' This clarifies when the tool works (public groups) and troubleshooting steps, though it doesn't explicitly name alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool scrapes data (not API-based) and only works on public groups, which are important behavioral traits. However, it doesn't disclose rate limits, authentication needs, pagination, or what format the posts are returned in.
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 appropriately brief (two sentences) and front-loaded with the core purpose. The second sentence adds important usage guidance. There's no wasted text, though it could be slightly more structured with bullet points or clearer separation of concerns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description provides adequate context about the scraping behavior and public-only restriction. However, for a data retrieval tool, it should ideally mention what data is returned (post content, metadata, etc.) and any limitations like date ranges or result limits.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description doesn't need to add parameter information, and the baseline for this situation is 4 according to the scoring guidelines.
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 the tool 'Get group posts' which is a clear verb+resource combination, but it doesn't specify what type of posts or how they're retrieved (scraped vs API). It doesn't distinguish from sibling tools like 'get_group_details' or 'search_groups_posts' which might serve similar purposes.
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 explicit guidance about when to use it ('Only PUBLIC groups can be scrapped!') and what to check if there's no response ('check if group is not private'). However, it doesn't mention alternatives like 'search_groups_posts' or 'get_group_details' which might be better for specific use cases.
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 full burden. It discloses pagination behavior ('Use cursor to get next page') which is valuable, but doesn't mention other important traits like whether this is a read-only operation, rate limits, authentication needs, or what format the results come in. The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each serve distinct purposes: the first establishes the core function, the second provides critical usage guidance. Every word earns its place with zero wasted text, making it easy to parse and understand 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?
Given the tool has no parameters (simple input), no annotations, and no output schema, the description provides adequate but minimal context. It explains the browsing behavior and pagination, but doesn't describe what 'games' means in this context, what data is returned, or how results are structured. For a tool with zero structured metadata, more completeness would be helpful.
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 0 parameters with 100% schema description coverage, so the baseline would be 4 even with no parameter information in the description. However, the description actually adds value by explaining the implicit behavior: 'Use empty query for browse all games' clarifies that browsing happens without parameters, and 'Use cursor to get next page' explains pagination mechanics beyond what the empty schema indicates.
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 the tool's purpose ('Browse games') which is a clear verb+resource combination, but it doesn't differentiate from sibling tools like 'search_games' (which doesn't exist in the list) or 'game_lives' (which might show live games). It's somewhat vague about what 'browse' entails compared to search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Use empty query for browse all games' indicates when to use this tool (for browsing without specific search criteria) and 'Use cursor to get next page' explains pagination behavior. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination behavior ('Use cursor to get next page of results'), which is useful context beyond basic functionality. However, it doesn't cover other traits like rate limits, authentication needs, error handling, or what 'past' means temporally (e.g., date range). The description adds some value but is incomplete for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, and the second adds critical behavioral detail (pagination). Every sentence earns its place with no wasted words, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving paginated historical data), no annotations, and no output schema, the description is moderately complete. It covers the purpose and pagination but misses details like return format, error cases, or temporal scope. For a tool with zero structured support, it should do more to compensate, leaving gaps in contextual understanding.
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 0 parameters with 100% coverage, so no parameter documentation is needed in the description. The description appropriately avoids repeating schema details and instead focuses on operational context (pagination). Baseline is 4 for zero parameters, as it adds meaningful semantics without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all past events created by page' specifies the verb ('Get'), resource ('past events'), and scope ('created by page'). It distinguishes from siblings like 'page_events' (likely current/future events) and 'search_events' (broader search), though not explicitly named. However, it doesn't fully differentiate from all siblings (e.g., 'events_details_by_id'), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'past events' and pagination with 'Use cursor to get next page of results,' suggesting it's for historical data retrieval in batches. However, it lacks explicit guidance on when to use this tool versus alternatives like 'page_events' or 'search_events,' and no exclusions or prerequisites are mentioned, leaving usage somewhat inferred.
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:

[![bachai-facebook-scraper3 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-facebook-scraper3/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-facebook-scraper3)

Score Badge

Copy to your README.md:

[![bachai-facebook-scraper3 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-facebook-scraper3/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-facebook-scraper3)

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/BACH-AI-Tools/bachai-facebook-scraper3'

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