A template MCP server using PulseEngine MCP framework with automatic tool discovery
Scoring was not performed
No output/return schemas documented. LLMs cannot plan downstream tool calls without knowing the structure of responses. Even simple tools like get_status should document what fields the response contains.
Parameter descriptions lack actionable detail. 'The message to echo back (required)' is minimal; should explain format constraints, length limits, special character handling, and when to use this tool vs alternatives.
Numeric parameters (a, b in add_numbers) lack range constraints. No min/max documented. LLMs may pass NaN, infinity, or absurdly large values without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
process_list 'operation' parameter accepts free-form string. Should be an enum: ['count', 'join', 'reverse']. Free-form strings invite hallucinated values outside the documented list.
create_data is marked as WRITE but has no confirmation/dry-run step. For a tool that modifies state, LLMs should have an option to preview before committing.
example_with_error demonstrates error handling but real error messages are absent. The tool name suggests it WILL fail, making it unsuitable for production. Real tools should have failure modes documented with recovery guidance ('Call search_users() first if...').
No error handling guidance. Tools lack descriptions of what can go wrong, when to retry, and what the agent should do next. This violates pattern:error-classification.