Loading ToolBench
Model Context Protocol integration for VayuPress, a sovereign single-binary publishing engine. Exposes blog post management, site settings, content search, and analytics tools authenticated via scoped API keys.
VayuPress MCP server exhibits solid tool design with consistently named verbs (site_info, create_post, update_post, delete_post, list_posts, get_post, search_content). All 7 tools have descriptions (average ~120 chars, within ideal 10-1024 range). All parameters include type definitions and descriptions. Tools follow single-responsibility principle and compose well (e.g., create_post returns slug, which get_post and update_post accept). Risk categories (READ_ONLY, WRITE, DESTRUCTIVE) are properly declared. However, several gaps prevent a higher score: (1) Input schemas lack formal constraints (no enums, min/max bounds, regex patterns); (2) Output schemas are undocumented, we know tools return data but see no explicit response field definitions; (3) Error handling guidance is absent, no recovery hints for common failures; (4) Parameter descriptions omit format constraints (e.g., 'title (1 - 500 chars)' is stated but not formalized); (5) no support for destructive operation confirmation/dry-run.
Create and publish a blog post. content is HTML (sanitized server-side). Returns the queued id and slug; the post is live within seconds at /<slug>.
Delete a post by slug.
Fetch a single post (including its HTML content) by slug.
List published posts (newest first). Supports pagination and an optional tag filter.
Full-text search across published posts. Returns matching titles and slugs.
Return this VayuPress site's name, primary domain, and version. Use it to confirm the connection.
Output schemas are not documented. Tool descriptions state what is returned (e.g., 'Returns the queued id and slug') but no formal schema defines response field types, required fields, or structure. LLMs cannot plan downstream calls or extract data reliably without knowing what fields exist.
Input parameters lack formal constraints (enums, min/max, patterns, regex). Descriptions state 'title (1 - 500 chars)' and 'slug (lowercase, hyphenated)' but these are not encoded in the schema. LLMs cannot validate constraints before calling and may pass invalid values, forcing error recovery.
delete_post lacks confirmation mechanism or dry-run mode. Destructive operations should offer a confirmation step to prevent accidental deletion by agents. Currently, a single call irreversibly deletes content.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Update an existing post by slug. Only the fields you pass change; omitted fields are left as-is.
Error handling does not include recovery guidance. No error examples show what to do if post creation fails (e.g., 'slug already exists'), a tag is invalid, or content is rejected for HTML sanitization. Agents have no actionable next steps.
create_post and update_post accept 'tags' as an array but no constraint on count is visible. Description says 'max 20' but this is not enforced in schema. No enum of valid tags is provided.
list_posts pagination parameters (page, limit) have no min/max bounds in schema. Agents could request page=1000000 or limit=-1, causing errors or resource exhaustion. Schema should enforce page≥1, 1≤limit≤100.
No documentation of what fields list_posts and search_content return. A schema or prose description stating 'Returns: {total: int, posts: [{slug, title, tags, published_at}, ...], next_cursor: ?string}' would enable agents to compose multi-step workflows.