Loading ToolBench

Reading the current corpus…

example-mcp-tools-rs MCP server · C · ToolBench

← Browse

example-mcp-tools-rs

github.com/resonatehq-examples/example-mcp-tools-rs

Expose a durable Resonate workflow as an MCP tool over stdio.

2026-07-28+STDIO1 tools

64/100

Definition Quality77

Protocol Readiness32

SupportabilityNot measured-

Spec posture

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

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Single tool with clear naming (get_forecast) and good description (127 chars, within 10-1024 range). Input schema properly defined with latitude/longitude as f64 with descriptions. However, output schema is undocumented, CallToolResult wraps a text response but the actual forecast format is not specified. No parameter constraints (min/max bounds for lat/lon). Error handling returns generic McpError::internal_error without recovery guidance. Tool is read-only (good), but lacks idempotent/readonly annotations. Resonate durability is a strength but not a standard MCP pattern.

Tools (1)

get_forecastread onlysource verified77/100

Get the National Weather Service forecast for a US location. Backed by a durable Resonate workflow — the call automatically retries on transient failure and survives process restarts.

Issues (5)

HIGHtool ↗

Output schema undocumented. Tool returns CallToolResult::success(vec![Content::text(result)]) but the structure and format of the forecast text response is not specified. LLMs cannot plan downstream operations or validate the response structure.

get_forecast

MEDIUMconstrained-input ↗

No parameter bounds. Latitude and longitude accept any f64 value, but NWS only covers the United States (roughly -125 to -66 longitude, 24 to 49 latitude). Unbounded parameters let LLMs pass invalid coordinates without validation.

get_forecast

MEDIUMrecovery-guide ↗

Error handling lacks recovery guidance. McpError::internal_error(format!("resonate rpc failed: {e}"), None) returns a generic error with no actionable next step. LLM cannot determine if the error is retryable, user-fixable, or fatal.

get_forecast

LOWtool ↗

No tool annotations. Tool is read-only and idempotent (same lat/lon always returns same forecast), but lacks readOnlyHint and idempotentHint annotations in the schema. LLMs cannot infer safety properties.

Recommendations

Document the output schema: specify that the response is a formatted string with 5 forecast periods, each containing name, temperature, wind, and detailed forecast. Example: '{"periods": [{"name": "Tonight", "temperature": 45, "forecast": "..."}, ...]}'
Add parameter constraints: latitude must be between 24 and 49, longitude between -125 and -66 (US bounds). Include these in the parameter descriptions: 'Latitude of the location (24 - 49, NWS covers US only).'
Enhance error handling with recovery guidance. Instead of 'resonate rpc failed: {e}', return 'Failed to fetch forecast for ({latitude}, {longitude}). Verify coordinates are within the US (lat 24 - 49, lon -125 to -66) and retry. If the error persists, the NWS service may be temporarily unavailable.'
Add tool annotations to the schema. Mark the tool as readOnly and idempotent so LLMs know it is safe to call multiple times without side effects.
Consider migrating from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote deployment and integration with hosted MCP clients.

Spec posture evidence

Inferred effective spec: 2026-07-28+.

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

Score history

Overall score trend

First recorded score · v2 rubric

64/100

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