Loading ToolBench

Reading the current corpus…

Scout MCP server · C · ToolBench

Scout

Local-first semantic file search for AI agents via MCP, with a cross-platform desktop app for humans too. Headless service wrapping hybrid retrieval (local index, semantic search, platform-native backends) to MCP clients.

2026-07-28+STREAMABLE_HTTP4 tools

62/100

Definition Quality58

Protocol Readiness72

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Scout MCP server has 4 tools with clear naming (verb_noun pattern: search, quick_search, index_status, reindex) and reasonable descriptions (100-200 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented in the source code provided, and parameter descriptions lack detail on constraints, formats, and error recovery guidance. Error handling is basic, no recovery hints or actionable error messages visible. The reindex tool (WRITE operation) lacks confirmation/dry-run pattern. Overall: solid foundation but missing production-grade polish on schemas and error guidance.

Tools (4)

index_statusread onlyauth50/100

Get the current indexing status including phase, progress, and statistics about indexed documents.

quick_searchread onlyauth50/100

System-level native file name index search using MFT/USN (Windows) or filesystem enumeration. Returns results from the entire volume without collection restrictions. Admin token required.

reindexwriteauth50/100

Trigger a full or incremental reindexing of the configured collection roots. Scans filesystem, extracts metadata and content, updates local index database.

searchread onlyauth50/100

Hybrid semantic and keyword search across indexed files and documents. Supports natural language queries with intent parsing, multi-source result merging, and relevance ranking.

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., does search return result_id, file_path, relevance_score?). Breaks tool chaining.

searchquick_searchindex_statusreindex

HIGHconstrained-input ↗

Parameter descriptions lack constraints. 'limit' has no min/max bounds, LLMs may pass absurd values (0, 999999). 'query' has no length/format guidance. 'collection' is optional but no guidance on default behavior.

searchquick_search

HIGHconfirmation-request ↗

reindex (WRITE operation) lacks confirmation/dry-run pattern. Agents can trigger full reindex without safeguard. No recovery guidance if reindex fails mid-operation.

reindex

HIGHrecovery-guide ↗

Error handling not visible in source. No evidence of actionable error messages, recovery hints, or error classification (retryable vs fatal). Agents cannot self-correct on failures.

Recommendations

Document output schemas for all tools. Example: search returns [{result_id, file_path, relevance_score, snippet, collection}]. index_status returns {phase, progress_percent, indexed_count, last_indexed_at}.
Add parameter constraints: limit (1-100, default 20), query (1-500 chars), collection (optional, defaults to all indexed collections).
Add error recovery guidance: 'If search returns no results, try broader query terms or call index_status to verify indexing is complete.'
Implement dry-run for reindex: add 'dry_run' boolean parameter. Return what would be reindexed without modifying state.
Document admin token requirement in quick_search schema as a security note, not just description text. Clarify how token is provided (header, parameter, environment).

Score history

Overall score trend

First recorded score · v2 rubric

62/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	62	2026-07-28+	v2