Personal MCP server framework — deploy your AI backend to Vercel in 5 minutes. Formerly MyMCP. Provides tools for Gmail, Calendar, Obsidian, Slack, and other integrations.
Kebab MCP exposes only 2 tools (vault_read, vault_write) with minimal schema documentation. Both tools have extremely brief descriptions (under 50 chars) that fail to explain WHEN to use them, WHAT they return, or dependencies. Input schemas are present but lack parameter descriptions, the 'path' and 'content' parameters have only type declarations, no guidance on format, constraints, or examples. No output schemas are documented. Error handling is absent, no recovery guidance, no validation rules, no actionable error messages. The tool names are verb-noun compliant but descriptions are far below the 50-200 char baseline for LLM-optimized tools. Risk annotations (READ_ONLY, WRITE) are present but not integrated into descriptions.
Read a file from Obsidian vault
Write content to a file in Obsidian vault
Tool descriptions are critically under-specified (both <50 chars). Descriptions must be 50-200 chars and explain WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions ('Read a file from Obsidian vault', 'Write content to a file in Obsidian vault') lack context for LLM selection and do not distinguish between the two tools or explain return values.
Input parameters lack descriptions. Both tools have 'path' and vault_write has 'content', but none have parameter-level descriptions explaining format, constraints, or examples. LLMs cannot infer that 'path' expects a relative vault path vs absolute filesystem path, or whether 'content' supports markdown, plain text, or binary.
No output schemas documented. LLMs do not know what vault_read returns (file contents as string? JSON? metadata?), or what vault_write returns (success boolean? file path? timestamp?). This forces LLMs to guess and breaks downstream tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If vault_read fails (file not found, permission denied, invalid path), the tool provides no actionable error message. LLMs cannot self-correct or know whether to retry, ask the user, or try an alternative.
vault_write is destructive (WRITE risk) but has no confirmation or dry-run pattern. Agents can overwrite vault files without safeguards. No idempotency guarantee, repeated calls with the same content should be safe, but this is not documented.