A local model can write an answer, but it needs a connection to read current information from your apps. OGAD (Off Grid AI Desktop) supports MCP, a standard that lets a server expose app tools to the assistant. You can connect a supported service or a local server, then ask the model to use its available tools.
| Get OGAD | Desktop releases |
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
Basic custom MCP connections are in the core app. Some built-in integrations need Pro or additional provider setup. An integration marked Not enabled yet is not a working connection to try.
What do you need?
Use a local text model that works with tool calls, plus a working MCP server for the app you want. Get its connection details from that server’s documentation. A service login page or normal API address is not necessarily an MCP endpoint.
A local server must already be installed with its required runtime. A remote server needs its network connection and authentication. MCP does not make a cloud service offline.
Add a custom connection
- Open Integrations and select Custom.
- Enter a Name that identifies the service.
- For a remote endpoint, choose HTTP / SSE and enter the documented MCP URL. For an installed local server, choose stdio (local) and enter its command and arguments.
- Select Add, then open the connection and select Test. Complete authorization if requested.
- Check that the connection is on. In chat options, enable Tools and Connectors.
- Ask for one small read operation that the server supports, such as listing a few documents in a test folder.
Use the server’s documented command. The local command field starts a program on your computer; do not paste an unfamiliar install command merely because a page calls it an MCP setup.
Check the first answer against the app
Name the service and the exact object you want in the request. For example: “Use my connected notes service to find the note titled Test checklist and summarize its first three items. Do not change it.”
Open the source note and compare the answer. This checks both the selected connection and the model’s use of the returned data. Do not assume that a successful connection test proves every tool works with your account.
If a tool is missing, check what the server actually exposes. If authorization fails, reconnect with the required account and permissions. If the model answers without calling the service, check the chat’s Tools and Connectors controls.
Choose the connection that matches the job
MCP is useful when the assistant needs current information from an app, not just text you paste into chat. A notes server might expose a search tool. A project system might expose an issue lookup. The server determines which operations exist; OGAD cannot invent a missing app capability.
For a first connection, choose one task with an answer you can check. Finding a known note is easier to verify than asking for a summary of an entire organization.
| Your situation | Connection to look for |
|---|---|
| You already run a local MCP program | Its documented stdio command and arguments |
| Your service provides an MCP endpoint | Its documented HTTP connection and authorization |
| You only have an ordinary REST API URL | A supported MCP server or adapter is still needed |
| The app card says Not enabled yet | Use an actually available connection instead |
A local server process is not automatically an offline service. It may act as a bridge to an online account. Review the server’s documented behavior when deciding which data to use in the first test.
Make the first request easy to verify
Create or choose a harmless test record in the source app. Give it a distinctive title and two or three facts you already know. Ask the assistant to find that exact record through the named connection and report those facts without changing it.
Compare the response with the source. Check that the model used a tool rather than producing a plausible answer from general knowledge. If it found the wrong object, narrow the name or folder before broadening the task.
Next, try a useful read request in the same scope: find the latest note for a project, retrieve one issue, or summarize one document. Use only operations that the server actually exposes and your account can access.
A successful connection is only the first check
The connection test can show that OGAD reached the server. A later request can still fail because the tool needs a different permission, an item moved, or the account cannot read it.
Read the tool error before changing the model. A missing object, expired authorization, and unavailable server need different fixes. If the server has no suitable tool, a more forceful prompt will not create one.
For a server that offers changes as well as reads, say whether you want wording in chat or a real edit. Some tools can write immediately when called. Keep the first useful workflow small enough that you can inspect its result in the source app.
Where does the data go?
A local model processes the tool results on your computer. The connected server still receives tool requests and can access data according to its permissions. A local server may itself contact a cloud service. Check that server’s behavior before calling the workflow fully offline.
Some connector tools can change data directly from a chat request. Start with a read-only task and be explicit about whether you want a draft or an actual change.
Try OGAD with one trusted MCP server and one test record. Confirm the source result before you use the connection for a larger workflow.