Skip to main content
Glama

Fetch & Index URL(s)

ctx_fetch_and_index

Fetch web URLs, convert to markdown or indexed entries, store in a searchable knowledge base, and retrieve sections on demand without raw content entering the conversation.

Instructions

Fetches URL content, converts HTML to markdown (JSON is chunked by key paths, plain text indexed directly), persists it in a searchable knowledge base, and returns a small preview window per source. The raw page bytes never enter your conversation — they live in storage and you retrieve any section on-demand via ctx_search.

Caching: every fetch is cached on disk and reused for repeat calls within the TTL window. The default TTL is 24 hours; override per-call with the ttl parameter (milliseconds, ttl: 0 bypasses cache like force: true). Stored content older than 14 days is cleaned up on startup.

WHEN:

  • You need web content (docs, changelogs, API references, spec pages) and the raw page bytes should NOT enter your conversation

  • Multi-URL research (library evaluation, migration scans, doc comparisons): pass the requests array and a concurrency value 2-8 for parallel I/O

  • You want repeat lookups against the same URL to be cheap (TTL cache hits return only a hint, no re-fetch)

  • You want a long-lived cache window (override ttl upward for stable specs) or a guaranteed-fresh fetch (ttl: 0 or force: true)

WHEN NOT:

  • You already have the content locally — store it via the inline index tool

  • The page is SPA-rendered (JavaScript-required to materialize content) — this is a plain HTTP fetch, no headless browser

RETURNS: Per-source preview windows extracted around indexable headings plus indexing metadata (chunk counts, source labels, cache state). Raw content is NOT echoed back — retrieve any section on-demand via ctx_search(source: ""). Concurrency parallelizes the fetch phase up to your chosen value (capped by the host's logical CPU count); the FTS5 write phase always runs serially because SQLite is a single-writer store. Net latency = max(fetch latency across the pool) + sum(per-source index write time). Cache hits skip both phases and return a small freshness hint instead of re-fetching. Use 4-8 for stable I/O-bound batches; lower the value when the target host enforces a per-IP rate limit you cannot raise.

EXAMPLE: ctx_fetch_and_index( requests: [{url: "https://react.dev/...", source: "react"}, {url: "https://vuejs.org/...", source: "vue"}], concurrency: 5 )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoOverride the cache freshness window for this call, in milliseconds. `ttl: 0` bypasses the cache like `force: true`; omit to use the default 24h TTL.
urlNoSingle URL to fetch and index (legacy single-shape)
forceNoSkip cache and re-fetch even if content was recently indexed
sourceNoLabel for the indexed content when using single `url` (e.g., 'React useEffect docs', 'Supabase Auth API'). For batch, put source in each requests entry.
requestsNoBatch shape: array of {url, source?} entries. Use with concurrency>1 for parallel fetch. Each request indexed under its own source label. Output preserves input order.
concurrencyNoMax URLs to fetch in parallel (1-8, default: 1). Use 4-8 for I/O-bound multi-URL batches (library docs, changelogs, pricing pages). Capped by os.cpus().length on small machines (response notes when capped). Indexing is always serial regardless — only fetches race.
Behavior5/5

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

Annotations are minimal (readOnlyHint false, destructiveHint false, idempotentHint false, openWorldHint true). The description adds extensive behavioral context: raw bytes never enter conversation, disk caching with default TTL, 14-day cleanup, serial indexing despite parallel fetches, net latency formula, cache hit behavior, and rate-limit considerations. This fully informs the agent of side effects and performance characteristics.

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 well-structured with sections (Caching, WHEN, WHEN NOT, RETURNS, EXAMPLE) and front-loaded with core purpose. However, it is somewhat lengthy and contains minor redundancy (e.g., force: true and ttl:0 mentioned in multiple places). It could be tightened without losing information.

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?

Despite having no output schema and 6 parameters, the description covers all necessary aspects: return value (preview windows and metadata), caching behavior, concurrency model, when to use/not use, and an example. It effectively positions the tool among 11 siblings and provides enough detail for an agent to invoke it correctly.

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 description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: explains legacy vs batch shapes, concurrency cap by CPU, ordering, cache bypass via ttl:0, and source label usage. This extra context justifies a score of 4.

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 clearly states the tool fetches URL content, converts it to markdown or indexes JSON/plain text, persists it in a searchable knowledge base, and returns preview windows. It distinguishes from siblings like ctx_search (retrieval) and ctx_index (local content) by focusing on external web fetching and indexing.

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?

The description provides explicit WHEN and WHEN NOT sections. WHEN includes needing web content for research, multi-URL parallel fetching, caching benefits, and long-lived cache. WHEN NOT includes already having content locally (use inline index) or SPA-rendered pages needing a headless browser. This clearly guides agent decision-making.

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/mksglu/context-mode'

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