# Verify and troubleshoot your MCP connection Installing a configuration is the start. Verify the server's identity, discover the expected tools, then complete one useful task. This guide does not execute requests or claim your client is connected. ## Choose the server for the task | | Documentation MCP | Apideck MCP server | | -------------------- | ------------------------------------- | ----------------------------------------------------------------------------- | | Endpoint | `https://developers.apideck.com/mcp` | `https://mcp.apideck.dev/mcp` | | Purpose | Find and read documentation | Operate on connected apps | | Credentials | No Apideck API key | Apideck credentials and intended consumer | | Expected tools | `search_docs`, `get_operation_context`, `get_doc`, `list_docs` | In dynamic mode: `list_tools`, `describe_tool_input`, `execute_tool`, `list_scopes` | | First useful outcome | Relevant source retrieved and cited | An approved, bounded read with the result verified | Seeing four discovery tools in the Apideck MCP server’s dynamic mode is expected. It is not an empty integration or evidence that no connector operations exist. Inspect discovery results before executing anything. Use the [installation instructions](/mcp#install) and your client's supported remote-server configuration. A successful handshake or `tools/list` response does not prove that credentials work. The public server can expose its meta-tool schemas before authenticating an operation. Check tool-level `isError` as well as HTTP status: a tool can return HTTP 200 with an authentication error. Use `list_tools` with `domain`, `search_terms` and `scope` to narrow discovery. Pass the exact returned name to `describe_tool_input`, then pass schema-validated arguments in `execute_tool.input`. A discovery filter such as `scope: "read"` selects results; it is not evidence of credential-enforced read-only access. Building a Python agent? Follow the [runnable LangChain sample and guide](/guides/langchain-mcp) to verify discovery and a bounded invoice read. ## Verify in your client These checks apply after the existing installation flow. Client labels vary by version; a connected indicator alone is insufficient. | Client | Check installation | Verify before proceeding | Remove local access | | ------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Cursor | Inspect the configured server in MCP settings. | Confirm its endpoint and enabled state; ask for the relevant server's tools. | Disable/remove the entry in MCP settings or the configuration file where it was added. | | VS Code | Inspect the MCP server configuration and server status/log output. | Start/reload the configured server and inspect discovered tools. | Stop the server and remove its workspace/user configuration. | | Claude Code | Run `claude mcp list` and inspect the configured server. | Use `/mcp` in the session to inspect status and tools. | Use `claude mcp remove ` for the installation scope used. | | Other clients | Inspect the server entry and connection log using the client's documentation. | Verify endpoint, authentication support and returned tool names. | Remove the configured server; confirm a new session no longer discovers it. | Do not put API keys in repository configuration or chat. Removing a local server entry does not revoke a shared API key or unlink the provider account. If a credential was exposed, rotate/revoke it through the Apideck application's credential controls and update other authorized clients. Provider authorization is managed separately through Vault/provider controls. Client configuration references: [Cursor](https://cursor.com/docs/mcp), [VS Code](https://code.visualstudio.com/docs/agent-customization/mcp-servers), [Claude Code](https://code.claude.com/docs/en/mcp). Claude Code HTTP JSON entries require `"type": "http"`; adapt examples to your client’s schema. ## First task: retrieve documentation Connect Documentation MCP, then ask: ```text Find Apideck guidance on parent and child requests in Logs. Retrieve the relevant document and explain how to compare a downstream response with the unified result. Cite the source URL. Do not connect to customer systems. ``` Verify that the answer cites the [Logs guide](/logs#follow-parent-and-child-requests) and distinguishes a parent request from its downstream child calls. A search result title without fetching the guidance is not a complete retrieval task. ## First task: read connected data Continue through the [first-call workspace](/first-api-call?language=mcp). Select your API and connector and use its contextual prompt. Discover the relevant tool, inspect its schema and confirm the consumer/source account before approving a read of at most ten records. Do not approve writes as a connection test. Verify the tool result, service, count and cursor against the intended account and Logs. Keep customer records out of the conversation. A successful empty page is valid but still needs an account check. A request template or the agent's promise to run it is not execution evidence. ## Recover from a specific symptom | Symptom | Check | Next action / stopping point | | --------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Documentation server asks for an Apideck key | Compare the exact endpoint with the table above. | Correct the server entry; do not supply customer credentials to docs retrieval. | | Cannot connect / transport error | Client log, remote HTTP support and endpoint spelling. | Correct configuration and reconnect. An HTML page in a browser is not a successful MCP handshake. | | API authentication rejected | Locally verify key, application and intended consumer settings. | Correct/rotate invalid credentials; do not retry indefinitely. | | Connected, but no tools | Check server identity, whether the client disabled tools, and discovery response. | Reconnect after configuration changes. For the Apideck MCP server’s dynamic mode, look for meta-tools rather than every operation. | | Meta-tools exist, selected operation does not | Check scopes, tool description and connector coverage. | Ask the administrator to review authorized access; stop if unsupported. Do not invent a tool name. | | Tool fails after discovery | Inspect sanitized error and parent/child request evidence. | Use the [failed-request walkthrough](/guides/investigate-failed-request); correct the cause before retrying. | | Timeout after a write | The destination may already have changed. | Reconcile the outcome before any replay. A timeout is not proof that nothing happened. | To report an issue, include the client/version, server type, UTC time, stage (connect/discover/execute) and sanitized error. Exclude keys, tokens, consumer identifiers and customer payloads from public issues. Record whether the task succeeded or stopped with a justified reason, not merely whether the install button was clicked.