MCP (Model Context Protocol) server for Averra Extract — lets AI agents like Claude, Cursor, and ChatGPT convert any webpage into clean, LLM-ready Markdown.
Listed in the official MCP registry as dev.averra/extract. MCP clients that support registry-based install can reference that identifier directly; for clients that need manual configuration, see the install sections below.
Exposes the Averra Extract API as 5 MCP tools:
Tool | Description |
| Convert any URL to clean Markdown with metadata |
| Check monthly quota and remaining requests |
| Create a new API key |
| List all API keys on the account |
| Revoke an API key by ID |
Related MCP server: mcp-server-scraper
Sign up at averra.dev — the free plan includes 50 requests/month.
Add this to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"averra-extract": {
"command": "npx",
"args": ["-y", "@averra/extract-mcp"],
"env": {
"AVERRA_EXTRACT_API_KEY": "sk_live_your_key_here"
}
}
}
}Restart Claude Desktop. The 5 tools will appear in your session.
Add to ~/.cursor/mcp.json (or use the Cursor MCP settings UI):
{
"mcpServers": {
"averra-extract": {
"command": "npx",
"args": ["-y", "@averra/extract-mcp"],
"env": {
"AVERRA_EXTRACT_API_KEY": "sk_live_your_key_here"
}
}
}
}Any stdio-based MCP client works. Point it at npx -y @averra/extract-mcp with AVERRA_EXTRACT_API_KEY in the environment.
Env var | Required | Default | Description |
| yes | — | Your Extract API key (starts with |
| no |
| Override API host |
| no |
|
|
| no |
| Port when |
Once installed, try:
"Extract the content from https://example.com and summarize it"
"What's my remaining Extract quota this month?"
"Read https://docs.anthropic.com/en/docs/intro and tell me the key concepts"
"List my Extract API keys"
MIT
Check the current month's Extract API usage and remaining quota for the authenticated account.
Usage is counted per user across all API keys (not per key). Cached requests also count against the quota. The counter resets at the start of each calendar month (UTC).
Args:
response_format ('markdown' | 'json', optional): Output format. Default 'markdown'.
Returns: For JSON format: { "plan": "free" | "starter" | "pro" | "scale", "monthly_limit": number, // Max requests allowed this month "used": number, // Requests made so far this month "remaining": number // max(0, monthly_limit - used) }
For Markdown format: a summary showing plan, limit, used, and remaining.
Examples:
Use when: "How many extracts do I have left this month?"
Use when: Before a batch of extracts, to confirm sufficient quota.
Use when: User asks "Am I on the free plan?" — the plan field answers this.
Error Handling:
401: Invalid API key — check AVERRA_EXTRACT_API_KEY
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable output (default), 'json' for machine-readable structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains that usage is counted per user across all API keys (not per key), cached requests count against quota, and counters reset at the start of each calendar month (UTC). While annotations cover safety (read-only, non-destructive, idempotent, open-world), the description provides operational details that help the agent understand quota mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, args, returns, examples, error handling) and front-loaded key information. While comprehensive, some sections like the detailed return format examples could be slightly condensed, but overall it's efficient and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only quota checking tool with comprehensive annotations and a simple parameter schema, the description provides excellent contextual completeness. It includes purpose, usage guidelines, behavioral details, parameter documentation, return format examples, and error handling—all without needing an output schema since return values are clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the single optional parameter (response_format with enum values and default). The description repeats this information in the 'Args' section but doesn't add significant semantic value beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the current month's Extract API usage and remaining quota for the authenticated account.' It specifies the exact resource (Extract API usage/remaining quota) and timeframe (current month), distinguishing it from sibling tools like key management or extraction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples with 'Use when:' statements, including scenarios like checking remaining quota, confirming quota before batch operations, and identifying the user's plan. It gives clear context for when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Extract API key for the authenticated account.
IMPORTANT: The plaintext key is returned ONLY ONCE in this response. It cannot be retrieved later — only the prefix is stored for display. If lost, the key must be revoked and a new one created.
The new key automatically inherits the plan and limits from your account's current subscription. You cannot choose a plan — it is determined by your billing state.
Args:
response_format ('markdown' | 'json', optional): Output format. Default 'markdown'.
Returns: For JSON format: { "key": string, // FULL plaintext key (shown once) — format: sk_live_<48 hex> "id": string, // Key ID for management operations "prefix": string, // First 12 chars (for display/reference) "plan": "free" | "starter" | "pro" | "scale", "monthly_limit": number, "created_at": string, // ISO 8601 "warning": string // Reminder to save the key }
Examples:
Use when: User wants to create a new API key for a different integration.
Use when: Rotating keys (create new, then revoke old).
Don't use without user confirmation — this creates a credential the user must save.
Error Handling:
401: Invalid API key — check AVERRA_EXTRACT_API_KEY
500: Database error — retry
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable output (default), 'json' for machine-readable structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it discloses that the plaintext key is returned only once and cannot be retrieved later, explains that the key inherits plan/limits automatically from the subscription, and includes error handling details (401, 500). These are not covered by the annotations, which only indicate it's a non-readOnly, non-destructive, non-idempotent, openWorld operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, important notes, args, returns, examples, error handling), front-loaded with critical information, and every sentence adds value without redundancy. It efficiently communicates necessary details in an organized manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating a sensitive API key), the description is complete: it explains the tool's purpose, critical behavioral warnings, parameter usage, return format details (compensating for no output schema), usage examples, and error handling. This provides all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single parameter 'response_format', the schema already fully documents it. The description adds minimal value by briefly mentioning the parameter in the 'Args' section but does not provide additional semantic context beyond what's in the schema. However, since there's only one parameter and the schema is comprehensive, a score above baseline is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new Extract API key') and resource ('for the authenticated account'), distinguishing it from siblings like 'averra_list_api_keys' and 'averra_revoke_api_key'. It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool (e.g., 'User wants to create a new API key for a different integration' and 'Rotating keys'), when not to use it ('Don't use without user confirmation'), and mentions alternatives implicitly through sibling tool names. It clearly defines the context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert any webpage URL into clean, LLM-ready Markdown using Averra Extract.
This tool fetches the page (executing JavaScript via a headless browser), strips navigation/ads/UI clutter via Mozilla Readability, converts the main content to Markdown, and returns it along with metadata (title, word count, links, language). Results are cached for 7 days and shared across users.
Use this when you need the actual content of a webpage for an LLM — e.g. reading a blog post, docs page, article, or product page to answer a question or synthesize information.
Args:
url (string, required): The webpage URL. Accepts https://example.com or bare example.com (https:// is auto-added). Max 2048 chars.
response_format ('markdown' | 'json', optional): Output format. Default 'markdown'.
Returns: For JSON format, structured data: { "markdown": string, // Clean markdown content of the page "metadata": { "title": string, // Page title (from first H1 or URL fallback) "word_count": number, // Word count of extracted text "links": string[], // Unique URLs found in the content "language": string, // "en" or "unknown" "timestamp": string // ISO 8601 extraction time }, "warning": string (optional) // Present if content is thin (<200 words) }
For Markdown format: a formatted document with title, metadata summary, and the extracted markdown.
Counts against your monthly Extract quota (including cached requests). Use averra_check_usage to see remaining quota.
Examples:
Use when: "Summarize this blog post: https://example.com/post" → extract then summarize
Use when: "What does this docs page say about auth?" → extract then answer
Don't use when: You just need a link preview or metadata (this returns full content)
Don't use when: You need JSON extraction with a schema (not supported yet)
Error Handling:
400: URL rejected by safety checks (malformed, private IP, unreachable host) — check the URL resolves publicly.
401: Invalid API key — check AVERRA_EXTRACT_API_KEY env var
404: Page not found at URL
429: Monthly limit exceeded — upgrade plan or wait
502/503/504: Scraping service temporarily unavailable — retry
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The webpage URL to extract content from. Accepts full URLs (`https://example.com`) or bare hostnames (`example.com` — auto-prefixed with `https://`). Max 2048 chars. Private/internal IPs are blocked by the API. | |
| response_format | No | Output format: 'markdown' for human-readable output (default), 'json' for machine-readable structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide: it explains the 7-day caching with cross-user sharing, mentions the monthly quota system, details the JavaScript execution via headless browser, and provides comprehensive error handling information (specific HTTP status codes with explanations). While annotations cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true), the description enriches understanding of operational constraints and implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidance, args, returns, examples, error handling) and most sentences earn their place. However, the error handling section is quite detailed with multiple specific status codes, making it somewhat lengthy. The information is valuable but could be more concise in presentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with rich annotations and no output schema, the description provides excellent completeness: it explains the return format in detail for both JSON and Markdown outputs, covers quota implications, references sibling tools, provides concrete usage examples, and documents error scenarios. This gives the agent comprehensive understanding despite the lack of structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions the URL format acceptance (bare hostnames get https:// auto-added) and clarifies the default response_format, but doesn't provide additional semantic context. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Convert any webpage URL into clean, LLM-ready Markdown') and distinguishes it from alternatives by emphasizing it's for extracting actual content rather than just metadata or link previews. It explicitly names the technology (Averra Extract) and processing steps (fetching with JavaScript execution, Mozilla Readability cleanup, Markdown conversion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ('when you need the actual *content* of a webpage for an LLM') with concrete examples (blog posts, docs pages, articles, product pages) and when not to use ('just need a link preview or metadata' or 'need JSON extraction with a schema'). It also references the sibling tool averra_check_usage for quota management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all API keys for the authenticated account.
Returns metadata only — the actual plaintext keys are never returned (only prefixes). Includes both active and revoked keys, ordered by creation date (newest first).
Args:
response_format ('markdown' | 'json', optional): Output format. Default 'markdown'.
Returns: For JSON format: { "keys": [ { "id": string, // Key ID (use for revoke operations) "key_prefix": string, // First 12 chars of key "plan": "free" | "starter" | "pro" | "scale", // Decorated from the account profile — identical across every key on the account. "monthly_limit": number, // Decorated from the account profile — identical across every key on the account. "is_active": boolean, // false if revoked "created_at": string, // ISO 8601 "revoked_at": string | null // ISO 8601 if revoked, null otherwise } ] }
Examples:
Use when: User asks "How many API keys do I have?"
Use when: Need to find a key's ID before revoking it.
Use when: Auditing which keys exist and their plans.
Error Handling:
401: Invalid API key — check AVERRA_EXTRACT_API_KEY
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable output (default), 'json' for machine-readable structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond this: it specifies that plaintext keys are never returned (only prefixes), includes both active and revoked keys, orders by creation date, and notes that plan/limit are identical across keys. This enriches behavioral 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, Args, Returns, Examples, Error Handling), but includes verbose JSON output details that could be omitted if an output schema existed. Sentences are front-loaded and purposeful, though the Returns section is lengthy for a tool without an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter), rich annotations, and no output schema, the description is complete: it covers purpose, usage, behavior, parameter, return format, examples, and error handling. The detailed JSON output compensates for the lack of output schema, ensuring the agent understands the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the optional 'response_format' parameter (enum, default, description). The description adds minimal value beyond the schema, only restating the parameter in the Args section without new semantics. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all API keys for the authenticated account'), and distinguishes it from siblings by specifying it returns metadata only (not plaintext keys), unlike averra_create_api_key (creates) or averra_revoke_api_key (revokes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'Use when' examples (e.g., 'How many API keys do I have?', 'Need to find a key's ID before revoking it'), which clearly indicate when to use this tool versus alternatives like averra_revoke_api_key (for revocation) or averra_check_usage (for usage data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke an Extract API key by its ID. The key is immediately deactivated and cannot be reactivated — create a new key if needed.
SAFETY: You cannot revoke the key that is currently authenticating the MCP server itself (the one set in AVERRA_EXTRACT_API_KEY). Attempting to do so returns a 400 error.
Args:
id (string, required): The key ID to revoke. Get this from averra_list_api_keys.
response_format ('markdown' | 'json', optional): Output format. Default 'markdown'.
Returns: For JSON format: { "message": "API key revoked", "id": string, // The revoked key's ID "prefix": string, // Key prefix for confirmation "revoked_at": string // ISO 8601 revocation time }
This operation is destructive (cannot be undone) but idempotent (revoking an already-revoked key is safe).
Examples:
Use when: User explicitly asks to revoke a specific key.
Use when: Rotating keys — after confirming the new key works.
Don't use without user confirmation — this invalidates a credential.
Error Handling:
400: Attempting to revoke the currently-authenticating key — use a different auth key first
401: Invalid API key — check AVERRA_EXTRACT_API_KEY
404: Key not found or already revoked
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the API key to revoke (from averra_list_api_keys). Cannot be the key currently authenticating this request. | |
| response_format | No | Output format: 'markdown' for human-readable output (default), 'json' for machine-readable structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations. While annotations indicate destructive and idempotent hints, the description elaborates with safety warnings (e.g., cannot revoke the currently authenticating key, returns 400 error), idempotency details ('revoking an already-revoked key is safe'), and error handling specifics (400, 401, 404). This provides actionable insights not covered by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (e.g., Args, Returns, Examples, Error Handling) and front-loaded key information. While comprehensive, some sections like 'Error Handling' are detailed but necessary for clarity. It avoids redundancy and each sentence adds value, though it could be slightly more concise in parts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with safety constraints), rich annotations, and lack of output schema, the description is highly complete. It covers purpose, usage, parameters, return values, examples, and error handling, providing all necessary context for an AI agent to invoke the tool correctly and handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents parameters well. The description adds minimal extra semantics, such as referencing averra_list_api_keys for obtaining the ID and noting the default output format. However, it doesn't provide significant additional meaning beyond the schema, so it meets but doesn't exceed the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('revoke') and resource ('Extract API key by its ID'), distinguishing it from sibling tools like averra_create_api_key and averra_list_api_keys. It explicitly mentions the immediate deactivation and irreversibility, which clarifies the nature of the operation beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool (e.g., 'User explicitly asks to revoke a specific key' and 'Rotating keys — after confirming the new key works') and when not to use it ('Don't use without user confirmation — this invalidates a credential'). It also references sibling tools like averra_list_api_keys for obtaining the key ID, offering clear alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: check_usage monitors quota, create_api_key and revoke_api_key manage key lifecycle, list_api_keys provides inventory, and extract_url performs content extraction. The descriptions explicitly differentiate use cases, preventing agent misselection.
All tools follow a perfect 'averra_verb_noun' pattern (e.g., averra_check_usage, averra_create_api_key), using snake_case consistently. The prefix 'averra_' identifies the server domain, and verb-noun combinations are uniformly applied across all five tools.
Five tools is well-scoped for the server's purpose of API key management and content extraction. Each tool earns its place: quota checking, key creation/listing/revocation, and the core extraction functionality, with no redundancy or obvious omissions for this focused domain.
The toolset provides complete coverage for API key lifecycle (create, list, revoke) and quota management, with the core extraction functionality included. A minor gap exists in lacking a tool for updating or managing account plans, but agents can work around this using existing tools for most workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Swwyymm/averra-extract-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
