Loading ToolBench

Reading the current corpus…

mcp-lisp MCP server · F · ToolBench

mcp-lisp

An MCP server implementation in Common Lisp that demonstrates MCP tool registration, HTTP transport, and integration with Claude for various use cases including energy grid simulation, train interlocking systems, escalation agents, and structured data extraction.

<=2025-11-25STREAMABLE_HTTP0 tools

18/100

Definition Quality0

Protocol Readiness0

Supportability30

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Sampling, Logging

Deprecated protocol patterns detected

Summary

Scoring was not performed

Issues (6)

CRITICALconstrained-input ↗

No input schemas visible for any tool. All tools have empty input objects {} in test calls, but no JSON Schema definitions found in source code.

test_simple_texttest_image_contenttest_audio_contenttest_embedded_resourcetest_multiple_content_typestest_error_handling

CRITICALtool ↗

Tool definitions are inferred from test method calls, not explicitly registered. Actual tool implementations cannot be verified from provided source.

test_simple_texttest_image_contenttest_audio_contenttest_embedded_resourcetest_multiple_content_typestest_error_handling

CRITICALtool-description ↗

Descriptions are trivial and under 20 characters (e.g., 'Test tool that returns simple text content'). No WHEN to use, prerequisites, or actionable guidance for LLM tool selection.

test_simple_texttest_image_contenttest_audio_contenttest_embedded_resource

Recommendations

Provide the actual conformance-server.lisp implementation file for evaluation. The test client alone cannot be assessed.
Add explicit input schemas for each tool with JSON Schema type definitions (string, number, object, array) and descriptions for every parameter.
Rename tools to follow verb_noun convention: 'test_simple_text' → 'get_simple_text', 'test_image_content' → 'fetch_image', 'test_error_handling' → 'simulate_error' or 'validate_error_response'.
Expand tool descriptions to 50-150 characters with WHAT, WHEN, and prerequisite information. E.g., 'Retrieve a simple text payload. Call this first to verify basic tool functionality.' instead of 'Test tool that returns simple text content'.
Document output schemas for each tool (expected response structure, fields, types) so LLMs can plan downstream operations.
Implement proper error handling with actionable recovery guidance. E.g., 'Invalid request. Expected parameters: {}. Supported media types: text, image, audio.'
Add parameter descriptions even if parameters are optional or empty. Explain what each parameter does and acceptable value ranges.

Score history

Overall score trend

↓ 8 points across a rubric change (v1 → v2)

18/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	18	<=2025-11-25	v2
2026-03-15	F	26	2025-11-25+	v1