MCP Server Usage Guidelines

using the chord mcp server the chord mcp server lets ai clients query your chord data conversationally this page covers what it is built for, what it is not, and the limits that apply so you can use it well what the mcp server is for the mcp server is for interactive, agentic querying from ai clients like ask chord, claude desktop, and other mcp compatible tools you ask a question in natural language, your client uses the chord tools to answer it, and you get an answer back it is designed for exploration and analysis in the moment a person or an agent asks a question, gets a result, and acts on it the tools it exposes ( search schema , search sql pairs , search instructions , and execute sql ) are there to help a client reason its way to a good answer, not to serve as a raw data feed what it is not for the mcp server is not a data api and not a warehouse connection please avoid using it to power live or production dashboards do not wire execute sql 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 is not a supported pattern bulk replicate the warehouse the mcp server is not a mechanism for copying your chord data out at scale these patterns generate very high call volume, run into the rate limits below, and drive up compute cost with no benefit over the supported patterns further down this page 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 additional limits over longer windows and may adjust these limits over time design your usage to stay well under the ceiling if your client is regularly hitting the limit, that is usually a sign it is being used as a polling api rather than as an interactive assistant, and the patterns below will serve you better cost awareness mcp queries run against snowflake and consume 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, for example daily or hourly, and cache the result in your app do not query live on every tile or page load batch related questions ask for what you need in as few calls as possible rather than many small ones cache and reuse store results your app reads repeatedly instead of re querying for the same data clients that stay comfortably within the limits tend to follow exactly 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 so we can point you to the right path for your setup