Skip to main content
Glama

KagiSearch

kagi_search
Read-only

Search the web with Kagi's curated index to get compact, SEO-resistant results with snippets and timestamps. Use it as an alternative when standard search returns few or low-quality results.

Instructions

Search the web using Kagi's curated search index.

Use this as an alternative to web_search when it returns few or poor quality results. Kagi's index is independently curated, resistant to SEO spam, and may surface different sources. Returns compact results with snippets and timestamps — much lighter on context than web_search's summarized snippets, making it better suited for multi-query research workflows.

Switch result categories via workflow= (search / images / videos / news / podcasts). Cap returns with limit=, scope with lens_id=, paginate with page=, filter by region= / after= / before=. The query string supports site: / filetype: / intitle: / inurl: filters, "exact phrases", +/- terms, boolean (A AND B) / (A OR B) grouping, and * wildcards — full operator syntax is on the query parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, 1-indexed (1..10). Page size is 'limit'; max practical reach is page × limit. The underlying ranking is stable — limit=N page=1 always returns the same top N — but adjacent pages can share some URLs because page selection is not strict offset slicing, so deduplicate downstream when consuming multiple pages. Repeated calls to the same page return identical results in identical order. Deep paging needs a larger 'limit' — at the default limit=5, page=10 only reaches ~result 50. Omit (or pass null) for the first page. Applies across all workflows.
afterNoISO 8601 date 'YYYY-MM-DD' (e.g. '2025-01-01'). Dates must be strict ISO 8601 — other forms either return HTTP 400 (search.filters_after_invalid) or are silently accepted with incorrect filtering (US-style 'MM-DD-YYYY' is the known silent-accept case). Returns only results published or updated on or after this date. Results that lack a detectable date are silently excluded. Overrides any date floor carried by 'lens_id'.
limitNoMaximum number of results returned per page. Default 5; max 1024. limit is always the page size — when 'page' is omitted you implicitly receive page 1. Caps the response count only — Kagi picks its top hits internally, so a smaller limit returns the best of the same ranking, not a different ranking. Applies across all workflows.
queryYesSearch query string. Supports operators: site:example.com (restrict to a domain), filetype:pdf (restrict to a file type), intitle:term (match in page title), inurl:term (match in URL), "exact phrase" (exact match), +term / -term (require / exclude), (A AND B) / (A OR B) (boolean grouping), * (wildcard word substitution).
beforeNoISO 8601 date 'YYYY-MM-DD' (e.g. '2025-12-31'). Dates must be strict ISO 8601 — other forms either return HTTP 400 (search.filters_before_invalid) or are silently accepted with incorrect filtering (US-style 'MM-DD-YYYY' is the known silent-accept case). Returns only results published or updated on or before this date. Results that lack a detectable date are silently excluded. Overrides any date ceiling carried by 'lens_id'.
regionNoLowercase Kagi region code (case-sensitive — 'us', not 'US'). Codes include lowercase ISO 3166-1 alpha-2 forms like 'us', 'de', 'jp', plus language-suffix variants for multilingual countries like 'ca_fr' (Canada in French). Bad codes (unknown values, wrong case) return HTTP 400 with a structured error — the filter never silently degrades. Pins both region and result language; there is no separate language argument. Omit to skip regional localization. Overrides lens_id's region.
lens_idNoKagi Lens to apply. A lens is a stored search profile that scopes the query (sites, keywords, file type, region, time window) before any filters set here take effect. Designed for the default 'search' workflow; on other workflows the lens may be silently ignored or may filter results to empty. Slugs are case-sensitive — use 'programming', not 'Programming'; wrong case silently falls back like an unknown slug. Unknown slugs are not rejected — they fall back silently to results that ignore the lens, so the response cannot confirm the lens engaged. The lens's site / filetype scope intersects with any 'site:' / 'filetype:' operators in the query — a conflict (e.g. 'site:reddit.com' with the 'academic' .edu lens) returns empty. The 'region', 'after', and 'before' parameters override the lens's equivalents when both are supplied. Accepted forms: a built-in lens slug (lowercase display name with spaces preserved; always-available slugs are 'forums', 'programming', 'news 360', 'fediverse forums', 'usenet/archive', 'academic', 'pdfs', 'kagi documentation' — note that 'news 360' is a web-search lens distinct from the 'news' workflow), a shareable lens ID (the ID portion of https://kagi.com/lenses/<id>), or the full lens URL. User-created lenses have no programmatic discovery path — pass null unless the user has handed you one.
workflowNoResult category. Omit for 'search' (web results with related-query suggestions); omitting is equivalent to workflow='search'. Other workflows surface only their named primary category: 'images' returns image hits, 'videos' returns video hits, 'news' returns news articles, 'podcasts' returns podcast episodes. The 'images' workflow does not respond predictably to most filters — region has no visible effect, after/before often do not engage (image results commonly lack date metadata), and lens_id may filter to empty or be silently ignored.
Behavior5/5

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

Beyond the readOnlyHint annotation, the description or its schema-rich parameter docs disclose stable pagination (same page returns identical results), deduplication needs across pages, silent failures for invalid lens slugs, and strict ISO date format pitfall. These behavioral traits are not in annotations and add significant safety context.

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 alternative usage in the first sentence. It is relatively long (two paragraphs) but every sentence contributes either purpose, usage context, or a parameter summary; given the 8-parameter complexity, the length is justified.

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?

The tool has no output schema, so the description's mention of 'compact results with snippets and timestamps' partially covers return value expectations. It provides strong coverage of purpose, usage, and edge cases; the only minor gap is a full description of the response shape, but this is acceptable for a search 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?

Schema description coverage is 100%, so baseline is 3. The description's parameter summary (workflow=, limit=, lens_id=, page=, region=, after=, before=) is a helpful overview but adds no new details beyond what the schema already provides. The operator syntax list is also fully duplicated in the query parameter description.

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 opens with a specific verb+resource: 'Search the web using Kagi's curated search index.' It immediately distinguishes from siblings by naming web_search as an alternative and stating Kagi's differentiators (curated, SEO-spam resistant, different sources).

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?

Explicitly states when to use this tool: 'Use this as an alternative to web_search when it returns few or poor quality results.' Also provides context on when it is better suited (multi-query research workflows) and what it returns (compact results, lighter on context).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blightbow/parkour-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server