MCP server for Matterbridge message gateway API integration
Three tools with basic schemas and minimal descriptions. Tool names lack action verbs (matterbridge_send is acceptable, but matterbridge_messages and matterbridge_health are noun-heavy). Descriptions are extremely terse (10-30 chars), providing no context on WHEN to use each tool or WHAT happens. Parameters lack descriptions for optional fields (userid, avatar). No output schema documented. Error handling returns raw error strings without recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Composition is reasonable (three separate concerns), but descriptions fail to guide LLM selection.
GET /api/health
GET /api/messages (clears buffer)
POST /api/message; gateway must match matterbridge.toml
Tool descriptions are critically short (10-30 chars). 'GET /api/messages (clears buffer)' and 'GET /api/health' provide no context on WHEN to call these tools or what the LLM should do with results. Baseline is 194 chars; these are 90% below baseline.
Optional parameters (userid, avatar) lack descriptions. LLMs cannot infer whether these are user IDs, display names, URLs, or something else. Baseline: 100% of A+ tools have descriptions for ALL params.
No output schema documented. Handlers return raw text or JSON-indented strings. LLMs cannot plan downstream calls or extract structured data. Baseline: 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Error handling returns raw error strings (e.g., 'text is required', err.Error()) without recovery guidance. No categorization of retryable vs fatal errors. Baseline: errors must tell LLM what to do next.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). matterbridge_send is destructive (sends a message) but LLM has no signal to treat it carefully. matterbridge_messages clears buffer (side effect) but is unmarked.