MCP Server

The Mycorr MCP Server is a remote Model Context Protocol server that lets AI assistants — such as Claude — explore and query your Mycorr data in natural language. Once connected, an assistant can find the right Tables across your Models, inspect their schema, summarize columns, and run read-only SQL — all scoped to exactly the data you already have access to.

It turns Mycorr into an analytics backend for AI agents: instead of exporting data or writing glue code, you ask a question in plain language and the assistant discovers the relevant tables, understands their structure, and computes the answer against your live (or released) data.

The server is read-only. It can read and analyze your data, but it can never create, modify, or delete it.

What you can do with it

• Ask questions in plain language — "How many orders shipped last month?", "What's our total revenue by region?", "Which customer segment is growing fastest?" The assistant translates these into the right discovery and query calls.
• Explore data you forgot you had — search across every Model and Table you can access by topic, name, or description in a single step.
• Understand a table before querying it — schema, row counts, column statistics, and the joinable relationships (Links) between tables.
• Run analytical SQL — aggregations, window functions, CTEs, and joins across linked tables, with results returned as structured rows.
• Released tables stay consistent — when a Table has a release (a specific version your team has pinned and published), every read goes against that released version, not the live data that may still be changing. So when an assistant runs describe_table, summarize_column, or run_sql against a released table, the schema, row counts, and totals it reports are the published numbers — the same ones your team sees — even if the table has been edited since the release. Tables that have no release simply serve their current data.

Connecting

Endpoint

Authentication

The server supports two ways to authenticate:

1. OAuth 2.0 (recommended). When you add Mycorr as a connector in a client that supports OAuth — such as Claude — you're redirected to sign in to Mycorr and authorize access. No token is copied by hand, and access follows your account's existing permissions. This is the standard flow for the Claude connectors directory.
2. Personal Access Token (alternative). For desktop or CLI clients that connect with a static credential, send a Personal Access Token (PAT) as a bearer token in the Authorization header.

Either way, the assistant can only ever see the Models and Tables your account already has access to — sharing and permissions are enforced on every request. See Sharing and Permissions.

Connecting from Claude (OAuth)

Add Mycorr as a custom connector:

1. Open Settings → Connectors → Add custom connector.
2. Set the URL to https://space.mycorr.app/mcp.
3. Click Connect and sign in to Mycorr when prompted — Mycorr will ask you to authorize the connection, then return you to Claude.

That's it — there's no token to copy. You can revoke the connection at any time from Mycorr or from your Claude connector settings.

Connecting with a Personal Access Token

Clients that read an mcpServers configuration block (for example Claude Desktop or Claude Code) can connect with a Personal Access Token sent in the Authorization header:

{
  "mcpServers": {
    "mycorr": {
      "url": "https://space.mycorr.app/mcp",
      "headers": {
        "Authorization": "Bearer ${MYCORR_API_TOKEN}"
      }
    }
  }
}

Your token needs the Read scope.

⚠️ Treat your token like a password. Store it in an environment variable (MYCORR_API_TOKEN) rather than hard-coding it, never commit it to version control, and revoke it from the Access page if it's exposed.

Tools

The server exposes six read-only tools. A typical session moves from discovery (find the right table) to introspection (understand its shape) to execution (compute the answer).

search

The entry point for any question that mentions data by name or topic. Searches names and descriptions across every Model and Table you can access in one round trip, using fuzzy matching that tolerates typos and separator differences. Each hit carries a relevance score and the field that matched.

list_models

Enumerates every Model you own or can access, with each Model's id, name, description, and table count. Best for "show me everything I have." Takes no parameters.

list_tables

Lists every Table in a given Model — id, name, description, and current version.

describe_table

Returns a Table's full shape: name, description, current version, total row count, per-column schema (id, name, data type, nullability, and category labels for categorical columns), and the declared Links to other tables. The links array is the only valid source of join keys for run_sql.

Sample rows let the assistant see a few real rows alongside the schema — handy for spotting how columns are actually populated before writing a query. They're off by default (schema only); set include_sample_rows to true to include them.

summarize_column

Computes column-level statistics for a single column — always row count, null count, and null rate, plus type-specific extras:

• Numeric: min, max, sum, average, median, quartiles, and deciles.
• Categorical: each category's label, count, and percentage.
• Timestamp / date: earliest and latest values, plus monthly or yearly counts.
• String / boolean: most frequent values and how much of the column they cover.

run_sql

Runs a read-only SQL query against your Tables. See Querying with SQL below for the full contract.

Querying with SQL

run_sql uses the DataFusion SQL dialect and is strictly read-only — SELECT, WITH, UNION, INTERSECT, EXCEPT, recursive CTEs, and window functions are supported. Any statement that writes or changes state (INSERT, UPDATE, DELETE, DDL, COPY, SET, EXPLAIN) is rejected.

A few rules keep queries safe and correct:

• Reference tables and columns by id, not by name. Use the ids returned by describe_table (e.g. "tab-019e…", "col_xxx"), wrapped in double quotes so the hyphens are read literally.
• Joins are only allowed on declared Links. A join on any other column pair is rejected — use describe_table to discover valid join keys. Cross joins are not allowed.
• Soft-deleted rows are excluded automatically. You never see deleted rows, and there is no column to query them.
• Released tables read their pinned cut. Query results reflect the released version, which may be older than today's live data.

Limits per query: up to 100,000 result rows, 1 GiB of memory, and a 30-second timeout.

Recommended workflow

1. search (or list_tables) to find the relevant tables by name or topic.
2. describe_table to get column ids, types, and joinable links.
3. run_sql using those table and column ids.

Example prompts

These show the kind of natural-language requests the server is built to answer. The assistant chooses and chains the tools for you.

Discovery → summary

"Find anything related to billing in my Mycorr data and tell me the total amount invoiced this year."

The assistant calls search(["billing", "invoice"]), picks the matching table, and either summarize_column (for a single total) or run_sql (for a grouped total).

Schema-aware aggregation

"In my orders table, what's the average order value by region?"

The assistant calls describe_table to learn the column ids and types, then issues a run_sql GROUP BY query.

Cross-table join

"Which product categories drive the most revenue from our enterprise customers?"

No single table holds this answer, and you don't have to name the tables. The assistant uses search and describe_table to find the relevant tables on its own, discovers how they relate through declared Links, and writes a single query that joins along those links and aggregates revenue by category for enterprise customers.

Distribution check

"How is the status column distributed in my support tickets table?"

The assistant calls summarize_column and reports the category breakdown with percentages.

Limits, permissions & data handling

• Read-only. The server exposes no write operations of any kind. It cannot modify your Models, Tables, or data.
• Per-user access control. Every request is authorized against your account. You only ever see Models and Tables you have access to, exactly as defined by Sharing and Permissions. Tables shared with you read-only stay read-only here.
• Trashed items are hidden. Models and Tables in the trash are excluded from discovery; querying one by id returns a clear error.
• Rate limiting. Requests are rate-limited per connection. If you exceed the limit you'll receive a 429 response with a Retry-After hint; the assistant will back off and retry.
• Data handling. Queries run against your data within Mycorr's infrastructure and return only the results to the connected assistant. No data is shared with third parties beyond the AI client you explicitly connect. See the Privacy Policy.

Support

Questions or issues with the MCP server? Reach us at support@mycorr.app.