Linklight is an MCP server for SEO link-building that lets AI agents find prospects, research backlinks, draft outreach emails, and monitor your site's SEO health — while keeping you in control of all sending.
Key Capabilities:
Prospect Discovery: Search for link-building prospects by keyword, find similar prospects given a URL, and discover competitor backlinks (with option to exclude domains already linking to you).
Data Enrichment: Get Moz Domain Authority, contact emails, and homepage details for any domain; look up contact emails via Hunter.
Outreach Drafting & Management: Generate personalized email drafts with spam scores, save drafts for manual review, and track replies.
Backlink Monitoring: List backlinks by health status, identify lost or unhealthy links.
Opportunity Analysis: Find quick-win keywords (positions 11-30), spot prospects missing emails (sorted by DA), and more.
All sends require manual approval, keeping the agent in a supportive, non-autonomous role.
Provides email drafting capabilities by leveraging OpenAI's language models to generate personalized outreach emails.
The MCP server for SEO. Plug linklight into Claude Desktop, Claude Code, Cursor, or any MCP client and let your AI agent find prospects, draft outreach, and monitor backlinks — you approve and send.
Dashboard included. But the agent is the point.
Sign in at lightlinks.dev with Google.
Go to Settings → API Access → Generate key. Copy it.
Paste this into ~/.claude/settings.json (or your MCP client's config):
{
"mcpServers": {
"linklight": {
"type": "http",
"url": "https://lightlinks.dev/api/mcp",
"headers": { "Authorization": "Bearer sk_ll_PASTE_YOUR_KEY_HERE" }
}
}
}Restart your MCP client. Ask your agent: "List my linklight campaigns."
Full docs: lightlinks.dev/docs/mcp.
Related MCP server: seo-mcp
Tool | What it does |
| Find prospect sites for a topic (Tavily-backed, DA-enriched) |
| Find pages linking to a competitor in roundups/alternatives lists — pass |
| Given one good prospect, return 20 more like it (Exa.ai neural search) |
| DA + contact email + homepage title/description |
| Look up a contact email (Hunter) |
| Write a personalised outreach email with a built-in spam score |
| Save a drafted email against a prospect for you to review |
| Return striking-distance keywords (pages 2-3 with impressions) |
| Prospects in a campaign missing an email, sorted by DA |
| Backlinks currently broken, unreachable, or redirected |
| Query your data |
Sending emails is never exposed as an MCP tool. Every send needs your manual approval in the dashboard.
Find the top 20 prospects for "nextjs seo" with DA ≥ 40.
For each, draft a warm personalised email referencing their most recent post,
save each draft against the prospect, and show me the spam scores.Who links to ahrefs.com in roundups or "best of" articles?
Exclude domains that already link to my site, and give me the top 15 by DA.List my lost backlinks from the past 30 days, group by domain,
and tell me which ones are worth reaching out to.For campaign "Q4 outreach", find prospects without emails and run find_email
on the top 10 by domain authority.$19/mo. 7-day free trial, no credit card required.
Next.js 16 (Turbopack) on Vercel
Supabase (Postgres) with RLS on every table
NextAuth + Google OAuth (Gmail + Search Console)
Tavily for real-time web search
Exa.ai for semantic prospect discovery
OpenAI for email drafting
Moz + Hunter for enrichment
See docs/mcp/directory-submission.md for ready-to-paste listing details.
MIT — see LICENSE.
Generate an outreach email draft. Returns subject, HTML body, plain-text body, and a spam score (0-10, higher = better). Pass prospect_url to fetch the target's page and personalize the draft with a reference to their actual content — this dramatically improves reply rate over generic drafts.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | friendly | |
| topic | Yes | What the email is about | |
| site_name | No | ||
| prospect_url | No | Optional. If provided, the tool fetches this URL and uses its title + first paragraph to personalize the draft. Best URL is the specific post you want to reference; the homepage works too. | |
| article_title | No | Their article being referenced (optional) | |
| campaign_type | No | outreach | |
| prospect_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It transparently discloses the fetching behavior when prospect_url is provided and the output components. But it does not discuss auth, rate limits, or error handling, which would add completeness.
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 with a clear structure: what it does, a key usage tip, and a benefit. It avoids redundancy, though the benefit clause could be tighter.
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 7 parameters and no output schema or annotations, the description should enumerate all parameters and edge cases. It covers outputs and prospect_url well, but other parameters are ambiguous, and there is no mention of required fields beyond the schema. Overall, it is not fully 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 schema coverage is only 43%, and the description adds meaningful guidance for prospect_url (fetch and personalize). However, it leaves site_name, campaign_type, and prospect_name undefined, and does not explain tone beyond the enum. The description only partially compensates for the schema's low 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: 'Generate an outreach email draft.' It enumerates the return fields (subject, HTML body, plain-text body, spam score), which distinguishes it from sibling tools like save_draft or find_email. The resource is specific and actionable.
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 clear usage context: for drafting outreach emails, with a strong recommendation to pass prospect_url for personalization. However, it does not explicitly mention when not to use this tool or alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return known facts about a domain: Moz Domain Authority, cached contact email, homepage title/description. Data is shared across all users of linklight so common domains are instant.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare hostname, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the contact email is cached and data is shared across users, implying a shared cache. However, it does not mention potential staleness, rate limits, or behavior for unknown domains.
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 two sentences, front-loaded with the core purpose and specific output facts. Every sentence adds value, including the performance note about shared data.
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 sufficiently covers what the tool returns and mentions caching behavior, which is helpful given no output schema. It could add error handling or unknown-domain behavior, but for a simple 1-parameter tool, it is largely 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 schema already provides a full description for the 'domain' parameter (bare hostname). The tool description does not add additional meaning beyond the schema, so baseline 3 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 the tool returns known facts about a domain, listing specific outputs (Moz Domain Authority, cached contact email, homepage title/description). This distinguishes it from sibling tools like find_email or list_backlinks, as no other tool focuses on domain-level enrichment.
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 domain enrichment but does not explicitly state when to use this tool versus alternatives. It mentions data sharing and instant results as a benefit but lacks guidance on exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return pages that link to or feature a competitor in roundups / lists / alternatives / vs. articles — the classic 'who could realistically link to me if they link to my competitor' list. Optionally excludes domains that already link to my_domain (pass my_domain to get only NEW opportunities). Returns url, title, domain, position, and Moz Domain Authority.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| my_domain | No | Optional. If provided, domains that already appear as source_url on the caller's backlinks are filtered out so results are only NEW opportunities. | |
| competitor_domain | Yes | The competitor's domain, e.g. 'ahrefs.com'. Scheme and www. prefixes are stripped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the output fields (url, title, domain, position, Moz DA) and the optional filtering behavior for my_domain. It does not mention pagination or rate limits, but given the read-only nature and the explicit return format, this 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 two sentences long, front-loading the central purpose and adding a memorable analogy. Every clause earns its place without redundancy, covering purpose, optional filtering, and return format efficiently.
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?
With no output schema, the description appropriately lists the return fields and explains the optional exclusion filter. It covers the essential information for a straightforward read tool, though it could mention the limit parameter's behavior or pagination, but these are not critical for usage.
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 schema already documents competitor_domain and my_domain with useful descriptions. The description reinforces the my_domain parameter by explaining it yields only new opportunities. However, the limit parameter is not mentioned in the description, and its semantics are left to the schema's default/max/min constraints. The added value is moderate.
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 identifies the tool's function: returning pages that link to or feature a competitor in roundups/lists/alternatives/vs articles. It uses a specific verb ('Return') and resource type ('pages that link to a competitor'), and distinguishes this from sibling tools like list_backlinks (own backlinks) and list_lost_backlinks.
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 clear context for when to use the tool (finding competitor-referencing pages as potential link prospects) and explains the optional my_domain parameter to filter for new opportunities. It does not explicitly name alternative tools or when-not-to-use scenarios, but the use case is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a contact email for a domain via Hunter. Cached in domain_facts on hit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a caching side effect ('Cached in domain_facts on hit'), which is a useful behavioral trait. However, it does not mention rate limits (implied by 'via Hunter'), error behavior when no email exists, or whether the lookup is read-only. The caching note adds some transparency but not comprehensive disclosure.
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: two short sentences with no filler. It front-loads the core purpose and adds one behavioral note. Every word 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?
For a single-parameter tool with no output schema, the description is adequate but not complete. It explains the main function and a caching side effect, but does not describe the return value structure, error cases, or when to use this instead of similar tools. Given the tool's simplicity, the description is minimally 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 schema has one parameter (domain) with no description, so schema coverage is 0%. The description only says 'for a domain', which adds little beyond the parameter name. It does not clarify expected format (e.g., with or without protocol), case sensitivity, or examples. The description fails to compensate for the lack of schema documentation.
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: look up a contact email for a domain via Hunter. It uses a specific verb ('look up'), names the resource ('contact email for a domain'), and identifies the external service ('via Hunter'). This distinguishes it from sibling tools like search_prospects or enrich_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?
No guidance is provided on when to use this tool versus alternatives. It does not mention any contrasting use cases, prerequisites, or excluded scenarios. The only additional context is the caching mention, which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return prospects in a campaign that are missing a contact email, sorted by Domain Authority DESC. Use to answer 'which prospects should I run find_email on next?'
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| campaign_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior: filtering for missing emails and sorting by Domain Authority descending. It does not mention side effects or permission requirements, but for a read-only query tool this is adequately 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 two sentences: the first states the function, the second provides a use case. Every word earns its place, and it is front-loaded with the primary 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?
This is a simple query tool with two parameters and no output schema. The description covers the what, the sorting, and the intended use case. It lacks explicit mention of the limit behavior but that is in the schema, so overall 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?
Schema description coverage is 0%. The description implies campaign_id via 'in a campaign' but never names the parameter or explains the limit parameter. It adds minimal value beyond the schema, and the limit functionality is completely undocumented in the 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 tool returns prospects in a campaign missing a contact email, sorted by Domain Authority descending. This is a specific verb (return), resource (prospects in a campaign), and filter/sort, clearly distinguishing it from siblings like find_email.
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 says to use it to answer 'which prospects should I run find_email on next?', providing clear context and suggesting the workflow. However, it does not explicitly state when not to use it or mention alternative tools, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return keywords the caller's site is ranking for in Search Console, filtered to 'quick win' opportunities: position 11-30 with meaningful impressions. Sorted by opportunity score (impressions ÷ position). Use to answer 'what should I write about next?'
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| site_id | Yes | UUID from list_campaigns' sites (or run list_sites first) | |
| position_max | No | ||
| position_min | No | ||
| min_impressions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses filtering logic (position 11-30, meaningful impressions) and sorting formula (impressions ÷ position), which is valuable behavioral detail. However, it does not explicitly state whether the operation is read-only or mention auth/rate limit constraints, which are relevant for a Search Console 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 sentences, front-loaded with the action, then the use case. No fluff or repetition.
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?
With no output schema, the description could have described the return format, but it states it returns 'keywords' which is sufficient for the agent's decision. It covers the main filtering and sorting behavior. Given the tool's simplicity, it is mostly complete, though not exhaustive.
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 only 20% (only site_id described). The description compensates by explaining the purpose of position_min, position_max, and min_impressions through the 'quick win' criteria and mentions the sorting formula. It does not explain 'limit' directly, but its meaning is implied by 'sorted' results. The site_id is adequately described 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?
Description explicitly states it returns keywords the caller's site ranks for in Search Console, filtered to positions 11-30 with meaningful impressions, and sorted by opportunity score. This clearly distinguishes it from sibling tools focused on prospects, backlinks, and emails.
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 an explicit use case: 'Use to answer what should I write about next?' This gives clear context for when to invoke. It does not mention exclusions or alternatives, but sibling tools are obviously different, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a known-good prospect URL, return semantically similar URLs via Exa.ai's neural search. Use this when the caller already has one great prospect and wants 5-20 more like it. Excludes the source domain by default.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The reference URL (e.g. https://backlinko.com/link-building-tools) | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description adds key behaviors: 'Excludes the source domain by default' and 'via Exa.ai's neural search.' This gives insight into the search method and a default filtering action. It does not discuss rate limits or auth, but for a read-oriented search tool this 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?
Three concise, front-loaded sentences: purpose, usage scenario, and a key default behavior. Every sentence adds distinct value with no redundancy or filler.
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 2-parameter tool with no output schema, the description covers the operation, input, appropriate use, and an important default behavior. It conveys that the output is URLs, which is sufficient for an agent to invoke this tool effectively.
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 schema covers the URL parameter but only gives type/range for limit. The description adds context to both: URL is a 'known-good prospect' reference, and limit is implicitly tied to '5-20 more like it.' This partially compensates for the schema's 50% 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 returns semantically similar URLs via Exa.ai's neural search, using a known-good prospect URL as input. This specifies the verb+resource and differentiates it from siblings like search_prospects or find_competitor_backlinks by requiring an existing reference URL.
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 explicitly says 'Use this when the caller already has one great prospect and wants 5-20 more like it,' providing a clear context. It does not name alternatives or when-not-to-use, but the prerequisite of a known-good URL implies the distinction from broader search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List backlinks earned to a site. Filter by health_status (healthy|redirected|broken|unreachable|pending|error).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| site_id | No | ||
| health_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the health_status filter and does not describe return format, pagination, auth requirements, or other behavior.
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 front-load the purpose and the filter option without any redundant information. Every word 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?
For a tool with three optional parameters and no output schema, the description is sparse. It omits details like whether site_id is required, what limit controls, and how this differs from 'lost' backlinks, leaving significant 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 description adds meaning to health_status by enumerating allowed values and clarifies that backlinks are 'to a site' (implying site_id). However, limit's semantics are not addressed, leaving the schema's default/max/min to do the work.
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 states 'List backlinks earned to a site' with a clear verb and resource. It distinguishes from sibling tools like list_lost_backlinks by implying all earned backlinks, but does not explicitly contrast with them.
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 is given on when to use this tool versus alternatives such as list_lost_backlinks or find_competitor_backlinks. The agent must infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the caller's campaigns with id, name, status, and created_at.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It specifies the scope (caller's campaigns) and output fields, but does not explicitly mention pagination, rate limits, or that it is read-only, though 'List' implies a non-destructive 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 a single, direct sentence with no fluff. It front-loads the action and includes relevant output details, making it appropriately concise.
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 parameterless list tool, the description covers the essential behavior and return fields. It omits potential details like pagination or ordering, but these are likely secondary for a simple listing operation.
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 zero parameters, so the schema is trivially covered. The description adds value by enumerating the returned fields (id, name, status, created_at), which the schema does not provide since there is no output 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 lists the caller's campaigns with specific fields (id, name, status, created_at). The verb 'List' and resource 'campaigns' distinguish it from sibling tools like list_prospects and list_backlinks.
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 is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning exclusions or comparing to sibling tools like search_prospects or list_replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return backlinks in unhealthy states (broken, unreachable, redirected). Use to answer 'what did I lose recently?' Combine with a since filter to scope to a time window.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ISO-8601 timestamp — only include backlinks whose last_health_check is after this | |
| site_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation with 'Return' and defines the unhealthy states, but it does not mention potential behaviors like authentication, pagination, or result ordering. For a simple list operation this is acceptable but not rich.
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 with no fluff. The first sentence states the core purpose and the second gives a practical use case plus filter hint. Front-loaded and 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?
The tool is simple (3 optional params, no output schema), but with no annotations the description should cover more. It defines the key concept and use case, but does not mention site_id scope or limit behavior, leaving some ambiguity for correct invocation.
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?
Input schema coverage is only 33% (only 'since' has a description). The description mentions 'since filter' but does not add meaning beyond the schema, and it fails to explain 'limit' or 'site_id'. It does not compensate for the gap in schema documentation.
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 returns backlinks in unhealthy states (broken, unreachable, redirected). This is a specific verb+resource+scope and distinguishes it from the sibling 'list_backlinks' by focusing on lost/unhealthy backlinks.
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 gives a concrete use case ('what did I lose recently?') and suggests combining with a since filter. However, it does not explicitly name alternatives or when-not-to-use scenarios, leaving a slight gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List prospects. Filter by campaign_id and/or status (prospect|contacted|replied|live_link|declined|archived).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| campaign_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It describes a read-oriented operation ('List'), but does not disclose return format, pagination behavior, or any side effects. It adds no behavioral context beyond the basic listing action.
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: two short sentences that state the primary action and filtering options. No wasted words, and the status enum is provided inline efficiently.
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 list tool with three optional parameters and no output schema, the description covers the essential use case (listing and filtering) adequately. It omits mention of the 'limit' parameter and return format, but these are either inferable from the schema or implied by the operation.
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 must compensate. It explicitly mentions two of three parameters (campaign_id and status) and enumerates valid status values, which adds meaning beyond the bare schema. The 'limit' parameter is not described, but its schema constraints (default, min, max) are self-explanatory.
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 prospects', a specific verb+resource pair, and mentions filtering capabilities. It does not explicitly distinguish from the sibling tool 'search_prospects', but the listing vs searching distinction is implicit.
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 through the filter options (by campaign_id and/or status) but does not provide explicit guidance on when to choose this tool over alternatives like 'search_prospects'. No exclusions or alternative mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List prospects who replied to outreach. Optionally filter by ISO-8601 since date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ISO-8601 timestamp; only prospects updated after this |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions an optional filter, not return format, pagination, ordering, or read-only safety. 'List' implies read-only but does not explicitly state it, leaving significant unknowns.
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 a single, concise sentence that front-loads the core purpose and then mentions the optional filter. Every word earns its place, with no redundant 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?
The tool has no output schema and no annotations, so the description should explain return values and usage context, but it does not. It only states the basic action and one filter, leaving the agent without enough information to anticipate the response shape or behavior, making it incomplete for a non-trivial 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 50%: the 'since' parameter has a description in the schema, and the tool description repeats that it is an ISO-8601 date filter, adding no new meaning. The 'limit' parameter has no description in schema or tool, although its default and max are present. The description does not compensate for the gap.
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 'prospects who replied to outreach', which is specific and distinguishes from sibling tools like list_prospects and search_prospects. It is unambiguous about what the tool does.
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 listing prospects who replied) but does not explicitly state when to choose this over alternatives like list_prospects or search_prospects. There are no exclusions or alternative references, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a drafted email as a note on a prospect. Does NOT send — user must review and send from the linklight UI.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| body_html | Yes | ||
| body_text | No | ||
| prospect_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of behavioral disclosure. It passes the most critical behavior: the tool does not send the email, only saves it as a note, and the user must send via the UI. This goes beyond the basic verb and adds meaningful workflow context. It could mention side effects (e.g., whether the note is visible on the prospect record) but the key non-sending behavior is well covered.
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 two sentences long and front-loads the core action in the first sentence. The second sentence adds essential clarification ('Does NOT send') without redundancy. Every sentence earns its place, making it highly efficient and easy to scan.
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 save-draft tool with no output schema and no annotations, the description provides the essential context: purpose, non-sending behavior, and the follow-up workflow (review and send from the UI). It could be richer by explaining what a 'note' means on the prospect record, but the core usage context is adequately covered.
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 parameters, and the tool description adds no semantic information about the parameters. While parameter names like prospect_id, subject, and body_html are somewhat self-explanatory from the context, the description does not explain relationships such as body_text vs body_html or whether body_text is required. With zero coverage, the description needed to compensate but fell short.
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: 'Save a drafted email as a note on a prospect.' It uses a specific verb ('save') and resource ('note on a prospect'). It also distinguishes itself from a sending tool with the explicit 'Does NOT send' and points to the linklight UI for the actual send, preventing confusion with sibling tools like draft_email.
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 clear context for when to use the tool: to save a drafted email without sending it. The explicit 'Does NOT send — user must review and send from the linklight UI' serves as a when-not-to-use directive, implying the tool is for drafting/note-saving rather than sending. However, it does not explicitly name alternative tools or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find link-building prospect sites for a keyword. Prefers roundup / list / resource-page targets over direct competitor product pages. Uses the shared SERP cache when fresh; hits Tavily on miss. Returns url, title, domain, position, and Moz Domain Authority.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | Yes | Search phrase (2-200 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explains key behaviors: uses a shared SERP cache when fresh and falls back to Tavily, and returns specific fields (url, title, domain, position, Moz DA). It also discloses the target preference. It doesn't mention rate limits or auth, but for a read-only search tool this is sufficient and adds value beyond the schema.
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 concise sentences: the first states purpose, the second adds target preferences, the third discloses cache behavior and return fields. Every sentence adds value, no fluff, and the most important info 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?
For a simple 2-parameter search tool with no output schema, the description covers purpose, target preferences, caching, and return fields. It is sufficiently complete to guide an agent, though it could mention the output format (e.g., array of objects) or the meaning of 'position' to be fully 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 description coverage is 50% (keyword described, limit not). The description mentions 'for a keyword' but not the limit's effect. The limit parameter has default/minimum/maximum in the schema, which gives semantics, so the description doesn't need to over-explain. However, it doesn't add any behavioral context about limit (e.g., how it affects result count), leaving a minor gap.
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 begins with a specific action and resource: 'Find link-building prospect sites for a keyword.' It clearly distinguishes from siblings by emphasizing keyword-driven discovery and target-type preferences (roundup/list/resource-page vs direct competitor pages). This is more specific than generic sibling names like 'list_prospects'.
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 clear context: use for finding link-building prospects by keyword, with a preference for curated pages. It does not explicitly name alternatives or state when not to use, but the purpose and expected output make the usage scenario evident. Lacks explicit exclusions or references to sibling tools, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0draft_emailenrich_domainfind_competitor_backlinksfind_emailfind_prospect_gapsfind_quick_win_keywordsfind_similar_prospectslist_backlinkslist_campaignslist_lost_backlinkslist_prospectslist_repliessave_draftsearch_prospectsMost tools have clearly distinct purposes: discovery (search, similar, competitor), enrichment (domain, email), listing (prospects, backlinks, replies, campaigns), outreach (draft, save), and analysis (quick win keywords, gaps). Minor overlap exists (list_backlinks vs list_lost_backlinks, enrich_domain vs find_email) but descriptions clarify the intended use cases.
All tool names use snake_case with a verb_noun structure, consistently using 'list' for listing actions and 'find' for discovery. The only deviation is 'search_prospects' using 'search' instead of 'find', but this is acceptable given the keyword-based nature of the search.
With 14 tools, the set is well-scoped for a link-building workflow, covering discovery, enrichment, outreach, and monitoring. Each tool serves a distinct purpose and none are redundant or superfluous, fitting the 3-15 tool sweet spot.
The toolset covers discovery, enrichment, outreach drafting, and backlink monitoring, but lacks lifecycle management operations such as updating prospect status or creating campaigns. This creates a dead end where agents can list prospects by status but cannot move them through the pipeline, making the surface incomplete for full workflow automation.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
SEO MCP server — backlinks, domain authority, tech stack, and 18+ tools via Common Crawl.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/grodgers1-ctrl/kinky_link'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
