MCP API Engineering Lab
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | No | PostgreSQL connection string. If defined, the get_database_schema tool queries information_schema. If not, a sample schema is used. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_database_schemaA | Read a PostgreSQL schema from DATABASE_URL. Falls back to a local sample schema when no database is configured. |
| list_api_contractsA | List local OpenAPI YAML contracts available in the lab. |
| get_api_contractB | Read an OpenAPI contract from the local contracts folder. |
| create_api_contractB | Create a new minimal OpenAPI 3.1 contract in the local contracts folder. |
| update_api_contractB | Update the title or version of an existing local OpenAPI contract. |
| delete_api_contractA | Delete a local OpenAPI contract. The base template is protected. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: get_database_schema retrieves schema, while the other five perform CRUD on API contracts. List, get, create, update, and delete are unambiguous.
All tools follow a consistent verb_noun pattern (list_, get_, create_, update_, delete_), and get_database_schema fits the same style. No mixed conventions.
Six tools is well within the ideal range for a focused server. Each tool serves a clear purpose without unnecessary overlap or bloat.
The CRUD lifecycle for API contracts is fully covered (list, get, create, update, delete). However, update only modifies title/version, not arbitrary fields, and a validation tool is absent—minor gaps for full contract management.