Skip to main content
Glama
Octen-Team

octen-mcp

Official
by Octen-Team

Pulse Search — find a site's URL

pulse_search
Read-only

Predict the likely web address and return ranked candidate URLs with titles for docs, API references, help centers, or known sites from a short query.

Instructions

When what is wanted is a web address rather than what is written on the page, this is the tool. It returns up to 10 ranked candidate URLs with titles — the single most likely one, the top three, or a shortlist to choose from, whichever the question calls for. Official docs and API references ("github docs", "uv documentation", "python list methods"), help centres ("how do I return an amazon order"), a site you know exists ("youtube").

Prefer it over search for those: one inference predicts the URLs instead of searching and ranking them, so it answers in about 10ms for a fraction of the cost. Reaching for search to look up an address is slower and costs more for the same answer.

NOT FOR news or anything needing freshness — use news_search. NOT FOR a question that needs real retrieval across the open web, domain or language filters, or a time window — pulse has none of those parameters, sees no fresh content, and is not a cheaper substitute for search.

mode decides what comes back. lite (the default) returns titles and URLs only. standard adds highlights, full page content and images at roughly twice the latency; highlight, full_content and include_images do nothing in lite.

keywords: url lookup, find the site, official docs, api reference, documentation, help centre, homepage, where is, which url, candidate urls, top urls, quick lookup, destination, autocomplete

Input Schema

NameRequiredDescriptionDefault
modeNo`lite` returns titles and schemeless URLs only and ignores the content options below. `standard` returns highlights, full content and images, at about twice the latency. Default lite.lite
countNoNumber of results (1-10). Default 5.
queryYesWhat to find the destination for, e.g. 'github docs'. Max 500 chars.
timeoutNoRequest timeout in seconds (1-60). Defaults to 30s if unset.
highlightNoRanked snippet per result. No effect in `lite` mode. Omit to use the server default.
safesearchNoAdult-content filter. Default strict.strict
full_contentNoCleaned page body per result. No effect in `lite` mode. The first result's content is free; the rest are billed.
include_imagesNoReturn image URLs per result. No effect in `lite` mode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly/openWorld/non-destructive), the description discloses latency (~10ms), relative cost, that no fresh content is seen, that no domain/language/time-window parameters exist, and a billing detail for `full_content` (first result free, rest billed). That is meaningful operational context an agent cannot get from the annotation block.

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 core claim is front-loaded and bolded, and the negative guidance is clearly delimited. It loses a point for redundancy: the mode/latency explanation appears in the prose and again in every relevant schema field description, and the parenthetical example list plus keyword tail are longer than needed.

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?

For an 8-parameter tool with nested objects and no output schema, the description states the return shape (candidate URLs with titles), the default-mode behavior, and the cost/latency implications of the alternatives — enough to call it correctly without experimentation.

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; the description still adds a useful mental model — `mode` as the switch that governs what comes back, with `lite` versus `standard` costing roughly double the latency and `highlight`/`full_content`/`include_images` inert in `lite`. It doesn't cover `count`, `timeout`, or `safesearch`, which is why it isn't a 5.

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?

Specific verb and resource — returns ranked candidate URLs for a site/address lookup, with a concrete result shape (up to 10 candidates with titles). The opening line explicitly frames the tool as answering 'what is the web address' rather than 'what is written on the page', which separates it from `search` and the content-oriented siblings.

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?

Gives both positive routing (official docs, API references, help centres, known sites) and explicit exclusions with named alternatives: news/freshness → `news_search`; real retrieval with domain/language/time filters → `search`. It also states the selection rationale (inference vs. search+rank, ~10ms, lower cost) so an agent can trade off correctly.

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