Loading ToolBench

Reading the current corpus…

aclimate_v3_mcp MCP server · D · ToolBench

← Browse

aclimate_v3_mcp

github.com/CIAT-DAPA/aclimate_v3_mcp

MCP server exposing the AClimate API v3 for climate and agroclimatic data access

<=2025-11-25STREAMABLE_HTTP7 tools

57/100

Definition Quality62

Protocol Readiness75

Supportability35

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

AClimate MCP demonstrates solid definition quality with consistent naming patterns, complete input schemas, and well-structured output models. All 7 tools follow verb_noun naming (search_, get_) and include descriptions. Input parameters are typed with descriptions. However, descriptions are brief (10-30 chars) and lack context about when to use each tool or dependencies between them. Output schemas are documented in code but not exposed in tool definitions. Error handling is present but generic. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only.

Tools (7)

get_available_climate_dataread onlyauth50/100

Get available date ranges for climate data at a location

get_available_climatology_dataread onlyauth50/100

Get available climate normals (climatology) for a location

get_available_indicatorsread onlyauth50/100

Get available indicators for a location

get_climate_dataread onlyauth50/100

Get climate time series data for a location within a date range

get_climatology_dataread onlyauth50/100

Get climate normals (climatology) for a location by month

get_indicatorsread onlyauth50/100

Get agroclimatic indicator values for a location within a date range

search_locations_by_nameread onlyauthsource verified75/100

Search for locations by name pattern

Issues (5)

HIGHtool-description ↗

Tool descriptions are too brief (10-30 chars). Baseline is 194 chars. Descriptions lack context about when to use each tool, dependencies, and what data is returned. E.g., 'Get available date ranges for climate data at a location' does not explain why an agent would call this before get_climate_data.

search_locations_by_nameget_available_climate_dataget_available_climatology_dataget_available_indicators

MEDIUMtool-annotations ↗

No tool annotations present. All 7 tools are read-only (Risk: READ_ONLY declared), but readOnlyHint is not set in tool definitions. This prevents clients from optimizing caching and retry logic.

search_locations_by_nameget_available_climate_dataget_available_climatology_dataget_available_indicatorsget_climate_dataget_climatology_dataget_indicators

HIGHresponse-shaper ↗

Output schemas are defined in code (AvailableDateRange, ClimateSeriesResponse, etc.) but not exposed in tool definitions. LLMs cannot see what fields to expect without reading source. Baseline: 100% of A+ tools have documented return types.

Recommendations

Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (e.g., 'Call this after search_locations_by_name to check if climate data exists for a location'), and WHAT it returns. Example: 'Get available date ranges for climate data at a location. Call this after search_locations_by_name to verify data exists before requesting get_climate_data. Returns min/max dates and data quality metrics.'
Add readOnlyHint: true to all 7 tool definitions in fastmcp registration. This signals to clients that these tools are safe to cache and retry without side effects.
Document output schemas in tool definitions. Use fastmcp's schema parameter or extend tool metadata to include return type definitions. At minimum, add a 'Returns' section to each description listing key fields (location_id, location_name, total_points, measures, etc.).
Enhance error messages with recovery guidance. When location_id is invalid, catch AClimateAPIError and return: 'Location ID not found. Call search_locations_by_name(name="...") to find valid location IDs.' When date range is invalid, suggest narrowing the range or using detail='summary'.
Add a discovery tool or resource that lists available locations and their metadata. This reduces the need for agents to call search_locations_by_name speculatively and enables better planning.

Spec posture evidence

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

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

Score history

Overall score trend

First recorded score · v2 rubric

57/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	57	<=2025-11-25	v2