chameleon

by xiabai2008

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: single URL scraping, batch scraping, site crawling, URL mapping, structured extraction, web search, screenshots, proxy checks, job status, robots.txt, and network logs. Descriptions clearly distinguish between overlapping concepts like crawl_site vs map_site and scrape_url vs extract_data.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., scrape_url, diagnose_site, get_screenshot). The only slight deviation is batch_scrape, but it still maintains the object-oriented naming style and is clearly readable.
Tool Count5/5
12 tools is well within the ideal 3-15 range and each tool serves a distinct purpose in the web scraping domain. The count feels comprehensive without being bloated.
Completeness4/5
The tool set covers the core scraping workflow: discover (map_site), analyze (diagnose_site, get_robots_txt), fetch (scrape_url, crawl_site, batch_scrape), extract (extract_data), and verify (get_screenshot, get_network_log). Minor gaps include no explicit job cancellation/management tool and no export/storage utility, but agents can work around these.
Average 3.4/5 across 12 of 12 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 9, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only restates the purpose (checking availability and exit info) without revealing network behavior, potential side effects, timeouts, or any security implications. The description adds no transparency beyond the purpose.
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 compact sentence, which is efficient and front-loaded. However, it is terse to the point of under-specification, lacking details that would make it genuinely useful. It does not waste words, but it also does not fully earn its place due to missing key 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 simplicity (one parameter) and presence of an output schema, some might argue it's complete. But the description fails to mention output shape, usage context, or any conditions (e.g., network dependency). The lack of annotations and usage guidance leaves significant gaps for a tool that seems to perform a network operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the 'proxy_url' parameter. It does not explain the expected URL format (e.g., http:// or socks5://), whether the parameter accepts authentication embedded in URL, or any constraints. The description adds no value over the schema's property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('检测' / check) and resource ('代理 IP' / proxy IP), and specifies the scope (availability and exit information). This unambiguously distinguishes it from sibling tools like scrape_url or crawl_site, which focus on web content extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. The description only states what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details such as network usage, rate limits, concurrency behavior, or output format. The tool name implies scraping, but there is no information about safety, side effects, or system impact.
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 redundant words. It is front-loaded with the verb and resource, making it efficient and easy to scan.
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 multiple parameters, an output schema, and no annotations, the description is too minimal to guide an agent on important nuances like concurrency settings, output format, or how batch results are returned. It provides only the most basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (urls, concurrency, output_format) with 0% description coverage in the schema. The description fails to explain any of them, providing no compensation for the missing schema 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 explicitly states the tool performs batch scraping of multiple URLs. This clearly differentiates it from sibling tools like scrape_url (likely single URL) and crawl_site, providing a specific verb+resource+scope.
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 an explicit condition for use: 'Use when the user gives multiple URLs.' This guides tool selection, though it does not name alternatives or explicitly say not to use for single URLs.
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 reveals that the tool returns a job_id, implying asynchronous operation, but does not detail side effects on the target site, rate limits, or how to retrieve results. This is minimal disclosure for a crawl operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff: the first states the action and return value, the second gives the trigger. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks parameter semantics, behavioral details, and explicit alternative comparisons. With four parameters and no description coverage, this is insufficient for safe and correct invocation, especially since the tool likely starts long-running crawl jobs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero explanation of parameters like strategy, max_depth, or max_pages. The agent is left without any guidance on how to set these parameters correctly, making the tool difficult to invoke properly.
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 performs '深度爬取整个网站' (deep crawl entire website) and returns 'job_id', distinguishing it from single-page tools like scrape_url by its entire-site scope. However, it does not explicitly name sibling alternatives, so differentiation is implicit rather than explicit.
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 an explicit trigger: '当用户要求采集整个网站或栏目时使用' (use when user requests to collect the entire website or section). This provides clear usage context, but it does not mention when not to use the tool or point to alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'query status,' which hints at a read-only operation, but it does not explain side effects, polling behavior, possible statuses, or whether it is safe to call repeatedly. This leaves the agent with insufficient behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core function. It contains no extraneous information, but its brevity also contributes to the lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered, but the description omits crucial context about how to obtain a job_id and how this tool fits into the async workflow. An agent would not know whether to call this after batch_scrape or crawl_site, or how long to wait before polling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes job_id as a required string, but the description adds no explanation of the parameter, its origin, or format. With 0% schema description coverage, the description fails to compensate, although the single parameter's name is self-explanatory.
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 queries the status of an asynchronous crawl task, using a specific verb ('查询'/'query') and resource. It is unambiguous and naturally distinguishes itself from sibling tools like crawl_site and scrape_url, which initiate operations rather than report status.
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 after an async job is started, but it does not explicitly state when to use it or mention which sibling tools produce a job_id. There is no exclusion of synchronous tasks or mention of alternatives, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does state a key trait—no content crawling—which signals a lighter, read-only style operation. But it omits other behaviors such as rate limiting, pagination, or how sitemap_only affects the request, leaving gaps in what the agent can anticipate.
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, compact sentence that is front-loaded with the core purpose. Every word serves a function, and there is no filler or repetition. It is excellently concise for what 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?
The tool has a simple 2-parameter schema and an output schema, but the description leaves one parameter unexplained and gives no comparative guidance against siblings. While the core purpose is clear, the missing parameter semantics and limited behavioral detail make it incomplete for an agent to fully leverage the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides zero explanation of the parameters. While 'url' is self-explanatory, 'sitemap_only' is entirely unexplained, and the description does not compensate for the missing schema documentation. The agent would have to guess the semantics of a key boolean parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers all URLs of a website and explicitly notes it does not crawl content, which distinguishes it from the sibling tool crawl_site. The verb+resource combination is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'does not crawl content' implies this tool is for pure URL discovery rather than deep crawling, giving a hint about when to use it. However, no explicit alternatives are named, and there is no guidance on when to use this versus other siblings like diagnose_site or crawl_site.
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 disclose behavioral traits. It does mention returning Markdown, but it is ambiguous what 'result pages' means (search engine results or the actual pages found). It does not disclose limitations, potential caching, or output details beyond Markdown, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and purpose. There is no redundant wording or filler; every word contributes to understanding the tool's function and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is an output schema, the description does not address parameter semantics or clarify ambiguous terms like 'result pages'. It covers the core use case but omits details needed for correct invocation (e.g., language and max_results), leaving the agent under-informed for a tool with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (query, language, max_results) or their defaults. The tool description completely fails to add meaning beyond the schema, so it cannot meet even a baseline 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 '搜索互联网并返回结果页面的 Markdown' (search the internet and return Markdown of result pages), specifying the action and output format. This distinguishes it from sibling tools like scrape_url (which targets specific URLs) and crawl_site.
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 when the user asks for real-time information/latest content), providing a clear usage context. However, it does not mention when NOT to use the tool or name alternatives, 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 the full burden. It only states purpose and usage time, but does not disclose whether diagnosis involves sending requests, potential side effects, or safety implications. 'Diagnose anti-crawling capabilities' implies probing but lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences, each serving a clear purpose: defining the tool's function and indicating when to use it. No redundant 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?
Given an output schema exists and there is only one parameter, the description provides the essential purpose and usage timing, but lacks details about the diagnostic process or prerequisites. It is minimally adequate but could be enriched with more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'url' parameter with 0% description coverage, and the tool description does not add any parameter-specific information. The agent gets no semantic guidance beyond the parameter name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('diagnose') with a clear target ('website anti-crawling capabilities') and outcome ('recommend strategy'), distinguishing it from sibling tools like scrape_url and crawl_site.
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 it ('when first encountering a new site'), providing clear context. However, it does not mention alternatives or when not to use it, so it falls short of full explicit 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 provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not reveal whether a network request is made, how missing robots.txt files are handled, or any error/rate-limit behavior. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one self-explanatory parameter, and an output schema exists, so return values need not be explained. However, the lack of usage guidance and behavioral context makes it minimally adequate but not fully complete. It covers the core purpose but leaves structural questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate for the 'url' parameter. However, the description does not mention the parameter at all or add any meaning beyond the schema's basic type and name. The parameter is self-evident, but the description fails to add context like expected format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (robots.txt rules for a website), which is specific and unambiguous. It distinguishes itself from sibling tools that focus on scraping, crawling, or diagnosing, as none specifically target robots.txt.
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 the tool is for retrieving robots.txt rules, but provides no explicit guidance on when to use it versus alternatives like scrape_url or crawl_site, nor any exclusions or prerequisites. The context is clear but not differentiated.
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, and the description carries the full burden of behavioral disclosure. It only mentions extraction based on JSON Schema, but doesn't disclose whether it executes JS, handles dynamic content, any rate limits, or that it's read-only. This is insufficient for a tool with no 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, front-loaded with the core action and then the usage condition. Every word earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose and usage scenario, and an output schema likely explains return values. However, it omits details on the 'strategy' parameter and any constraints or edge cases, leaving clear gaps in understanding for a moderately complex schema-driven tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only hints at the 'schema' parameter's role through 'based on JSON Schema'. The 'strategy' parameter is completely undocumented, and 'url' is only implicitly understood. The description provides minimal added meaning beyond the schema's field names.
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 structured data from web pages using JSON Schema, and provides specific examples of requested fields (price/title/date). This distinguishes it from sibling scraping tools like scrape_url or crawl_site.
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 the tool: when the user requests specific fields. It doesn't explicitly name alternatives or exclusions, but the context implies it's for targeted extraction vs broader scraping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the output is a base64 PNG, which is useful. However, it does not describe any limitations such as lack of JavaScript rendering, viewport behavior, or potential delays, leaving notable gaps for a screenshot 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 extremely concise, consisting of just two short sentences. It front-loads the core purpose and then gives a clear usage condition without any unnecessary 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?
Given the tool is fairly simple, the description covers the main purpose and usage context. However, it omits parameter semantics and any behavioral caveats. Since an output schema exists, return values are likely covered, but the description overall is not fully complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention either parameter (url or full_page) at all. The parameter names are somewhat self-explanatory, but full_page in particular could benefit from clarification. The description provides no added 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?
The description clearly states the tool's function: '获取网页截图（base64 PNG）' (get webpage screenshot as base64 PNG). It includes the specific resource (webpage) and output format, and it is distinct from sibling tools like scrape_url or crawl_site, which do not produce screenshots.
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 an explicit when-to-use condition: '当用户想看页面外观/布局时使用' (use when the user wants to see page appearance/layout). However, it does not mention alternatives or when not to use it, so it falls short of full 5-level 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?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It states the basic conversion behavior but does not mention dynamic content handling, wait_for behavior, proxy/geolocation behavior, extraction semantics, rate limits, authentication, or error handling. This leaves the agent guessing about important runtime characteristics.
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 long, front-loaded with the core purpose, and contains no filler. Every sentence contributes to either understanding what the tool does or when to use it.
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 an output schema, the tool has 7 parameters, no annotations, and a rich set of sibling tools (extract_data, crawl_site, batch_scrape). The description covers the simple default use case but leaves advanced invocation and parameter-specific behavior unexplained, so it is not fully contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate for 7 undocumented parameters. It only adds minimal meaning by connecting the output format to 'Markdown/JSON', but mode, schema, wait_for, proxy_region, and extract_prompt remain entirely unexplained, making it hard to use the tool beyond defaults.
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 ('采集' / scrape), names the resource ('单个 URL' / single URL), and states the conversion output (Markdown/JSON). It also implicitly distinguishes itself from siblings like search_web, crawl_site, and batch_scrape by emphasizing single-URL scope.
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?
It explicitly tells the agent when to use the tool ('当用户给出具体网址或询问某页面内容时') and what not to use it for ('不要用于：搜索互联网'), explicitly naming the alternative tool (search_web). This is exactly the when/when-not/alternatives guidance the rubric asks for.
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 behavioral disclosure burden. It only says '获取' (get) and provides filter types, but does not mention side effects, permissions, whether it makes additional network requests, or any operational caveats.
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, front-loading the core purpose in the first sentence and adding the filter_type hint in the second. Every word contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema, the description covers the basic purpose and filter options, but it lacks behavioral caveats and explicit guidance on when to use it versus sibling tools. It is minimally adequate but has clear 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by listing filter_type options (xhr|fetch|all) and implies that url refers to the target page through '页面'. However, url semantics are implicit rather than explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取页面网络请求日志' (get page network request logs) with a clear purpose '用于 API 发现' (for API discovery), making the verb, resource, and intent explicit. This clearly distinguishes it from sibling tools like scrape_url or crawl_site, which focus on page content rather than network logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is for API discovery, which tells the agent when to use it. However, it does not explicitly name alternatives or exclusions, such as when to prefer scrape_url or crawl_site.
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:

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

Score Badge

Copy to your README.md:

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

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/xiabai2008/chameleon'

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