Skip to content

How to connect your first tool

· 4 min read · ByModuleX Team

Most integration guides start by asking you to plan your stack. This one starts by suggesting you don't.

ModuleX does not require you to configure integrations before you can do anything. You ask for the work you want, and if the assistant needs access to a service it does not have, it stops and asks for it. Connection is something that happens during your first real task, not before it.

That changes the useful question from "what should we connect?" to "what should we ask for first?"

Step 1 — Ask for something you actually do

Pick a real recurring task, not a demo. The best first request is one you did manually this week and will do again next week.

Good first asks look like: catch me up on what I missed in the launch channel, what changed in the repo overnight, sort my inbox into things that need a reply and things that don't.

Bad first asks are the ambitious ones — anything spanning four tools and a judgement call. Not because the assistant cannot chain tools, but because a first task that touches one service teaches you the flow without confounding it.

Step 2 — Let the assistant tell you what it needs

This is the part that differs from most platforms. The assistant raises a request for a credential when it hits a service it cannot reach, naming the integration it wants. You are not guessing which connector a task requires; the task tells you.

It is one of a small set of things the assistant can stop and ask you for — a choice, a yes or no, some text, or access to a service. The same pause mechanism that asks for a credential is the one that asks for approval before it acts.

Practically: you make the request, the assistant works until it needs the service, and you connect it at that moment with your own credentials.

Step 3 — Choose the first tool for reach, not ambition

If you would rather choose deliberately than let the first task decide, the rule that holds up is: connect the tool you most often open to look something up.

  • Slack — if your team's context lives in channels, this single connection turns "what happened while I was out" into an answer. → Slack · catch up on a busy channel
  • Notion — if your plans and docs live here, connecting it gives the assistant both a source to read and somewhere to put results. → Notion
  • GitHub — if you are technical, the overnight-changes question is the highest-frequency one you have. → GitHub · daily repo brief
  • Gmail — worth a specific note. Its integration is narrow: it sends messages and lists labels. It is a strong destination and not a way to have your mail read. → Gmail

That Gmail caveat generalises. Before assuming a tool can do something, check what its integration actually exposes — the action set is defined per integration, and it ranges from a handful to over fifty.

Step 4 — Notice what the second task costs

The real test is the second request, not the first.

If the first task connected Slack, the second one — say, taking what you caught up on and filing it somewhere — needs one more connection and reuses the first. The cost of each additional task falls as the connected set grows, because most work is a join between two tools you have already connected.

This is why "connect one and see" beats a planning exercise. After three real tasks you will have connected exactly the tools your work actually crosses, and you will not have spent an afternoon wiring up services nobody asked about.

What to do when it fails

Connections fail — an expired token, a denied OAuth prompt, a closed popup. When that happens the failure is passed back as a structured result rather than being quietly accepted, so the assistant can tell you what went wrong and retry, instead of proceeding as though it has access it does not have.

That distinction matters more than it sounds. A silent credential failure is how automations end up appearing to work while doing nothing — and it happens in production. Dan Musetoiu of Romania's Agency for Financing Rural Investments has described a live assistant in which one unset configuration parameter silently truncated every over-long prompt for weeks, cutting the behavioural rules out of the request with no error raised, while the symptoms were attributed to the model being weak rather than to a setting nobody had set. That is one documented incident rather than a measured frequency, but it is the exact shape of the failure: nothing broke loudly.

Where to go next

Once one tool is connected and one task is done, the useful next step is browsing what other teams chain together — the use-case library is organised by task rather than by tool, and every recipe lists the integrations it needs. Or start from your stack in the integrations directory, which carries 175+ tools.

Questions, answered. The ones support teams ask most.

  • No. The assistant asks for a service when it needs one, mid-task, rather than requiring you to set up integrations in advance. Connecting the one tool your first real question touches is enough to begin.

References

Research

  1. 1.D. Musetoiu, "RAGAL: A Frugal, Fully Local Retrieval-Augmented Assistant for Technical Support at a Government Agency", arXiv:2607.18756v1 [preprint], July 2026. https://arxiv.org/abs/2607.18756v1

On ModuleX

Put these integrations to work.

Connect each tool once with your own credentials, then run its actions from a plain-English request. No workflow to build.

Last updated: Jul 2026More ModuleX guides