Choose one task you want your assistant to perform. Reading a known record is a useful first task because you can compare the result with the source before granting permission to change anything.
An MCP server makes capabilities available to an AI client. Those capabilities might read information, perform actions, or provide reusable context. You connect a particular client to a particular server; the details depend on their supported transport and authentication.
Collect the connection details
Use the server provider's documentation to find the endpoint or local installation instructions. Check who operates it, what data it accesses, and what permissions it requests. A URL from an unrelated post is not enough to establish any of those facts.
A remote server is reached over the network. A local server runs as a process in a supported environment. Follow the instructions for your client and server combination instead of mixing a local configuration example with a hosted endpoint.
The MCP remote-server guide explains the connection model. Client interfaces and supported features change, so keep the current client instructions open during setup.
Choose the matching setup path
For a local server, the client generally needs a command it can launch and the arguments that identify the server. The process must run in that client's supported environment. A command that succeeds in your terminal may still fail in a desktop client if it depends on a different executable path or working directory. Use explicit paths where the client documentation requires them.
For a remote server, collect its exact endpoint, supported connection method, and sign-in requirements. Confirm that it is reachable from the environment making the request. That environment may belong to a cloud-hosted client rather than the computer displaying the chat.
Record the setup information before changing anything: client surface, local command or remote URL, intended account, and first operation. If the client expects a remote URL, pasting a local launch command into that field will not create the local process.
Keep installation and data access separate in your notes. A running server establishes that the process started. Successful sign-in establishes another part of the connection. Reading the intended record is the final check that these pieces work together for your task.
Authenticate, then check identity
Use the service's sign-in flow. After connecting, ask the assistant to identify the account and workspace where the server provides an identity tool. Confirm the target before asking it to make changes.
For OBTO, the universal endpoint documented in the getting-started guide is https://app.obto.co/ms/mcp. Its identity tool can report the connected identity. App-scoped operations require an explicit application and domain.
Do not assume that seeing tools in the assistant establishes access to every application. Confirm the scope returned by the service and keep the initial task small.
Verify a read before a write
Ask for a known item whose expected answer you can inspect independently. Then try a missing item. The assistant should distinguish a successful read, an empty result, and an access failure.
For a later write test, use a reversible change to a test record and read it back. Record the exact destination and result. If a call times out, check the destination before retrying; the action may have completed even though the response did not arrive.
Connection troubleshooting should start with the failing layer: client configuration, network reachability, sign-in, permission, or the requested tool. Report the actual error instead of repeatedly changing settings. Once the read works, add the next capability your workflow needs.