meridian-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | No | Optional direct DB access fallback | |
| MERIDIAN_API_KEY | No | mrd_ API key (Better Auth) for REST calls. Without this every tool still responds in dry-run mode, explaining what endpoint would be called. | |
| MERIDIAN_API_URL | No | Meridian app base URL | http://localhost:3000 |
| MERIDIAN_MCP_LOG_LEVEL | No | debug/info/warn/error | info |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| meridian_statusA | Check Meridian API connectivity (MERIDIAN_API_URL + MERIDIAN_API_KEY) and list available tools/resources. No params. |
| list_servicesA | List Meridian services. Filter by category slug, active flag, or country code (e.g. TN, FR, PT). |
| get_serviceA | Get a single Meridian service by id or slug, including formConfig and delivery steps. |
| list_categoriesA | List Meridian service categories (name, slug, icon, isActive, sortOrder, countryCode). |
| list_service_requestsC | List service requests. Filter by status (DRAFT, REQUIREMENTS, ADMIN_VALIDATION, PROVIDER_ACCEPTANCE, QUOTE, PAYMENT, DELIVERY, FULFILLMENT, COMPLETED, DISPUTED, CANCELLED), customerId, providerId. |
| get_service_requestB | Get a single service request by id, including current step, phase, and requestSteps. |
| create_service_requestA | Create a new service request. Needs serviceId (or slug) and answers matching the service formConfig. |
| update_request_statusA | Advance or set a request's status. Prefer advance_step for workflow transitions. Use only when you know the target phase is valid. |
| get_workflow_statusA | 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. |
| advance_stepA | Advance the current step for a request to the next step (completes current step and moves currentStepId). Validates phase transitions. |
| list_request_stepsA | List all RequestSteps for a request in order, including key, phase, assignedTo, stepType, status, startedAt, completedAt. |
| get_payment_statusA | Get payment state for a service request (Payment row: amount, status, provider, serviceRequestId unique). Returns verification status — never trust redirect alone. |
| verify_paymentA | 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. |
| list_meetingsC | List meetings. Filter by serviceRequestId, status, or participant userId. Meetings are created with a fixed title/time/duration and explicit invites (customer/provider/both). |
| create_meetingA | 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. |
| respond_to_meetingA | Record RSVP for a meeting (ACCEPTED/DECLINED/PENDING). Declining records your answer but does NOT cancel the meeting. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Service catalog | All Meridian services and their form configs |
| Workflow definition | Meridian's DEFAULT_WORKFLOW_STEPS backbone and phase diagram |
TDQS
Scored across 16 tools
Most tools target distinct resources, but there is notable overlap between update_request_status and advance_step, and between get_workflow_status, list_request_steps, and get_service_request (all expose step/phase data). The descriptions help clarify intent, but an agent could still select the wrong tool for workflow inspection or transition.
The set mostly follows a clear verb_noun pattern: list_*, get_*, create_*, update_*, verify_*. Minor deviations like meridian_status (no verb) and advance_step (imperative without the request object) break the pattern slightly, but the style is generally predictable.
With 16 tools, the server is slightly above the ideal 3-15 range, but the count is justified by the broad domain covering service catalog, requests, workflow state, payments, and meetings. Each tool addresses a meaningful operation, so the size feels reasonable rather than bloated.
The tool surface covers the main service request lifecycle: listing services, creating requests, advancing workflow, checking payments, and managing meetings. Minor gaps exist such as no dedicated cancel/delete operation, no way to update service request answers, and limited meeting management beyond RSVP, but agents can work around these with existing tools.