Skip to main content
Glama
Sign In
uk-he-data-mcp

uk-he-data-mcp

by wilgreeves-cmd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_providers

Resolve UK higher-education provider names, nicknames, or fragments to official UKPRN identifiers. Use this tool to convert casual names into recognized provider keys.

Instructions

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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_providers"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools