college-scorecard-mcp-server

Lookup CIP Code

scorecard_lookup_cip

Read-onlyIdempotent

Search the Classification of Instructional Programs (CIP) taxonomy by keyword or partial name. Returns matching CIP codes with standard titles. Use this before passing cip_code filters to scorecard_search_programs or scorecard_get_programs when you know a program by name but not its code. Served entirely from embedded static data — no API call, no rate limit impact.

Input Schema

Name	Required	Description
`limit`	No	Requested limit; serving cap 50, hard ceiling 1,000.
`query`	Yes	Search term — program name keyword (e.g. "computer science", "nursing", "business"). Matches against CIP titles and family names.
`offset`	No	Zero-based offset into the complete relevance-ordered matches.

Output Schema

Name	Required	Description
`cap`	No	The limit that was applied.
`error`	No	Present when the call failed. Absent on success.
`query`	No	The search query used.
`shown`	No	Number of CIP codes returned.
`notice`	No	No-match guidance.
`offset`	No	Zero-based offset of this result page.
`results`	No	Matching CIP entries ranked by relevance.
`guidance`	No	Concrete narrowing guidance when matches remain.
`truncated`	No	True when results were capped at the limit.
`nextOffset`	No	Offset to request next; absent when no matches remain.
`queryContext`	No	Effective selectors.
`totalMatches`	No	Number of matches found.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 3, 2026

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Zero-based offset into the complete relevance-ordered matches.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

changedOutput schema / anyOf

Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "query",
-      "results",
-      "totalMatches",
-      "queryContext",
-      "truncated",
-      "shown",
-      "cap"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "query",
+      "results",
+      "totalMatches",
+      "offset",
+      "queryContext",
+      "truncated",
+      "shown",
+      "cap"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / nextOffset

Added value: +{
+  "description": "Offset to request next; absent when no matches remain.",
+  "type": "number"
+}

addedOutput schema / properties / offset

Added value: +{
+  "description": "Zero-based offset of this result page.",
+  "type": "number"
+}

addedOutput schema / properties / queryContext / properties / offset

Added value: +{
+  "description": "Applied zero-based offset.",
+  "type": "number"
+}

changedOutput schema / properties / queryContext / required

Previous value: -[
-  "query",
-  "limit"
-]New value: +[
+  "query",
+  "limit",
+  "offset"
+]

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds genuinely new operational context: results are served entirely from embedded static data with no API call and no rate-limit impact, which tells an agent it can call this freely. It does not discuss match ordering or how relevance ranking behaves across pages, which would round this out.

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?

Three sentences, each carrying distinct information: what it searches, what it returns, when to use it versus siblings, and its cost profile. The usage guidance is front-loaded after the purpose statement with no filler.

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?

With an output schema present and full parameter documentation, the description covers purpose, routing, and cost. The only thin area is result-set behavior for broad queries — it doesn't hint that matches may exceed the serving cap and require offset paging, though the schema does note the cap.

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

Parameters3/5

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

Schema coverage is 100%, so query, limit, and offset are each documented in the schema, including the 50-item serving cap versus the 1,000 hard ceiling. The description restates the keyword/partial-name matching behavior that the schema already specifies, adding little beyond it, so baseline 3 applies.

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 names a specific verb and resource — search the CIP taxonomy by keyword or partial name — and states exactly what comes back (matching CIP codes with standard titles). It is clearly distinguishable from the sibling lookup/search tools because it operates on a code taxonomy, not on institutions or programs.

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?

It gives an explicit use case and names the two alternatives it feeds into: 'Use this before passing cip_code filters to scorecard_search_programs or scorecard_get_programs when you know a program by name but not its code.' The condition that selects this tool over those siblings is unambiguous.

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

All college-scorecard-mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.