Does a page link to your domain? Dofollow/nofollow, anchor, status, robots guards. Live, no store.
Scored across 8 tools
link_check, link_audit, and outreach_queue all perform link checking against a target domain, differing mainly in batch size and output detail; anchor_profile and robots_guard_check also overlap partially with link_check's fields. The descriptions clarify the intended use case enough to avoid constant misselection, but boundaries are not crisp.
All names are lowercase snake_case, but they mix noun-noun descriptors (anchor_profile, license_status, referring_domain_summary) with verb-final actions (license_activate, link_check, robots_guard_check). There is no consistent verb_noun convention or shared prefix, though the names remain readable.
Eight tools is a reasonable size for a backlink-verification server; the six core checkers plus two license lifecycle tools each serve a distinct purpose. No obvious bloat or thinness.
The surface covers single-page link checks, batch audits, outreach follow-ups, outbound anchor profiles, domain summaries, and robots guard checks, so the main verification workflows are supported. It lacks backlink discovery/enumeration, but the descriptions consistently frame the server as checking supplied referring pages rather than finding new ones.
Fetch one referring page and list every outbound link with its anchor text and dofollow/nofollow classification, so you can see how a site links out before requesting a link change.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max links to return (default 50) | |
| page_url | Yes | Page URL, including https:// |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral details beyond the operation itself (e.g., no mention of pagination or rate limits), but it is consistent with the annotations. With strong annotation coverage, a 3 is appropriate.
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, front-loaded sentence with zero filler. It states the action, the output, and the purpose in under 30 words, making it highly scannable.
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 two parameters (one required) and no output schema, the description adequately explains what the tool does and what the output will contain ('list every outbound link...'). It doesn't address edge cases like the limit parameter's effect or pagination, but for a simple read-only tool this is minor. The output format is implied clearly enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (page_url and limit) are already documented in the schema. The description adds no additional parameter semantics; it simply restates the action. 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 a specific action ('Fetch one referring page') and a specific output ('list every outbound link with its anchor text and dofollow/nofollow classification'). It distinguishes itself from sibling tools like 'link_audit' or 'referring_domain_summary' by focusing on a single page's outbound 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 provides a clear use case ('so you can see how a site links out before requesting a link change') but does not explicitly mention alternative tools or when NOT to use it. It gives contextual guidance but lacks exclusions or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the 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 two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present 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 uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
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 use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information 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?
With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
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 verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
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 when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check up to N referring pages against one target domain and return a per-URL table: HTTP status, dofollow/nofollow, anchor text, robots guards. Free tier: 3 URLs per call.
| Name | Required | Description | Default |
|---|---|---|---|
| page_urls | Yes | Referring page URLs | |
| target_domain | Yes | Domain the backlinks should point at |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns a per-URL table, includes specific metrics, supports a batch of URLs, and enforces a free-tier limit of 3 URLs per call. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all essential information: the action, the resource, the output shape, and the call limit. There is no filler, and the most important behavioral detail is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with rich annotations, the description is fairly complete: it explains the return table fields, the input relationship, and the free-tier limit. Since there is no output schema, the description compensates by naming the output columns. It could still benefit from clarifying what 'N' means more explicitly, though the free-tier sentence largely resolves this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters minimally described ('Referring page URLs' and 'Domain the backlinks should point at'). The tool description adds some semantic context—target_domain is the single domain against which referring pages are checked—but does not substantially elaborate beyond the schema, so the baseline of 3 is appropriate.
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 names a specific verb ('Check'), a clear resource ('referring pages against one target domain'), and an explicit output shape ('per-URL table: HTTP status, dofollow/nofollow, anchor text, robots guards'). This distinguishes link_audit from sibling tools like link_check or robots_guard_check, which appear narrower in scope.
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: audit a list of backlinks and get per-URL metrics, and it adds a practical constraint ('Free tier: 3 URLs per call'). However, it does not explicitly state when to prefer this tool over alternatives such as link_check or robots_guard_check, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a referring page and report whether it links to the target domain, whether that link is dofollow or nofollow, the anchor text, HTTP status and robots guards (meta robots / X-Robots-Tag noindex, nofollow).
| Name | Required | Description | Default |
|---|---|---|---|
| page_url | Yes | Referring page URL, including https:// | |
| target_domain | Yes | Domain the backlink should point at, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail: it fetches a live page, checks HTTP status, and inspects robots guards (meta robots / X-Robots-Tag), which tells the agent the tool performs network I/O and may be affected by page availability. It does not mention rate limits or failure behavior, but the added detail is valuable.
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?
A single, dense sentence that front-loads the action and then lists all reported signals in a compact enumeration. Every clause earns its place; no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent, two-parameter tool with full schema coverage, the description is nearly complete. It covers what the tool does, what it reports, and the key behavioral nuance (robots guards). It does not describe the output format, but there is no output schema and the listed signals effectively define the return shape. A small gap is the lack of explicit failure/edge-case behavior (e.g., 404 page, redirects), but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds context by explaining that page_url is the referring page and target_domain is the link target, but it does not add format details beyond the schema's examples. Baseline 3 is appropriate.
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 a specific verb ('Fetch... and report') and a precise resource (a referring page's backlink to a target domain), and enumerates the exact checks performed. It is clearly distinguishable from siblings like link_audit (which presumably audits many links) and robots_guard_check (which focuses on robots guards only).
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 a single-page, single-backlink check and lists the exact signals it reports, which tells an agent when to use it (one-off verification) versus a broader audit. It does not explicitly name alternatives or exclusion conditions, but the sibling names and the singular framing provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch link check for outreach follow-ups: pass up to 10 page URLs and your domain, get one line per page (status, linked or not, dofollow). Built for the Monday-morning question: which of the sites that promised a link actually shipped it?
| Name | Required | Description | Default |
|---|---|---|---|
| page_urls | Yes | Up to 10 page URLs, including https:// | |
| target_domain | Yes | Your domain, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by specifying the output format (one line per page with status, linked status, and dofollow) and the batch limit, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and then giving necessary details. It is concise with no 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?
The description covers the purpose, input format, output format, and use case. Combined with the annotations and schema, there is no critical information missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (page_urls and target_domain), achieving 100% coverage. The description does not add additional semantic detail beyond what's 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 tool's function: batch link checking for outreach follow-ups, with specific inputs and output. It distinguishes itself from sibling link-checking tools by focusing on batch processing and the outreach use case.
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 it ('Monday-morning question' of checking which sites shipped links), and the batch nature of up to 10 pages implies it's for multiple URLs. However, it does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page and summarize the referring domain: HTTP status, indexability, outbound link count, and whether the target domain appears anywhere in the text (brand mention without a link).
| Name | Required | Description | Default |
|---|---|---|---|
| page_url | Yes | Page URL, including https:// | |
| target_domain | Yes | Domain to look for, linked or mentioned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior, so the remaining burden is light. The description adds the page-fetching behavior and clarifies that target-domain detection covers unlinked brand mentions, but it does not disclose failure modes such as unreachable pages or how redirects are handled.
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?
A single sentence packs the action, scope, and output fields with no filler or repetition. The results list is front-loaded after the verb, making the most important information immediately visible.
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 two fully described parameters, rich read-only annotations, and no output schema, the description's enumerated result fields provide most of what an agent needs. It would be slightly more complete with a note about live-fetch failures or response shape, but the current level is sufficient for a low-risk read 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 100%, so the baseline is met. The description adds operational meaning by stating that page_url is actually fetched and that target_domain is checked both as a link and as a plain-text mention, refining the schema's terse 'linked or mentioned' wording.
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 names a precise action ('Fetch a page and summarize the referring domain') and lists the exact outputs: HTTP status, indexability, outbound link count, and brand mention. It is specific and actionable, but it does not contrast with sibling tools such as anchor_profile or link_audit, so it stops short of full differentiation.
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 explains the operation but gives no guidance about when to select this tool over link_audit, link_check, or anchor_profile, and no exclusions or prerequisites. An agent must infer the use case from the title and output list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one URL and report HTTP status plus meta robots / X-Robots-Tag noindex and nofollow signals, without extracting links.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL, including https:// |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to re-cover safety. It adds useful behavioral detail: a network fetch happens, only a single URL is processed, and the response reports specified robots signals rather than link extraction.
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 one focused sentence with the primary action and scope stated first, followed by a precise negative qualifier. There is no redundant or filler language.
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 only one required parameter, full schema coverage, and safety annotations, the description provides enough for an agent to call the tool and understand the returned signals. It does not specify the exact response format or error behavior, but that is not critical for this simple read-only 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 schema fully documents the only parameter (`url` as 'Page URL, including https://'), so the baseline is 3. The description reinforces that the tool fetches a single URL but adds no 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 uses specific verbs ('Fetch' and 'report'), identifies the resource ('one URL'), and names the exact outputs (HTTP status, meta robots / X-Robots-Tag noindex and nofollow signals). The phrase 'without extracting links' further distinguishes it from the link-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: checking robots signals on a single page. The phrase 'without extracting links' suggests this is not for link auditing, but it never explicitly names alternatives or states when to prefer link_audit/link_check over this tool.
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.
anchor_profileoutreach_queuereferring_domain_summarylicense_activatelicense_statuslink_auditlink_checkrobots_guard_checkCheck if a link on a live page is followable: rel tokens, meta robots and X-Robots-Tag
Checks whether AI search engines cite your domain for a prompt. From $0.15/call via x402 or Stripe.
Linkheft: 0-100 domain authority, web-graph rank and trend for any domains, from open data.
Linkheft: 0-100 domain authority, web-graph rank and trend for any domains, from open data.
Add one secure layer between your agents and this server.