Before you start to use our MCP, please review the following items:
Ensure you have completed the iPaaS.com platform training before using this to best understand what is going on. If you need to gain access to it reach out to partnerships@ipaas.com.
With great power comes great responsibility - the MCP can do things like trigger a sync for your entire catalog and modify (or remove) data from your account. Ensure you understand what you want it to do before you work with it. iPaaS.com is not responsible for restoring any data or configuration changes made using the MCP.
Measure twice, cut once: When working with this, planning ahead of time (or asking the MCP to plan for you) will greatly benefit your work.
Remember that this is in beta so some features may be added, removed or altered as we continue our development. The latest change log notes can be found here.
If you have any issues or need to report a bug please reach out to us at mcp@ipaas.com.
This is the article to read before you let the assistant change anything. It explains how changes are previewed and confirmed, which actions send data to other systems, what your API key allows, and the limits you will run into.
Every change starts as a preview
Any tool that creates, updates or deletes something works in two steps:
Preview (also called a dry run). The tool shows exactly what it would send and changes nothing. It also checks the request, so problems are reported before anything is written.
Confirm. Only after you've agreed does the assistant run the tool again with confirmation switched on.
A few details are worth knowing:
Updates replace the whole record. The iPaaS.com API replaces a record rather than patching it, so an update sends every field. The tool fetches the current record and merges your change in, and the preview lists any value that would be cleared because the update doesn't carry it. Read that list before you confirm.
Unknown fields are silently ignored by the API. A field name the platform doesn't recognise doesn't produce an error. It just has no effect. The preview flags this, so check it.
Most deletes can be undone. Deleting a record is normally a soft delete, and the matching reactivate tool brings it back. Some deletes are permanent. For example, deleting a Message can't be reversed, so it needs a second, separate acknowledgment before it will run.
External IDs are never created without your say-so. An external ID links an iPaaS.com record to its counterpart in a connected system, so a wrong one can send changes to the wrong record. Tools that create or change them stay off until you explicitly confirm. However, syncing a piece of data through an integration will carry the external ID as built.
NOTE: A preview protects you only if you read it. If the assistant tells you a change is small, check that the preview agrees.
Actions that move data or settings
These deserve extra care because they reach beyond a single record or send data to another system. Each one names what it will act on and waits for your confirmation.
Action | What it does | Worth knowing |
resync_record | Sends one record between iPaaS.com and a connected system | Confirm the exact record and the direction. The preview checks that the connected system supports that data type and direction. |
resync_batch | Does the same for a list of records | Up to 25 records per call. A larger backfill has to be split and run in batches of 25, which is deliberate. Review the exact list in the preview. It is blocked outright if the data type or direction isn't supported. |
enable_webhook | Starts sending a scope's changes to a destination system | Enabling creates the webhook. The tool refuses to create a second one for the same scope and destination, because a duplicate makes the record fire twice. |
disable_webhook | Stops sending a scope's changes to a destination | Disabling deletes the webhook. It can't be reactivated, and enabling again creates a new one with a new ID. |
Mapping and translation tools | Create, change, clone or delete mapping and translation collections | These change configuration, not your records, but they change how every later record syncs. Ask the assistant to review the collection first and explain the effect. |
run_poll_event_now | Forces a poll to run soon | It does this by rewriting the poll schedule to run once, about two minutes from now. It gives you the call that restores the original schedule. |
dismiss_errors | Clears errors from the queue, or moves them to another status | Dismissing doesn't fix or retry anything. Up to 25 at a time. |
preview_formula and run_live_diagnostic | Run a formula or a transfer check against one real record | They use a real record from your account. Confirm which one before they run. |
Before you resync
Firing a sync isn't the same as the record arriving. Syncs run in the background. After a resync, ask the assistant to check whether the record landed (the check_records_landed tool). A record has arrived when it has an external ID linked in the destination, not just because a run says "Complete".
A successful run can mean nothing was sent. If a mapping collection's filter excludes the record, the run finishes without sending it.
Manual resyncs ignore whether the webhook is enabled. A record you resync by hand is sent even if its webhook is disabled. Be sure you want it to go.
Start with one record. Check the result, then widen.
For more information, see the failed sync guide.
Permissions: your key decides
The MCP server can only do what your API key allows. For the full list of permissions, see Getting Started. The points that matter for safety:
Give the key as little as it needs. A key with View only can read but never change anything, whatever the assistant is asked to do. Add Create, Edit or Delete only for the work that needs them.
Consider two keys: a read-only key for everyday questions, and a second key with change permissions that you use only for planned work.
Keys can't be edited. To change a key's permissions, create a new one and update your connection.
Check what a key can do by asking the assistant to run check_my_permissions.
On Team and Enterprise Claude plans, everyone using a shared connector uses the same key. Give it only what all of them should be allowed to do.
Protect the key. Never paste it into a conversation, a shared file or a repository.
One key, one company
A key belongs to exactly one iPaaS.com company, and a connection can't switch companies. To work in another company, connect with that company's key. Before any change, ask the assistant to run get_active_tenant and check that it names the company you intend. Every change log records the company it was made in.
Limits and known behaviours
Rate limit. Each API key can make about 110 requests per minute. Beyond that, calls are rejected with a "too many requests" (429) response and a request to wait 60 seconds. The limit is approximate, and every record in a batch counts as a request.
Current state, not history. The tools show what your data looks like now. The reports don't show how it changed over time. Some reports, such as those over transactions, can't filter by date. Each report states its own limits in its answer.
Fields must already exist. The assistant can only use fields that are defined in your integration. If one you need is missing, that's a gap in the integration rather than a fault, and the integration needs it added. Contact support@ipaas.com. Custom fields are the exception, because the assistant can create them.
Active records by default. Searches leave out soft-deleted records unless you ask for them.
It can't connect a new system for you. Setting up a connected system needs that system's own credentials, which shouldn't pass through a chat. The assistant points you to the connector's installation guide instead.
Partial failures are possible. The platform has no way to undo a half-finished batch, so a batch that fails partway reports which records succeeded and which didn't.
Assistants can be wrong. They can misread a result or choose the wrong tool. Treat their answers as a starting point, and verify anything you will act on.
Your data and what is logged
Your key is never stored by the MCP server. The server holds no credentials of its own. Your key travels in a request header over an encrypted (HTTPS) connection and isn't written to logs.
What iPaaS.com records. One entry per tool call: the tool name, whether it succeeded, how long it took, the platform's response status, a one-way hash that identifies your company without naming it, plus the session, environment, version and domain. We don't record what you asked for or the records returned.
Your AI provider sees the results. What a tool returns becomes part of your conversation with the assistant, so it is handled under that provider's terms and your organization's own data policies. Choose your assistant and tool scope with that in mind.
Before you confirm a change
Check the company. Ask for get_active_tenant.
Plan first. Ask the assistant to describe what it intends to do and why.
Read the preview. Look at the target, the values that would change, and any value that would be cleared.
Start small. Use one record or one collection before a batch.
Confirm.
Verify. Check the change log, and for syncs, check that the record landed.
If something goes wrong
The change log records the values before and after each change, so you can see what to put back.
A soft-deleted record can be brought back with its reactivate tool.
Remember that iPaaS.com isn't responsible for restoring data or configuration changed through the MCP, as noted at the top of this article. Prevention (read-only keys, previews and starting small) is your main protection.
Report bugs to mcp@ipaas.com. For help with the platform itself, contact support@ipaas.com.