What can you do with this server?

This server lets you query UK higher-education open data — including student satisfaction, outcomes, and graduate earnings — with every figure paired with its appropriate benchmark. * search_providers: Look up any UK higher-education provider by name, nickname, or fragment (e.g. "UCL", "Manchester Met") to get their official name and UKPRN identifier used by all other tools. * nss_scores: Retrieve National Student Survey positivity scores for a provider, filterable by subject, question/theme, population, mode, and level of study — paired with the OfS benchmark and UK sector average. * compare_providers: Compare NSS results across two or more providers side-by-side, each judged against their own benchmark, with similar filtering options. * b3_outcomes: Access OfS B3 continuation, completion, and progression rates with benchmarks and regulatory thresholds, filterable by subject or demographic splits (sex, ethnicity, age, disability, deprivation quintile). * leo_earnings: Retrieve lower-quartile, median, and upper-quartile graduate earnings at 1, 3, and 5 years post-graduation by subject, with UK-wide figures for context. * run_sql: Execute read-only SQL SELECT queries directly against the underlying DuckDB database (capped at 100 rows) for custom exploration. * data://dictionary resource: Descriptions of every table, its granularity, and what is deliberately absent from the dataset. * Guided prompts: Built-in MCP prompts (provider_health_check and subject_shortlist) that walk through the tools in the correct order with statistical conventions applied.

How do I use uk-he-data-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@uk-he-data-mcp NSS scores for Law at Birmingham" 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.

uk-he-data-mcp

by wilgreeves-cmd

Overview Schema Source Related Servers Discussions Admin

Python

Local

uk-he-data-mcp

An MCP server that lets Claude (or any MCP client) query UK higher-education open data: National Student Survey satisfaction, OfS student outcomes (continuation, completion, progression) and LEO graduate earnings, every figure paired with the benchmark the regulator intends it to be read against.

Status: built in public, moving fast. All three data sources are queryable; the interface may still change before the first tagged release.

Why

UK HE publishes a lot of good open data, and almost nobody can use it in conversation. The files are large, split across regulators, keyed on codes (UKPRN, CAH) that mean nothing to most people, and full of statistical conventions that are easy to get wrong — quoting an NSS score without its benchmark is the classic one. This server puts that data behind a small set of tools that carry those conventions with them, so an AI assistant can answer carefully instead of confidently.

Related MCP server: mcp-geo

Install

# one-off: build the local database (downloads open data from the OfS and DfE)
uvx --from git+https://github.com/wilgreeves-cmd/uk-he-data-mcp uk-he-data-mcp build

# then add the server to Claude Code
claude mcp add uk-he-data -- uvx --from git+https://github.com/wilgreeves-cmd/uk-he-data-mcp uk-he-data-mcp

(PyPI release is coming, which shortens both commands to plain uvx uk-he-data-mcp.)

The build downloads open data straight from the Office for Students and loads it into a DuckDB file on your machine — no keys, no accounts. Queries run locally; tool results then enter your AI assistant's conversation context like anything else you discuss with it.

Try asking

"How satisfied are Law students at Birmingham, and is that good for a university with their intake?" — uses the OfS benchmark, so the answer compares like with like.
"Compare Sheffield and Sheffield Hallam for Computing" — side by side, each judged against its own benchmark rather than raw score vs raw score.
"Do mature students complete their degrees at Birmingham?" — B3 outcomes split by age on commencement, against the OfS regulatory threshold.
"What do Law graduates actually earn five years on?" — LEO quartiles, with the caveats stated: pre-tax, employment-matched, and emphatically not causal.
"Show me assessment-and-feedback scores for nursing at a small provider" — often returns nothing, and says why: cuts under 10 respondents are suppressed by the OfS, which is an answer, not an error.
"Which university gets the most applications for Computer Science?" — the server tells you this isn't answerable from open data (UCAS publishes no bulk application volumes) rather than guessing from satisfaction scores.

That last behaviour is deliberate. Each tool description states what the data cannot answer, so the model declines honestly instead of inferring.

Tools

Tool	What it does
`search_providers`	Name, nickname or fragment → official name + UKPRN ("UCL" and "Sheffield Uni" both work)
`nss_scores`	NSS positivity vs OfS benchmark and UK sector average, filterable by subject (CAH), question/theme, population, mode and level
`compare_providers`	Two or more providers side by side, each judged against its own benchmark
`b3_outcomes`	Continuation, completion and progression rates vs OfS benchmarks and regulatory thresholds, by subject or demographic split
`leo_earnings`	Graduate earnings (LQ/median/UQ) at 1, 3 and 5 years, by subject, with the UK figure for context
`run_sql`	Read-only SELECT against the underlying DuckDB, capped at 100 rows, for anything the fixed tools don't cover

Plus a data://dictionary resource describing every table, its grain, and what is deliberately absent, and two MCP prompts — provider_health_check and subject_shortlist — that walk a client through the tools in the right order with the statistical conventions attached.

Roadmap

Discover Uni course catalogue — the full course census, crawled from the public sitemap.
Prebuilt database download, so the one-off build takes seconds rather than minutes.

Data sources and licences

Source	Publisher	Licence
National Student Survey 2026	Office for Students	OGL v3.0
Student outcomes (B3) Feb 2026	Office for Students	OGL v3.0
LEO graduate earnings 2022/23	Department for Education	OGL v3.0

Contains public sector information licensed under the Open Government Licence v3.0. This project is not affiliated with or endorsed by the Office for Students or the Department for Education.

Code is MIT licensed.

Available Tools

5 tools

b3_outcomesA

Student outcomes (OfS B3 indicators) for one provider.

Three indicators, each a percentage of students:
  - Continuation: still in higher education (or qualified) about a year
    after starting.
  - Completion: qualified or still studying four years after starting.
  - Progression: in managerial/professional employment or further study
    15 months after graduating.

Each row carries the OfS benchmark (expected value given the provider's
student and course mix), the regulatory minimum threshold the OfS
enforces (condition B3), and the number of students behind the figure.
Quote outcomes against the benchmark, not just the raw percentage. Years
are pooled windows (e.g. "2019-2022") — the latest available per
indicator is returned.

Args:
    ukprn: Provider id from search_providers.
    indicator: Optional filter — "Continuation", "Completion" or
        "Progression" (partial match). Omit for all three.
    subject: Optional subject filter by CAH name ("Law") or code
        ("CAH16-01"). Omit for whole-provider figures.
    split_type: Optional demographic split instead of subject — e.g.
        "Sex", "Ethnicity", "AgeOnCommencement", "Disability",
        "DeprivationQuintile". Use with or without split_value.
    split_value: Optional value within the split, e.g. "Female",
        "Mature". Partial match.
    mode: "Full-time" (default), "Part-time" or "Apprenticeship".
    level: "FirstDegree" (default), "AllUndergraduates",
        "OtherUndergraduate", "PostgraduateTaughtMasters",
        "PostgraduateResearch", "PGCE" and others.

A NULL value with a supp_reason (e.g. "[low]") means the OfS suppressed
that figure, usually for small numbers — report the suppression, don't
estimate. This dataset has no application volumes, entry grades or
satisfaction scores (NSS tools cover satisfaction).

ParametersJSON Schema

Name	Required	Default
`mode`	No	Full-time
`level`	No	FirstDegree
`ukprn`	Yes
`subject`	No
`indicator`	No
`split_type`	No
`split_value`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully bears the burden of transparency. It explains data source (OfS), what each indicator represents, benchmark and threshold inclusion, pooled years, latest data retrieval, handling of NULL values with suppression reasons, and exclusions (no application volumes, entry grades, or satisfaction scores).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, bullet-pointed indicator details, and clear argument list. It is front-loaded with the core purpose and each sentence adds distinct value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, output schema exists), the description covers all necessary aspects: return structure, parameter usage, suppression handling, and data limitations. It is comprehensive enough for an AI agent to effectively use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description thoroughly explains all 7 parameters, including default values, allowed values, examples, and relationships (e.g., split_type and split_value). It also provides context for ukprn (from search_providers) and subject (CAH name or code).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns OfS B3 student outcomes for one provider, listing the three indicators and explaining their meaning. It implicitly distinguishes from siblings like compare_providers and nss_scores by specifying that it is for a single provider and noting that satisfaction scores are covered by NSS tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (e.g., for a specific provider) and details on filtering, but does not explicitly state when not to use it or compare directly to sibling tools. However, it does mention that satisfaction scores are not included, directing users to NSS tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_providersA

Compare NSS results across two or more providers, side by side.

Returns one entry per question/theme, each holding every provider's
positivity score, its OfS benchmark and its position against it, plus the
UK sector average for context. Because each provider is judged against
its own benchmark, this comparison is fairer than ranking raw scores —
say which providers beat their benchmark, not just who scored highest.

Args:
    ukprns: Two or more provider ids from search_providers.
    subject: Optional CAH subject name filter, e.g. "Computing". Omit to
        compare at whole-provider level.
    question: Filter on question/theme text. Defaults to "Theme" (the
        seven headline themes), which keeps the comparison readable.
        Pass None (or a specific question) to widen or narrow it.
    subject_level, population, mode_of_study, level_of_study: As in
        nss_scores.

A provider missing from a row has suppressed data on that cut (under 10
respondents) — report the gap, don't fill it.

ParametersJSON Schema

Name	Required	Default
`ukprns`	Yes
`subject`	No
`question`	No	Theme
`population`	No	Registered
`mode_of_study`	No	All modes
`subject_level`	No	CAH2
`level_of_study`	No	First degree

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that missing providers indicate suppressed data (under 10 respondents) and that output includes positivity scores, benchmarks, and UK averages. No annotations exist, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with main purpose, followed by output explanation, parameter details, and a specific behavior note. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers output structure and suppression behavior, but relies on referencing nss_scores for some parameters, which may not be fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Describes key parameters (ukprns as provider ids from search_providers, subject as CAH filter, question as theme filter) but defers subject_level, population, etc. to 'As in nss_scores', assuming familiarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool compares NSS results across providers, distinguishing it from search_providers and nss_scores by focusing on side-by-side comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains that the comparison is fairer than raw ranking and provides parameter guidance (e.g., default question is 'Theme'), but does not explicitly state when to use alternatives like nss_scores.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

leo_earningsA

Graduate earnings (DfE Longitudinal Education Outcomes) for one provider.

Returns lower-quartile, median and upper-quartile annualised earnings at
1, 3 and 5 years after graduation, by CAH2 subject, with the UK-wide
figure on the same cut for context. Always quote the median with its
quartiles — the spread is usually the story — and say how many graduates
the figure is based on.

Args:
    ukprn: Provider id from search_providers.
    subject: Optional CAH2 subject name filter, e.g. "Law", "Computing"
        (partial match). Omit for all subjects.
    years_after: 1, 3 or 5 (years after graduation). Omit for all three.
    tax_year: e.g. "2022/2023". Omit for the latest available.
    characteristic_type: "All graduates" (default), or a split:
        "sex", "ethnicity", "POLAR4", "prior_attainment_code".
    characteristic_value: Value within the split, e.g. "F", "M".

Honest limits, worth repeating to the user: these are pre-tax earnings of
UK graduates in sustained employment whose records matched tax data —
the self-employed abroad, or those out of work, aren't in the medians.
Earnings reflect where graduates live and work (London weighting is
real), and nothing here is causal: a subject's high earnings may be who
it admits, not what it teaches. No figures on application volumes,
satisfaction or dropout — other tools cover the latter two.

ParametersJSON Schema

Name	Required	Default
`ukprn`	Yes
`subject`	No
`tax_year`	No
`years_after`	No
`characteristic_type`	No	All graduates
`characteristic_value`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: earnings are pre-tax, from matched tax data, exclude self-employed/unemployed graduates, reflect location weighting, and are not causal. It also states what the tool does not provide (application volumes, satisfaction, dropout). This is comprehensive and honest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with paragraphs for purpose, args, and limitations. It is front-loaded with essential info. While slightly lengthy, every sentence adds value; minor redundancy in repeating 'omit' for parameters could be tightened, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, detailed output) and presence of an output schema, the description covers return values, limitations, and usage context thoroughly. It explains what the data represents and its caveats, making it complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description bears full burden. It explains each parameter: ukprn (from search_providers), subject (CAH2 partial match, optional), years_after (1,3,5), tax_year (format example), characteristic_type (default and split options), characteristic_value (value examples). This adds significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns graduate earnings data for one provider, specifying lower-quartile, median, and upper-quartile annualised earnings at 1, 3, and 5 years by CAH2 subject, with UK-wide context. This is distinct from sibling tools like b3_outcomes (broader outcomes) or nss_scores (satisfaction), so purpose is specific and well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly guides the agent to always quote median with quartiles and mention graduate counts. Discusses honest limits (pre-tax, excludes self-employed, not causal) and clarifies that other tools cover application volumes and dropout. References search_providers for ukprn, providing clear when-to-use and when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nss_scoresA

National Student Survey results for one provider.

Returns positivity scores (the % of students answering positively) per
question and theme, with two comparators: the OfS benchmark (the score a
provider with this mix of students and subjects would be expected to get,
including whether the provider is materially above or below it) and the
UK sector average on the same cut. A score without its benchmark is
misleading; always quote both.

Args:
    ukprn: Provider id from search_providers.
    subject: Optional CAH subject name filter, e.g. "Law", "Nursing"
        (matches partially). Omit for provider-level results.
    question: Optional filter on question/theme text, e.g. "feedback",
        "Theme 3", "Q14". Omit for everything.
    subject_level: Granularity of the subject cut when `subject` is given:
        "CAH1" (broadest, ~23 groups), "CAH2" (default, ~35 groups) or
        "CAH3" (finest, ~100+). Without this the same subject would appear
        once per level.
    population: "Registered" (default; the OfS headline convention) or
        "Taught".
    mode_of_study: "All modes" (default), "Full-time", "Part-time" or
        "Apprenticeship".
    level_of_study: "First degree" (default), "Other undergraduate",
        "Undergraduate with postgraduate component" or
        "All undergraduates".

This is survey data about the student experience. It cannot tell you
application volumes, offer rates, entry requirements or fees — none of
that is in the NSS. Say so rather than inferring it from satisfaction.

ParametersJSON Schema

Name	Required	Default
`ukprn`	Yes
`subject`	No
`question`	No
`population`	No	Registered
`mode_of_study`	No	All modes
`subject_level`	No	CAH2
`level_of_study`	No	First degree

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description fully discloses the survey data nature, the return structure (positivity scores with comparators), and limitations (cannot infer other metrics). This provides comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured with a summary sentence, a detailed Args block, and a concluding note on limitations. Every sentence adds value without waste, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and an existing output schema, the description covers all parameter semantics, usage guidance, and data limitations. It is fully complete for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains each parameter in detail with defaults, examples, and the effect of combinations (e.g., subject filter with subject_level granularity). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns National Student Survey results for one provider, including positivity scores per question/theme with benchmarks and UK sector averages. This distinguishes it from sibling tools like b3_outcomes, compare_providers, leo_earnings, and search_providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises that a score without its benchmark is misleading and to always quote both. Also states what the tool cannot provide (application volumes, offer rates, etc.), guiding when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_providersA

Find UK higher-education providers by name, nickname or fragment.

Returns each match with its UKPRN, the key that every other tool uses to
identify a provider. Use this first when the user names a university
loosely — "UCL", "Sheffield Uni" and "Manchester Met" all resolve.
Universities rank above colleges when a fragment matches both.

Covers the ~450 providers that appear in the National Student Survey.
It cannot tell you about providers with no published NSS results (very
small or new providers are often suppressed).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description discloses scope (~450 providers), matching behavior (universities rank above colleges), and limitations (no NSS results for small/new providers).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise 4-sentence description, front-loaded with purpose, then usage guidance, then details and limitations. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter search tool with no annotations, description covers purpose, usage, return value (UKPRN), scope, and limitations. Output schema exists, so return details are covered. Complete for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'query' has no schema description, but description explains it accepts name, nickname, or fragment and gives concrete examples, fully compensating for schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Find UK higher-education providers by name, nickname or fragment' with specific verb and resource. Distinguishes from siblings by mentioning UKPRN as key identifier used by other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises 'Use this first when the user names a university loosely' and provides examples. Also notes limitation: cannot find providers without published NSS results.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jul 15, 2026
- First observedb3_outcomes
- First observedcompare_providers
- First observedleo_earnings
- First observednss_scores
- First observedsearch_providers

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-07-15 16:20 across 5 tools

Disambiguation5/5

Each tool covers a distinct aspect of UK higher education data: student outcomes (b3_outcomes), NSS satisfaction (nss_scores and compare_providers for cross-provider comparison), graduate earnings (leo_earnings), and provider lookup (search_providers). There is no overlap in purpose.

Naming Consistency5/5

All tool names follow snake_case and a predictable pattern: data type nouns (b3_outcomes, leo_earnings, nss_scores) or verb_noun (compare_providers, search_providers). The naming is uniform and descriptive.

Tool Count5/5

With 5 tools, the server is well-scoped for its domain. Each tool serves a necessary function without redundancy or bloat, covering key areas of higher education data.

Completeness4/5

The toolset covers student outcomes, satisfaction, and earnings comprehensively. Minor gaps exist (e.g., no tool for application data or fees), but these are explicitly excluded in tool descriptions and not core to the server's purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Nihr A
io.github.pipeworx-io
UK NIHR (National Institute for Health and Care Research) open-data MCP.
Open Data Research & Data Health & Wellness
361
FirstData
io.github.Vist233
Hosted MCP server for finding authoritative primary data sources and official portals.
Search Open Data Government Data
2144
altmetric-mcpOAuth
com.altmetric.mcp
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Research & Data Social Media
27
Datagov Uk A
io.github.pipeworx-io
data.gov.uk MCP — UK national open-data portal (CKAN API).
Government Data Open Data
352

Related MCP Servers

uk-schools-mcp
Government Data Open Data Education & Learning Tools
mkb-123
A
license
A
quality
D
maintenance
MCP server providing access to comprehensive UK school data from official government sources, including search, details, near-postcode, comparisons, Ofsted ratings, and DfE education datasets.
Updated 7 months ago (2026-02-07 09:30 UTC)
11
MIT
mcp-geo
chris-page-gov
A
license
Not graded
quality
C
maintenance
A research MCP server for UK geospatial and statistical data, enabling AI assistants to query Ordnance Survey and ONS datasets.
Updated 2 months ago (2026-07-21 23:06 UTC)
3
MIT
urban-edc-mcp
Education & Learning Tools Open Data Government Data
sribnick-coder
A
license
Not graded
quality
C
maintenance
Federated MCP server that routes K-12 education data requests to public sources like Urban Institute, EDC/Zelma, NAEP, and MA E2C, handling comparability and provenance automatically.
Updated a month ago (2026-07-30 20:45 UTC)
MIT
academyinfo-mcp
Open Data Government Data Research & Data
yousunjung84-edu
A
license
A
quality
B
maintenance
Read-only MCP server for factual queries and side-by-side comparisons of Korean university disclosure indicators using a bundled local snapshot, with no API key or network required.
Updated a month ago (2026-08-16 17:10 UTC)
8
21 npm
MIT