Search1API MCP Server

Discover links on a site

sitemap

Read-only

Discover related public links from a page or domain to explore a site's structure and available pages, returning absolute URLs for crawling.

Instructions

Discover related public links from a page or domain when the user wants to explore a site's structure or available pages. Returns a list of absolute URLs found on that site, which can then be read with crawl.

Input Schema

Name	Required	Description	Default
`url`	Yes	Public page or domain URL whose links should be discovered

Output Schema

Name	Required	Description	Default
`links`	Yes	Absolute URLs discovered on the site, without titles or page content

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.9.0Oct 29, 2026
- addedOutput schema / properties / links / description
```
Added value: +"Absolute URLs discovered on the site, without titles or page content"
```

Changed3 schema fields changedv0.4.0Jul 29, 2026

changedInput schema / properties / url / description

Previous value: -"URL to get sitemap"New value: +"Public page or domain URL whose links should be discovered"

addedInput schema / properties / url / format
```
Added value: +"uri"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "links": {
+      "items": {
+        "format": "uri",
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "links"
+  ],
+  "type": "object"
+}

First observedv0.1.8May 8, 2026

TDQS

A4/5.0

Behavior3/5

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

The annotations already declare readOnly, openWorld, non-idempotent and non-destructive, so the safety profile is carried structurally. The description adds that results are absolute URLs restricted to public links and are meant to be fed into crawl, but it says nothing about result volume, same-domain vs cross-domain scope, or why the operation is non-idempotent, so added value is modest.

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

Conciseness5/5

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

Two sentences, zero filler, with the trigger condition front-loaded before the return-shape and follow-up guidance. Every clause earns its place.

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

Completeness4/5

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

With an output schema present, the description rightly omits return-value detail and focuses on when to call and what to do next. The remaining gap is scope: it does not say whether results are limited to the given domain or how the search sibling differs, which matters for a link-discovery tool.

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

Parameters3/5

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

There is a single parameter with 100% schema description coverage, so the schema already explains it fully. The description only echoes the page-or-domain distinction found in the schema and adds no format, normalization, or redirect-handling detail, 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.

Purpose5/5

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

"Discover related public links from a page or domain" names a specific verb (discover) and resource (links), scoping the input to a single site. It implicitly contrasts with the crawl sibling by casting sitemap as the discovery step and crawl as the reader, so an agent can tell the two apart.

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

Usage Guidelines4/5

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

The trigger condition is explicit: "when the user wants to explore a site's structure or available pages," and it names crawl as the natural next tool. It stops short of stating when not to use it (e.g., versus the search sibling for cross-site discovery), so it is clear context without exclusions.

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

Deploy Server