A keyless remote MCP server providing 91 tools for accessing dynamic feed data
Single tool 'current_weather' has a verb-noun name (good), but the description is extremely brief (24 chars) and lacks critical context. Input schema is minimal: only 'city' parameter with basic string type, no format constraints, no examples of valid input, no error guidance. No output schema documented. The tool appears to be a thin wrapper around a remote API (dynamicfeed.ai/mcp) with 91 tools, but this example only demonstrates one. No parameter validation rules, no error handling guidance, no idempotency guarantees. The description does not explain when to use this tool, what format the response takes, or what happens on failure (e.g., invalid city name).
Get current weather for a city
Description is 24 characters, below the 34-char p10 baseline and well below the 50-200 char LLM-optimized range. Lacks WHAT (what does it return?), WHEN (when should I call this vs. a forecast tool?), and prerequisites.
No output schema documented. LLM cannot plan downstream tool calls or extract fields. Does it return temperature, humidity, wind speed? Format (Celsius/Fahrenheit)? Structured JSON or free text?
Parameter 'city' lacks format constraints, examples, and validation rules. No guidance on what happens if city is invalid, ambiguous (e.g., 'Springfield'), or misspelled. No error recovery hint.
No error handling guidance. If the city is not found or the API times out, what should the LLM do? Retry? Ask the user? No recovery guide provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
This example demonstrates only 1 of 91 available tools on the remote server. No visibility into the full tool catalog, their schemas, or quality. Evaluation is limited to the single example provided.