apidog-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIDOG_LOCALE | No | Locale setting, defaults to en-US. | en-US |
| APIDOG_TEAM_ID | No | Default team ID for apidog_list_team_projects. | |
| APIDOG_ACCESS_TOKEN | Yes | Access token for Apidog API calls. Required for tools to work. | |
| APIDOG_CLIENT_VERSION | No | Client version, defaults to 2.8.34. | 2.8.34 |
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 |
|---|---|
| apidog_check_authA | Verify APIDOG_ACCESS_TOKEN by calling Apidog's current user endpoint. |
| apidog_configure_projectB | Write apidog.json in the current directory and add it to .gitignore. |
| apidog_list_user_projectsA | List projects accessible by the current user. |
| apidog_list_user_teamsA | List teams accessible by the current user. |
| apidog_list_team_projectsA | List projects for APIDOG_TEAM_ID, or for an explicit teamId. |
| apidog_list_modulesB | List modules in an Apidog project. |
| apidog_list_environmentsB | List environments in an Apidog project. |
| apidog_list_api_treeC | List the Apidog API tree for the configured or specified project. |
| apidog_list_api_detail_foldersA | List API detail folders for endpoint placement reference. |
| apidog_list_api_responsesC | List reusable API response components. |
| apidog_list_test_case_categoriesA | List test case categories for a project. |
| apidog_list_test_case_tagsB | List test case tags for a project. |
| apidog_list_runnersA | List self-hosted general runners for a project. |
| apidog_get_http_apiB | Get an Apidog HTTP API detail by ID. |
| apidog_create_moduleB | Create a module in an Apidog project. |
| apidog_update_moduleC | Update module fields. Use for renaming modules. |
| apidog_rename_moduleC | Rename a module in an Apidog project. |
| apidog_delete_moduleB | Delete a module in an Apidog project. Requires confirmDelete=true. |
| apidog_create_api_detail_folderC | Create an API detail folder. |
| apidog_rename_api_detail_folderC | Rename an API detail folder. |
| apidog_delete_api_detail_folderB | Delete an API detail folder. Requires confirmDelete=true. |
| apidog_create_api_detailC | Create an Apidog API detail using raw Apidog form fields. |
| apidog_update_api_detailA | Update an Apidog API detail using raw Apidog form fields. Prefer passing a full detail body from apidog_get_http_api. |
| apidog_delete_api_detailC | Delete an Apidog API detail/request. Requires confirmDelete=true. |
| apidog_add_requestC | Create an Apidog HTTP request/API detail with practical defaults. |
| apidog_update_requestB | Update an Apidog HTTP request/API detail with practical defaults. Include all fields you want preserved. |
| apidog_delete_requestB | Alias for deleting an Apidog HTTP API detail/request. Requires confirmDelete=true. |
| apidog_export_openapiC | Export OpenAPI from Apidog. |
| apidog_get_openapiD | Alias for apidog_export_openapi. |
| apidog_validate_openapiA | Validate an OpenAPI JSON or YAML document without importing it. |
| apidog_import_openapiC | Validate and import OpenAPI into Apidog. |
| apidog_add_endpointC | Add an endpoint by export-modify-validate-import. |
| apidog_update_endpointC | Patch an existing endpoint operation by export-modify-validate-import. Null values remove fields. |
| apidog_upsert_endpointC | Create or update an endpoint operation by export-modify-validate-import. |
| apidog_delete_endpointC | Delete an endpoint by export-modify-validate-import. Requires confirmDelete=true. |
| apidog_patch_openapiA | Apply RFC 6902 JSON Patch to exported OpenAPI, validate, then import. |
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 36 tools
Multiple tools overlap significantly: create_api_detail, add_request, and add_endpoint all create API endpoints; update_api_detail, update_request, update_endpoint, and patch_openapi all handle updates; delete_api_detail, delete_request, and delete_endpoint are near-duplicates. Agents will struggle to choose the correct tool without deep inspection.
All tools share a consistent 'apidog_' prefix and snake_case format, mostly following verb_noun. However, there are inconsistencies: 'add' vs 'create' for similar operations, 'get_openapi' is an alias for 'export_openapi', and 'update_module' overlaps with 'rename_module'.
With 36 tools, the surface is too large for a single MCP server. Many tools are aliases or redundant variants (e.g., three creation methods, three update methods, three delete methods), inflating the count without adding distinct capability.
The API lifecycle is covered through multiple overlapping paths, but there are notable gaps: no environment CRUD beyond listing, no test case management beyond listing tags/categories, and the export-modify-validate-import cycle suggests missing native mutation endpoints. The surface is broad but not cleanly complete.