Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sat-score-percentiles-mcp What percentile is a 1350 on the SAT?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SAT score percentiles and class of 2026 SAT averages by state for AI assistants, from College Board's percentile tables and the 2026 SAT Suite Annual Report.
This is a Model Context Protocol (MCP) server. It answers from bundled College Board data, so it needs no API key and no network calls.
Tool | What it returns |
| User group and nationally representative percentiles for any SAT total (400-1600) or section score (200-800), with the class of 2026 national mean and score band. |
| The lowest total or section score that reaches a target percentile, for example the 90th. |
| Class of 2026 SAT results for any state, DC, Puerto Rico or the US Virgin Islands: test takers, participation rate, mean total, Reading and Writing and Math, percent meeting benchmarks, 25th/50th/75th percentile scores and rank. |
| States and DC ranked by mean score, participation rate, benchmark rate or test takers, with an optional minimum participation filter. |
Every result has structured JSON, a one-paragraph summary, as_of, source (the College Board page or PDF) and more (a page on examscorecalc.com).
Related MCP server: U.S. Census Bureau Data API MCP
Class of 2026 SAT results, published by College Board in fall 2026: 1,954,833 test takers nationally with a mean total of 1045 (528 Reading and Writing, 517 Math), and the same figures for every state.
Each state's participation rate, which explains most of the gap between state averages. States that test every 11th grader have lower means than states where only college-bound students test.
The 25th, 50th and 75th percentile SAT scores for each state's class of 2026.
The exact College Board percentile for every 10-point score, in both reference groups, instead of a rounded guess.
Paste this URL. No token, no sign-up.
https://sat-score-percentiles-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http sat-percentiles https://sat-score-percentiles-mcp.lipmichal.workers.dev/mcpOr run it locally over stdio:
claude mcp add sat-percentiles -- npx -y github:theluckystrike/sat-score-percentiles-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"sat-percentiles": { "command": "npx", "args": ["-y", "github:theluckystrike/sat-score-percentiles-mcp"] }
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"sat-percentiles": { "url": "https://sat-score-percentiles-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json:
{
"servers": {
"sat-percentiles": { "type": "http", "url": "https://sat-score-percentiles-mcp.lipmichal.workers.dev/mcp" }
}
}Node 20 or newer is needed for the local stdio version.
"What percentile is a 1350 on the SAT?"
"What SAT Math score do I need for the 90th percentile?"
"What was the average SAT score in Texas for the class of 2026, and how many students took it?"
"Which states had the highest SAT averages in 2026 among states where at least half of students took the test?"
"Is a 1200 a good SAT score in Ohio?"
Full list with fetch dates and file hashes in DATA_SOURCES.md.
Percentiles: College Board, SAT Nationally Representative and User Percentiles.
Class of 2026 results: College Board, 2026 SAT Suite of Assessments Annual Report, total group report and the state supplements.
The percentile page does not print a year. User group percentiles cover SAT takers from the past three graduating classes, as College Board states on that page.
State means depend on who tests. Compare states with similar participation rates, or use min_participation_pct.
Puerto Rico and the US Virgin Islands reports have no participation rate, so they are not ranked.
The Ohio supplement was not linked from the report index on 2026-11-03; it was fetched from the same College Board path pattern and parsed like the others.
Data are fixed at the 2026 reports. When College Board publishes the class of 2027 report, the data file is rebuilt with scripts/build_data.py.
Digital SAT score calculators and practice score conversions are on examscorecalc.com.
Part of the Zovo MCP collection: https://mcp.zovo.one
npm install
npm test # builds, then runs fixtures copied by hand from the College Board sources
node scripts/smoke-stdio.mjs # stdio check, one call per tool
npx wrangler deploy # Cloudflare Worker, Streamable HTTP at /mcpMIT
Percentile rank of a digital SAT total score (400-1600) or section score (200-800, Reading and Writing or Math), from the College Board percentile tables: the user group percentile (actual SAT takers, past three graduating classes) and the nationally representative percentile (all US 11th and 12th graders). Also compares the score with the class of 2026 national mean (1,954,833 test takers) and score band.
| Name | Required | Description | Default |
|---|---|---|---|
| score | Yes | SAT score in steps of 10, for example 1350 for a total or 680 for a section. | |
| section | No | total (400-1600), rw (Reading and Writing, 200-800) or math (200-800). Default total. | total |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond annotations by naming the source tables, distinguishing the two percentile definitions, and noting the class of 2026 mean and score-band comparison, though it does not describe the response shape or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then supplies relevant percentile-table context. It is dense but not redundant; the exact test-taker count is extra detail, but it supports the national comparison context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with full schema coverage and rich annotations, the description is nearly complete: it explains the two percentile types and the mean/band comparison. It does not spell out the response structure or routing alternatives, but no output schema is provided and the core behavior is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including ranges, enum values, default, and step-of-10 guidance. The description restates the score ranges and section categories but adds little semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: computing the percentile rank of a digital SAT total or section score, and identifies the College Board percentile tables and comparison outputs. It does not explicitly differentiate this tool from the inverse sibling get_score_for_sat_percentile or the state-based siblings, so it is clear but not fully sibling-routed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting a known SAT score into percentiles, but gives no explicit when-to-use/when-not guidance or alternative-tool routing. It does not mention using get_score_for_sat_percentile for the inverse lookup, so an agent must infer which sibling to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Class of 2026 SAT results for one state, DC, Puerto Rico or the US Virgin Islands from the College Board 2026 SAT Suite Annual Report state supplement: test takers, participation rate, mean total, Reading and Writing and Math scores, percent meeting college readiness benchmarks, 25th/50th/75th percentile scores, rank by mean, and the national comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter code (TX) or full name (Texas). DC, PR and VI also work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact data vintage ('Class of 2026') and source ('College Board 2026 SAT Suite Annual Report state supplement'), which tells the agent this is authoritative, static published data rather than live data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the resource and vintage before listing metrics; every clause carries content. It is slightly long and reads as a field dump, but nothing is wasted or repeated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned metrics (participation rate, mean total, section scores, benchmark percentages, percentiles, rank, national comparison). For a single-parameter read tool this is nearly sufficient; only the response shape (scalar vs object) is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains that two-letter codes, full names, DC, PR and VI are accepted. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Class of 2026 SAT results for one state') and enumerates the exact metrics returned, so the agent knows precisely what data comes back. It does not, however, differentiate itself from siblings like rank_states_by_sat or get_sat_percentile, even though it lists 'rank by mean' as a returned field, which could confuse selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one state, DC, Puerto Rico or the US Virgin Islands' implies single-geography lookups and implicitly contrasts with the multi-state rank_states_by_sat tool, but no explicit when-to-use or when-not-to-use guidance or alternative routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The lowest SAT total or section score whose College Board percentile is at or above a target (for example the 75th or 90th percentile), for the user group (SAT takers) or the nationally representative group.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | user_group (actual SAT takers, default) or nationally_representative (all US 11th and 12th graders). | user_group |
| section | No | total (400-1600), rw (Reading and Writing, 200-800) or math (200-800). Default total. | total |
| percentile | Yes | Target percentile, 1 to 99, for example 90. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so the safety profile is covered. The description adds genuine semantics beyond that: it resolves the rounding/tie-breaking rule by specifying the LOWEST score at or above the percentile, which is the key ambiguity for this kind of lookup. It does not say anything about response shape, but no output schema exists and the answer is a single value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that defines the computation first and qualifies the population second; no filler. It is dense and slightly run-on with its parenthetical example, but every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only three fully documented parameters, rich annotations, and no output schema, the description covers what is needed to call the tool. However, it omits the direction-vs-alternative framing that would help an agent choose between this and get_sat_percentile, leaving a gap for a three-sibling family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with enum values and defaults documented for group and section, so the schema carries the parameter burden. The description restates the group distinction (SAT takers vs. nationally representative) without adding format, edge-case, or interaction detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (SAT total or section score) and the exact relation computed: the lowest score whose College Board percentile is at or above the target. The inverse direction relative to a percentile lookup is clear from 'lowest ... score whose percentile is at or above', which implicitly separates it from get_sat_percentile, but that sibling is never named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the worked examples ('for example the 75th or 90th percentile'), which show the intended kind of query. There is no explicit when-to-use statement, no mention of when to prefer get_sat_percentile instead, and no note on what happens at boundary percentiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank the 50 states and DC by class of 2026 SAT mean total, mean Math, mean Reading and Writing, participation rate, percent meeting both benchmarks, or number of test takers. Use min_participation_pct (for example 50) to compare only states where most students take the SAT, since low-participation states have higher means.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many states to return, 1 to 51. Default 10. | |
| order | No | desc = highest first (default), asc = lowest first. | desc |
| metric | No | What to rank by. Default mean_total. | mean_total |
| min_participation_pct | No | Only include states with at least this participation rate, for example 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds genuine methodological context beyond annotations: that low-participation states show higher means, which explains the filtering parameter's purpose and warns against naive interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the ranking scope and metric list, followed by the one caveat that matters. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, zero-required, read-only tool with full schema coverage, the description covers purpose, metrics, and the key filtering caveat. It never says what a result row contains (state plus metric value) and there is no output schema, leaving a small gap on return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the statistical rationale for min_participation_pct rather than just restating its bounds, which is the one parameter whose semantics are non-obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (rank), resource (50 states and DC), and enumerates the exact metrics available: mean total, Math, Reading and Writing, participation rate, benchmark attainment, test takers. The ranking framing inherently separates it from get_sat_scores_by_state, which retrieves rather than orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete conditional guidance for min_participation_pct with a worked example (50) and the reason to use it. It does not name the sibling tools or say when to prefer get_sat_scores_by_state over this one, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_sat_percentileget_sat_scores_by_stateget_score_for_sat_percentilerank_states_by_satScored across 4 tools
The four tools target distinct operations: score→percentile, percentile→score, state lookup, and state ranking. The only risk is the near-mirror pair get_sat_percentile vs get_score_for_sat_percentile, which are inverse functions with very similar names; the descriptions disambiguate direction, but an agent could still pick the wrong one at a glance.
All names are snake_case with verb-first phrasing (get_*, rank_*), which is consistent and readable. The minor deviation is that the two inverse tools use asymmetric, easily-confused constructions rather than a clean pattern like percentile_for_score / score_for_percentile.
Four tightly scoped tools map exactly onto the domain's two axes (score↔percentile conversion and state-level data/ranking). Each tool earns its place with no redundancy or filler.
Both directions of percentile lookup plus state detail and cross-state ranking give solid coverage. Minor gaps remain: no tool to compare two scores or list available states/metrics, and no national-aggregate lookup beyond what's embedded in the state comparison.
SEC filings, Wikipedia, arXiv, US Census and more for AI agents, with every answer source-linked.
California school data for AI agents — scores, comparisons, feeder paths, TK ages, applications.
Machine-readable utilities and datasets for AI agents.
Live SEO intelligence, rank tracking, site audits, and backlink analysis for AI agents.
