Loading ToolBench
MCP server for the Meridian business-services platform — expose services, requests, workflow, payments and meetings as MCP tools. Works with Claude Code, Codex CLI, Claude Desktop, pi, and any MCP-compatible client.
Meridian MCP has 16 well-named tools with consistent verb_noun patterns (list_, get_, create_, update_, advance_, verify_, respond_). All tools have descriptions (avg ~120 chars, within baseline 34-392). Input schemas are present and typed for all tools. However, parameter descriptions are sparse or missing in several tools (e.g., list_services lacks descriptions for categorySlug, isActive, countryCode; advance_step lacks description for stepId). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance or actionable error messages visible in code. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Composition is sound, tools chain well (e.g., list_services → get_service → create_service_request). Security: credentials injected via config, not parameters (good). Overall: solid naming and basic structure, but parameter documentation and output schemas need work.
Advance the current step for a request to the next step (completes current step and moves currentStepId). Validates phase transitions.
Create a meeting with title, scheduledAt (ISO), duration minutes, optional serviceRequestId, and invite selection (customer/provider). Creates Teams meeting via Graph and sends invites immediately.
Create a new service request. Needs serviceId (or slug) and answers matching the service formConfig.
Get payment state for a service request (Payment row: amount, status, provider, serviceRequestId unique). Returns verification status — never trust redirect alone.
Get a single Meridian service by id or slug, including formConfig and delivery steps.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Forces agents to guess what data is available after each call.
Parameter descriptions missing or incomplete. list_services has no descriptions for categorySlug, isActive, countryCode. advance_step lacks description for stepId. LLMs cannot infer parameter meaning from names alone.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in metadata but not in schema. Agents cannot determine safety/idempotency from tool definition alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Get a single service request by id, including current step, phase, and requestSteps.
Get the workflow state for a request: current phase, current step, and all requestSteps with status (PENDING/IN_PROGRESS/COMPLETED). Status is derived from currentStepId → phase.
List Meridian service categories (name, slug, icon, isActive, sortOrder, countryCode).
List meetings. Filter by serviceRequestId, status, or participant userId. Meetings are created with a fixed title/time/duration and explicit invites (customer/provider/both).
List all RequestSteps for a request in order, including key, phase, assignedTo, stepType, status, startedAt, completedAt.
List service requests. Filter by status (DRAFT, REQUIREMENTS, ADMIN_VALIDATION, PROVIDER_ACCEPTANCE, QUOTE, PAYMENT, DELIVERY, FULFILLMENT, COMPLETED, DISPUTED, CANCELLED), customerId, providerId.
List Meridian services. Filter by category slug, active flag, or country code (e.g. TN, FR, PT).
Check Meridian API connectivity (MERIDIAN_API_URL + MERIDIAN_API_KEY) and list available tools/resources. No params.
Record RSVP for a meeting (ACCEPTED/DECLINED/PENDING). Declining records your answer but does NOT cancel the meeting.
Advance or set a request's status. Prefer advance_step for workflow transitions. Use only when you know the target phase is valid.
Verify a payment with the provider (Flouci for Tunisia — local wallet/card — or Stripe for international cards). Triggers server-side verification — redirect back to the portal alone is never proof of payment.
Error handling not visible in tool definitions. No recovery guidance, actionable error messages, or error classification (retryable vs user-fixable). Agents cannot self-correct on failures.
No pagination guidance in list tools. list_services, list_service_requests, list_meetings lack limit/offset/cursor parameters and total count in response. Large result sets risk context window exhaustion.