MCP performance and rate limits

Loomi Connect MCP applies rate limits and caches responses to protect service stability. This page covers performance considerations, how limits and cache behave, and what your client should do.

Performance

• Dashboard-level APIs: Tools call the same APIs that power the Bloomreach UI, not dedicated backend endpoints. Responses can be slower or less consistent than a production API.

• Analytics latency: Ad-hoc analytics computations can take 10 to 30 seconds on large datasets.

• Cross-project calls: Cross-project overview tools make one API call per project and can be slow on organizations with many projects.

• Large-project list calls: search_scenarios and search_banners allow up to 50 seconds for the upstream request to complete (up from 10), so listing on large projects no longer times out.

• Organization listing: A brief upstream delay no longer interrupts a listing call. If a listing still can't complete, you get a clear prompt to retry instead of a failed call.

Rate limits

Rate limits prevent burst traffic from overwhelming downstream systems.

A single request can be subject to multiple limits. All applicable limits must pass before the tool runs.

If a request exceeds a limit, the MCP returns an error with retry guidance. Back off and retry once the suggested wait time has passed.

Downstream project APIs impose their own limits as well. Handle throttling errors even after a request passes MCP-level checks.

Default limits

Every read tool falls under one of two default ceilings, and both are counted per user:

• Marketing and Data hub reads: 3 calls per second and 60 calls per minute.

• Search reads: 3 calls per second and 120 calls per minute.

The two ceilings are separate buckets. A Search call doesn't count against your Marketing and Data hub budget, and the reverse holds too.

Extra limits on top of the default

Some tools carry a second, stricter limit alongside the default ceiling. The stricter of the two sets your effective pace for those tools.

Each limit below shows its internal name in parentheses. That name appears in the rate limit error message, so you can match an error to the limit that triggered it.

Read customer data (PII)

Tools that read customer profiles, events, or schemas allow 1 call per second and 30 calls per minute.

Examples include list_customers, get_customer_properties, list_customer_events, list_customers_in_segment, get_customer_schema, get_customer_property_schema, search_customer_filters, and get_customer_prediction_score.

Run analytics and reports (IMF)

Analytics and reporting tools that trigger heavy computation allow 1 call per 3 seconds and 20 calls per minute. Both execute_analytics_eql and calculate_report fall under this limit.

This budget is shared across all users on the same Marketing instance rather than counted per user. One person running analytics in a tight loop can rate limit everyone else on that instance. Space out analytics calls, and read a rate limit error here as a sign that the instance is busy rather than a problem with your own pace.

List organizations, workspaces, and projects (BOOTSTRAP)

Navigation tools that list or summarize your account structure allow 1 call per second and 30 calls per minute. This covers list_cloud_organizations, list_workspaces, list_projects, list_projects_with_overview, get_cloud_organization_details, and get_project_overview.

All other read tools use only the default ceiling for their product area.

Write tool limits

Write tools carry a stricter limit on top of the default ceiling, because a mutation is harder to undo than a read. A write tool allows 1 call per 5 seconds and 10 calls per minute, and the default ceiling for its product area still applies. Space out consecutive writes rather than issuing them in a tight loop.

This applies to Data hub write tools alongside the Marketing and Search write tools. The Data hub write tools that create and update an item collection are documented in Item collections tools, and the tool that applies a configuration change list is documented in Item collection configuration tools.

Deletes are limited more tightly: 1 call per 10 seconds and 10 calls per minute. Deleting an item collection falls under that limit.

Submit feedback (FEEDBACK)

The submit_llm_feedback tool, which your client uses to report a capability gap, allows 1 call per 10 seconds and 20 calls per hour.

This is the one limit that doesn't stack. No default ceiling applies, so a feedback submission never spends your read budget.

Handle rate limit errors

Apply retry and backoff logic in your client. Exponential backoff is a common pattern.

Caching

Loomi Connect MCP caches responses to reduce load on the Marketing API and improve latency. Expect some reads to come from cache. If your workflow depends on near-real-time data, account for a short delay between when a change is written and when it becomes visible in MCP reads.

Cache lifetimes

Cache lifetimes vary by resource type:

• Resources that change frequently are cached for only a few seconds.

• More stable metadata caches for longer.