Loading ToolBench
MCP server for the ArsMedicaTech medical platform, handling integration with medical systems and services
This MCP server has critical gaps in tool definition quality. Of the 6 tools, all have extremely sparse schemas and descriptions. Tool descriptions are brief (8-47 chars), far below the 50-200 char baseline for LLM-optimized tools. Input parameter schemas are visible but incomplete, many parameters lack proper type constraints and enums where needed. Output schemas are entirely absent from the codebase (no documentation of what these tools return). Error handling guidance is missing. The server is clearly functional but fails to meet production-grade definition standards expected of MCP servers.
Create a LiveKit join token for a specific room and identity
Extract named entities from the provided text
Check if the NER service is ready
Start a composite recording for a specific room
Stop an ongoing egress recording
Receive LiveKit webhooks for room and egress events
Output schemas completely absent. No documentation exists for what any tool returns. LLMs cannot plan downstream tool calls or extract needed data without knowing response structure.
Tool descriptions are far too brief (8-47 chars vs 50-200 baseline). 'Receive LiveKit webhooks for room and egress events' (51 chars) and 'Start a composite recording for a specific room' (47 chars) do not explain WHEN to call these tools or what makes them distinct from alternatives.
Parameter 'Authorization' in webhook tool is exposed as a required input parameter. Authorization tokens must NEVER be tool parameters, they should be server-side injected via environment variables or a secure vault. Exposing tokens in tool parameters risks logging them in traces.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool naming ambiguity: 'webhook' is not verb_noun convention and does not clearly describe what calling it does. Does it RECEIVE webhooks, REGISTER a webhook handler, or SEND webhooks? Name should be 'receive_webhook_event' or 'handle_webhook' to be self-documenting.
Input parameter schemas are incomplete. The 'room' and 'identity' params in create_token have no length constraints, enum values, or validation rules. The 'text' param in extract has no length limit or format specification. Unbounded parameters let LLMs pass absurd values.
No error handling or recovery guidance. Tools do not document what can fail, how errors are classified (retryable vs fatal), or what the LLM should do next. A failed recording start returns what error? 'Room not found'? 'S3 write permission denied'? 'Egress service down'? Unknown recovery path.
No idempotency guidance. 'create_token' and 'start_recording' are stateful write operations, can they be safely retried? If an agent retries after a transient network error, does a duplicate token or recording result? Idempotency expectations must be documented.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. The MCP spec supports tool annotations to help clients and LLMs understand intent and risk, these should be implemented for all write operations.
No pagination or result limits documented. If extract returns a large number of named entities, is there pagination support? Are results capped at a reasonable limit to avoid context window explosion?