code-explorer

Overview Schema Source Related Servers Discussions Admin

scan_workspace

Scans and indexes source files, projects, ASTs, and dependencies into a graph database; use it to build or refresh a code architecture index, optionally clearing prior data.

Instructions

Scan and index source files, projects, ASTs, and dependencies into graph DB.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_workspace"
  }
}

Input Schema

Name	Required	Description
`path`	No	Optional subfolder path to scan.
`clear`	No	Clear index before scanning if true.
`workspacePath`	No	Optional workspace root path.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.80.5Nov 11, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full burden. It says it writes into a graph DB but does not disclose whether the scan is incremental or replaces the existing index, how long it may take, whether it is synchronous, or what permissions/paths it requires. For a mutating indexing operation that is a substantial gap.

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?

A single front-loaded sentence with no filler, and the verb/resource come first. It is slightly under-specified rather than padded, so it loses a point only for thinness, not verbosity.

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?

For a parameterized mutation tool with no annotations and no output schema, the description should explain re-scan semantics, what the agent gets back, and how 'clear' changes behavior. None of that is present, leaving an agent unable to predict the effects of calling it.

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 three parameters and their defaults are already documented in the schema. The description adds no extra meaning about path resolution, what 'clear' destroys, or how workspacePath interacts with path, so the baseline 3 applies.

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 gives a specific verb pair (scan, index) and names the resources involved (source files, projects, ASTs, dependencies) plus the destination (graph DB). It is clear what the tool does, though it never contrasts itself with close siblings like clear_workspace_index or init_workspace.

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 explicit when-to-use guidance, no prerequisites, and no mention of how this relates to init_workspace or clear_workspace_index, which would obviously be alternatives or prerequisites. The agent must infer the workflow from sibling names alone.

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