rest_api_mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_OTP | No | The OTP code to submit to API_VERIFY_ENDPOINT. On staging this is typically a fixed test code. | |
| API_EMAIL | No | Login email (required for authenticated endpoints) | |
| API_PASSWORD | No | Login password (required for authenticated endpoints) | |
| REST_BASE_URL | Yes | Base API URL, no trailing slash | |
| API_TOKEN_PATH | No | Dot-path to token in login/verify response, e.g. data.access_token | |
| API_SWAGGER_URL | No | OpenAPI JSON URL for fetch_spec, search_endpoints, and login auto-discovery | |
| API_LOGIN_ENDPOINT | No | Override login path, e.g. /auth/sign-in | |
| API_VERIFY_ENDPOINT | No | Path of the 2FA/OTP verify step. Setting this enables two-step auth. Example: /auth/verify-otp | |
| API_LOGIN_CREDENTIALS | No | JSON object of extra fields merged into the login POST body alongside email/password. Use for role, source, tenantId, etc. Example: {"role":"admin"} | |
| API_VERIFY_CREDENTIALS | No | JSON object of extra fields merged into the verify POST body, beyond the auto-carried session identifiers and OTP. Example: {"client_id":"web-app"} | |
| REST_ENABLE_SSL_VERIFY | No | Set false to skip TLS cert validation (dev/staging only) | true |
| REST_RESPONSE_SIZE_LIMIT | No | Max response characters before truncation | 100000 |
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 |
|---|---|
| fetch_specA | Fetches the OpenAPI/Swagger JSON spec for this API. Use this to discover endpoint paths, HTTP methods, and request body schemas before calling request(). |
| search_endpointsA | Fuzzy-search the API spec by keyword. Use this when you don't know the exact path. Searches across path, HTTP method, summary, description, tags, and operationId. Returns matching endpoints with their method, full path, summary, and required parameters. |
| requestA | Makes an authenticated API call. Handles login automatically — if the token is expired it re-logins transparently. Returns the full response body plus login_data (which contains IDs like pharmacyId returned from login). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Implementation Workflow Guide | Step-by-step guide for implementing a REST API endpoint in Flutter using this MCP server |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: fetch_spec retrieves the API specification, request makes actual API calls, and search_endpoints provides discovery functionality. An agent can easily differentiate between these three distinct operations.
All tools follow a consistent verb_noun pattern with snake_case: fetch_spec, request, and search_endpoints. The naming is predictable and readable throughout the set.
With only 3 tools, the set feels thin for a general-purpose REST API server, as it lacks operations for common workflows like managing resources or handling specific endpoints directly. However, the tools are well-scoped for their intended discovery and request functions.
The tools cover core discovery and request-making needs (fetch spec, search, and execute calls), but there are minor gaps such as no direct tools for CRUD operations or error handling beyond automatic login. Agents can work around this by using request with discovered endpoints.