Outscraper MCP

Official

by outscraper

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.2.3
Disambiguation3/5
Most tools target distinct sources/actions, but the legacy aliases (tp_data, tp_reviews) directly duplicate trustpilot_data and trustpilot_reviews, creating ambiguity. Additionally, google_maps_search and businesses_search have overlapping purposes, though detailed descriptions help differentiate them.
Naming Consistency4/5
The dominant naming pattern is `<source|object>_<action>` (e.g., google_maps_search, businesses_get, requests_list), which is consistent. However, tools like ping, ai_scraper, emails_validator, and phones_enricher break the pattern, and the tp_* aliases use inconsistent abbreviations.
Tool Count2/5
At 28 tools, the server exceeds the 25-tool threshold and feels heavy, even though the broad multi-source scope explains the count. Several tools could be consolidated, such as removing legacy aliases.
Completeness4/5
Core workflows are well covered: search across major platforms, reviews, enrichment, validation, and async request management. Minor gaps exist, such as missing yelp_search and booking_search while having reviews for those sources, but agents can work around with available tools.
Average 3.8/5 across 28 of 28 tools scored. Lowest: 2.4/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
- Last stable release on April 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 disclosing behavior, but it only references an undocumented endpoint. It fails to mention sync/async behavior, pagination, rate limits, or any side effects, offering no meaningful transparency for an action that may involve network requests and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it includes the redundant phrase 'with the documented /tripadvisor-search endpoint' that adds no practical value. It is not bloated, but the lack of substance makes the structure underinformative rather than optimally concise.
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?
Despite having an output schema and abundant parameter documentation, the tool is complex (8 parameters, multiple async-related options) and sits among many sibling tools. The description provides zero contextual guidance on when to use it, how it behaves, or how to configure it, leaving the agent to rely solely on external documentation and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level information beyond what the schema already provides, but since the schema thoroughly documents all parameters (e.g., query, limit, execution_mode), a baseline score is appropriate.
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 'Search' and the resource 'Tripadvisor', which makes the tool's primary purpose evident. It distinguishes itself from other platform-specific searches (e.g., google_search, yelp_reviews) by naming Tripadvisor, though it does not differentiate among the multiple Tripadvisor tools (e.g., tripadvisor_reviews).
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 the many sibling tools (e.g., tripadvisor_reviews, tp_data, businesses_search). It does not mention any context, prerequisites, or alternatives, 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Fetch', implying a read operation, but does not disclose async behavior, return format, rate limits, or any side effects. The mention of a 'documented endpoint' is a reference to external docs, not a behavioral trait.
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?
The description is a single under-specified sentence that restates the tool name without providing useful information. It is not concise in an effective way; it is merely terse. There is a typo ('/trustpopic') that detracts from professionalism and 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 six parameters, a rich schema, an output schema, and many sibling tools, the description is highly incomplete. It does not help the agent select this tool over alternatives, explain when to use async modes, or indicate typical use cases. The output schema exists, so return values need not be described, but all other context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it only references the endpoint. The schema already documents all six parameters, including 'query', 'fields', 'enrichment', and 'execution_mode', so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Fetch') and resource ('Trustpilot business data'), but 'business data' is vague and does not specify what type of data (e.g., ratings, company profiles) or distinguish it from sibling tools like 'trustpilot_reviews' and 'tp_data'. The reference to a '/trustpilot endpoint' is unclear and contains a typo ('/trustpopic'), further reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Sibling tools like 'tp_data', 'trustpilot_reviews', and 'businesses_get' exist, but the description provides no direction on which to choose.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only references a 'documented endpoint' without mentioning sync/async options, return format, rate limits, or authentication needs, providing zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear structure, but the phrase 'with the documented /yellowpages-search endpoint' is redundant given the tool name and adds little value. It is concise but not maximally efficient in communicating useful information.
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 (9 parameters, execution modes, output schema), a one-sentence description is insufficient. There is no guidance on query construction, region/location handling, or enrichment usage, making correct tool invocation difficult without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all nine parameters, so the baseline is 3. The tool description adds no parameter-level meaning beyond the schema, and the 'documented endpoint' phrase does not clarify any parameter semantics.
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 ('Search') and resource ('Yellowpages'), making the core purpose explicit. However, it does not differentiate this from sibling search tools like google_search or businesses_search, nor does it specify the type of data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer applicability solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It only says 'Fetch Tripadvisor reviews', with no details on rate limits, pagination, authentication, or async behavior. The mention of a 'documented endpoint' is vague and does not reveal outcomes of using the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise, but it is under-specified and does not fully earn its place. It conveys the basic action but omits crucial context that would help the agent, making it minimal rather than effectively streamlined.
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?
Despite having 8 parameters and an output schema, the description does not provide sufficient context. It fails to mention that multiple URLs can be processed, the async/execution_mode mechanics, or any differentiation from sibling review tools. The description is too thin for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains parameters like query, cutoff, reviews_limit, and execution_mode. The description adds no extra semantic value beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch Tripadvisor reviews', which clearly identifies the action and resource. It also references the specific endpoint '/tripadvisor-reviews'. However, it does not distinguish from sibling tools like tp_reviews or booking_reviews beyond the name itself, so it lacks explicit 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?
There is no guidance on when to use this tool versus alternatives. It does not mention that Tripadvisor URLs are required, nor does it explain when to prefer it over other review-fetching tools. No exclusions or scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions an external endpoint ('documented /google-search endpoint') without explaining behavior like sync/async options, pagination, output format, or whether this is a read-only operation. The description adds minimal behavioral context beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It states the tool's purpose in nine words. Though very thin, it is appropriately sized for the minimal information it provides, with no filler. However, it could be more informative without becoming verbose.
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?
Despite the tool having 12 parameters, an output schema, and a rich feature set (execution_mode, enrichment, fields, pages_per_query), the description gives no context on how to approach these options. An agent would have to rely entirely on parameter descriptions but would lack guidance on overall workflow, when to use async, or what enrichments are relevant. The description is insufficient for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters. The description adds no extra parameter meaning, such as typical usage of 'fields' or how 'execution_mode' interacts with 'async'. With full schema coverage, a baseline of 3 is appropriate—the description does not need to repeat schema info, but it also does not enrich it.
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 'Search Google with the documented /google-search endpoint' clearly identifies the action (search) and resource (Google). It does not explicitly differentiate from sibling google_search_images, but the name itself implies a general web search. The mention of the endpoint is a minor addition, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 simply states what it does without mentioning contexts, prerequisites, or that other siblings (e.g., google_search_images, google_maps_search) might be more appropriate for other search types. There is no exclusion or alternative instruction.
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 'Search Google Images' without revealing whether the operation is read-only, synchronous or asynchronous (despite the execution_mode parameter), or any rate limits or authentication requirements. This is a significant gap for a tool with 9 parameters.
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, clear sentence with no wasted words. It is concise but not under-specified to the point of being unhelpful, unlike a pure tautology. The reference to the endpoint is mild filler but not harmful.
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?
Despite having 9 parameters and an output schema, the description provides almost no contextual information about how the tool behaves, what the parameters influence, or the nature of the results. It does not explain the distinction between sync/async modes, pagination, or how 'uule' and 'region' affect searches. This is notably incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions in the input schema. The description adds no additional parameter meaning or usage context, but the baseline of 3 is appropriate since the schema does the heavy lifting.
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 function ('Search Google Images') and names the specific endpoint, which makes the purpose unambiguous. However, it does not explicitly distinguish it from the sibling tool 'google_search' or mention what makes it unique (e.g., image-specific results).
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 over alternatives like 'google_search' or 'google_maps_search'. There is no mention of appropriate scenarios, exclusions, or prerequisites, leaving the agent to rely solely on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey whether the tool is safe, read-only, synchronous, rate-limited, etc. It only says 'Search Indeed,' which is minimal and does not disclose any behavioral traits such as async execution modes, webhook behavior, or result delivery. Since the schema includes async, webhook, and enrichment parameters, the description omits important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary fluff, making it easy to read and front-loaded. However, the phrase 'with the documented /indeed-search endpoint' is not genuinely helpful because the endpoint is not documented here, so it adds little value. It is concise but slightly under-specified in content.
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 7 parameters, including execution_mode, webhook, enrichment, and output schema, the one-sentence description is inadequate. It does not explain when to use async vs sync, what enrichment options exist, or how webhooks are used. While the output schema exists and the schema covers parameter definitions, the overall context for effective use is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, including their types, required status, and some details (e.g., execution_mode values, webhook format). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches Indeed, which distinguishes it from the many other search tools in the sibling list (e.g., google_search, tripadvisor_search). However, it adds the vague phrase 'with the documented /indeed-search endpoint' without actually documenting the endpoint, and it does not describe what 'Indeed' refers to or what kind of results are returned. It is clear enough for a basic purpose but not as rich as a top-tier description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives, nor any mention of when not to use it. The sibling list includes several other search tools, but the description does not explain what makes indeed_search the preferred choice. This is a clear gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'fetch reviews' and mentions an endpoint, without revealing important behaviors like pagination, async defaults, rate limits, or read-only guarantees. This is insufficient for a tool with 8 parameters.
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 sentence that front-loads the action 'Fetch Trustpilot reviews' and adds a helpful reference to the endpoint. It is concise with no wasted words, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, an output schema, and many sibling review tools, yet the description is extremely sparse. It fails to explain when to use this tool, how async/webhook behavior works, or what differentiates it from similar tools, leaving the agent under-informed for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides detailed descriptions for all parameters (query, execution_mode, reviews_limit, etc.). The description itself adds no parameter-level meaning, but the baseline of 3 applies when the schema handles parameter documentation well.
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 'Fetch Trustpilot reviews' with a specific verb and resource, and references the documented endpoint. It tells the agent exactly what the tool does, though it doesn't explicitly distinguish it from sibling tools like tp_reviews or trustpilot_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 gives no guidance on when to use this tool versus alternatives like yelp_reviews or tripadvisor_reviews. There are no exclusions, conditions, or alternative recommendations, leaving the agent without selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'Fetch Yelp reviews' and does not mention pagination, async execution, rate limits, or whether the operation is read-only, leaving the schema to imply these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is front-loaded with the action and resource, and the phrase 'documented /yelp-reviews endpoint' adds a useful reference 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?
The tool has 9 parameters and an output schema, yet the description is too brief to provide adequate context. It does not explain that 'query' expects business URLs, nor does it mention the async execution options or cursor-based pagination, leaving a large burden on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter descriptions, such as the significance of the 'query' field or the difference between sync and async modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Yelp reviews, with a specific verb and resource. It distinguishes from sibling review tools like google_maps_reviews and tripadvisor_reviews by explicitly naming Yelp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or situations where this tool is preferred, such as needing Yelp-specific reviews vs. other platforms.
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. It only states the endpoint, with no mention of asynchronous behavior, pagination, authentication, rate limits, or response handling. The schema hints at async options and webhooks but the description adds no 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 sentence with no filler or repetition. It is front-loaded with the core action and resource. Though sparse, it is appropriately concise for the information it conveys.
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?
Despite an output schema existing and 11 parameters (1 required), the description provides no guidance on how to construct queries, what the endpoint returns, or any operational details. For a tool with this complexity, it is insufficiently contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 11 parameters. The description adds no extra meaning beyond saying 'Booking reviews' and the endpoint name. Baseline of 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('Booking reviews'), and explicitly names the endpoint ('/booking-reviews'), making its purpose clear. It distinguishes itself from sibling review tools by focusing on Booking specifically.
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 Booking reviews but provides no explicit guidance on when to choose this over alternatives like tripadvisor_reviews or yelp_reviews. No exclusions or alternative suggestions are given, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions it uses an 'enrichment' on top of a pipeline but does not disclose any side effects, permissions, rate limits, or the fact that the tool supports synchronous/asynchronous execution via execution_mode/webhook parameters. This is a significant gap for a tool with 7 parameters.
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 three sentences with no fluff. It front-loads the primary purpose, provides context about the underlying pipeline, and ends with a clear usage directive. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. However, the description does not mention the async execution capabilities (execution_mode, async, webhook parameters), which are important behavioral options for this tool. The description is sufficient for a basic read operation but misses a key aspect of the tool's flexibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all 7 parameters. The description adds no parameter-specific meaning beyond the schema, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Detect chain membership' and explicitly states the tool's purpose: determining whether a business is part of a chain. It also mentions the underlying pipeline ('Google Maps search pipeline') and the documented ai_chain_info enrichment, which distinguishes it from sibling search tools like businesses_search or google_maps_search.
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 an explicit 'Use it when you want to know whether a business is part of a chain.' This clearly indicates the intended usage context. However, it does not mention when not to use it or explicitly name alternative tools, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It discloses only that it's a legacy alias, but doesn't describe any behavior, side effects, or how it differs from trustpilot_data. This is insufficient for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key information about being a legacy alias and the preference for trustpilot_data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a legacy alias, the description is complete in redirecting agents, but it doesn't explicitly confirm that behavior is identical to trustpilot_data. Given the rich schema and output schema, the description adds the deprecation context but lacks some clarity on whether any differences exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no parameter semantics beyond the alias implication. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a legacy alias for trustpilot_data, which clarifies its role but doesn't explicitly state the underlying function (fetching Trustpilot data). However, the name and title convey the purpose, and it distinguishes from the sibling trustpilot_data by naming the preferred alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Prefer trustpilot_data for new integrations,' naming the alternative and indicating when not to use this tool. This is clear usage guidance, even though it doesn't specify the exact legacy use case.
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 for behavioral disclosure. It mentions 'documented /email-validator endpoint' but does not describe key behaviors such as rate limits, whether validation includes deliverability vs. syntax, how invalid addresses are handled in responses, or the distinction between sync and async execution. The schema hints at async/webhook options, but the description adds no transparency about how these affect 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 concise: one opening sentence plus three bullet points, all directly relevant. It front-loads the primary action and use cases without any redundant filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and fully documented parameters, the description covers purpose and usage context well. It lacks behavioral transparency (e.g., async behavior, return details), but the output schema and parameter descriptions fill many gaps. Overall it is nearly complete for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema (query array, async deprecated flag, webhook URI, execution_mode enum). The description adds no additional parameter semantics beyond what the schema already provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validate email addresses' with a specific resource ('documented /email-validator endpoint'). The bullet list of best-for use cases further clarifies the tool's distinct function. It is unambiguously differentiated from the sibling tools, which are mostly search/enrichment or management tools, making this the only email validator.
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 context on when to use the tool via the 'Best for' bullet points: deliverability checks, outbound lead list validation, and filtering invalid emails before enrichment/outreach. It does not name alternative tools or state when not to use it, but the use-case guidance is clear and actionable.
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 must carry the transparency burden. It discloses that the tool lists requests scoped to the current API key and can filter by bucket (running/finished/all). However, it does not mention pagination, result limits, sorting, or the exact data returned, leaving behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence and bullet lists. It is concise but has some redundancy between 'debugging async flows' and 'debugging async submissions across tools', and between 'seeing running, completed, or failed jobs' and 'quick view of recent running or finished requests'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description covers the purpose, typical use cases, and bucket filtering. It doesn't specify default behavior when 'type' is omitted, but the schema marks it optional. Overall it provides sufficient context for an AI agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter 'type' with an enum and its own description, achieving 100% schema coverage. The description adds context by explaining 'bucket' and aligning with 'running, completed, or failed jobs', but it doesn't add significant new meaning beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List recent Outscraper requests by bucket' – a specific verb+resource+scope. It clearly distinguishes from siblings like requests_get (which likely fetches a specific request) and requests_delete (which deletes). The 'by bucket' clarifies filtering.
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 'Best for' and 'Use this when' sections list concrete scenarios: debugging async flows, losing a request id, viewing running/finished jobs, and cross-tool debugging. This provides clear usage context, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'Fetch' which implies a non-destructive operation, but it does not disclose async execution behavior, rate limits, authentication needs, or how the 'async' and 'execution_mode' parameters affect the request. The description lacks any warning about potential long-running operations or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core action, and uses a bulleted list for use cases. Every sentence earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema, the description provides a sufficient overview. The output schema and parameter descriptions cover the details, so the description's focus on use cases is appropriate. However, it could be more complete with a brief mention of async behavior or note that the query parameter accepts multiple places, but these are partially covered by schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by hinting at the 'tag' parameter through phrases like 'menu photo retrieval' and 'owner photo', which map to enum values (menu, by_owner). This gives contextual meaning beyond the schema's generic 'Optional photo filter tag.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Fetch Google Maps photos' and enumerates specific use cases (place photo extraction, menu photo retrieval, owner photo and latest photo analysis), which distinguishes it from sibling tools like google_maps_reviews. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Best for' list gives clear context on when to use the tool (photo-related tasks) but does not explicitly mention alternatives or when not to use it. It implies differentiation from review/search tools but could be more explicit about exclusions, such as 'Use google_maps_reviews for reviews.'
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 discloses a key behavioral trait (synchronous only, no async or webhooks), which is valuable. But it does not state whether the tool mutates data, requires specific authentication, or any rate limiting, so it's somewhat thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one purpose sentence, a list of use cases, and a note. Every sentence adds value and is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description covers the essentials: purpose, use cases, and a key limitation. It lacks some details like error handling or required permissions, but for this scope it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter 'query' as 'One or more phone numbers to enrich.' The description adds no extra semantics beyond what is in the schema, so it does not improve on the 100% schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Enrich phone numbers using the documented /phones-enricher endpoint.' It also lists concrete use cases (carrier lookup, phone validation, message deliverability checks) that clearly distinguish it from sibling tools like emails_validator or businesses_search.
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 'Best for' section provides clear context on when to use this tool, and the note about synchronous-only execution adds a limitation. However, it does not explicitly name alternatives or give 'when not to use' instructions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. However, it only states that this is a legacy alias and does not disclose any actual behavior, side effects, or limitations. The agent learns nothing about what the tool does beyond its alias status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core alias information and a clear preference directive. No wasted words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a legacy alias, the key contextual information is that it should be avoided in favor of trustpilot_reviews. The description conveys this effectively. An output schema exists, so return values are documented. However, the description does not explain the tool's functionality, relying on the canonical tool's documentation, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information, but the schema already provides full descriptions for all 8 parameters, including 'execution_mode' and 'skip'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a legacy alias for trustpilot_reviews, which is a specific resource and distinguishes it from sibling tools. The title 'Trustpilot Reviews (Legacy Alias)' reinforces this, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Prefer trustpilot_reviews for new integrations', providing direct when-to-use versus when-not-to-use guidance. This is a clear recommendation of the alternative.
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. The verb 'Fetch' implies a read-only operation, and the content emphasizes account status and billing details. However, it does not explicitly state that the tool has no side effects, does not consume credits, or require special permissions beyond the active API key, which would strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence followed by bullet-point sections. It is slightly repetitive between 'Best for' and 'Use this when', but each bullet carries meaningful information and the main point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description adequately covers purpose, usage context, and decision-making scenarios. It answers why and when to use the tool without needing to describe return values, which are handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (input schema properties are empty), so per the baseline rule for 0 params, the description need not explain parameter semantics. The mention of 'active API key' adds useful context about implicit authentication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch the current Outscraper account balance and billing summary for the active API key.' This uses a specific verb (fetch) and names the resource (balance/billing summary), effectively distinguishing it from sibling search and data tools.
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 concrete 'Best for' and 'Use this when' sections with explicit scenarios like checking whether the key is attached to a funded account and confirming account status before running larger jobs. It does not explicitly mention alternatives or when-not-to-use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries full responsibility. It discloses execution_mode behavior (sync vs async), explains that async returns a request id for polling with requests_get, and describes how schema shapes the output. This is substantive, but it does not address failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers ('Best for', 'How schema works', 'Execution notes') and leads with purpose. The example schema JSON is informative and earns its place, though it does lengthen the description slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested schema and 5 parameters, the description covers schema semantics, execution modes, and the combined use of prompt and schema. An output schema is present, so return value details are not necessary. Minor gaps like page size limitations exist but do not undermine 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?
Schema description coverage is 100%, so the baseline is 3. The description exceeds this by explaining execution_mode values (sync/async) and providing a detailed schema example with type, properties, and required guidance, adding meaning beyond the raw parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Extract structured information from a web page with Outscraper AI Scraper.' It further clarifies scope with 'Best for scraping one page and turning it into structured JSON' and explicitly distinguishes from sibling tools by stating it is best for structured data from a single page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Best for' section lists clear use cases, and the description states 'This tool is best for extracting structured data from a single page.' It does not explicitly name alternative tools or state when not to use it, but the context is strong and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the sync/async execution modes and the return style for each ('direct response payload' vs 'async request metadata'), and mentions tracking with requests_get. It does not delve into rate limits, authentication, or error conditions, but for a read-only enrichment tool this is a reasonable level of detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into clear sections with headers, making it easy to scan. It is front-loaded with the core purpose and maintains focus, though there is some redundancy between the 'Best for' and 'Prefer this tool when' sections that could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's primary purpose, typical use cases, alternative tools, and both sync and async execution behavior. Since an output schema is present, the absence of a detailed return-field breakdown is acceptable. It lacks explicit discussion of webhook behavior and error handling, but overall it is complete enough for an agent to select and invoke the tool correctly in most situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with 100% coverage, including descriptions for query, fields, webhook, enrichments, and execution_mode. The description adds contextual guidance on when to use async versus sync mode, but does not meaningfully enhance parameter-level semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get structured company-level insight data from Outscraper,' identifying a specific verb, resource, and data type. It further clarifies the scope with concrete examples (firmographics, size, revenue, industry, founding) and explicitly distinguishes itself from the sibling tool emails_and_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Prefer this tool when' and 'Use emails_and_contacts instead when' sections, clearly defining when to use this tool versus a direct alternative. It also gives guidance on choosing async mode for large batches and expensive enrichment, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It clearly implies a read-only search operation and adds useful behavioral context about using the Google Maps search pipeline and supporting async submissions for larger batches. It does not mention rate limits or costs, but for a search tool the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section labels and bullet-like guidance. Every sentence serves a purpose, and the most important information is front-loaded. It is concise despite covering several usage scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations) and the presence of an output schema, the description provides sufficient context for selection and invocation. It covers main use cases, alternative tools, and async behavior. It could mention error/rate-limit behavior, but the description is largely complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema fully documents all 12 parameters. The description adds light semantic framing by mentioning natural-language queries and enrichments, but it does not provide deeper parameter semantics beyond what the schema already offers. This aligns with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search Google Maps places through Outscraper', which combines a specific verb, resource, and data source. It further differentiates from siblings by emphasizing the Google Maps search pipeline and contrasts with businesses_search, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Best for', 'Prefer this tool when', and 'Use businesses_search instead when' sections. This clearly delineates when to select this tool over obvious alternatives and even includes guidance on execution_mode='auto' for batch/enriched use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses async behavior, performance expectations ('crawl/enrichment to take longer'), and progress tracking via requests_get. It does not mention rate limits or auth requirements, but for a contact-discovery tool these are less critical.
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?
Well-structured bullets, front-loaded with a one-sentence summary. Some redundancy between 'Best for' and 'Prefer this tool when' sections, but overall each line conveys distinct usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and full parameter descriptions, the description covers purpose, selection criteria, execution modes, and a key alternative. It could mention more edge cases (e.g., rate limits, validation use cases) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 5 params. The description adds domain/URL context for the query field and explains when to use async mode, but it does not go beyond schema for webhook or preferred_contacts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line uses a specific verb ('Find') and identifies exact data types (emails, phones, social/contact data) and scope (company domains). It explicitly differentiates from company_insights by contrasting contact data vs. company metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Prefer this tool when' conditions, async-mode guidance, and a named alternative ('Use company_insights instead when...'). This tells the agent both when to select and when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds behavioral context such as async mode for heavy jobs, polling with requests_get, and the deprecation of the async flag in favor of execution_mode. However, it does not disclose potential limitations like rate limits or data freshness, so it falls short of a 5.
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 well-structured with a clear opening sentence followed by bullet-point sections. It is concise yet informative, with every line serving a purpose. The front-loaded main purpose makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, output schema, and many sibling tools), the description covers the essential context: when to use it vs. alternatives, async behavior, and typical use cases. The output schema handles return value details, and the sibling differentiation is explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 17 parameters. The description adds minimal extra value beyond clarifying that 'query' accepts place ids or business queries and that async mode is preferred for large volumes. This aligns with 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch Google Maps reviews for place ids or place queries.' It distinguishes itself from siblings like google_maps_search and other review tools by specifying its focus on reviews rather than place discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Prefer this tool when' and 'Do not use this for basic place discovery' sections, naming google_maps_search as the alternative. It also gives clear async mode usage guidelines, explaining when to use async and how to poll progress with requests_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It clearly states the behavior: checks server status and returns metadata. While it doesn't elaborate on error behavior or metadata structure, it adds value beyond the name by specifying the action and output, enough for a simple ping tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a focused bullet list of use cases. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the absence of parameters, and the existence of an output schema, the description is fully complete. It covers what the tool does and when to use it, and the output schema handles return-value expectations. No additional detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately avoids mentioning parameters since none exist, and there is no additional semantic burden to carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies the resource ('whether the Outscraper MCP server is running'), clearly distinguishing it from data-fetching siblings. It also mentions returning metadata, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Best for' section explicitly lists three concrete use cases: validating startup, confirming reachability, and lightweight health checks. It gives clear context for when to use this tool, though it doesn't explicitly mention when not to use it or alternatives, which is acceptable for a health check utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation checks status, that statuses are Pending/Success/Failure, and that it returns completed data. It also implies a polling flow. It does not discuss auth, rate limits, or idempotency, but these are less critical for a read-only status check.
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 well-structured with a clear topic sentence, a numbered typical flow, and a bulleted 'Use this tool when' list. Every sentence adds value and the content is effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema. The description provides enough context for correct usage: when to use, what the request_id is, the statuses, and that completed data is returned. No additional information is necessary for effective 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?
Schema coverage is 100% and the only parameter 'request_id' has a terse schema description 'Async request id.' The tool description adds meaningful context by explaining how to obtain the request_id (capture the returned id from a previous async submission), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check the status of an asynchronous Outscraper request' with a specific verb and resource. It clearly differentiates from sibling tools like requests_list and requests_delete by focusing on status polling for a single async request.
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?
Provides explicit when-to-use guidance: after calling any tool with execution_mode='async', when you need to know status, and when you need completed data. It outlines a typical flow with steps. However, it does not explicitly mention alternatives like requests_list, so no direct 'when-not' is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It clearly implies a read-only operation via 'Get' and adds useful behavioral nuance: calling without fields returns a full detail payload, while including fields returns a smaller selected payload. It does not mention error behavior or authentication, but for a simple get-by-id tool this is sufficient.
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 well-structured: an opening one-sentence summary, 'Best for' bullets, and a clear do-not-use section. Every sentence adds value, with no fluff or repetition, making it easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, one optional parameter) and the presence of an output schema, the description fully covers purpose, usage context, parameter behavior, and relationship to sibling tools. It leaves no significant gaps for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning by explaining that omitting fields yields the full detail payload and including fields produces a smaller field-selected payload, which clarifies the practical effect of the fields parameter beyond the schema's 'Specific fields to return.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one business by Outscraper business id,' specifying the exact action and resource. It also distinguishes itself from businesses_search by explicitly positioning this tool for post-search enrichment rather than discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with 'Best for' bullets and a direct 'Do not use this for discovery' exclusion. It names the alternative tool (businesses_search) and gives a clear workflow: search first, then call businesses_get for a specific id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys the destructive nature ('Delete or terminate'), the irreversible consequence ('after deletion, the original async request should not be expected to complete normally'), and the intent for cleanup or cancellation. This is rich context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a single opening sentence followed by bullet points for 'Best for' and 'Use this carefully'. Every sentence contributes meaningful guidance without fluff, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers all necessary context: purpose, usage scenarios, cautionary notes, and post-deletion behavior. No critical information is missing, and the output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'request_id' with a clear description ('Async request id to delete'), and it has 100% coverage. The description only repeats 'by request id' without adding format, validation, or additional semantic detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete or terminate an asynchronous Outscraper request by request id', providing a specific verb and resource. It distinguishes the tool from siblings like requests_get and requests_list by focusing on deletion/termination rather than retrieval or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Best for' section explicitly lists when to use the tool (cleaning up queued jobs, stopping polling, testing lifecycle), while 'Use this carefully' provides clear when-not guidance (only when sure the request is no longer needed). This gives implicit alternatives and cautions without explicitly naming other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses important behavioral traits: the /businesses endpoint is synchronous in this MCP server, async-style execution controls are intentionally not exposed, structured filters are more reliable than free-form queries, and live testing showed query parsing may fail with a specific error. This goes well beyond typical descriptions.
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 well-structured with a lead sentence followed by labeled bullet sections. Each sentence serves a distinct purpose: clarifying scope, usage context, differentiation, and caveats. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested filters, no required params, output schema present), the description covers all essential decision factors: when to use, differentiators from alternatives, pagination behavior, and known failure modes. It is sufficiently complete for an agent to select and invoke correctly.
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 provides 100% coverage with descriptions for all 6 parameters, so the baseline is 3. The description adds value by warning that free-form query parsing may fail and recommending structured filters as the most reliable input mode, giving practical parameter guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Outscraper businesses using structured filters, a natural-language query, or both.' It clearly distinguishes this tool from google_maps_search by highlighting the normalized /businesses dataset and cursor-based pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Best for', 'Prefer this tool when', and 'Use this instead of google_maps_search when' sections. This gives unambiguous guidance on when to choose this tool over its sibling, including context like building lead lists and needing stable field selection.
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:

[![outscraper-mcp-server MCP server](https://glama.ai/mcp/servers/outscraper/outscraper-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/outscraper/outscraper-mcp-server)

Score Badge

Copy to your README.md:

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

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/outscraper/outscraper-mcp-server'

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