CrawlForge MCP Server

Server Quality Checklist

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

Latest release: v4.10.0
Disambiguation4/5
Most tools have distinct purposes, though there is some overlap between extract_text, extract_content, and scrape with markdown format, which could cause confusion. Overall, the vast majority are clearly differentiated.
Naming Consistency3/5
Naming conventions are mixed: some use verb_noun (fetch_url, extract_text), others use noun_verb (serp_rank) or adjectives (deep_research), and a few are single verbs (scrape) or nouns (agent, localization). This inconsistency reduces predictability.
Tool Count3/5
At 27 tools, the count is on the higher side for a scraping toolkit. While each tool serves a specialized purpose, the number feels slightly bloated and could potentially be consolidated (e.g., scrape with formats could replace several extract functions).
Completeness5/5
The tool set covers the full lifecycle of web scraping: fetching, extraction, search, crawling, analysis, batch processing, stealth, localization, templates, and monitoring. There are no obvious gaps for the stated purpose of web data acquisition and content processing.
Average 4.2/5 across 27 of 27 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 70 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint. Description adds that content extraction is optional but does not elaborate on other behavioral aspects like respects robots.txt or potential long runtime. No contradiction with annotations.
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?
Description is concise, front-loaded with purpose, includes a workflow suggestion and example. Slightly longer than necessary but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 params, nested objects, no output schema), the description provides sufficient context for usage but lacks details on return values or time considerations. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. Description includes an example call but adds no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool discovers and optionally extracts content from many pages within a site, with specific use cases. It distinguishes from siblings by mentioning map_site as a prerequisite, but does not explicitly contrast with all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies when to use (for multi-page discovery/extraction) and suggests using map_site first, providing a clear workflow. Lacks explicit when-not-to-use guidance.
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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds important behavioral details: default LLM usage and fallback to CSS selectors. This transparency aids agent understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes an illustrative example. Every sentence is informative, with no unnecessary fluff. It could be slightly more structured (e.g., bullet points) but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested schema object) and lack of output schema, the description omits return format and error handling. The example provides partial coverage, but the level of detail is adequate for typical use, leaving some gaps for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat parameter details. The example demonstrates url and schema usage, but adds marginal new semantics beyond the schema definitions. 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 clearly states it extracts structured data using a JSON schema, with examples like product details and job listings. It differentiates from siblings by emphasizing JSON schema input and fallback behavior, but could more explicitly contrast with similar tools like scrape_structured or extract_with_llm.
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 gives a clear usage context ('when you need a specific data shape extracted'), but lacks explicit guidance on when not to use it or alternatives. The example is helpful but does not cover exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and is open-world. The description adds the workflow context but does not disclose behavioral traits like what data is stored, authentication needs, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~60 words) and front-loaded with the main purpose. It contains only relevant information, with no wasted words. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects, many operations), the description only covers basic usage. It does not explain advanced operations or return values. However, the schema descriptions are thorough, partially compensating. The description is adequate for simple use cases but incomplete for advanced ones.
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 baseline is 3. The description provides a usage example (url + operation) but adds no semantic value beyond the schema's parameter descriptions. The schema already explains each parameter thoroughly.
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 monitors a URL for content changes over time, provides concrete examples like competitor pricing, and distinguishes from sibling scraping tools by emphasizing temporal monitoring. The verb 'monitor' and resource 'URL content changes' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: start with 'create_baseline', then use 'compare'. It also mentions support for webhooks and scheduled monitoring. However, it does not explicitly state when not to use this tool or list alternatives beyond the implicit sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only, idempotent behavior. The description adds that it reads sitemap.xml and discovers URLs without fetching content, which is useful but does not go into depth about rate limits, error handling, or behavior of domain filters. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and an example. Every sentence adds value, with no fluff or repetition of schema details. The structure front-loads the purpose and usage context, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, including a nested domain_filter), the description provides a high-level overview but lacks detail on what the return value looks like (no output schema). It does not explain how search or domain_filter modify the behavior. The example helps, but for a tool with rich parameters, more guidance on parameter combinations would improve completeness.
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% coverage, so the description does not need to re-explain each parameter. However, the description provides a concrete example call (url, include_sitemap, max_urls) which adds value. It does not explain nested objects like domain_filter or the search parameter beyond what the schema provides. Thus, it meets the baseline but does not exceed it.
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 purpose: to discover all URLs on a domain without fetching full page content. It gives specific use cases (before crawl_deep, site audit, finding section URLs) and distinguishes from sibling tools like crawl_deep by emphasizing it doesn't fetch content.
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 includes explicit guidance on when to use the tool (e.g., 'before a crawl_deep, for a site audit, or to find specific section URLs'). It provides an example call with parameters. While it does not explicitly list alternative tools, the mention of crawl_deep as a later step gives context. No explicit 'when not to use' but the guidance is clear.
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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds behavioral specifics (removes ads, nav, footers, boilerplate) without contradicting annotations, enhancing 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 three focused sentences including an example, with no wasted words. It is front-loaded with the main action. Could be slightly more concise but adequately sized.
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?
No output schema exists, and the description does not describe the return format. It adequately covers purpose and usage but lacks details on output structure or error behavior. For a simple tool, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions (url and options). The description includes an example URL but does not elaborate on the options parameter beyond what the schema provides. Given high schema coverage, the description adds minimal parameter meaning.
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 it extracts a clean, readable version of web articles by removing ads, nav, etc., and distinguishes itself from extract_text by preferring it for article-style pages. This provides a specific verb+resource and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases (RAG ingestion, summarization, LLM context) and explicitly advises preferring this over extract_text for article-style pages, giving a comparison. It lacks explicit when-not-to-use scenarios but offers sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safety profile is transparent. The description adds the action of extracting links and an example, but no additional behavioral traits (e.g., rate limits, 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?
Two sentences plus a concise example. Front-loaded with purpose. Every sentence adds value; no redundancy. Ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only link extraction tool with no output schema, the description covers the essential context. It doesn't detail return format, but the tool's behavior is straightforward and well-illustrated by the example. Minor gap: could mention that it returns a list of URLs.
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?
Input schema has 100% description coverage for all 3 parameters. The description adds an example using filter_external, which provides context but does not significantly extend schema information. 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 clearly states 'discover all hyperlinks on a page' with specific use cases (crawl seed lists, audit broken links, find related resources). It distinguishes from sibling tools like fetch_url and extract_text by focusing on link discovery.
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 when-to-use guidance and an example with filter_external. It does not explicitly state when not to use or compare to siblings like map_site, but the context is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds an example but no additional behavioral traits like rate limits or return format. With annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a single-line example, thoroughly concise and front-loaded with the essential purpose. No redundant or extraneous information.
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 schema richness (100% coverage, 5 params with nested objects) and annotations, the description covers the primary use case. No output schema exists, but the domain implies returning file content. Minor gap in explaining return values, but overall sufficient.
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 an example using the required 'url' parameter but does not elaborate on other parameters, which are already documented in 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 clearly states the tool generates an llms.txt file for a website, specifying the verb 'generate' and the resource. It distinguishes itself from sibling scraping and extraction tools by its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool, mentioning site owners and AI discoverability. It includes an example but does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds pagination context and that it works for completed or in-progress jobs, but does not describe other behavioral aspects (e.g., polling behavior, error states).
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 plus an example; no fluff, front-loaded with the main purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no output schema), the description is sufficient. It explains the input, pagination, and relation to batch_scrape. However, without output schema, it does not describe the return format, 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 coverage is 100% with descriptions for all parameters. The description includes an example but adds no semantic meaning 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?
Description clearly states it retrieves paginated results for a batch_scrape job, specifying the required input (batchId) and providing an example. It distinguishes from sibling tools like batch_scrape.
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?
Description implies use after batch_scrape to retrieve results, and includes an example. It does not explicitly mention when not to use or alternatives, but the context is clear enough for a specific retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so description does not contradict. The description adds context that this configures country context for scraping, but does not detail side effects, persistence, or rate limits. It provides moderate additional insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences with no wasted words. Purpose is front-loaded, and the example is valuable. It earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects, openWorldHint=true) and no output schema, the description provides a good high-level overview but does not explain all operations or parameter interactions. It is adequate for basic use but leaves gaps for advanced scenarios.
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% coverage, baseline 3. The description adds value by giving an example call with specific parameters (operation, countryCode, language) and recommends using 'configure_country' operation, which helps narrow down usage among many parameters.
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 purpose: to scrape geo-restricted content or emulate locale/timezone. It gives concrete examples (region-specific pricing, bypassing geo-blocks) and distinguishes from sibling scraping tools by focusing on context setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('when you need to scrape geo-restricted content or emulate a specific locale/timezone') and provides an example operation. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an agent.
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 already indicate readOnlyHint, idempotentHint, etc. The description adds behavioral context beyond annotations, such as reliability comparison with LLM extraction and the @attr syntax for attribute extraction. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the key usage instruction. The example is embedded, which slightly reduces clarity but overall efficient. No wasted words.
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 3 parameters (all described) and no output schema, the description is mostly complete. It covers when to use, example usage, and selector syntax. Minor gap: no mention of max_results behavior or how multiple matches are handled.
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 already well-documented. The description provides an example call and clarifies the @attr syntax, but adds minimal new meaning beyond the schema. 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 clearly states the tool's purpose: scraping structured data using exact CSS selectors for well-structured pages like pricing tables or product lists. It distinguishes itself from LLM extraction, indicating a specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you know the exact CSS selectors') and implies an alternative (LLM extraction) but does not mention other sibling tools like scrape_with_actions or extract_with_llm. It provides clear context but lacks exclusions for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true, meaning stateful behavior. The description mentions managing a browser and operations, but does not detail side effects or state persistence beyond the example. It adds some behavioral context but could be more explicit about state management.
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 (two sentences and an example) and front-loaded with the purpose. Every sentence is useful; there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested schema and no output schema. The description explains the main operational flow but does not cover all configuration options in detail. Given the complexity, it is adequate but not comprehensive.
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 baseline is 3. The description adds value by providing a usage example and explaining the operation sequence, which aids understanding beyond the schema alone. It does not describe each parameter, but the schema already does.
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 purpose: bypassing bot detection systems like Cloudflare and Datadome. It distinguishes from siblings by specifying the use case and underlying technology (Playwright with anti-detection measures).
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 a clear usage sequence ('Start with operation: create_context then use the contextId') and an example. However, it does not explicitly state when not to use it or mention alternative tools for normal scraping, though the context implies it.
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 already indicate readOnlyHint=true (safe read) and destructiveHint=false. The description adds behavioral details: parallel execution, concurrency control (maxConcurrency), and trade-offs between sync and async modes. It does not mention potential failures or rate limits, but annotations cover the 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?
The description is extremely concise: two sentences plus an example. Every sentence adds value, with the first sentence defining purpose and the second providing mode guidance. The example is practical and demonstrates key parameters.
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 (11 parameters, nested objects), the description covers the essential decision (sync vs async) and constraints (batch size, concurrency). It lacks detail on response format or error handling, but these are partially covered by annotations and schema. Overall, it provides sufficient context for correct tool selection.
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 itself explains all parameters adequately. The description provides an example call that illustrates usage of 'urls', 'formats', and 'maxConcurrency', but does not add significant semantic value beyond what is in 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 clearly states the tool's purpose: scraping 2–50 URLs in parallel, with specific use cases (product pages, news articles, competitor pages). It distinguishes from siblings by focusing on batch processing and gives example scenarios, making the tool's role 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 description provides explicit guidance on when to use sync vs async modes, with concrete thresholds (async for large batches, sync for up to ~25 URLs for immediate results). It does not explicitly exclude alternatives for single URLs, but the context implies a distinction from single-URL tools like fetch_url.
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 already mark the tool as readOnlyHint and idempotentHint, so the description's main behavioral contribution is listing the exact metadata fields extracted (title, meta description, etc.), adding value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose with listing, ideal use cases, and an example. It is front-loaded and every sentence adds value without redundancy.
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 no output schema, the description partially covers return values by listing extracted metadata items. It lacks details on format or structure but is sufficient for a simple extraction tool within a rich set of sibling tools.
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 fully describes the url parameter (with format and description), so baseline is 3. The description does not add further parameter-specific semantics beyond the tool's overall purpose.
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 extracts SEO metadata (title, meta description, Open Graph tags, canonical URL, schema.org data) with a specific verb 'extract' and resource 'page's SEO metadata'. It distinguishes from siblings like fetch_url or extract_text by focusing on structured metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need a page's SEO metadata' and suggests use cases (site audits, competitive SEO analysis). It does not explicitly exclude other tools or mention when not to use, but provides clear context.
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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds that the tool is faster than extract_content and returns unstructured content, complementing the annotations without contradiction.
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 concise sentences plus an example, front-loaded with purpose and use cases. No unnecessary words.
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 4 parameters, no output schema, and the tool's simplicity, the description covers purpose, usage, and parameter hints adequately. It could mention the return format more explicitly, but 'unstructured content' suffices.
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% (all parameters described). The description adds minimal extra meaning beyond the schema, though it does provide an example and usage guidance for output_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts human-readable text/markdown stripped of HTML, scripts, and styles, and distinguishes itself from the sibling tool 'extract_content' by noting it is faster but returns unstructured content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies use cases (keyword search, summarization, RAG, NLP) and recommends output_format:'markdown' for RAG. It also contrasts with extract_content, though it doesn't explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool supports custom headers and configurable timeout, and implies it returns raw text. No contradictions. Could be improved by mentioning that it returns raw HTTP content and does not modify any state.
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, front-loaded with purpose, and includes an example. Every sentence adds value with no redundancy.
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 fetch tool with 3 parameters (1 required) and 100% schema coverage, the description covers key aspects: what it fetches, when to use, custom headers, timeout. Missing details like response format (implied raw content) but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (url, headers, timeout all documented). The description adds a concrete example of using auth tokens for headers and shows a usage example, but these add limited value beyond the schema. 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 clearly states the tool fetches raw HTTP content from a URL (HTML, JSON, XML, plain text) and distinguishes it from sibling tools by positioning it as a first step before extract_text or extract_content. The verb "fetch" and resource "URL" are specific.
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?
Description explicitly says when to use (need raw HTTP content, as first step before certain tools) and notes it's preferred over built-in fetch. However, it lacks explicit 'when not to use' guidance, such as avoiding for structured extraction when extract_structured is better.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds value by clarifying it returns real SERP positions (not custom API order) and mentions return fields: rank, URL, and positions. It does not discuss rate limits, error cases, or authentication, but these may be inferred from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and an example, all front-loaded with the core purpose. Every sentence contributes meaning, no redundancy. The example is a valuable addition without bloating the text.
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 7 parameters and no output schema, the description covers main functionality and output fields (rank, URL, positions). It does not explain output structure in detail or error cases, but for a check tool with good annotations, 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?
Schema description coverage is 100%, so the schema documents each parameter adequately. The description provides an example that demonstrates use of 'keyword', 'target', and 'location_name', adding practical context. However, it does not add new semantic information beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks a domain's rank in Google organic results, using specific verb 'check' and resource 'domain rank'. It distinguishes from custom search by emphasizing 'real SERP position, not Custom Search order'. No sibling tool serves the same specific function, making 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use this to check where a domain ranks', providing clear usage context. It includes an example with typical parameters. However, it does not explicitly state when not to use it or mention alternatives among siblings, though the tool is quite specific and no direct alternative exists.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat safety. It adds value by explaining partial success behavior (per-format warnings never fail the whole call) and the effect of onlyMainContent (strips boilerplate via Readability). This enriches the behavioral understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the key use case, then lists formats with brief explanations, mentions important options (onlyMainContent), and ends with an example. Every sentence adds value; there is no fluff.
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?
Despite the complexity of multiple formats and nested objects, the description does not detail the output structure for each format. It mentions screenshot returns crawlforge resources but omits explicit return shapes for other formats. Given the absence of an output schema, this is a notable gap for an agent to understand what to expect from the tool.
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%, giving a baseline of 3. The description adds meaning beyond the schema by explaining the purpose and behavior of formats (e.g., 'branding' returns design tokens, 'screenshot' renders in a browser and returns crawlforge resources, and the JSON object format for structured extraction). It also provides a concrete example.
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 purpose: to scrape a single URL for multiple content formats in one call. It uses a specific verb ('scrape'), identifies the resource (URL), and distinguishes itself from sibling tools like fetch_url and extract_text by emphasizing multi-format capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: when needing multiple content formats from a single URL. It also positions it as preferred over the client's built-in web fetch for page content. While it doesn't list alternatives for single-format use, it provides clear context for its primary use case.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by noting that screenshots are stored as crawlforge://screenshot/{actionId} resources, which provides useful operational 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 very concise: two sentences and an example. It front-loads the key use case and provides an illustrative example without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (11 parameters, nested objects, no output schema), the description could be more complete. It does not mention what the scraped output looks like or how to interpret the formats parameter, which is crucial for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description compensates by providing a concrete example of the actions array, making the complex nested structure easier to understand.
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 defines the tool's purpose: interacting with a page before scraping (login, clicks, forms, scroll, dynamic content). It specifically mentions use cases like SPAs, login-gated content, multi-step flows, which distinguishes it from simpler fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool and provides concrete examples of scenarios. However, it does not explicitly mention when not to use it or suggest alternatives, but the context of sibling tools implies that for static scraping, other tools are more appropriate.
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?
The description discloses numerous behavioral traits not covered by annotations: dependence on LLM configuration for synthesis, storage of results as crawlforge:// URIs, confirmation elicitation when maxUrls > 50, and the multi-step process of searching, fetching, analyzing, and synthesizing. This adds significant value beyond the readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and an example, with no redundant information. It front-loads the core purpose and immediately provides actionable guidance. 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?
Given the tool's high complexity (19 parameters, nested objects, no output schema), the description covers the key behavioral aspects and constraints. It mentions output storage location and LLM dependency. However, it does not specify the exact return format or structure, which would be helpful for completeness.
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, so the baseline is 3. The description adds minimal parameter semantics beyond an example usage. The example illustrates how to set topic, maxUrls, and researchApproach but does not elaborate on syntax or constraints not already in 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 clearly states the tool performs exhaustive multi-source research, with specific verbs like 'searches', 'fetches', 'analyzes', 'detects conflicts', and 'synthesizes'. It distinguishes itself from sibling tools by claiming preference over built-in deep-research skills/tools, and the resource is explicitly the research topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'when you need exhaustive multi-source research' and 'best for complex questions needing 10+ sources'. It also states preference over built-in alternatives. However, it lacks explicit when-not-to-use scenarios or comparisons to simpler search tools.
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 declare readOnlyHint=true and destructiveHint=false. The description adds context by explaining the default local Ollama model, the need to list models, and API key requirements for cloud providers. It does not cover failure modes or cost implications, but the added transparency is valuable.
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 only three sentences, front-loaded with the purpose, and each sentence adds essential information without waste. It is concise and well-structured.
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 (7 parameters, multiple providers, no output schema) and supportive annotations, the description covers key behavioral aspects. However, it does not explain the output format (e.g., structured JSON), which might be inferred but is not explicit. Still, it 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 coverage is 100%, but the description adds significant usage context beyond the schema descriptions. For example, it explains default model names and the need to call list_ollama_models for Ollama, and specifies default models for each provider. This helps agents use the parameters correctly.
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 starts with a clear verb+resource: 'Extract structured data from a URL or text using a natural-language prompt.' It distinguishes itself from siblings like 'extract_structured' by emphasizing LLM-based extraction and provider flexibility (local Ollama vs cloud models).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'call list_ollama_models first to see what's installed and pass the name via the model parameter' and 'Pass provider: "openai" or "anthropic" with the matching API key.' It also notes that one of url/content is required. However, it lacks explicit when-not-to-use or alternative tool recommendations.
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 already declare read-only, idempotent, and non-destructive. Description adds value by detailing the output (structured sections, metadata, word count) and providing an example, but does not cover error behavior or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with usage guidance. Every sentence is necessary and informative without fluff.
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?
Covers input, output, and example. Missing details on error handling or pagination, but sufficient given good schema and annotations.
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 baseline is 3. Description adds an example call that demonstrates usage of 'source' and 'sourceType', and references options in the schema, providing extra context.
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 it extracts text from PDFs and HTML URLs, specifies return of structured sections, metadata, and word count, and includes an example. It distinguishes from siblings by focusing on document extraction.
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?
Explicitly says 'Use this when you need to extract text from a PDF URL or file' and provides examples. Does not explicitly mention when not to use or alternative tools, but the context is clear.
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 already declare read-only, idempotent, non-destructive. The description adds value by explaining the template mechanism, the 'list' special value, and an example call. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, all front-loaded and concise. Every sentence adds necessary information with no fluff.
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 purpose, usage, supported templates, and an example. It lacks details on output format, but the structured nature of templates implies JSON. Given no output schema, it is reasonably 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?
With 100% schema coverage, baseline is 3. The description adds the special 'list' usage for the template parameter and provides an example, clarifying behavior 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 clearly states the tool's purpose: getting structured data from well-known sites using templates, avoiding custom selectors. It lists specific template IDs, distinguishing it from siblings like 'scrape_structured' that may require custom selectors.
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 tells when to use it (structured data from well-known sites) and hints at listing templates with 'list'. While it doesn't explicitly exclude alternatives, the list of supported sites implies when not to use (non-listed sites). Sibling tools are present but not referenced.
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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details beyond annotations: it mentions two summarization modes (extractive and abstractive) and the backend (Ollama/sampling). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a purpose: first sentence states when to use, second defines modes, third provides an example. It is front-loaded with usage guidance and contains no unnecessary words.
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 no output schema, the description does not enumerate return values, but it sufficiently conveys the tool's purpose and behavior. It mentions 'condensed version' and supports extraction/abstractive modes. Agents can infer what they get back. Slight gap: no mention of output format, but it's acceptable for this tool.
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% as both parameters (text, options) have descriptions. The description adds value by clarifying that 'text' typically comes from extract_text/extract_content and provides an example showing 'options' properties (summaryLength, summaryType). This goes beyond the schema's minimal 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 clearly states the tool's purpose: condensing text content. It specifies the input source (extract_text/extract_content) and use cases (briefings, comparison tables, LLM context reduction). This effectively distinguishes it from sibling tools like extract_text (which extracts but doesn't summarize) and analyze_content (which might analyze but not condense).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool when text content is available and a condensed version is needed. It provides concrete examples of when to use it (e.g., briefings, comparison tables). However, it lacks explicit guidance on when not to use it or alternatives besides the implicit reference to extract_text/extract_content.
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?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses hard limits (maxSteps, maxUrls, wall-clock), confirmation behavior for pro model, and degraded output when LLM keys or Ollama are missing. This adds significant behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 5 lines, with clear sections for usage, behavior, limits, and an example. Every sentence adds value and there is no fluff.
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 complexity (6 parameters, 1 required, nested objects, no output schema), the description covers key behavioral details, limits, edge cases (degraded output), and return type. It is complete enough for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds a summary and example, but does not provide additional semantic detail for individual parameters beyond what the schema offers. Baseline score of 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 clearly states the tool's purpose: an autonomous agent for web research and synthesis without requiring URLs. It distinguishes from other tools like search_web or deep_research by emphasizing autonomy and no need for seed URLs.
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 specifies when to use: when an autonomous agent is needed for web research. It mentions model variations and confirms before pro runs, but does not explicitly compare to sibling tools or state when not to use it. However, the context is sufficient for most agents.
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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by enumerating the specific NLP features available (sentiment, topics, etc.) and provides an example demonstrating how to invoke these features, which goes beyond what annotations convey.
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 (two sentences plus a short example) and front-loaded with the usage guidance. Every sentence serves a clear purpose: stating when to use, what it does, and how to use it. No unnecessary information.
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 NLP analysis tool with 2 parameters and no output schema, the description adequately covers what the tool does and how to use it. However, it could be more complete by briefly noting the expected return format (e.g., returned object structure) to compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, but the description adds significant semantic value by listing concrete analysis capabilities and showing an example with options like extractTopics and includeSentiment. This transforms the generic 'options' object into meaningful parameters.
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 as providing NLP metrics for text, listing specific capabilities like language detection, sentiment, topic extraction, entity recognition, and readability score. This effectively distinguishes it from sibling tools focused on scraping or extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when you need NLP metrics for text') and provides an example of usage, giving clear context. However, it does not mention when not to use it or directly name alternatives among the extensive sibling list.
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 already declare readOnlyHint and idempotentHint. The description adds that it returns titles, URLs, snippets, and optional metadata, and supports filters. No contradictions. Adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus an example. No fluff. Every sentence adds value. Front-loaded with purpose.
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 tool with 18 parameters and rich schema, the description is sufficiently complete. It explains the tool's role, when to use, key features, and provides an example. No output schema but return type is described. An agent can correctly select and invoke this 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 covers 100% of parameters with descriptions. The description mentions lang, time_range, and site filters, and gives an example with limit and time_range. This adds some illustration but the schema already provides full documentation. Baseline score of 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 clearly states it performs web search and returns titles, URLs, snippets, and optional metadata. It also distinguishes from sibling tools like fetch_url and deep_research. The 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you need web search results' and provides guidance to start research workflows here before using fetch_url or deep_research. Also includes an example showing typical usage.
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 already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context about requiring Ollama server and environment variable, which is beneficial beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Every sentence is essential: action, purpose, prerequisite.
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 parameterless tool with a simple output, the description fully covers what the tool does, why it is useful, and what is needed to use it. No gaps.
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?
With zero parameters, baseline is 4. The description adds value by explaining the purpose of the output (model names for extract_with_llm), compensating for the lack of param details.
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 'List the Ollama models installed locally on this machine' using a specific verb and resource. It also distinguishes itself from sibling tools by noting its output is used by extract_with_llm.
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 tells when to use the tool ('Use this to discover which model values you can pass to extract_with_llm') and states the prerequisite of Ollama running on localhost or OLLAMA_BASE_URL.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mysleekdesigns/crawlforge-mcp'

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