Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →reinamaccredy/mcp-for-agents
Designs or reviews MCP servers so AI agents can use them reliably: outcome-oriented tools, flat constrained parameters, actionable errors via isError, token-efficient responses, composable outputs, and disciplined tool surfaces.
Passed 22 of 22 test cases with the skill, and 16 of 22 without it.
and 5 more in the full report
6 fixed16 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are building an internal Model Context Protocol integration for our database query tools, but when queries fail, the model gets stuck in repetitive error loops due to unhelpful raw exception dumps. Can you provide a specification for how our tool error outputs and return payloads should be formatted so the model can intelligently recover from invalid inputs?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies returning execution failures as result content with isError set to true. | Passed | Passed |
| Specifies error messages formatted as plain text action instructions for self-correction. | Passed | Passed |
| Recommends plain text or structuredContent payloads to minimize context token usage. | Missed | Passed |
The instructions your model reads when the skill loads.
Developer-oriented MCP servers often fail agents: 1:1 REST-to-tool mappings that force multi-step orchestration, vague descriptions that cause wrong tool selection, nested parameter objects that invite hallucination, and raw API passthrough that exhausts the context window. Design for the agent's constraints, not the developer's convenience.
The agent decides when to call; the server decides how. Combine backend operations server-side so the agent makes one call, not three.
Bad: Expose get_user_by_email, list_orders, get_order_status separately -- agent chains three calls.
Good: Expose track_latest_order(email) -- server handles the lookup internally, returns what the agent needs.
A tool that maps 1:1 to a REST endpoint is almost always wrong. Ask: "What outcome does the agent want?" and build the tool around that.
Agents hallucinate missing keys in nested objects. Flatten parameters to top-level primitives, constrain with enums, and add sensible defaults so the agent makes fewer decisions.
Bad:
{
"filters": {
"status": "string",
"date_range": { "start": "string", "end": "string" },
"sort": { "field": "string", "order": "string" }
}
}
Good:
{
"status": { "type": "string", "enum": ["pending", "shipped", "delivered"], "default": "pending" },
"since_date": { "type": "string", "description": "ISO 8601 date. Defaults to 30 days ago." },
"sort_by": { "type": "string", "enum": ["date", "total"], "default": "date" },
"limit": { "type": "integer", "default": 20, "minimum": 1, "maximum": 100 }
}
Mark required fields explicitly in the schema. Add description to every property -- the agent reads these, not your README. Use consistent parameter names across all tools: pick user_id or userId, never both.
test cases passed, vs 16 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.