Skip to main content
Glama
zademy
by zademy

Fetch & Index URL(s)

ctx_fetch_and_index

Fetch web pages, convert them to markdown, and store them in a searchable knowledge base so raw bytes stay out of context—only small previews are returned for later retrieval.

Instructions

Fetches URL content, converts HTML to markdown (JSON chunked by key paths, plain text indexed directly), persists it in a searchable knowledge base, returns a small preview window per source. Raw page bytes never enter your conversation — they live in storage, retrievable via ctx_search. Every fetch is cached on disk for 24h by default; override per-call with ttl.

WHEN:

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

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

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

  • You want 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) — this is a plain HTTP fetch, no headless browser

RETURNS: Per-source preview windows around indexable headings plus indexing metadata (chunk counts, source labels, cache). Raw content is NOT echoed back. concurrency parallelizes the fetch phase only — FTS5 is single-writer, so index writes always serialize. Use 4-8 for I/O-bound batches; lower it under per-IP rate limits.

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

Input 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (non-readonly, open-world, non-idempotent, non-destructive); the description adds the behaviors that matter beyond them: 24h disk cache with per-call ttl override, raw bytes never echoed into context, FTS5 single-writer serialization meaning only fetches parallelize, and CPU-count capping of concurrency.

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?

Front-loaded with the core action, then structured WHEN/WHEN NOT/RETURNS/EXAMPLE blocks that each earn their place. Slightly long and the RETURNS section restates some fetch/index mechanics, but no sentence is filler.

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?

No output schema exists, so the description carries the return contract (per-source preview windows plus indexing metadata, no raw echo) and it also covers cache, concurrency, and limitation behavior for a 6-parameter, zero-required tool. Nothing an agent needs to call it correctly is missing.

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 already 100%, so baseline is 3, but the description adds behavioral meaning to parameters: ttl:0 behaves like force:true, concurrency 2-8 should be used for parallel I/O, and batch requests carry per-entry source labels while preserving input order. These are invocation-shaping details beyond the schema text.

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?

States a specific verb+resource chain (fetch URL, convert, persist into searchable KB, return preview) and explicitly contrasts with siblings by naming ctx_search as the retrieval path and the inline index tool for local content. An agent can distinguish it from ctx_index and ctx_search without opening schemas.

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?

Dedicated WHEN and WHEN NOT sections give explicit selection criteria: multi-URL research, repeat lookups, forced freshness, plus exclusions (content already local, SPA-rendered pages require a headless browser, which this is not). Alternatives and the conditions that select them are spelled out.

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