> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/analyze-with-ai/mcp-limits-and-usage-guidelines.md). # MCP limits and usage guidelines The Chord MCP server lets AI clients query your Chord data conversationally. This page covers what it's built for, what it isn't, and the limits that apply. To connect a client, see [MCP setup](/analyze-with-ai/mcp-setup.md). ## What the MCP server is for The MCP server is for interactive querying from AI clients like Ask Chord, Claude Desktop and other MCP-compatible tools. You ask a question in natural language, your client uses Chord's tools to answer it, and you get an answer back. It's designed for exploration and analysis in the moment: a person or an agent asks a question, gets a result and acts on it. Its tools for searching your schema, past queries and instructions, and for running SQL, are there to help a client reason its way to a good answer. They aren't a raw data feed. ## What it isn't for The MCP server isn't a data API or a warehouse connection. Don't use it to: * **Power live or production dashboards.** Don't connect its query tools to dashboard tiles that refresh on a timer. A single dashboard refresh can fan out into hundreds or thousands of tool calls. * **Continuously poll for data.** Firing repeated queries on a short loop to keep an external app in sync isn't supported. * **Bulk-copy the warehouse.** The MCP server isn't a way to copy your Chord data out at scale. These patterns create very high call volume, run into the rate limits below and drive up compute cost, with no benefit over the [patterns that work](#patterns-that-work). ## Rate limits MCP tool calls are rate-limited per account. The current limit is **60 tool calls per minute.** Calls above the limit are rejected until the next window. Chord may apply more limits over longer windows, and may adjust limits over time. Design your usage to stay well under the limit. If your client regularly hits it, it's usually being used as a polling API rather than an interactive assistant, and the patterns below will work better. ## Cost MCP queries run against Snowflake and use compute. Occasional interactive querying is inexpensive. Sustained, high-frequency querying, like the dashboard and polling patterns above, can get expensive quickly, because every call is real warehouse compute. A few efficient, scheduled queries cost a fraction of continuous per-tile polling. ## Patterns that work If you have a recurring data need, you can still use MCP well. The goal is fewer, well-formed queries instead of many small live ones. * **Pull on a schedule, not on every view.** Run one efficient query on a cadence that fits your needs, such as daily or hourly, and cache the result in your app. Don't query live on every tile or page load. * **Batch related questions.** Ask for what you need in as few calls as possible. * **Cache and reuse.** Store results your app reads repeatedly instead of querying again for the same data. Clients that stay comfortably within the limits follow this shape: a small number of efficient queries on a schedule, with results cached on their side. ## Need data in your own systems? If you need Chord data delivered into your own warehouse or application beyond what interactive MCP querying supports, reach out to your Chord contact. They'll point you to the right option for your setup. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.chord.co/analyze-with-ai/mcp-limits-and-usage-guidelines.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.