Skip to main content
Glama
zademy
by zademy

Index Content

ctx_index

Index documentation, API references, or skill prompts into a searchable knowledge base so agents retrieve raw sections on demand instead of loading everything into context.

Instructions

Store content in a searchable knowledge base (BM25 over FTS5). Splits markdown by headings, keeps code blocks intact, persists the raw chunks. The full content stays in storage — retrieve any section on-demand via ctx_search; nothing is summarized or truncated.

WHEN:

  • Documentation from Context7, Skills, or MCP tools (API docs, framework guides, code examples)

  • API references (endpoint details, parameter specs, response schemas)

  • MCP tools/list output (exact tool signatures and descriptions)

  • Skill prompts and instructions too large to keep verbatim in conversation

  • README files, migration guides, changelog entries

WHEN NOT:

  • Log files, test output, CSV, or build output — use ctx_execute_file, which processes in-sandbox without persisting bytes

  • Single-use ephemeral content you will not query later — keep it inline if it fits, or ctx_execute_file it

RETURNS: Indexing metadata: chunk counts, source label, and the exact ctx_search call shape. Raw content is NOT echoed back. With path, a content hash lets ctx_search auto-flag staleness later.

EXAMPLE: ctx_index(content: "# React useEffect\n\nThe Effect Hook lets you ...", source: "react-useeffect-docs") EXAMPLE: ctx_index(path: "/path/to/large-spec.md", source: "openapi-v2-spec")

Input Schema

NameRequiredDescriptionDefault
pathNoFile OR directory path to read and index (content never enters context). Provide this OR content. Directory paths trigger a bounded recursive walk (#687).
sourceNoLabel for the indexed content (e.g., 'Context7: React useEffect', 'Skill: frontend-design')
contentNoRaw text/markdown to index. Provide this OR path, not both.
excludeNoDirectory-only: glob patterns to exclude. Merged with defaults (node_modules, .git, dist, build, .next, coverage, .venv, __pycache__, .DS_Store).
includeNoDirectory-only: glob patterns to include (default: all matching extensions).
maxDepthNoDirectory-only: max recursion depth from root (default: 5).
maxFilesNoDirectory-only: hard cap on files indexed (default: 200) — FTS5 blow-up guard.
extensionsNoDirectory-only: allowed file extensions (default: .md .mdx .txt .json .yaml .yml .ts .tsx .js .jsx .py .rs .go .sh).
followSymlinksNoDirectory-only: follow directory symlinks (default: false — cycle hazard + escape risk).
respectGitignoreNoDirectory-only: apply nearest .gitignore (default: true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and idempotentHint=false, telling the agent this is a persisting, non-idempotent write. The description usefully adds that content persists untruncated, that nothing is summarized, and that a content hash enables staleness flagging. It does not, however, disclose retention/eviction behavior, capacity limits, or how re-indexing the same source behaves, so it adds moderate value over the annotations but leaves real behavioral gaps.

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 purpose, then cleanly sectioned into WHEN / WHEN NOT / RETURNS / EXAMPLES. The two examples are slightly redundant with the schema but earn their place by showing intent. Minor verbosity, but every section is purposeful.

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?

Ten parameters, zero required, and no output schema make completeness a real risk, but the description supplies a RETURNS section covering the metadata shape (chunk counts, source label, the ctx_search call shape) and explicitly notes raw content is not echoed. Combined with the routing guidance, an agent has what it needs to invoke correctly.

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 the schema already documents all ten parameters, including the directory-only flags, defaults, and the include/exclude/extension semantics. The description's two examples illustrate content-vs-path usage but add no syntax or meaning beyond what the schema provides, so the baseline of 3 applies.

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 and resource ('Store content in a searchable knowledge base (BM25 over FTS5)') and immediately scopes the mechanism (splits markdown, keeps code blocks, persists raw chunks). It also distinguishes itself from siblings by pointing to ctx_search for retrieval and ctx_execute_file for the alternative, so an agent can differentiate it without opening other 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?

Explicit WHEN and WHEN NOT sections enumerate concrete content types to index and name alternatives (ctx_execute_file for logs/test output/CSV, keeping single-use content inline). This gives the agent routing conditions and exclusions rather than leaving selection to inference.

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