Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/raintree-technology/docpull/docs-searchgit clone --depth 1 https://github.com/raintree-technology/docpullWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00022 | $0.00663 |
| Opus 5 | $0.00011 | $0.00331 |
| Sonnet 5 | $0.00004 | $0.00133 |
| Haiku 4.5 | $0.00002 | $0.00066 |
Grade A, and why
docs-search scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Search fetched Markdown
Compatibility alias: prefer /web-search for new web-source workflows.
The user wants to search Markdown that has already been pulled by /docs-add (or ensure_docs). This composes two MCP tools: grep_docs finds matching files; read_doc pulls more context around the top hits so the answer is grounded, not just a list of file:line references.
User input: $ARGUMENTS
How to handle the input
Parse $ARGUMENTS as:
- First whitespace-separated token = pattern (regex; can be quoted to include spaces).
- Optional second token = source alias to restrict the search to one fetched source. Pass it as the
libraryargument when callinggrep_docs.
If empty: reply Usage: /docs-search <pattern> [source]. Run /docs-list to see what's cached. and stop.
Workflow
-
Find candidates. Call
grep_docs(pattern=<pattern>, library=<source if given>, limit=10, context=2). The tool returns the top files ranked by match density with two lines of context above and below each hit. -
Read deeper context for the top 2–3 files. For each of the top files in the grep result (max 3), call
read_doc(library=<lib>, path=<path>, line_start=<top-hit-line - 30>, line_end=<top-hit-line + 30>)to pull a ~60-line window. Skip this step if the user's pattern is very narrow (a literal symbol name) and the grep context already answers the question. -
If grep returns nothing:
- If a source was specified, run
list_indexed()to confirm the source is actually cached. If it isn't, suggest/docs-add <source>and stop. - If no library was specified, broaden the pattern once (e.g. add common prefixes/suffixes, drop word boundaries) and retry. If still nothing, surface the gap to the user.
- If a source was specified, run
-
If
grep_docssays "search timed out": the pattern is likely catastrophic. Suggest a tighter pattern (no nested quantifiers, anchor with\b).
Output
- Lead with the synthesized answer to the user's likely question, grounded in what you read.
- Cite each source as
source/path.md:lineso the user can verify. - Don't dump the full grep output unless the user asked for it — the goal is an answer, not a search log.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 47 lines · 22 tokens per session scan A 944c8d598497
docs-search is a command published in the GitHub repository raintree-technology/docpull (25 stars, last pushed 6d ago), licensed MIT. It adds 22 tokens to every session and 663 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
check
Run all code quality checks and tests for the webdown project using the make all-checks target, which includes.
release
Update CHANGELOG.md with changes since the last version increase. Check our README.md for any necessary changes. Check the scope of changes since the last release and increase our version number as apropraite.
sync-config
Sync a scraping config's URLs against the live documentation site.
triage-prs
Daily DISCOVER→PLAN→EXECUTE→VERIFY→ITERATE triage of open PRs and issues.
cli-anything-web:validate
Validate a cli-anything-web CLI against the tiered quality checklist (Tier 1 critical / Tier 2 comprehensive). Reports per-category and per-tier results.
cli-anything-web:test
Run tests for a cli-anything-web CLI and update TEST.md with results.