What can you do with this server?

The inquisitor server provides AI agents with tools for optimal-path problem-solving through web search, code analysis, tracing, project scaffolding, and structured multi-phase investigation management. * inquisitor_search — Search the web using DuckDuckGo (free/keyless), Brave, or SearXNG; supports domain filtering (include/exclude), time range filtering (day/week/month/year), configurable result count, and optional full-page content extraction (HTML + PDF). * inquisitor_analyze — Scan a project directory and return a structured overview of languages, frameworks, dependencies, tests, and git history — useful when entering an unfamiliar codebase. * inquisitor_trace — Trace a function, class, or method through the codebase in both directions (callers/callees), with configurable depth and file:line references — useful when a bug spans multiple files or functions. * inquisitor_scaffold — Generate a new project with minimal boilerplate and researched best practices given a project type and list of requirements. * inquisitor_phase_get — Retrieve the current phase, findings, evidence, and open questions of an ongoing Newton 7-phase investigation (DEFINE → AXIOMS → ANALYSIS → EXPERIMENT → SYNTHESIS → VALIDATE → QUERY) for a given session. * inquisitor_phase_set — Advance the investigation to a new phase, recording findings, evidence, and open questions into a SQLite-backed persistent state machine — enabling memory across conversation turns. * inquisitor_verify — Validate investigation findings against the original problem definitions, ensuring evidence is cited, all phases are complete, and no contradictions exist before closing an investigation.

Which integrations are available for this server?

Provides web search capabilities using Brave Search (requires BRAVE_API_KEY) with content extraction. Provides web search capabilities using DuckDuckGo (free, no API key required) with content extraction for retrieving full page text. Provides web search capabilities using a self-hosted SearXNG instance (requires SEARXNG_URL) with content extraction.

How do I use inquisitor?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@inquisitor Investigate the flaky test in the checkout flow." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

inquisitor

by iamalisson

Overview Schema Source Related Servers Discussions Admin

Python

Local

inquisitor

Hypothesis-driven problem solving for AI agents Probe · Falsify · Escalate — never overcomplicate, never blind-retry

Python MCP License

Overview

inquisitor makes AI agents solve problems the way a chess engine plays chess: it cannot explore every branch, so it estimates complexity first, prunes paths that add no information, and spends its search budget only where the problem actually is.

It ships as two coordinated layers:

MCP server (inquisitor-mcp) — the engine. Web search, project analysis, code tracing, project scaffolding, and a persistent investigation state machine. Works with any MCP-compatible agent: OpenCode, Claude Code, Claude Desktop, Cursor.
Agent skill (skills/inquisitor/SKILL.md) — the behavioral layer. Injects the probe-and-gate loop, the pruning rules, and the full methodology into the agent's reasoning.

The method is not invented here — it is assembled from primary sources: Newton's Analysis→Synthesis skeleton, hardened with the scientific method's own defenses against wrong assumptions (falsification, strong inference, competing-hypotheses analysis, anti-fixation reframes, pre-mortems) and constrained by engineering discipline (NASA/JPL's Power of Ten, surgical-change guidelines, the minimalism ladder). Every source is cited in Foundations.

Web search, codebase scans, and code tracing are tools invoked when local evidence is insufficient — never mandatory rituals.

Related MCP server: Recursive Thinking MCP Server

How it decides

Depth is an output, not a label. An LLM's up-front difficulty guess is its least reliable signal — poorly calibrated, and biased to under-rate exactly the hard problems that matter. So inquisitor never classifies a problem before understanding it: it runs a cheap probe (the single cheapest action that could confirm or kill the best current hypothesis), and the probe's result — never the prediction — sets the depth:

flowchart TD
    P([Problem]) --> F["FRAME<br/>done = ? · must not break = ?"]
    F --> D{"delegate?<br/>a specialist skill<br/>owns this"}
    D -->|yes| SK["hand off — /tdd,<br/>/code-review, ..."]
    D -->|no| PR["PROBE<br/>cheapest action that could confirm<br/>or kill the best hypothesis"]
    PR -->|"obvious, local"| SH["<b>Shallow</b><br/>fix → verify<br/><i>no ceremony</i>"]
    PR -->|"clear single-<br/>component cause"| ST["<b>Standard</b><br/>frame → minimal evidence<br/>→ fix → verify"]
    PR -->|"root cause unknown,<br/>multi-component"| DE["<b>Deep</b> — Newton 7-phase:<br/>DEFINE → AXIOMS → ANALYSIS →<br/>EXPERIMENT → SYNTHESIS →<br/>VALIDATE → QUERY<br/><i>+ session tracking as memory</i>"]

    SH -.->|"gate trigger /<br/>failed fix / low confidence"| ST
    ST -.->|"gate only raises depth —<br/>never lowers"| DE

Escalation is enforced, not just allowed. The probe is only a starting point: objective gate triggers (touching infra/deploy/routing/config, auth/security, data migrations, multi-file fixes, prod-only symptoms) force a minimum depth regardless of how "clear" the problem feels, and a 3-question confidence check (read the runtime path? can name the runtime signal? verified the platform assumption?) bumps the depth up per unanswered question. Downgrades need cited evidence, never a feeling. Inflated ceremony is not allowed either — a 7-phase investigation of a typo is as wrong as a blind guess at a race condition.

Retry is never blind. "Loop until it passes" agents (the Ralph-loop pattern) have persistence but no memory: on failure they revert, flush, and re-roll — the same wrong idea, retried with fresh confidence. Inquisitor keeps a failure ledger instead: every dead hypothesis is recorded with the evidence that killed it, every retry must name what is different and why that changes the outcome, and two dead hypotheses from the same family force a reframe — re-audit an assumption, invert the question, widen the system boundary — never a third attempt at the same idea. Persistence with memory, creativity on evidence.

Foundations

Each rule in the method traces to a primary source. The left column is the citation; the right column is the exact mechanism inquisitor takes from it.

The scientific method

Source	Mechanism adopted
Isaac Newton, Opticks, Query 31 (1704)	The investigation skeleton: Analysis before Synthesis — define, decompose, experiment, only then reconstruct — and closing with open Queries instead of false certainty. Hypotheses non fingo.
T.C. Chamberlin, The Method of Multiple Working Hypotheses, Science (1890)	Hold at least two rival explanations at all times; a single hypothesis turns every subsequent observation into confirmation.
Abraham Luchins, Mechanization in Problem Solving (1942) — the Einstellung effect	The failure ledger's trigger: repeating a familiar approach after it stopped working is a measurable fixation, and the cure is a forced reframe, not another attempt.
Karl Popper, The Logic of Scientific Discovery (1959)	Falsify first: for the leading hypothesis, name the observation that would disprove it and hunt for that observation before anything else.
John Platt, Strong Inference, Science (1964)	Design the experiment that excludes a hypothesis, not the one that corroborates the favorite — discriminating tests over confirming tests.
Richards J. Heuer, Psychology of Intelligence Analysis, CIA (1999)	Analysis of Competing Hypotheses: rank hypotheses by the evidence inconsistent with each — confirming evidence is cheap and usually fits several at once.
Gary Klein, Performing a Project Premortem, Harvard Business Review (2007)	Before shipping: assume the fix is live and the problem still happens — name the likeliest reason and probe it now.

Engineering discipline

Source	Mechanism adopted
Gerard J. Holzmann (NASA/JPL), The Power of Ten: Rules for Developing Safety-Critical Code (2006)	The P10 template: a rule set small enough to remember and strict enough to check mechanically.
Andrej Karpathy's LLM coding guidelines (2025)	Think before coding · simplicity first · surgical changes · goal-driven execution.
Ponytail decision ladder	YAGNI → reuse → stdlib → native platform → installed dependency → one line → minimum code that works.

Installation

Requires uv and Python 3.12+.

Claude Code — plugin install (recommended)

inquisitor ships as a Claude Code plugin that installs both the skill and the MCP server — no cloning, no editing absolute paths, no manual symlink.

From within Claude Code, first add the marketplace:

/plugin marketplace add iamalisson/inquisitor

Then install the plugin:

/plugin install inquisitor@inquisitor

That's it. The plugin bundles the inquisitor-mcp server (registered automatically via ${CLAUDE_PLUGIN_ROOT}) and the inquisitor skill. uv syncs the server's dependencies on first launch. Update later with /plugin marketplace update inquisitor.

Prefer to point at a local checkout instead of GitHub? /plugin marketplace add /path/to/inquisitor works too.

For OpenCode and Claude Desktop (which don't use Claude Code plugins), or for a manual Claude Code setup, use the steps below.

Step 1 — Get the server

Option A — no clone (recommended). Once published to PyPI, uvx fetches and runs it on demand — no clone, no absolute paths:

uvx inquisitor-mcp   # prints a ready message and waits for a client — Ctrl+C to exit

You'll reference uvx inquisitor-mcp directly in the config below.

Option B — from a checkout (for local development, or before the PyPI release):

git clone https://github.com/iamalisson/inquisitor.git ~/tools/inquisitor
cd ~/tools/inquisitor
uv sync

The clone path is up to you — just use the same absolute path in the config below. ~ does not expand inside JSON config files, so write the full path (e.g. /home/you/tools/inquisitor).

You do not run the server manually. It's a stdio MCP server: your agent spawns and manages it automatically. (If you run it by hand it prints a ready message on stderr and waits silently — that's normal.)

Step 2 — Register the MCP server with your agent

OpenCode — add to ~/.config/opencode/opencode.json (global) or ./opencode.json (per-project):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "inquisitor": {
      "type": "local",
      "command": ["uvx", "inquisitor-mcp"],
      "enabled": true
    }
  }
}

Claude Code — add to .mcp.json in your project, or ~/.claude.json for all projects:

{
  "mcpServers": {
    "inquisitor": {
      "command": "uvx",
      "args": ["inquisitor-mcp"]
    }
  }
}

Claude Desktop — same mcpServers block in claude_desktop_config.json (Settings → Developer → Edit Config).

Using a checkout instead of uvx? Swap the command for uv with args ["run", "--directory", "/home/you/tools/inquisitor", "inquisitor-mcp"].

Step 3 — Install the skill (the behavioral layer)

Symlink it so it stays up to date with the repo:

# OpenCode
mkdir -p ~/.config/opencode/skills
ln -s /home/you/tools/inquisitor/skills/inquisitor ~/.config/opencode/skills/inquisitor

# Claude Code
mkdir -p ~/.claude/skills
ln -s /home/you/tools/inquisitor/skills/inquisitor ~/.claude/skills/inquisitor

(Copying the folder works too — you'll just need to re-copy after updates.)

Or, no clone — install just the skill across agents with the skills CLI:

npx skills add iamalisson/inquisitor

(This installs the skill only. For the inquisitor_* tools you still need the MCP server from Steps 1-2 — or use the Claude Code plugin above, which bundles both.)

Step 4 — Restart your agent

Config is loaded at startup. Quit and reopen OpenCode / Claude Code, then verify: the inquisitor_* tools appear in the tool list, and the inquisitor skill is available.

Tools

Tool	Purpose	When
`inquisitor_search`	Multi-backend web search (DuckDuckGo free/keyless, Brave, SearXNG) with content extraction (HTML + PDF)	Local evidence insufficient: unknown errors, unfamiliar libraries, current best practices
`inquisitor_analyze`	Project overview: languages, frameworks, tests, deps, git history	Entering an unfamiliar codebase
`inquisitor_trace`	Symbol tracing: definition, callers, callees with `file:line` refs	Bug spans multiple functions/files
`inquisitor_phase_get` / `_set`	Newton 7-phase state machine, SQLite-backed per project; forward moves advance one phase at a time, backward loops always allowed	Deep investigations — persistent memory across turns
`inquisitor_verify`	Completeness check: every phase recorded? evidence cited? (semantic validation — contradictions, DEFINE satisfaction — stays with the agent)	Before declaring a Deep investigation done
`inquisitor_scaffold`	Minimal project scaffolding with researched best practices	New project setup, after requirements are clarified

Example: `inquisitor_search`

inquisitor_search(
    query="httpx ConnectTimeout retry pattern",
    max_results=8,
    time_range="year",              # day | week | month | year
    include_domains=["github.com"], # optional site: filter
    fetch_content=True,             # full page text, not just snippets
)

Example: phase tracking (Deep path)

inquisitor_phase_set(
    target_phase="experiment",
    findings="500 only occurs when session token > 4KB",
    evidence="repro script output; nginx.conf:34 large_client_header_buffers",
    open_questions="why did token size grow after v2.3 deploy?",
)

Project Structure

inquisitor/
├── src/inquisitor/
│   ├── server.py                # MCP entry point (FastMCP, 6 tools)
│   ├── config.py                # env configuration
│   ├── tools/                   # thin MCP adapters
│   │   └── search / analyze / trace / scaffold / phase / verify
│   └── backend/                 # pure Python, zero MCP dependency
│       ├── search.py            # DDG / Brave / SearXNG + re-ranking
│       ├── extract.py           # trafilatura → readability fallback, SSRF guard
│       ├── analyzer.py          # project structure scan
│       ├── tracer.py            # callers / callees mapping
│       └── phase_tracker.py     # Newton state machine (SQLite)
├── skills/inquisitor/SKILL.md   # behavioral layer for the agent
├── .claude-plugin/
│   ├── plugin.json              # Claude Code plugin manifest
│   └── marketplace.json         # self-hosted marketplace (source ".")
├── .mcp.json                    # bundled MCP server (${CLAUDE_PLUGIN_ROOT})
└── tests/                       # 36 tests

The backend/ package is importable standalone — no MCP required:

from inquisitor.backend.search import search
results = search("python asyncio best practices", max_results=5)

Environment Variables

Variable	Required	Default	Description
`INQUISITOR_SESSION_DIR`	no	`~/.inquisitor/sessions/`	Investigation state storage
`BRAVE_API_KEY`	no	—	Brave Search backend (2k free/month)
`SEARXNG_URL`	no	—	Self-hosted SearXNG instance
`INQUISITOR_DEFAULT_ENGINE`	no	`ddg`	`ddg` \| `brave` \| `searxng`
`INQUISITOR_SEARCH_TIMEOUT`	no	`15`	HTTP timeout (seconds)
`INQUISITOR_MAX_CONTENT_LENGTH`	no	`40000`	Max chars per fetched page
`INQUISITOR_PREFERRED_DOMAINS`	no	—	Comma-separated domains to boost in ranking
`INQUISITOR_PDF_BACKEND`	no	`auto`	PDF extraction: `auto` \| `docling` \| `pypdf`

No API key is required — DuckDuckGo works out of the box.

PDF extraction

Search results and fetched URLs that are PDFs (RFCs, specs, papers, datasheets) are extracted, not skipped. The default policy is auto, which uses pypdf (pure-Python, fast, no models, handles text PDFs) unless docling is installed and a GPU is present. For complex tables or scanned/OCR PDFs, install the optional docling backend:

uv pip install "inquisitor-mcp[docling]"   # or: pip install "inquisitor-mcp[docling]"

docling is heavy (pulls in torch + ML models) and slow on CPU, so auto only uses it when it's installed and a GPU is present; otherwise it falls back to pypdf. Force it with INQUISITOR_PDF_BACKEND=docling (works on CPU, just slower), or pin pypdf with INQUISITOR_PDF_BACKEND=pypdf. Any docling failure falls back to pypdf, so a PDF read never hard-fails.

Security

SSRF guard: content fetching refuses non-http(s) schemes and loopback / private / link-local / metadata targets (localhost, 127.0.0.1, 10.x, 192.168.x, 169.254.169.254, …).
Path traversal guard: session names are sanitized before touching the filesystem.
No shell execution: subprocess calls use argument lists, never shell=True.
Parameterized SQL throughout the session store.
The server runs locally over stdio with your user's privileges — it does not listen on the network.

Companion skills

inquisitor is a router as much as an investigator — it delegates to purpose-built skills (/tdd, /code-review, …) when one fits, but it never installs them for you. See docs/companion-skills.md for the curated set worth installing alongside it (mattpocock/skills, spec-kit, last30days, ponytail, gstack) and design references.

Development

uv sync                  # install deps
uv run pytest tests/ -v  # run tests
uv run ruff check .      # lint

Tech

uv — package manager
FastMCP — MCP server framework
ddgs / httpx — search + HTTP
trafilatura + readability-lxml — content extraction (two-tier fallback)
SQLite — investigation state
pytest / ruff — tests and lint

Acknowledgments

Research sources are cited in Foundations. The implementation additionally builds on:

andrej-karpathy-skills (forrestchang) — behavioral guidelines derived from Andrej Karpathy's observations on LLM coding pitfalls.
ponytail (Dietrich Gebert) — the decision ladder and the lazy-senior-dev discipline.
last30days-skill (mvanhorn) — inspiration for multi-source research design and the SKILL.md-as-contract pattern.

Licensed under MIT.

Available Tools

7 tools

inquisitor_analyzeC

Scan a project directory and return a structured overview.

ParametersJSON Schema

Name	Required	Description	Default
`project_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It does not disclose whether the tool is read-only, destructive, or requires specific permissions. The term 'scan' implies non-destructive analysis but is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it omits necessary details that could be added without excessive length. It is appropriately sized but under-informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description does not explain what 'structured overview' entails. The tool is simple but the description is too vague for complete understanding without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description only implies that 'project_path' is a directory path. It adds no details about format, constraints, or behavior when null.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'scan' and the resource 'project directory', and promises a 'structured overview'. It is specific enough to distinguish from siblings, though it does not explicitly differentiate from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'inquisitor_search' or 'inquisitor_trace'. There is no mention of prerequisites or context.

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

inquisitor_phase_getB

Get the current phase of the Newton investigation.

ParametersJSON Schema

Name	Required	Description	Default
`project_path`	No
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits on its own. It only states 'Get' without mentioning side effects, read-only nature, required context, or error handling. It does not describe what happens with default session_name or how project_path affects the result, leaving a significant transparency gap for a tool with no annotations.

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 a single, grammatically complete sentence, making it highly concise and easy to parse. However, the brevity sacrifices useful detail—it is not bloated, but it lacks enough substance to be considered a fully helpful description. This earns a 4 rather than a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple signature (two optional params) and an output schema (covering return values), but the description lacks domain-specific context about the 'Newton investigation' and the meaning of 'phase.' It also does not explain how parameters affect the outcome, and without annotations, the description is insufficient for complete understanding of when and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters with no descriptions (0% coverage), and the description provides no explanation of what project_path or session_name mean. The description adds no semantic value for the parameters, leaving agents unable to determine their purpose or how they influence the retrieval of the phase. With low schema coverage, the description must compensate but does not.

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 action ('Get') and the specific resource ('the current phase of the Newton investigation'), which distinguishes it from sibling tools like phase_set (which sets the phase). The verb-resource pairing is specific and unambiguous, rating a 5 on purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for retrieving the current phase, but it does not explicitly mention when to use it versus alternatives such as inquisitor_phase_set or inquisitor_analyze. No exclusions or alternative references are given, so usage context is only implied rather than clearly instructed.

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

inquisitor_phase_setC

Advance to a new phase in the Newton investigation process.

ParametersJSON Schema

Name	Required	Default
`evidence`	No
`findings`	No
`project_path`	No
`session_name`	No	default
`target_phase`	Yes
`open_questions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'advance', which implies forward progression. It does not disclose side effects, such as recording evidence or findings, despite the presence of these parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but front-loads the verb. It is minimally adequate but could be improved with additional context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 6 parameters (1 required) and the existence of an output schema, the description is incomplete. It does not explain the tool's full behavior, the role of each parameter, or what the output contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema), and the description only hints at target_phase being the phase to advance to. Other parameters like evidence, findings, open_questions are not explained at all.

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 'Advance to a new phase in the Newton investigation process' uses a specific verb (advance) and resource (phase), clearly distinguishing it from sibling tools like inquisitor_phase_get (which retrieves the phase).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like inquisitor_analyze or inquisitor_phase_get. No context, prerequisites, or exclusions are given.

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

inquisitor_scaffoldC

Set up a new project with best practices and minimal boilerplate.

ParametersJSON Schema

Name	Required	Description	Default
`output_path`	No
`project_type`	Yes
`requirements`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, so the description must disclose side effects, permissions, or constraints. It only says 'set up' without mentioning file creation, overwriting, or required access rights.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it sacrifices necessary detail. It could be expanded to include parameter guidance or behavioral notes without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and schema descriptions, the description is insufficient for a tool with 3 parameters (2 required). It does not cover output or typical use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds no meaning to parameters like output_path, project_type, or requirements. It does not explain their purpose or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('set up') and resource ('new project'), and the name 'scaffold' aligns with initialization tasks. However, it lacks specificity about the type of project or what 'best practices' entail, making it moderately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings (e.g., inquisitor_analyze, inquisitor_verify) or prerequisites like existing directories or context.

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

inquisitor_searchC

Search the web using DuckDuckGo (free), Brave, or SearXNG.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`engine`	No
`time_range`	No
`max_results`	No
`fetch_content`	No
`exclude_domains`	No
`include_domains`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It mentions the engines but does not explain rate limits, authentication needs, default engine behavior, or what happens when fetch_content is true. The lack of detail on side effects or constraints reduces transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but overly brief for a tool with 7 parameters and no schema descriptions. It front-loads the key action and engines but omits crucial details, making it somewhat under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description still lacks completeness. It does not explain output format, engine-specific behaviors, or edge cases like missing results. The output schema partially compensates, but the description remains insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must clarify parameters. It does not mention any parameter (query, engine, time_range, etc.) beyond the engines listed. The agent cannot infer what each parameter does from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches the web and lists three specific engines (DuckDuckGo, Brave, SearXNG), distinguishing it from sibling tools like inquisitor_analyze or inquisitor_trace which have different functions. However, it could be more explicit about the resource being 'web search results'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, when not to use it, or how to choose between engines. It only states the engines supported, leaving the agent to infer usage context.

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

inquisitor_traceC

Trace a function, class, or method through the codebase.

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`direction`	No	both
`max_depth`	No
`project_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'trace' without explaining what tracing entails (e.g., whether it returns a call graph, follows dependencies, or is read-only). This is a significant gap for a tool that likely performs a complex codebase analysis.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that earns its place. It is appropriately sized and front-loaded with the verb and resource, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having four parameters and an output schema, the description gives no context about how parameters affect behavior, what the output represents, or what 'trace' means in this codebase. This is inadequate for a tool of this complexity, especially with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. However, it does not mention any of the four parameters (symbol, direction, max_depth, project_path). The agent has no additional insight beyond the schema's type/default information, which is insufficient for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Trace') and the resource ('a function, class, or method') within the codebase. It is specific enough to distinguish from search/analyze, but does not explicitly name sibling tools, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like inquisitor_search or inquisitor_analyze. There is no mention of specific scenarios or exclusions, leaving the agent without context for tool selection.

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

inquisitor_verifyC

Validate investigation findings against the original problem definitions.

ParametersJSON Schema

Name	Required	Default
`project_path`	No
`session_name`	No	default
`original_definitions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'validate', without indicating whether the tool is read-only, modifies state, requires prior investigation steps, or what side effects occur. This is a significant gap for a validation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at one sentence, but it is overly terse. It earns its place by stating the purpose, but fails to provide necessary details that could be added without significant length. A balanced description would include parameter context and usage hints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters, no annotations, and an output schema (not shown), the description is severely incomplete. It does not explain what the validation entails, how to use the parameters, or what the output represents. The agent cannot effectively use this tool from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not mention any parameters or their roles. Parameters like 'project_path', 'session_name', and 'original_definitions' are entirely unexplained, leaving the agent unable to correctly invoke the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'validate' and the resources 'investigation findings' and 'original problem definitions', giving a clear purpose. However, it does not differentiate from sibling tools like inquisitor_analyze or inquisitor_trace, which could have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description is a single sentence with no explicit instructions on prerequisites, workflow context, or exclusions. Usage must be inferred from the name and purpose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.2.3Aug 12, 2026
- Addedinquisitor_phase_get
- Addedinquisitor_trace
2 tool updatesv0.2.2Jul 22, 2026
- Removedinquisitor_phase_get
- Removedinquisitor_trace
7 tool updatesv0.1.0Jul 9, 2026
- First observedinquisitor_analyze
- First observedinquisitor_phase_get
- First observedinquisitor_phase_set
- First observedinquisitor_scaffold
- First observedinquisitor_search
- First observedinquisitor_trace
- First observedinquisitor_verify

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-08-12 04:25 across 7 tools

Disambiguation5/5

Each tool clearly targets a distinct action: analyzing directories, searching the web, tracing code, scaffolding projects, managing investigation phases, and verifying findings. There is no overlap or ambiguity between tool purposes.

Naming Consistency5/5

All tools follow a consistent pattern with the 'inquisitor_' prefix and snake_case verb-based names (analyze, search, trace, scaffold, phase_get, phase_set, verify). Naming is uniform and predictable.

Tool Count5/5

Seven tools is well within the ideal range and each serves a distinct role in the investigation workflow. The count feels neither excessive nor sparse.

Completeness4/5

The tools cover the core investigation cycle: gather (analyze, search), understand (trace), verify, and manage progress (phase_get, phase_set). A minor gap is the lack of an explicit tool for recording or persisting findings, but the phase and verify tools partially address this.

Maintenance

ActivitySlowing

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

troth
io.github.thegrenadinekid25
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Coding Agents Autonomous Agents
2
Axis Iliad — Codebase Intelligence For Agentic Commerce A
io.github.lastmanupinc-hub
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Code Analysis Developer Tools Documentation Access
4
agentstack-mcp A
io.github.inity13
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Autonomous Agents Agent Orchestration
241
Mapnostics
io.github.ffteema
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Code Analysis Developer Tools
1

Related MCP Servers

MCP Think Tank
Knowledge & Memory Autonomous Agents Agent Orchestration
flight505
A
license
B
quality
D
maintenance
Provides AI assistants with enhanced reasoning capabilities through structured thinking, persistent knowledge graph memory, and intelligent tool orchestration for complex problem-solving.
Updated a year ago (2025-07-14 11:03 UTC)
20
217 npm
62
MIT
Recursive Thinking MCP Server
Autonomous Agents Developer Tools Agent Orchestration
rover-001
A
license
Not graded
quality
D
maintenance
Enables AI agents to achieve production-ready solutions through iterative refinement and recursive thinking processes. It features token optimization via context compression and session-based tracking to improve problem-solving depth while minimizing cost.
Updated 5 months ago (2026-04-28 12:06 UTC)
16 npm
6
MIT
PrecisionContextEngine
Code Analysis Developer Tools
Bluezeamer
A
license
A
quality
F
maintenance
Enables AI coding agents to efficiently navigate and understand large codebases by providing tools for entry point location, call chain analysis, and impact assessment, reducing context consumption and model costs.
Updated 6 months ago (2026-04-01 08:41 UTC)
5
3
GPL 3.0
LATS MCP Server
Code Analysis Autonomous Agents Knowledge & Memory
slapglif
F
license
Not graded
quality
D
maintenance
Enables systematic code investigation using Monte Carlo Tree Search to explore codebases, analyze files, and provide intelligent insights. It features persistent memory and pattern learning for improved investigations.
Updated a year ago (2025-09-01 17:28 UTC)
-

inquisitor

Overview

How it decides

Foundations

The scientific method

Engineering discipline

Installation

Claude Code — plugin install (recommended)

Step 1 — Get the server

Step 2 — Register the MCP server with your agent

Step 3 — Install the skill (the behavioral layer)

Step 4 — Restart your agent

Tools

Example: inquisitor_search

Example: phase tracking (Deep path)

Project Structure

Environment Variables

PDF extraction

Security

Companion skills

Development

Tech

Acknowledgments

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Example: `inquisitor_search`