WET - Web Extended Toolkit

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v3.7.3
Disambiguation4/5
search, extract, media, config, and help have broadly distinct top-level jobs, and the search-vs-extract guidance is explicit. However, config__open_relay sits awkwardly alongside config, and sub-actions like extract-agent and search action="x" can both produce synthesized answers, creating mild selection ambiguity.
Naming Consistency3/5
Most top-level names are lowercase single words, but there is no consistent verb_noun pattern across the set. config__open_relay breaks the simple naming style, and search/extract/media are broad nouns/verbs whose internal actions like batch, crawl, or diff are not reflected in the tool names.
Tool Count5/5
With 6 top-level tools, the server stays well-scoped for a web toolkit: search, extract, media, config, and help each serve a distinct high-level need. The many sub-actions are tucked inside these tools rather than inflating the exposed tool list.
Completeness4/5
The toolkit covers a broad workflow: finding, reading, crawling, structured extraction, page interaction, media download, and configuration. The main gap is that media handling stops at local download, with media analysis explicitly delegated to another server, and some sub-actions overlap rather than adding entirely new capabilities.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 115 of 118 community issues answered or closed in the last 6 months
- 351 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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?
The description does not disclose behavioral traits such as side effects, permissions, reversibility, or what happens on success/failure. The annotations indicate idempotent and non-destructive, but the description does not elaborate on these, leaving the actual behavior of actions like set or cache_clear unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: it opens with a clear summary then lists actions in a compact, pipe-separated format. It is front-loaded with the main purpose and does not include unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (many distinct actions), the description is incomplete. It does not explain what each action does, any side effects, or required parameters for each action. It relies on the help tool for full docs, which is not sufficient for a complete understanding.
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 description adds no meaning to the schema parameters. It lists actions but does not explain the role of 'key', 'force', 'value', or 'remote_type'. The schema provides types and defaults but no descriptions, so the parameter semantics are entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Server config and management' and enumerates specific actions (status, set, cache_clear, etc.), which gives a good high-level understanding. It is distinct enough from sibling tools, though it does not explicitly compare with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It only suggests using the help tool for full documentation, which is a weak form of guidance. There is no indication of prerequisites or typical use cases for the listed actions.
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 responsibility for disclosing behavior. It mentions the side effect of opening a browser 'when possible', and lists return values (URL, browser launched, status). However, it omits potential failures, permission requirements, or any side effects beyond the browser action.
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, front-loaded with the primary purpose, and includes all essential behavioral information without superfluous details. It earns its length efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (likely documenting the return values), the description covers the core purpose and side effects adequately. It lacks details on error handling or integration with other tools, but for a straightforward config command it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'ctx', a standard context object, but the description does not mention or explain it. Schema coverage is 0% as the description adds no parameter-specific meaning. While the ctx parameter is typically auto-injected, the description should at least note its presence or purpose, making this a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'relay configuration URL', and specifies the browser-opening behavior. It distinguishes itself from the sibling 'config' tool by focusing on the relay URL retrieval and browser action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no preconditions, and no mention of when it should not be used. It simply states what the tool does without contextual advice.
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 and idempotentHint=true, covering safety. Description adds that it returns detailed documentation, but no extra behavioral traits beyond what annotations convey. Consistent but not additive.
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?
Efficient: first sentence states purpose, second lists valid values, then a concise quick guide in bullet-style. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter; description covers purpose, usage guidelines, valid values, and sibling differentiation. Output schema exists but return values are self-explanatory. Complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with only type 'string' and a default. Description compensates by explicitly listing valid tool_name values ('search, extract, media, config') and explaining each's usage in the guide, adding 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 'Get detailed documentation for any tool,' using a specific verb and resource. It distinguishes from siblings via the quick guide that maps each sibling tool to its purpose.
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 'Call this when you need full parameter reference or usage examples.' Provides a quick guide comparing sibling tools, stating when to use each (e.g., 'Need to FIND information? Use search'), giving clear when-to-use and when-not-to-use 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=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it notes that 'x' returns a synthesized answer with citations (not a link list), mentions billing (~$0.032/query), and explains that 'enrich' adds latency. It also clarifies that results are listings, not full content. Minor gap: no mention of pagination or rate limits, but the description adds substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Actions, Key parameters) and front-loaded with the core purpose. It is longer than ideal but every sentence adds value—each action has an example, and parameters are grouped logically. The use of bullet-like formatting and examples makes it scannable. Slight deduction for length, but it's justified given the tool's complexity (8 actions, 20 parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (8 actions, 20 parameters, no schema descriptions), the description is remarkably complete. It covers all actions with examples, explains parameter semantics, notes behavioral nuances (e.g., X's synthesized answers, billing), and points to the 'help' tool for full documentation. The output schema exists, so return values are not the description's responsibility. This is a comprehensive description for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does this excellently: it lists key parameters with their purpose, defaults, and action-specific applicability (e.g., 'handles / exclude_handles (x only)', 'from_date / to_date (x only)'). It also provides concrete examples for each action, making parameter usage clear. The description fully compensates for the lack of 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 clearly states the tool's purpose: 'Find information across web, academic sources, X/Twitter, or library docs.' It specifies the verb (find/search), the resource (information across multiple sources), and distinguishes it from the sibling 'extract' tool by explicitly noting it returns listings, not full content. The action list further clarifies each sub-mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it names the alternative 'extract' tool for reading full content, and details each action with examples and specific use cases (e.g., 'research' for academic sources, 'x' for X/Twitter). It also includes exclusions like 'X blocks direct extraction' and notes prerequisites like XAI_API_KEY.
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 openly discloses that the tool downloads files to local storage (a side effect consistent with readOnlyHint=false), and it explains the reserved 'prompt' parameter is ignored. It also describes the legacy action removal, adding context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points and examples, front-loaded with the core purpose. It is somewhat verbose due to the workflow and legacy notes, but every section adds value and aids usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers actions, parameters, workflow, and even directs to the help tool for full documentation. Given the output schema exists and the tool is complex, the description is remarkably complete and self-sufficient.
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 0% schema coverage, the description compensates well by explaining url, media_urls, media_type, output_dir, and prompt behavior. It also gives defaults and examples, though it omits 'max_items' and detailed accepted values for 'action'.
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 discovers and downloads media files, lists specific actions (list, download) with examples, and distinguishes from sibling tools like extract and search by naming the resource type (media) and workflow. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the typical workflow (list then download), tells when to use which action, and points to the alternative for LLM analysis (imagine-mcp's understand action). It also warns that the legacy 'analyze' action is removed, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: batch per-domain rate limiting (max 50 URLs), crawl depth and max_pages constraints, stealth anti-bot bypass, persistent browser sessions, refetch behavior, and the ability to click/fill/submit via interact. This goes well beyond the annotations and sets accurate expectations.
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 long but well-structured: opening purpose, actionable examples for each of nine modes, and a key-parameters section. It front-loads the core use case and search distinction. Every sentence earns its place given the tool's complexity; the final pointer to 'help' is a minor but useful note.
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 an 18-parameter, multi-action tool, the description is remarkably complete. It documents every action mode with examples, covers nearly all parameters with defaults and constraints, and notes the existence of an output schema. No critical gaps remain for an agent to select and invoke the tool correctly.
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 has 0% description coverage, so the description carries the full burden. It compensates with action-specific mappings, defaults (max_urls=5, depth=2, token_budget=10000), constraints (max crawl depth 5, max_pages 100), and concrete examples showing how to pass parameters. Only 'prompt' is not explicitly described, but overall semantics are richly defined.
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 'Read and return full page content from URLs or local files' and enumerates nine specific action modes (extract, batch, crawl, map, convert, extract_structured, agent, interact, diff). It distinguishes itself from the sibling 'search' tool by explicitly saying 'For finding URLs first, use the search tool instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this when you have a specific URL and need its content.' It names the alternative search tool, and each action includes an example with concrete parameter usage. The key parameters section further clarifies which parameters apply to which action.
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:

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

Score Badge

Copy to your README.md:

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

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