Loading ToolBench

Reading the current corpus…

mcp-shared-memory MCP server · C · ToolBench

mcp-shared-memory

MCP server providing shared memory functionality across multiple Claude Code instances through a centralized Git-backed storage system. Supports project-specific configurations, templated instructions, and collaborative workflow management.

<=2025-11-25STDIO1 tools

61/100

Definition Quality77

Protocol Readiness47

Supportability43

Spec posture

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

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

This MCP server exposes a single tool (ip_get_details) with reasonable documentation and a complete Zod schema. The naming is verb-first and clear, the description is comprehensive and exceeds 100 characters, and parameters include type information and descriptions. However, there are several quality gaps: (1) the tool is READ_ONLY but lacks tool annotations (readOnlyHint/destructiveHint) in the schema that the current MCP spec (2026-07-28) expects; (2) the output schema is not documented in the code, we can infer the tool returns text content but no formal schema is declared; (3) parameter descriptions are present but could be more explicit about constraints (e.g., what defines a 'private IP' or how includeExtendedData interacts with tokens); (4) no error handling examples or recovery guidance are provided in the description. The server correctly uses Zod for validation and follows a verb_noun pattern, but falls short of A-grade polish that would include explicit output schemas, tool annotations, and structured error responses.

Tools (1)

ip_get_detailsread onlyauthsource verified77/100

Retrieves detailed geolocation and network information for a public IP address (`ipAddress`). If no IP is provided, automatically uses the server's current public IP. Returns comprehensive location data including country, region, city, coordinates, timezone, and network details like ISP and organization. Use `includeExtendedData` to get additional information such as ASN, mobile/proxy detection (requires API token). **Note:** Cannot lookup private IPs (e.g., 192.168.x.x, 10.x.x.x). Powered by ip-api.com. Enable `useHttps` for secure connections (required for paid tier).

Issues (5)

HIGHtool-annotations ↗

Tool lacks MCP spec-compliant annotations (readOnlyHint, destructiveHint, idempotentHint). The ip_get_details tool is READ_ONLY but does not declare this via tool annotations, making it harder for agents to reason about safety.

ip_get_details

HIGHresponse-shaper ↗

Output schema not documented. The tool handler returns text content in a specific format, but no formal JSON Schema is documented in the source or returned to the client. This forces LLMs to infer the response structure and limits downstream tool composition.

ip_get_details

MEDIUMconstrained-input ↗

Parameter constraint descriptions lack specificity. The 'ipAddress' parameter description says 'omit for current IP' but does not explain what constitutes a valid IP (IPv4 vs IPv6, private IP rejection). The 'includeExtendedData' description mentions 'requires API token' but does not explain how to configure or provide it.

ip_get_details

Recommendations

Add tool annotations to the server.tool() call: supply readOnlyHint: true to explicitly mark ip_get_details as read-only. Ref: MCP spec 2026-07-28, tool annotations section.
Document the output schema explicitly. Add a comment or JSDoc describing the structure returned: { country: string, region: string, city: string, coordinates: { lat, lon }, timezone: string, isp: string, organization: string, asn?: string, ...rest }. Consider returning this as a typed object rather than a text blob.
Expand parameter descriptions: (1) For 'ipAddress': 'IPv4 or IPv6 address to lookup (omit to use server's current public IP). Cannot resolve private IPs (192.168.x.x, 10.x.x.x, 172.16 - 31.x.x).'; (2) For 'includeExtendedData': 'Include ASN, organization, and mobile/proxy detection. Requires a valid ip-api.com API key passed via the IP_API_KEY environment variable.'; (3) For 'useHttps': 'Use HTTPS for the connection (required for paid ip-api.com tier). Set false only if your IP API plan does not support HTTPS.'
Add error handling guidance to the tool description. E.g.: 'If the lookup fails due to rate limiting or API unavailability, the tool will return an error with a retry-after suggestion. If the IP is invalid or private, the tool returns a clear message indicating which constraint was violated.'
Consider splitting parameter validation feedback into the error response. When an LLM passes an invalid IP, respond with: 'Invalid IP address: got "xyz". Expected IPv4 (a.b.c.d) or IPv6 (hex:format). Cannot resolve private IPs.' This enables self-correction.

Spec posture evidence

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

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

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

61/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	C	61	<=2025-11-25	v2
2026-03-09	C	60	-	v1