Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Link Finder MCP Search for backlink opportunities for 'digital marketing tools'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Link Finder API — find backlink opportunities, analyze competitors, discover similar domains with AI embeddings, and manage prospecting projects directly from Claude, ChatGPT, Cursor, or any MCP client.
Secrets are provided only through environment variables, and the server is host-agnostic: run it locally over stdio, or deploy it anywhere (Render or any VM) with a bearer-token-protected HTTP/SSE endpoint.
All Link Finder API v2 endpoints are exposed as tools:
Tool | Endpoint | Plan | What it does |
|
| Booster | Plan, remaining credits, available features |
|
| Booster | Supported netlinking platforms |
|
| Booster | Countries/locations for keyword search |
|
| Booster | Find opportunities from keywords (SERP analysis) |
|
| Booster | A competitor's available referring domains |
|
| Booster | AI prospecting with relevance scoring |
|
| Booster | AI-embedding lookalike domains (the gem finder) |
|
| Booster | Create a project |
|
| Booster | List projects with counts |
|
| Booster | Favorites in a project with full metrics |
|
| Booster | Add / remove a domain from a project |
|
| Booster | Annotate a standout favorite |
|
| API | Check one domain across all platforms |
|
| API | Check up to 50,000 domains at once |
| local | — | Read locally saved search history |
Plus a guided prompt backlink_workflow that runs the step-by-step interview and prospecting flow.
The server also follows the API's best practices: every search result is saved locally to a data/ folder and logged in data/searchHistory.json so agents can avoid duplicate, credit-wasting searches.
Related MCP server: crawlgraph-mcp
Python 3.10+
A Link Finder API key — get it in your account at https://app.link-finder.net/account/ (Booster plan or higher; checkDomain and bulk need the API plan)
git clone https://github.com/<you>/link-finder-mcp.git
cd link-finder-mcp
python -m venv .venv && source .venv/bin/activate # optional but recommended
pip install -r requirements.txtCopy the example environment file and fill in your key:
cp .env.example .env
# then edit .env and set LINK_FINDER_API_KEYNo credentials in code. The API key is read only from
LINK_FINDER_API_KEYand is never accepted as a tool argument, so it can't leak through the model context.
All configuration is via environment variables:
Variable | Required | Default | Description |
| yes | — | Your Link Finder API key |
| no |
|
|
| hosted only | — | Shared secret clients send as |
| no |
| Port to bind in hosted mode (Render/Railway/Fly inject this) |
| no |
| Bind address in hosted mode |
| no |
| Streamable HTTP only. Stateless = no per-session server state; robust behind proxies/load balancers |
| no |
| Streamable HTTP only. |
| no |
| Where results + history are saved (empty = disable) |
| no |
| Override the API base URL |
| no |
| HTTP timeout in seconds |
| no | (empty) | Comma-separated Host allowlist for DNS-rebinding protection. Empty = disabled (works behind any proxy). Supports a |
| no | (empty) | Comma-separated Origin allowlist (used with the above). |
Local clients (Claude Desktop, Cursor, ...) → stdio.
Hosted (Render or any VM) → http (Streamable HTTP). This is the recommended, proxy-friendly transport; the endpoint lives at /mcp.
sse is the older transport (endpoint at /sse). It works, but long-lived SSE streams can be buffered or reset by PaaS proxies, which can stall the MCP initialization handshake. Prefer http unless your client only speaks SSE.
There are two ways to use this server. Choose based on your chat app:
A. Local (on your computer) | B. Hosted (online URL) | |
Best for | Claude Desktop, Cursor, Cline, and other desktop apps | ChatGPT, Claude (web), or any chat that connects to a remote MCP URL |
How it runs | The chat app launches the server for you | You deploy once (e.g. Render), then paste a URL + token |
Transport |
|
|
Setup | Deploy then ChatGPT · any client |
Rule of thumb: desktop app → A (local), web/cloud chat → B (hosted).
export PYTHONPATH=src
python -m link_finder_mcp.serverOr debug interactively with the MCP Inspector:
PYTHONPATH=src mcp dev src/link_finder_mcp/server.pyEdit your Claude config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"link-finder": {
"command": "python",
"args": ["-m", "link_finder_mcp.server"],
"env": {
"PYTHONPATH": "/absolute/path/to/link-finder-mcp/src",
"MCP_TRANSPORT": "stdio",
"LINK_FINDER_API_KEY": "your_link_finder_api_key_here",
"LINK_FINDER_DATA_DIR": "/absolute/path/to/link-finder-mcp/data"
}
}
}
}Restart Claude Desktop. You'll see the Link Finder tools under the tools (hammer) icon. Try:
"Check my Link Finder credits, then find French backlink opportunities for the keywords
assurance auto;comparateur assurancewith DR 20+ and 500+ traffic. Save the best ones to a new project called Assurance Q3."
Claude will chain get_account → keyword_search → create_project → add_favorite, then suggest similar_domains on the top matches.
Tip: in Claude Desktop you can also attach the
backlink_workflowprompt (the "+" / prompts menu) to launch the full guided interview.
ChatGPT supports remote MCP servers (Developer mode / custom connectors and the Responses API tools of type mcp). For that you need the server reachable over HTTPS with a bearer token — see Deploy on Render first.
Deploy the server (e.g. on Render) with MCP_TRANSPORT=http and a strong MCP_BEARER_TOKEN.
In ChatGPT: Settings → Connectors → Advanced → Developer mode, then Create a connector.
Set the server URL to your deployment's MCP endpoint, e.g. https://your-app.onrender.com/mcp.
Add an Authorization header: Bearer <your MCP_BEARER_TOKEN>.
Save, then enable the connector in a chat and ask it to find backlinks.
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-4.1",
tools=[
{
"type": "mcp",
"server_label": "link-finder",
"server_url": "https://your-app.onrender.com/mcp",
"headers": {"Authorization": "Bearer YOUR_MCP_BEARER_TOKEN"},
"require_approval": "never",
}
],
input="Use Link Finder to find Spanish (language 2724) backlink "
"opportunities for 'hosting wordpress' with TF 15+ and report a table.",
)
print(resp.output_text)Add to ~/.cursor/mcp.json (or the project .cursor/mcp.json):
{
"mcpServers": {
"link-finder": {
"command": "python",
"args": ["-m", "link_finder_mcp.server"],
"env": {
"PYTHONPATH": "/absolute/path/to/link-finder-mcp/src",
"LINK_FINDER_API_KEY": "your_link_finder_api_key_here"
}
}
}
}Most other clients (Claude on the web, n8n, custom apps, MCP SDKs, ...) connect to a remote MCP server the same way: a URL + a bearer token. After you deploy:
{
"url": "https://your-app.onrender.com/mcp",
"headers": { "Authorization": "Bearer YOUR_MCP_BEARER_TOKEN" }
}URL → your deployment + /mcp (Streamable HTTP). Use /sse only if your client speaks the legacy SSE transport.
Token → the exact value you set in MCP_BEARER_TOKEN.
That's all any compliant MCP client needs. Once connected, just ask in plain language (e.g. "find backlink opportunities for my coffee blog in France") and the model will call the right tools.
The server is host-agnostic. In hosted mode it binds 0.0.0.0:$PORT and protects the MCP endpoints with a bearer token. The recommended hosted transport is Streamable HTTP (MCP_TRANSPORT=http), served at /mcp.
A ready-made render.yaml is included:
services:
- type: web
name: link-finder-mcp
runtime: python
buildCommand: pip install -r requirements.txt
startCommand: python -m link_finder_mcp.server
envVars:
- key: PYTHONPATH
value: src
- key: MCP_TRANSPORT
value: http
- key: LINK_FINDER_API_KEY
sync: false
- key: MCP_BEARER_TOKEN
sync: falsePush this repo to GitHub.
In Render: New → Blueprint, point it at the repo.
Set the two secret env vars (LINK_FINDER_API_KEY, MCP_BEARER_TOKEN) in the dashboard.
Deploy. Your MCP endpoint will be https://<service>.onrender.com/mcp.
The same works on any VM / PaaS — just set the env vars and run python -m link_finder_mcp.server. Set MCP_TRANSPORT=sse (endpoint /sse) only if your client requires the legacy SSE transport.
Point your client at the /mcp endpoint with the bearer token:
{
"url": "https://your-app.onrender.com/mcp",
"headers": { "Authorization": "Bearer YOUR_MCP_BEARER_TOKEN" }
}Note on saved data: on ephemeral hosts (like Render's default disk) the
data/folder is not persistent. Mount a persistent disk, or setLINK_FINDER_DATA_DIRto a mounted path, if you want the search history to survive restarts. Local (stdio) usage persists normally.
Failed to validate request: Received request before initialization was complete (repeating, on SSE) — the MCP initialize handshake is stalling. With the legacy SSE transport the initialize response travels back over the long-lived GET /sse stream, and PaaS proxies (Render included) often buffer or reset that stream so it never reaches the client. Fix: use MCP_TRANSPORT=http (Streamable HTTP, endpoint /mcp), which doesn't depend on a persistent stream and runs stateless by default.
SSE error: Non-200 status code (421) / Invalid Host header — this is DNS-rebinding protection rejecting the proxy's public hostname. The server disables host checking by default (the bearer token already guards it), so a fresh deploy works out of the box. If you set MCP_ALLOWED_HOSTS, make sure it includes your public host, e.g. your-app.onrender.com.
GET / → 404 / POST <path> → 405 in the logs — harmless. Each transport serves on its own path (/mcp for Streamable HTTP, /sse + /messages/ for SSE); probes hitting other paths/methods are expected. Point your client at the right path for your transport.
Credits are shared across the web app, browser extension, and API.
keyword_search costs 1 keywords_search credit per keyword; competitor_analysis 1 per request; ai_search 1 per request; similar_domains 1 per domain (or per project search).
Credits are only consumed when results are found.
Always call get_account first to check remaining credits and which features your plan unlocks.
Each domain result includes fields you can filter and sort on: title, domain, dr (Ahrefs), tf/cf (Majestic), rd, traffic, ttf0 (topic), ai_lang, gg_news, and per-platform prices (-2 = not found, -1 = price unavailable, >0 = price in the chosen currency). Each platform also has a _url field with the direct purchase link, and best_price_platform names the cheapest one.
MIT — see LICENSE.
Add or remove a domain from a project.
Args:
project_id: Project ID (from `list_projects`).
domain_id: Domain ID (from any search result).
action: "add" (default) or "remove".
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | add | |
| domain_id | Yes | ||
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action is add or remove, without explaining persistence, side effects, idempotency, or whether the 'add' action creates a favorite record. Missing critical behavioral 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 brief and to the point, with a clear args list. No wasted words, but it could be better structured with a summary of what 'favorite' means. Still, it earns its place.
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 number of sibling tools (15), the description lacks context on how this tool fits into workflows. It does not mention that 'project_favorites' lists favorites, nor does it explain the concept of favorites. Incomplete for a simple mutation 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?
Schema description coverage is 0%, so the description adds value by explaining the source of project_id and domain_id (from other tools) and the default for action. This goes beyond the schema's type/title info, though it does not explain the meaning of 'add' or 'remove'.
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 'Add or remove' and resource 'domain from a project', making the purpose evident. However, it does not explicitly distinguish this tool from sibling tool 'project_favorites', which likely lists favorites.
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 guidance on parameter sources (project_id from list_projects, domain_id from search results), implying usage context. However, it lacks explicit instructions on when to use add vs remove, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-powered backlink prospecting (SERP + competitor + semantic matching).
Costs 1 `ai_search` credit per request. Returns extra scoring fields such
as `linkFinderScore` (1-99 relevance), `kwsFound`, `categoryScore`,
`serpScore`, and `concCount`.
Args:
url: Your domain, e.g. "mysite.com".
ia_desc: Short description of your website / niche.
ia_kw: Focus keywords, comma separated.
language: Location ID from `list_locations`.
conc1: Optional competitor domain #1.
conc2: Optional competitor domain #2.
conc3: Optional competitor domain #3.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| conc1 | No | ||
| conc2 | No | ||
| conc3 | No | ||
| ia_kw | Yes | ||
| ia_desc | Yes | ||
| language | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses credit cost and extra scoring fields returned, but lacks details on rate limits, authentication requirements, or any destructive behavior. It is adequate but not thorough.
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 front-loaded with purpose, then cost, then return fields, then argument list. Every sentence is informative with no fluff. Highly efficient.
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 complexity (7 params, no output schema, no annotations), the description covers purpose, parameters, cost, and return fields. It references list_locations for language and explains competitor fields. Minor gap: no error handling or output structure beyond stated fields.
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 0% schema coverage, the description fully explains each parameter (url, ia_desc, ia_kw, language, conc1-3) with examples and cross-reference to list_locations. This adds critical meaning beyond the bare 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?
The description clearly states it is for 'AI-powered backlink prospecting (SERP + competitor + semantic matching).' This specific verb-resource combo differentiates it from sibling tools like competitor_analysis or keyword_search, which are less comprehensive.
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 mentions credit cost and argument details but does not explicitly state when to use this tool versus alternatives. No guidance on exclusions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check up to 50,000 domains at once (API plan only).
Args:
urls: Domains separated by ";" (e.g. "site1.com;site2.com;site3.com").
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the batch size limit and API plan requirement, but does not describe the return format, error handling, or side effects. For a checking tool, these are important but not disclosed.
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 extremely concise, with only two sentences and a clear args section. Every piece of information earns its place, and the main purpose is 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?
Given the lack of annotations and output schema, the description is somewhat incomplete. It covers the basic usage and constraints but omits return value details, possible error conditions, or confirmation of no side effects. Minimum viable but leaves gaps.
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 input schema has 0% description coverage for the 'urls' parameter, but the description compensates well by specifying the format ('Domains separated by ;') and providing an example. This adds essential meaning beyond what the schema provides.
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 action ('check') and resource ('domains'), with a specific batch limit ('up to 50,000') and plan restriction ('API plan only'). This distinguishes it from the sibling 'check_domain' tool, which presumably handles single domains.
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 implies usage for bulk operations and mentions the API plan requirement, but does not explicitly state when not to use it or provide alternatives. The sibling 'check_domain' exists, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a single domain across all netlinking platforms (API plan only).
Returns SEO metrics, per-platform prices, and direct `_url` links.
Exclusive to the API plan (250€/month).
Args:
domain: Domain or URL to check, e.g. "example.com".
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It explains what the tool returns (SEO metrics, per-platform prices, _url links) and the plan restriction. It does not mention side effects, but the tool is a read-only check, so the description is sufficiently transparent.
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 highly concise: three sentences, each adding essential information (what it does, what it returns, plan requirement). No wasted words.
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 simple single-parameter tool with no output schema, the description covers all necessary aspects: input parameter, return values, and usage constraints. It is complete without needing additional detail.
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 input schema has one parameter 'domain' with no description (0% coverage). The description adds clear semantics: 'Domain or URL to check, e.g. "example.com"', fully compensating for the lack of schema description.
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 (Check), resource (a single domain), and scope (across all netlinking platforms). It distinguishes from sibling tools like bulk_check by emphasizing 'single domain' and returns specific outputs (SEO metrics, prices, links).
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 explicitly states the tool is 'API plan only' and exclusive to a 250€/month plan, guiding the agent on when it is applicable. It implies single-domain checking but does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a competitor's referring domains available on netlinking platforms.
Costs 1 `analyse_concurentielle` credit per request (only if results found).
Args:
competitor: Competitor domain, e.g. "competitor.com".
| Name | Required | Description | Default |
|---|---|---|---|
| competitor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses credit consumption condition and scopes the analysis to netlinking platforms. It does not mention side effects or return format, but for a read-like analysis, the disclosure is adequate.
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 sentences plus an argument line. It is front-loaded with the purpose, then cost, then param. No superfluous words, every sentence serves a purpose.
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?
The description covers purpose, cost, and argument, but lacks any indication of the output format (e.g., list of domains, counts). Given no output schema, the agent would benefit from knowing what to expect. Still, for a simple parameter, it is reasonably 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?
The single parameter 'competitor' is described with its meaning ('Competitor domain') and an example ('competitor.com'), adding significant value over the schema which only has type and title. With 0% schema coverage, the description fully compensates.
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 'Analyze' and the resource 'competitor's referring domains' with context 'available on netlinking platforms'. It distinguishes from siblings like 'check_domain' and 'similar_domains' which serve different purposes.
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 an explicit cost condition ('Costs 1 credit per request only if results found') and the argument format. However, it lacks explicit guidance on when not to use this tool versus alternatives like 'similar_domains' or 'check_domain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a project to organize favorite domains.
Args:
name: Project name (max 255 characters).
domain: Optional main domain for the project, e.g. "mysite.com".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| domain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects, authentication needs, or idempotency, but it does not.
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?
Concise and front-loaded with purpose, but could omit the 'Args' label for even tighter structure.
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?
No output schema and no annotation coverage; description lacks return value details, making it incomplete for a creation 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?
Parameter descriptions add constraints (max 255 characters for name) and an example for domain, which are absent in the 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?
The description clearly states the verb 'create' and resource 'project', differentiating from sibling tools like list_projects or project_favorites.
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?
No guidance on when or when not to use this tool compared to alternatives like list_projects or project_favorites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Link Finder plan, remaining credits, and available features.
Always call this FIRST in an automated workflow to confirm which endpoints your plan unlocks and how many credits remain before spending any.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden. Clearly indicates it is a read operation returning account info. No side effects mentioned, but none expected.
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?
Two sentences, zero waste. Purpose is front-loaded, usage guidance is immediate.
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, no output schema, and no annotations, description adequately covers purpose and usage context for this 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?
No parameters, schema coverage 100%. Baseline 4 applies; description explains what is returned (plan, credits, features), adding context 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?
Clearly states the tool retrieves Link Finder plan, remaining credits, and features. Distinguishes from siblings by recommending it be called first.
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?
Explicitly instructs to call this first in automated workflows and explains why (to confirm plan endpoints and credit availability before spending).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the locally saved search history (data/searchHistory.json).
Check this before launching a new search to avoid duplicate work and save credits. Returns an empty list when nothing has been saved yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It states it reads a local file, returns an empty list if nothing saved, and implies no destructive effects. It is transparent about the read-only nature and the return format.
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 has three sentences, each serving a purpose: action, usage, return. It is concise and front-loaded with the most important information.
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 no parameters and no output schema, the description covers purpose, usage, and return behavior adequately. It could be slightly more explicit about the local scope, but it is otherwise 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?
There are no parameters (0 params), and the description does not add parameter information. According to guidelines, baseline is 4 for 0 parameters. The description is consistent with the 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?
The description clearly states the tool reads the locally saved search history, with a specific file path and the behavior when empty. It distinguishes from other search-related tools by emphasizing it's for review before a new search.
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 explicitly advises checking history before a new search to avoid duplicate work and save credits, providing clear when-to-use guidance. It does not name specific alternative tools but implies this is the pre-search check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find backlink opportunities from keywords (SERP analysis).
Costs 1 `keywords_search` credit per keyword. Credits are only consumed
when results are found. This is the best entry point to discover relevant
sites in a niche.
Args:
language: Location ID from `list_locations` (e.g. 2250 France, 2840 US).
keyword: A single keyword. Use this OR `keywords`.
keywords: Multiple keywords separated by ";" (e.g. "best vpn;vpn free").
search_engine: "google" (default) or "bing".
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| keywords | No | ||
| language | Yes | ||
| search_engine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers cost, credit consumption logic, keyword input options, search engine choices, and language parameter reference. It lacks details on pagination or rate limits but provides essential behavioral context.
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 concise and well-structured: summary, cost, recommendation, then parameter list. Every sentence adds value, front-loaded with main purpose.
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 no output schema and no annotations, the description lacks details on return format, error handling, or limits on keyword count. Still covers critical input aspects.
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 0% schema coverage, the description explains each parameter meaningfully: language with examples, mutual exclusivity of keyword/keywords, and search engine defaults. Adds value beyond the 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?
The description clearly states the tool finds backlink opportunities from keywords via SERP analysis. It uses specific verbs and resources, and hints at being the best entry point, but does not explicitly differentiate from siblings like ai_search or competitor_analysis.
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 mentions credit cost and consumption condition, and recommends it as the best entry point. However, it does not specify when not to use it or contrast with alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available countries/locations for keyword search.
Use the returned `id` as the `language` argument of `keyword_search` and
`ai_search`. Served from the live API, with a built-in fallback list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions 'served from live API with a built-in fallback list', which is useful behavioral context. Does not detail rate limits or caching, but adequate for a read-only list tool.
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?
Two concise sentences with no superfluous information. Front-loaded with purpose. Every sentence earns its place.
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?
No output schema, so description should clarify return structure. Mentions returned `id` but does not specify if list contains names, codes, etc. Adequate for a simple list but could be more 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?
Tool has zero parameters, and schema coverage is 100%. Description need not explain parameters. Baseline 4 applies as specified.
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?
Clearly states it lists available countries/locations for keyword search. Verb 'List' and resource are explicit. Distinguishes from sibling tools like keyword_search and ai_search by being a preparatory list. Could be more precise about what 'locations' includes.
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?
Explicitly states to use the returned `id` as the `language` argument for `keyword_search` and `ai_search`. Provides clear actionable guidance. No need for when-not-to-use given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every supported netlinking platform (ereferer, paperclub, ...).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing behavioral traits like read-only nature, authentication needs, or rate limits. The burden is on the description but it fails to add safety or usage context.
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?
Single concise sentence with examples, front-loaded, no fluff.
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?
Tool is simple with no params and no output schema; description adequately covers the functionality of listing all supported platforms.
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 has zero parameters with 100% coverage; baseline is 3. No parameter info needed, description adds no additional semantic 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 the tool lists every supported netlinking platform, with specific examples (ereferer, paperclub). It distinguishes from sibling tools like keyword_search or competitor_analysis.
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?
No explicit when-to-use or when-not-to-use guidance. Usage is implied as retrieving the platform list, but no comparison to alternatives or context about calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects with their favorite and ordered counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention authentication requirements, pagination, ordering, or whether it respects user context. The description only states what it returns, not how it behaves.
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?
Single sentence, front-loaded with the main action, every word adds value. No redundancy or unnecessary detail.
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 no output schema and no parameters, the description is adequate but lacks details on potential pagination, ordering, or scope. It could mention that it returns all projects without filters to be 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?
There are no parameters, so the baseline is 4. The description adds value by specifying that the output includes 'favorite and ordered counts', which is not obvious from the empty input 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?
The description clearly states the verb 'List' and the resource 'all projects', with specific data returned ('favorite and ordered counts'). It distinguishes from siblings like create_project or add_favorite by focusing on listing all projects with aggregated counts.
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?
No explicit guidance on when to use this tool versus alternatives like ai_search or keyword_search. For a tool that lists all projects, it would be helpful to mention that it returns all projects without filtering, or to suggest search tools for specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all favorite domains in a project, with full SEO metrics and prices.
Args:
project_id: Project ID (from `list_projects`).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It implies a read operation but does not explicitly state read-only, nor mentions any side effects, auth needs, or rate limits.
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?
Two sentences, one for purpose and one for parameter. No redundant information, very efficient.
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?
Lacks explicit mention of return format (list of domains). No output schema, so description could better describe the structure of the response. Adequate for 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?
Schema coverage is 0%, so description compensates by explaining that project_id comes from list_projects, giving context for obtaining the parameter value.
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 the verb 'Get' and resource 'favorite domains in a project', and adds context about SEO metrics and prices. Distinguishes from sibling like 'add_favorite' which adds a domain.
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?
Mentions that project_id comes from list_projects, which is helpful. However, no explicit guidance on when to use this vs alternatives like check_domain or competitor_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find domains similar to a seed domain (or to a whole project) via AI embeddings.
One of the most powerful features: it surfaces hidden gems you won't find
through keyword search. Costs 1 `similar_domains_api` credit per domain
search, or 1 `similar_search` credit per project search. Returns up to 50
similar domains with SEO metrics.
Args:
domain: Seed domain, e.g. "example.com". Use this OR `project_id`.
project_id: Use all domains in this project as seeds. Use this OR `domain`.
currency: "euros" (default) or "dollars".
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| currency | No | euros | |
| project_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses credit costs, search scope (domain or project), and result count (up to 50). No mention of side effects or permissions, but the tool appears read-only.
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 concise and front-loaded, with key information in the first sentence. It includes necessary details without excessive verbosity.
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?
No output schema, but description states it returns up to 50 similar domains with SEO metrics, adequate for a retrieval tool. Parameter complexity is low, and the tool is self-contained.
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 0%, so description must compensate. It explains domain as a seed domain, project_id as using all domains in a project, and currency defaults. This adds significant meaning beyond the 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?
The description clearly states the tool finds similar domains using AI embeddings, with specific details on credit costs and result limits. It distinguishes itself from sibling tools like keyword_search and competitor_analysis by its embedding-based approach.
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 explains when to use domain vs project_id, mentions credit costs, and result limits. However, it does not explicitly state when not to use this tool or contrast with alternatives like competitor_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a note on a favorite domain.
Reserve notes for standout opportunities (exceptional value, perfect
thematic fit). Do NOT annotate every domain.
Args:
project_id: Project ID (from `list_projects`).
domain_id: Domain ID (must already be a favorite in the project).
note: Note text (max 500 characters).
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| domain_id | Yes | ||
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses operation (add/update upsert), max note length (500 chars), and domain must be favorite. Could mention idempotency or side effects more explicitly, but sufficient.
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?
Concise two-paragraph structure: purpose, usage guidance, then args list. Each sentence adds value, but could be slightly tighter (e.g., 'Args:' redundant if using structured format).
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 inputs, usage constraints, and when to use. Lacks return value description (no output schema), but acceptable for a mutation tool. Overall complete for its complexity.
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 0%, so description adds meaning for all three parameters: source of project_id (list_projects), condition for domain_id (must be favorite), constraint for note (max 500 characters). Fully compensates for missing schema descriptions.
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?
Clearly states verb-resource: 'Add or update a note on a favorite domain.' Distinguishes from siblings like add_favorite and project_favorites by focusing on notes specifically.
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?
Explicitly says when to use: 'Reserve notes for standout opportunities... Do NOT annotate every domain.' Also notes prerequisite: domain must be a favorite. Lacks direct comparison to alternative tools but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct purposes, though 'bulk_check' and 'check_domain' could be confused as both involve checking domains. Descriptions clarify the difference, so disambiguation is strong but not perfect.
Tool names predominantly follow a verb_noun pattern in snake_case (e.g., 'add_favorite', 'check_domain'). A few names deviate like 'project_favorites' (noun_noun) and 'similar_domains' (adjective_noun), but overall consistency is high.
With 15 tools, the count is well-scoped for a link finder/SEO tool. Each tool serves a distinct function without bloat, covering search, management, and account features.
The tool set covers core workflows: finding opportunities (keyword_search, ai_search, similar_domains, competitor_analysis), checking domains (check_domain, bulk_check), and managing favorites/projects. Minor gaps exist, such as lacking a delete_project tool, but the surface is largely complete for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO Backlinks MCP — backlink intelligence via DataForSEO Backlinks API
Backlink & domain authority MCP for AI agents: referring domains, link gap, toxic review queue
Backlink Analysis MCP for AI Agents: authority, referring domains, and competitor link gaps.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/webloom-agency/link-finder-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
