An AI application can suggest an action in conversation. An MCP connection gives it a structured way to request an available tool. MCP DigLab sends the configured request to an approved service and returns the result to the AI application.
The request path#
You ask a question
-> Your AI application selects an enabled tool
-> Your private MCP connection checks access
-> The approved business service handles the request
-> The result returns to your AI applicationThe AI application decides how to explain the result. Check its explanation against the returned evidence when accuracy matters.
The main terms#
| Term | Meaning |
|---|---|
| AI client | The application where you chat with an AI and add an MCP connection. |
| Endpoint | The exact remote address assigned to your connection. |
| Tool | A named operation with defined inputs, such as searching records. |
| Tool inputs | The arguments required by that operation, such as a record identifier. |
| Upstream service | The business platform that actually stores data or performs the action. |
| Authentication | The check that establishes who may access a connection or service. |
| Scope | The allowed class of operations for a credential or account. |
Two separate access checks#
First, your AI client authenticates to MCP DigLab. Second, the configured integration authenticates to the business service. A valid MCP credential does not grant a subscription or permission that the business account does not have.
This distinction explains a common failure: a connection can discover tools successfully while a particular tool fails because its business-service authorisation has expired. Use troubleshooting to identify which stage failed.
Connection status and actual readiness#
Treat readiness as a sequence: connection accepted, expected tools discovered, exact account confirmed and real task completed. Write actions need their own authorised verification. A tool being visible does not prove it has been tested for your account.