College Scorecard
Server Details
Higher education data: tuition, graduation rates, and earnings
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose with no overlap: search_schools finds schools, get_school_detail provides comprehensive data for a single school, compare_schools compares multiple schools side-by-side, and get_field_of_study focuses on program-level earnings and debt data. The descriptions reinforce these distinct roles, making tool selection unambiguous.
All tool names follow a consistent verb_noun pattern (search_schools, get_school_detail, compare_schools, get_field_of_study), using clear action verbs that accurately reflect each tool's function. The naming is uniform and predictable throughout the set.
Four tools is reasonable for a College Scorecard API, covering core workflows: discovery (search), detail retrieval, comparison, and field-of-study analysis. While slightly lean, it avoids bloat and each tool serves a clear purpose. A minor gap might be the lack of filtering or sorting tools beyond search, but the count is well-scoped.
The toolset covers essential operations for college data exploration: search, get details, compare, and analyze fields of study. It supports a complete user journey from discovery to detailed comparison. A minor gap is the lack of update or delete operations, but these are unnecessary for a read-only data API; the surface is functionally complete for its domain.
Available Tools
4 toolscompare_schoolsAInspect
Compare multiple colleges or universities side by side.
Returns key metrics for each school including tuition, admission rate,
median earnings, debt, and completion rate for easy comparison.
Args:
school_ids: Comma-separated list of College Scorecard school IDs
(e.g. '166027,166683,243780'). Use search_schools to find IDs.| Name | Required | Description | Default |
|---|---|---|---|
| school_ids | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior by stating it 'Returns key metrics' and lists specific data points (tuition, earnings, debt) beyond empty annotations.
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?
Three tightly structured sentences: purpose, return value, and parameter specification—no redundancy despite null 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 single-parameter tool with output schema, description provides complete usage context including preview of returned metrics.
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?
Fully compensates for 0% schema coverage by providing comma-separated format, concrete example IDs, and sourcing instruction from search_schools.
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?
Specific verb 'Compare' and resource 'colleges or universities' with clear 'side by side' differentiator from sibling get_school_detail.
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?
Explicitly references sibling tool 'search_schools' for ID sourcing, implying prerequisite workflow, though could explicitly contrast with single-school retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_field_of_studyAInspect
Get earnings and debt data by field of study from the College Scorecard.
Returns median earnings and median debt for graduates of specific academic
programs. Can be filtered by school, by field name, or both.
Args:
school_id: College Scorecard school ID to see field-level data for one school.
field: Field of study name or keyword to search across schools
(e.g. 'Computer Science', 'Nursing', 'Business').| Name | Required | Description | Default |
|---|---|---|---|
| field | No | ||
| school_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions returns median earnings/debt but lacks operational details (rate limits, data freshness) given no annotations
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?
Well-structured with purpose upfront and clear Args section; slightly informal docstring style but effective
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?
Adequately covers scope given output schema exists; parameter details compensate for sparse schema
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?
Fully compensates for 0% schema coverage with detailed Args section including examples for each parameter
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?
Clear specific purpose (get earnings/debt by field of study) implicitly distinguishes from school-level siblings
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?
Explains filtering combinations (school, field, or both) but lacks explicit when-to-use vs sibling alternatives
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_school_detailAInspect
Get detailed data for a specific college or university.
Returns comprehensive information including costs, admissions, demographics,
earnings outcomes, financial aid, debt levels, and completion rates.
Use school IDs from search_schools results.
Args:
school_id: The College Scorecard school ID (integer). Find IDs via search_schools.| Name | Required | Description | Default |
|---|---|---|---|
| school_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden; it discloses returned data categories (costs, admissions, etc.) but omits side effects, caching, or rate limit details.
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?
Well-structured with front-loaded purpose, logical flow from function to return values to parameter specification; no redundant content.
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?
Given the simple single-parameter schema and existence of output schema, description provides adequate completeness by specifying the data domain (College Scorecard) and high-level return value categories.
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?
Since schema description coverage is 0%, description compensates effectively by explaining school_id is a 'College Scorecard school ID' and directing users to search_schools to find it.
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?
Clear specific verb ('Get detailed data') and resource ('college or university'), with implicit differentiation from search_schools via the ID dependency note, though explicit contrast with compare_schools and get_field_of_study is absent.
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 workflow guidance to use IDs from search_schools, but lacks explicit when/when-not guidance regarding compare_schools or get_field_of_study alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_schoolsAInspect
Search colleges and universities in the College Scorecard database.
Returns matching schools with basic info: name, location, size, tuition,
admission rate, median earnings, and completion rate.
Args:
name: Full or partial school name to search (e.g. 'Harvard', 'community college').
state: Two-letter US state abbreviation (e.g. 'CA', 'NY') to filter by state.
zip_code: Five-digit ZIP code for location-based search. Use with distance parameter.
distance: Search radius in miles from zip_code. Only used when zip_code is provided.
degree_type: Filter by predominant degree type: '1' (certificate), '2' (associate),
'3' (bachelor), '4' (graduate). Omit for all types.
limit: Maximum number of schools to return (default 25, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| state | No | ||
| distance | No | ||
| zip_code | No | ||
| degree_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return content (basic info fields), data source (College Scorecard), and parameter dependencies (distance only used with zip_code), though could explicitly note read-only nature.
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?
Well-structured with purpose first, then returns, then detailed Args; front-loaded effectively though Args section is lengthy it is necessary given schema deficiencies.
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?
Complete coverage of 6 parameters and their relationships, plus return value summary; appropriate given output schema exists to detail full return structure.
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?
Comprehensive Args section compensates for 0% schema coverage by explaining all 6 parameters, valid formats (e.g., 'CA', 'NY'), valid values for degree_type, and constraints (max 100).
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?
Specific verb 'Search' with clear resource 'colleges and universities in the College Scorecard database' inherently distinguishes from sibling detail/comparison tools.
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 clear context that this is for searching/filtering, but lacks explicit 'when not to use' or comparisons to sibling tools like compare_schools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!