Loading ToolBench

Reading the current corpus…

vingularity-protocol MCP server · D · ToolBench

← Browse

vingularity-protocol

github.com/VltrnOne/vingularity-protocol

Auto-scan any codebase and generate a unified mind map. MCP Server + CLI.

2026-07-28+STDIO6 tools

55/100

Definition Quality72

Protocol Readiness50

Supportability31

Spec posture

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

Static source inference · medium confidence

Current-spec patterns detected

Summary

Server has 6 tools with complete schemas and descriptions, but quality is uneven. All tools are READ_ONLY and follow verb_noun naming (scan_*, get_*). Descriptions are present (avg ~80 chars) but lack actionable context for LLM selection. Parameters are typed with Zod but lack detailed constraints and format guidance. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (generic 'No scan data available' messages). No tool annotations (readOnlyHint, idempotentHint). Composition is reasonable: tools chain logically (scan → get_mind_map/connections/ports/tech_stack), but descriptions don't explain prerequisites or when to call each tool.

Tools (6)

get_connectionsread onlysource verified72/100

Get the connection graph showing how projects are linked

get_mind_mapread onlysource verified72/100

Get the mind map from the last scan in markdown or json format

get_port_mapread onlysource verified70/100

Get all detected ports and their associated services

get_tech_stackread onlysource verified67/100

Get the technology inventory across all scanned projects

scan_ecosystemread onlysource verified77/100

Scan a directory tree and detect all projects, APIs, databases, agents, infrastructure, and connections

scan_projectread onlysource verified73/100

Deep scan a single project directory

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting). Responses are free-text markdown/JSON without field-level documentation.

scan_ecosystemscan_projectget_mind_mapget_connectionsget_port_mapget_tech_stack

HIGHtool-description ↗

Descriptions lack actionable context. 'Get the mind map from the last scan' does not explain when to call this vs scan_ecosystem, what format to expect, or what the LLM should do with the output.

get_mind_mapget_connectionsget_port_mapget_tech_stack

MEDIUMconstrained-input ↗

Parameter descriptions lack format/constraint guidance. 'path' parameter has no validation rules (absolute vs relative, must exist, max length). 'depth' has no min/max bounds. 'format' enum is documented but not explained (when to use markdown vs json).

scan_ecosystemscan_projectget_mind_mapget_connections

Recommendations

Document output schemas for each tool. E.g., scan_ecosystem returns {stats: {totalProjects, totalApis, ...}, projects: [{id, name, type, ...}], connections: [...]}. Include field types and nesting.
Enhance descriptions with LLM-optimized context: 'Scan a directory tree to detect all projects, APIs, databases, and connections. Returns a structured mind map. Call this first to initialize the ecosystem model. Subsequent get_* tools query this cached result.'
Add min/max bounds and format rules to parameters: 'path (string, absolute or relative, must exist)', 'depth (number, 1-20, default 8)', 'format (enum: markdown for human-readable output, json for structured parsing)'.
Implement structured error responses with recovery guidance: '{error: "no_scan_data", message: "No scan available", recovery: "Call scan_ecosystem(path) first to initialize the model", retryable: false}'.
Add tool annotations via MCP SDK: mark all tools with readOnlyHint=true and idempotentHint=true to signal safety properties to LLMs.

Score history

Overall score trend

First recorded score · v2 rubric

55/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	55	2026-07-28+	v2