Unblocked Context Search — Documentation

Documentation-only retrieval. Calls context_search_documentation with a natural-language query to semantically search wikis, READMEs, runbooks, API references, architecture docs, and ADRs — surfacing written guidance that lives outside the codebase.

Sources: Confluence, Confluence Data Center, Notion, Google Drive, Google Drive for Workspaces, Coda, Stack Overflow for Teams, External Websites.

How to Invoke

context_search_documentation is CLI-only in most environments — it does not appear in the MCP tool list even when fully available. Run command -v unblocked once per session and cache the result. Do not conclude the tool is unavailable from the MCP surface alone. See unblocked-tools-guide for full routing rules.

CLI (preferred):

unblocked context-search-documentation --query "<your query>" [--instruction "<instruction>"]

MCP fallback (only if CLI is confirmed unavailable): fall back to context_research with instruction: "Prefer documentation, wikis, and runbooks; deprioritize code and messages".

If neither is available: stop and tell the user Unblocked is not configured in this environment (see unblocked-tools-guide for the full message). Do not substitute with other documentation-search tools.

When This Adds Value Over Grep/Read

Grep and Read search local files. Use this tool when:

• The doc lives outside the repo — wikis, internal portals, and team docs aren't in the local workspace
• You need operational guidance — runbooks, deployment procedures, and incident playbooks are typically documented, not coded
• You want doc-only results — context_research returns everything (Slack, PRs, issues, code); this returns only documentation, so results stay focused when that's all you need
• You're looking for explained concepts — architecture decisions, design rationale, and API contracts are often captured in docs rather than code comments

When to Use context_research Instead

Use context_research when you need the full picture alongside docs — PR discussions, Slack threads, issue tracker context, or code history. This tool returns documentation only; broader context requires context_research.

Input

Parameter	Required	Description
query	Yes	What to find — write a complete question with concrete identifiers, not bare keywords.
instruction	No	Fine-grained control over which results surface: preferred doc types, teams, or topics to prioritize or deprioritize.

Writing effective queries — include the most concrete identifiers you have:

• Service, component, or feature names (billing-service, API gateway, order fulfillment pipeline)
• Doc types when known (runbook, ADR, onboarding guide, API reference, architecture doc)
• Concepts or procedures (local setup, deployment, event schema, rate limiting configuration)
• Team or project names when relevant (payments team, infrastructure, web-client)

Write a complete question or directive, not a keyword fragment:

Instead of	Write
setup	Is there a local development setup guide for billing-service?
rate limiting	Is the rate limiting configuration for the API gateway documented?
event schema	Where is the OrderCreatedEvent payload schema documented?
deployment	Is there a runbook for deploying checkout-service to production?

instruction examples:

• "Prefer runbooks and operational guides over conceptual docs"
• "Focus results on the payments team's documentation"
• "Prefer ADRs and architecture docs over README files"

Splitting Queries

Split distinct unknowns into separate context_search_documentation calls rather than cramming everything into one query. Run them in parallel when the unknowns are independent.

One query, two unknowns (diluted results):

Find the setup guide for billing-service and also the ADR for the event-driven architecture.

Two parallel queries (focused results):

Query 1: Is there a local development setup guide for billing-service?

Query 2: Is there an architecture decision record explaining the event-driven design?

When to Skip

• You need the current code state — use Grep/Glob/Read
• You also need Slack threads, PRs, or issues — use context_research instead

Interpreting Results

• Docs may be outdated — cross-reference procedural docs against current config or code before following them
• Mine concrete identifiers (doc titles, service names, team names) from results and use them in follow-up queries
• If results are thin, try rephrasing around the doc type (runbook, guide, ADR) or a more specific component name

Reference

• references/query-patterns.md — query examples organized by use case, with good/bad comparisons and instruction patterns