Loading ToolBench

Reading the current corpus…

my-mcp-server MCP server · D · ToolBench

my-mcp-server

github.com/chinenyeuwanaka-dev/my-mcp-server

Example MCP Server with integrated or separate OAuth authentication modes, supporting tools, prompts, resources, logging, sampling, and completions

<=2025-11-25STREAMABLE_HTTP7 tools

59/100

Definition Quality71

Protocol Readiness63

Supportability36

Spec posture

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

Static source inference · medium confidence · detected: Sampling, Logging, Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Server has 7 tools with consistent naming (mostly verb-based) and reasonable descriptions (10-200 chars range). Most tools have complete input schemas with type definitions and parameter descriptions. However, output schemas are not documented anywhere in the source code, and several tools have vague or generic descriptions that don't explain WHEN to use them or what they return. No error recovery guidance is evident. Tool compositions are simple (no chaining requirements documented). The server follows basic good practices but falls short of production-grade quality due to missing output schema documentation and insufficient descriptions for some tools.

Tools (7)

addread onlyauthsource verified73/100

Add two numbers

annotatedMessageread onlyauthsource verified73/100

Generate an annotated message with optional image

echoread onlyauthsource verified73/100

Message to echo

getResourceReferenceread onlyauthsource verified72/100

Get a reference to a resource

getTinyImageread onlyauthsource verified58/100

Get a tiny example image

longRunningOperationread onlyauthsource verified73/100

Simulate a long-running operation

sampleLLMread onlyauthsource verified75/100

Sample an LLM with a given prompt

Issues (5)

CRITICALtool-output-schema ↗

Output schemas not documented. No tool explicitly documents what fields or data structure it returns. LLMs cannot plan downstream tool calls or know what data to extract without knowing the response shape.

echoaddlongRunningOperationsampleLLMgetTinyImageannotatedMessagegetResourceReference

HIGHtool-description ↗

getTinyImage and getResourceReference have minimal descriptions (under 30 chars). 'Get a tiny example image' and 'Get a reference to a resource' lack context for when to use them or what they return. Descriptions should be 50-200 chars explaining purpose, use case, and key behavior.

getTinyImagegetResourceReference

HIGHrecovery-guide ↗

No error handling or recovery guidance. Tools do not document what errors can occur, how to classify them (retryable vs fatal), or what the LLM should do next. For example, sampleLLM calling an LLM could timeout or rate-limit, no guidance provided.

sampleLLMlongRunningOperation

Recommendations

Document output schema for every tool. Include in the tool definition or a separate schema reference. Example: 'Returns {result: number}' for add, '{message: string}' for echo, '{url: string, format: string, size: {width: number, height: number}}' for getTinyImage.
Expand tool descriptions to 50-150 chars. For getTinyImage: 'Returns a small example PNG image (64x64) for testing image rendering in annotations.' For getResourceReference: 'Retrieves a resource reference object containing the resource ID, URI, and metadata. Use before accessing the resource directly.'
Add error recovery guidance in descriptions. Example for sampleLLM: 'Calls an LLM with the given prompt. May fail if rate-limited or timeout if the LLM is unresponsive. Retry with a shorter maxTokens if timeout occurs.'
Document parameter constraints and defaults more explicitly. For longRunningOperation, explain what happens if duration or steps are zero, negative, or very large (e.g., max 3600s, max 1000 steps).
For add, clarify numeric behavior: 'Adds two IEEE 754 floating-point numbers. Returns the sum as a number. Note: very large numbers may lose precision.'
Add per-tool return examples in the description or a separate schema. This helps LLMs understand what to expect without guessing.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Sampling (deprecated) - integrate directly with the LLM provider API

Score history

Overall score trend

↑ 59 points across a rubric change (v1 → v2)

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	59	<=2025-11-25	v2
2026-03-09	F	0	-	v1