SAT score percentiles and class of 2026 SAT averages and participation by state (College Board).
Scored across 4 tools
The two inverse-mapping tools (get_sat_percentile vs get_score_for_sat_percentile) are the closest pair, but their descriptions clearly state the opposite input/output direction, and the state-level tools (single state vs ranking) are well delineated. An agent can reliably pick the right one.
Three tools use a get_ verb_noun pattern while rank_states_by_sat is a natural verb_noun deviation. The naming is mostly predictable; get_score_for_sat_percentile is slightly long but still readable and consistent in style.
Four tools fit a narrowly scoped percentile/state dataset well, with each tool covering a distinct axis (score→percentile, percentile→score, state lookup, ranking). The surface is lean but each tool earns its place.
The set covers bidirectional percentile lookup plus state-level statistics and ranking, which is the core of the stated domain. Minor gaps like listing available states or a raw percentile table lookup are workable around via the existing tools.
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.
get_sat_percentileget_sat_scores_by_stateget_score_for_sat_percentilerank_states_by_satOfficial College Board AP score distributions 2026, 2025, 2024: percentiles, pass rates.
Higher education data: tuition, graduation rates, and earnings
US federal 2026 tax brackets, standard deductions, payroll and retirement limits, sourced.
Broadband availability, providers, speeds, and BEAD classification from the FCC
Add one secure layer between your agents and this server.