Cluefinch MCP

Official

Overview Schema Source Related Servers Discussions Admin

web_links

Read-only

Inspect a known HTML page to list its explicit links, helping you navigate documentation chapters, pagination, references, or related pages after search and before reading.

Instructions

Navigate from a known HTML page to pages that it explicitly links.

USE THIS when you already found a useful source but need its structure:
documentation sections, report chapters, table-of-contents entries,
next/previous publication pages, appendices, references, datasets, standards,
or related pages. It is the bridge between web_search discovery and web_fetch reading.
Prefer this over another search when the desired page is plausibly
linked from the source you already have.

This is NOT a crawler or browser. It inspects ordinary <a href> links in this
one fetched HTML page only. It does not follow them, click controls, execute
JavaScript, submit forms, DNS-resolve destinations, or safety-approve them.
Selecting a returned URL for web_fetch/web_links later triggers the normal
outbound SSRF policy.

same_origin=true keeps only links with the same scheme, normalized hostname
and effective port as the final fetched page. Leave same_origin=null when
external citations or primary sources may matter; same origin does not mean
same organization, and cross-origin does not mean untrusted.

The retained list preserves document order after deterministic URL
deduplication. Fragments remain part of link identity. same_document=true
means only that the destination has the same document identity ignoring the
fragment; web_fetch still navigates text by Unicode offsets, not HTML anchors.

Filtering happens BEFORE pagination. Copy continuation.arguments to retrieve
the next retained link page. links_hash versions the whole retained ordered
list before filtering/pagination; links_changed means the old start_index must
not be reused. continuation means more retained links exist; links_truncated
means some admissible links were lost to hard page-level resource ceilings
and continuation cannot recover them.

Each link returns url, best-effort label, rel, fragment, same_origin and
same_document. An empty links list does not prove that the site has no other
pages. Expected failures return {error, hint}.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Known HTTP(S) HTML page whose exposed navigation you want to inspect. Use after finding a useful source when you need chapters, pagination, references or related pages. The page itself is fetched safely; returned destinations are not contacted until selected later.
`max_links`	No	Maximum links returned: default 50, hard cap 100. Ready continuation preserves the effective budget.
`same_origin`	No	Navigation filter relative to the final fetched page. true=same scheme+normalized host+effective port only; false=cross-origin only; null=keep both (default, best when external references may matter). Filtering happens before pagination.
`start_index`	No	Zero-based index in the filtered retained link list. Ready continuation arguments provide it.
`expected_links_hash`	No	Optional retained-link-list version guard. Ready continuations supply it; mismatch returns links_changed without using the old index.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete non-behavior: it does not follow links, click controls, execute JavaScript, submit forms, DNS-resolve destinations, or safety-approve them. It also explains that later selection triggers SSRF policy, describes pagination/hash/continuation semantics, and notes that an empty list does not prove absence of other pages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and usage, then moves through limitations, filtering, pagination, and output in a logical order. It is long, but the complexity of the tool justifies most of the detail; a few points repeat schema content rather than adding new value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, substantial annotations, and the presence of an output schema, the description is complete enough for correct invocation. It covers routing, safety boundaries, continuation behavior, hash guards, truncation caveats, returned fields, and error shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantic nuance beyond the schema for same_origin (same origin does not mean same organization; cross-origin does not mean untrusted), same_document versus fragment identity, and links_hash behavior. Much of this overlaps with the schema's own parameter descriptions, so it is helpful but not entirely additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: navigating from a known HTML page to pages it explicitly links. It distinguishes the tool from web_search and web_fetch by calling itself the bridge between discovery and reading, and explicitly contrasts itself with a crawler or browser.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance ('USE THIS when you already found a useful source but need its structure') and when-not guidance ('This is NOT a crawler or browser'). It also names the sibling alternative indirectly by saying to prefer it over another search when the target is plausibly linked from the current source.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server