Crawlgraph MCP
Server Details
MCP server for the CrawlGraph backlink-intelligence API. Gives any MCP client - Claude Desktop, Claude Code, Cursor, Cline, Zed, Windsurf - backlink lookups and competitor gap analysis built on the public Common Crawl webgraph (4.4B edges, 120M domains).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: backlinks for single domain, gap_analysis for competitor gaps, gap_outreach_targets for prioritized outreach, releases for listing snapshots. No overlap.
All names use snake_case consistently, though they are noun phrases rather than verb_noun. Pattern is predictable and readable across all tools.
4 tools is well-scoped for a backlink analysis server. Each tool serves a distinct need without unnecessary bloat or missing essentials.
Covers core workflows: single backlinks, gap analysis, outreach targets, and release management. Minor gap in additional graph metrics but sufficient for common use cases.
Available Tools
4 toolsbacklinksBacklink lookupARead-onlyIdempotentInspect
Look up referring domains (backlinks) for a single target domain from the Common Crawl webgraph. Returns each linking domain with host count and CrawlGraph authority score, plus the target's own authority/rank. Costs one backlinks call against the monthly quota (1,000/mo on lifetime).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 'authority' (default) or 'hosts'. | |
| limit | No | Max rows (1..10000, default 1000). | |
| domain | Yes | Target domain, e.g. 'stripe.com'. | |
| release_id | No | Common Crawl release id (defaults to latest; see the releases tool). |
Output Schema
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| cg_rank | Yes | |
| results | Yes | |
| returned | Yes | |
| release_id | Yes | |
| cg_authority | Yes | |
| release_label | Yes | |
| total_linking_domains | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds beyond annotations by detailing return values (host count, authority score, target's own authority/rank) and the quota cost per call, which are not in 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 three concise sentences, front-loaded with purpose and outputs. Every sentence provides valuable information without redundancy.
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 presence of an output schema and full parameter descriptions, the description covers purpose, return, and quota. It could be more complete by referencing the releases sibling tool for release_id, but overall it's sufficient.
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 coverage is 100%, so baseline is 3. The description does not add significant parameter-specific meaning beyond the schema, though it reinforces that domain is a single target.
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 'Look up' and resource 'referring domains (backlinks) for a single target domain'. It distinguishes from sibling tools like gap_analysis, which are for different analyses.
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 specifies it's for a single target domain and mentions cost/quota, providing usage context. However, it does not explicitly mention when not to use this tool or suggest alternatives like the releases tool for release_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gap_analysisCompetitor backlink gap analysisARead-onlyIdempotentInspect
Run a competitor backlink gap analysis: find domains that link to one or more of your competitors but NOT to you. Submits an async job and polls until done (usually 5-30s). Returns every gap with found_on listing which competitors each domain links to. Costs one gap job against the monthly quota (50/mo on lifetime).
| Name | Required | Description | Default |
|---|---|---|---|
| my_domain | Yes | Your domain. | |
| competitor_domains | Yes | 1 to 5 competitor domains. |
Output Schema
| Name | Required | Description |
|---|---|---|
| gaps | Yes | |
| my_domain | Yes | |
| total_gaps | Yes | |
| competitor_domains | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, openWorld, idempotent, not destructive. Description adds async job submission, polling behavior, and quota consumption, enriching beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: what it does, how it executes, what it returns. Concise and front-loaded.
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?
Covers async behavior, polling time, quota cost, and return structure (found_on field). Output schema exists to handle detailed return format, so description is sufficiently complete.
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 covers both parameters with descriptions. Description adds context that competitor_domains is 1-5 and clarifies the logic of finding gaps (linking to competitors but not you), adding value beyond schema.
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?
Description clearly states 'competitor backlink gap analysis' and explains finding domains linking to competitors but not to you. Distinguishes from sibling tools like 'backlinks' and 'gap_outreach_targets'.
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?
Describes async nature, polling duration (5-30s), and quota cost (50/mo). Does not explicitly state when not to use or compare to alternatives, but context from siblings implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gap_outreach_targetsOutreach target finderARead-onlyIdempotentInspect
The warm-outreach play. Runs a gap analysis, then ranks results: PRIORITY = domains linking to ALL your competitors but not you (publishers who cover your whole space and have never heard of you), SECONDARY = domains linking to 2+ competitors. Platform/CDN noise is filtered, top N priority targets are scored by authority. Use 2-3 competitors. Costs one gap job + one backlinks call per enriched target.
| Name | Required | Description | Default |
|---|---|---|---|
| my_domain | Yes | Your domain. | |
| enrich_top | No | Authority-score the top N priority targets. Default 10; each costs one backlinks call. 0 disables. | |
| include_platforms | No | Keep platform/CDN/social domains in the list. Default false. | |
| competitor_domains | Yes | 2 to 5 competitor domains (2-3 recommended). |
Output Schema
| Name | Required | Description |
|---|---|---|
| my_domain | Yes | |
| total_gaps | Yes | |
| priority_targets | Yes | |
| secondary_targets | Yes | |
| authority_enriched | Yes | |
| competitor_domains | Yes | |
| platforms_filtered | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, but the description adds significant behavioral detail: it internally runs a gap job and backlinks calls, filters platform/CDN noise, and scores targets by authority. No contradictions.
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?
Extremely concise: five sentences covering purpose, priority logic, filters, authority scoring, competitor count, and cost. No wasted words; front-loaded with the key concept.
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 an output schema exists, the description adequately covers the workflow, input constraints, and output ranking logic. All essential aspects are addressed without redundancy.
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 coverage is 100% with good individual parameter descriptions. The tool description adds value by contextualizing parameters (e.g., 'enrich_top costs one backlinks call') and recommending '2-3 competitors' for the competitor_domains array.
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?
Description clearly states it runs a gap analysis and ranks results into PRIORITY and SECONDARY targets, specifying the exact logic. It distinguishes itself from sibling tools like backlinks and gap_analysis by combining both into a specific 'warm-outreach play'.
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?
Provides explicit usage guidance: 'Use 2-3 competitors' and notes the cost (one gap job + backlinks call per enriched target). Does not explicitly state when not to use or alternatives, but the context is clear for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
releasesList Common Crawl releasesARead-onlyIdempotentInspect
List the Common Crawl releases the API can query. Does not count against any quota. Use a release id with the backlinks tool to query a specific snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| releases | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it does not count against quota, which is a rate-limit trait beyond what annotations cover. No contradictions.
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 only two sentences, no wasted words. It front-loads the core purpose in the first sentence. Every sentence adds unique value: listing action, quota note, and usage guidance with sibling tool.
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 zero parameters and an output schema (presumably explaining the release id), the description is complete. It covers what the tool does, its non-counting behavior, and how to use its output. No gaps for such a simple tool.
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?
The tool has no parameters, so the input schema is trivially covered. The description does not need to explain parameters, but it implicitly references the release id as an output (used with backlinks). Baseline score of 4 applies.
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 'List the Common Crawl releases the API can query', specifying the exact verb and resource. It distinguishes this tool from siblings by mentioning that the release id is used with the backlinks tool, implying this is the listing tool.
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 instructions on when to use this tool (to list releases) and includes a key usage note: it does not count against quota. It also explains how to use the output (release id) with the backlinks tool. Lacks explicit 'when not to use', but the guidance is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!