Loading ToolBench
esa-mcp-server has adequate tool definitions with clear action verbs and reasonable parameter schemas, but falls short of production quality in several areas. All 7 tools are explicitly registered with names and descriptions. However, output schemas are undocumented (no structured response format specified), error handling lacks recovery guidance, and several parameter descriptions could be more specific about constraints and expected formats. The server implements basic functionality well but needs refinement in parameter validation, output documentation, and error classification to meet A-grade standards.
Create a new post in esa.io. Required parameters: name. Optional parameters: body_md, tags, category, wip (default: true), message.
Delete a post in esa.io. Required parameters: postNumber.
Retrieves comprehensive documentation about esa.io search queries. Provides detailed information about available query syntax, operators, and search parameters to effectively search through esa posts.
Read multiple posts in esa.io.
Read a post in esa.io.
Search posts in esa.io. Response is paginated. For efficient search, you can use customized queries like the following: keyword for partial match, "keyword" for exact match, keyword1 keyword2 for AND match, keyword1 OR keyword2 for OR match, -keyword for excluding keywords, title:keyword for title match, wip:true or wip:false for WIP posts, kind:stock or kind:flow for kind match, category:category_name for partial match with category name, in:category_name for prefix match with category name, on:category_name for exact match with category name, body:keyword for body match, tag:tag_name or tag:tag_name case_sensitive:true for tag match, user:screen_name for post author's screen name, updated_by:screen_name for post updater's screen name, comment:keyword for partial match with comments, starred:true or starred:false for starred posts, watched:true or watched:false for watched posts, watched_by:screen_name for screen name of members watching the post, sharing:true or sharing:false for shared posts, stars:>3 for posts with more than 3 stars, watches:>3 for posts with more than 3 watches, comments:>3 for posts with more than 3 comments, done:>=3 for posts with 3 or more done items, undone:>=3 for posts with 3 or more undone items, created:>YYYY-MM-DD for filtering by creation date, updated:>YYYY-MM-DD for filtering by update date.Strongly recommend see get_search_query_document for complete query usage.
Output schemas are not documented. Tools return YAML-formatted text via formatTool() but no structured schema is declared for response fields. LLMs cannot plan downstream operations without knowing what fields to expect.
Parameter descriptions lack specificity on constraints and formats. 'Search query string' (search_esa_posts) does not explain the query syntax detailed in the tool description. Parameter descriptions should restate or reference key constraints inline.
Error handling is generic. formatTool() catches errors and returns a generic 'Error: {name}: {message}' response. No recovery guidance, no error classification (retryable vs. user-fixable vs. fatal), and no actionable next steps provided to the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Update an existing post in esa.io. Required parameters: postNumber. Optional parameters: name, body_md, tags, category, wip, message.
Destructive tool (delete_esa_post) has minimal description ('Delete a post in esa.io.'). No warning about irreversibility, no confirmation step, no dry-run option. Critical for preventing accidental deletions.
read_esa_post and read_esa_multiple_posts have identical, minimal descriptions ('Read a post in esa.io.'). The distinction and use cases are unclear. LLMs may choose the wrong tool or conflate them.
create_esa_post and update_esa_post descriptions are vague about optional vs. required parameters. Descriptions state 'Optional parameters: ...' but do not explain what happens if you omit them or whether they trigger different code paths.
No pagination limit documented for search_esa_posts. perPage defaults to 50 but max is 100. Large result sets are not capped at a reasonable default, and no guidance on when to call repeatedly vs. fetch all results.
search_esa_posts description embeds extensive query syntax documentation inline, making it very long (400+ chars). Better to move to get_search_query_document and keep search_esa_posts focused on parameter explanation.