Using the MCP
Once you have connected a client, you can build and operate Monad pipelines by describing what you want in plain language. This guide covers what you can do through the MCP, how to ask for it well, and the habits that make the difference between a good session and a frustrating one.
If you have not connected a client yet, start with the MCP overview and pick your assistant from the setup guides there.
Start in a Sandbox Organization
The single most useful habit: authorize the MCP against an organization you are willing to break.
You choose which organizations a client can act on at authorization time, and that choice is stamped into the credential. Pick a dev or test team - one with nothing production-critical in it - and grant only that.
The difference this makes is that you can stop supervising. Let the assistant create, rewire and delete freely, try things that might not work, and iterate quickly, without a mistake reaching anything that matters. No amount of careful prompting buys the same confidence as simply not having production in scope.
When you are ready to work against production, revoke under Settings > Connected Applications and reconnect with that organization selected - or keep two clients authorized to different scopes and use the right one deliberately.
What It Can Do
| Discover | Browse available input, output, transform, enrichment and alert types, and inspect the exact configuration each requires — which fields are mandatory, which are secrets, what the allowed values are |
| Build | Create inputs, outputs, transforms and enrichments, then wire them into a pipeline as nodes and edges, including conditional routing |
| Operate | Check pipeline and node status, read metrics and logs, sample records flowing through a node, trigger runs |
| Alert | Create and manage alert rules, review triggered alerts |
Things You Can Ask
Getting oriented
List my pipelines and tell me which ones are disabled.
What inputs do I have configured, and which pipelines use them?
Show me the status of my Okta pipeline, including per-node health.
Building
Set up a pipeline that pulls Okta system logs and sends them to my S3 bucket.
What configuration does the CrowdStrike Falcon input need?
Add a transform to my Okta pipeline that drops events where the outcome is SUCCESS.
Understanding your data
Sample some records from the input node in my Okta pipeline so I can see the field names.
What fields are available on records coming out of that transform?
Sampling is the fastest way to learn a payload's real shape before you write a condition or a transform against it.
Operating
Why is my CrowdStrike pipeline showing errors? Check the logs.
Create an alert rule that fires when any pipeline's error rate goes above 5%.
How a Build Actually Goes
Asking for a pipeline kicks off a sequence, and it helps to know the shape so you can follow along:
- Discovery — the assistant looks up the connector types you named and reads their configuration schemas. It does not guess field names.
- Components first — inputs and outputs are created before the pipeline, because the pipeline references them by id.
- Placeholder secrets — for every credential the connector needs, it creates a secret with the value
REPLACE_ME. - The pipeline is wired disabled. Always.
- You fill in the secrets in the Monad UI under Settings → Secrets.
- Test — connection tests and a data sample confirm it works.
- Enable — only after the tests pass.
The pipeline arriving disabled is deliberate, not an oversight. Nothing starts moving data until you have supplied real credentials and confirmed the connection works.
Getting Good Results
Ask for the plan before the build. "Before creating anything, tell me what you're going to build." Cheaper to correct a plan than a half-built pipeline.
Name your organization if you have several. The assistant can act on the organizations you approved at authorization time, and it will otherwise have to ask or guess.
Let it look things up. If you are unsure of an exact connector name, describe it — "the Okta one that gets system logs" — rather than inventing an id. It searches the catalog; a guessed id becomes a failed create.
Ask it to sample before writing conditions. Routing rules and transforms are written against real field names. One sample removes an entire class of mistake.
Point it at credentials you already have. The assistant defaults to creating placeholder secrets, which you then have to fill in. If a credential already exists in Monad, say so - "use the existing Splunk HEC token" - and it will reference that secret instead. Ask it to list your secrets first if you are not sure what is there. On a destination you have already wired up once, this removes the fill-in-the-secrets step entirely.
Review before enabling. Ask "show me the pipeline you built" and read it. Enabling is the step that starts moving data.
Organizing Data in a Destination
A pattern worth knowing, because it is tedious by hand and quick through the MCP.
Most destinations partition data somehow - a Splunk index, an Elasticsearch index, an S3 prefix, a table name. Getting each source into its own partition normally means building near-identical pipelines and editing one field in each.
Ask for it directly:
Build a pipeline for each of my Okta, CrowdStrike and Duo inputs, all writing to the same Splunk output, and set the index on each one to match the source.
The assistant creates each pipeline and sets the index, prefix or table per pipeline as it goes. The same works retroactively:
For every pipeline writing to my S3 output, set the prefix to the name of its input.
That gives you data organized by type at the destination - queryable per source, with retention and access controls you can apply per index - without hand-editing every pipeline.
Credentials
The assistant will never ask you for a password, API key, or token, and you should never paste one into a chat.
When a connector needs a credential it creates a placeholder secret and tells you to set the real value yourself in the Monad UI under Settings → Secrets. Secret values are never sent to the assistant and never echoed back.
If an assistant ever asks you to paste a live credential, stop and set it in the UI instead.
Testing Without Real Credentials
Many inputs support synthetic data, which is useful for learning the shape of a pipeline before wiring up a real source. Ask for it directly:
Build me a test pipeline using synthetic data so I can see how routing works.
Enabled pipelines with synthetic data emit roughly one record per second, so there is always something to sample.
Worth Knowing
Deleting a pipeline does not delete its components. Inputs, outputs and transforms are reusable and survive on their own. If you want them gone, say so — and the assistant will confirm first, because the API refuses to delete anything still in use by a pipeline.
Only input and transform nodes can be sampled. Outputs are sinks with no readable stream, so "sample the S3 output" cannot work.
Most inputs need a schedule. A cron expression tells the input how often to poll. The assistant will ask if you have not said.
Changes are made against current state. The assistant fetches a resource before modifying it rather than working from memory, so your edits will not clobber a change made elsewhere.
When Something Goes Wrong
For connection and authorization problems — authorization failing, requests refused, missing organizations — see Troubleshooting on the MCP overview.
For pipeline problems, the assistant is usually the fastest route:
My pipeline stopped delivering. Check its status and recent logs and tell me what changed.