Compare 488 Korean universities on 17 official disclosure indicators (대학알리미). No API key.
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.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 3/5.
compare_universities and explore_universities both return side-by-side data for multiple universities, making their boundaries unclear. search_university also overlaps with explore's resolution function, while get_university_metrics is distinct but adds to the confusion around which tool to use for similar tasks.
All tools follow a consistent snake_case verb_noun pattern (compare_universities, list_indicators, validate_source_coverage), with no mixed conventions or irregular naming styles.
8 tools is well-scoped for a university disclosure data API, covering search, retrieval, comparison, explanation, listing, and validation without being overly sparse or bloated.
The core read-only workflow is covered: search, get, compare, explain, list indicators/sources, and validate coverage. A minor gap is the lack of an explicit 'list all universities' tool, but explore_universities and search_university likely handle this need.
compare_universitiesCompare UniversitiesBCompare verified local metrics for multiple universities when available.
| Name | Required | Description | Default |
|---|---|---|---|
| indicators | No | ||
| university_names | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the context of 'verified local metrics' and 'when available', implying partial data coverage, but does not disclose behavior like how missing data is handled or what the output format is. This is a modest addition beyond 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?
The description is a single, tight sentence with no filler. It front-loads the core action ('Compare') and includes a useful qualifier. Every word contributes to the 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?
Given the absence of an output schema and low parameter documentation, the description leaves significant gaps: it doesn't explain the result structure, how comparisons are presented, what happens when some universities lack data, or how indicators are specified. The tool appears simple, but the description is too sparse to be self-sufficient.
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 0%, yet the description provides no explanation for 'indicators' or 'university_names'. While names are somewhat self-explanatory, 'indicators' is ambiguous and could refer to various metric types. The description does not compensate for the lack of parameter documentation.
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 clearly states a specific action ('Compare') and resource ('universities') with a qualifier ('verified local metrics'), which distinguishes it from siblings like search_university or get_university_metrics. However, it doesn't explicitly name alternatives or further differentiate from explore_universities, so it falls short of a 5.
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 offers no guidance on when to use this tool versus the sibling tools. The phrase 'when available' hints at data limitations but does not provide explicit context or exclusions for alternative tools. There is no mention of prerequisites or scenarios favoring this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_indicatorExplain IndicatorBExplain a v0.1 indicator with source metadata and verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates safety. The description adds that the explanation includes source metadata and verification status, giving insight into the output content. However, it doesn't disclose how the indicator is identified, what happens if not found, or any behavioral nuances. Given the annotations, this adds moderate 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?
The description is a single, focused sentence that leads with the verb 'Explain' and immediately specifies the object and relevant details. No unnecessary words or clauses.
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 and minimal description, the tool's overall context is partially complete. The description mentions that an explanation includes source metadata and verification status but leaves ambiguous what 'v0.1' refers to and the exact return shape. It is not as undeveloped as a hyper-minimal description, but gaps remain.
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?
The input schema has a single 'indicator' string parameter with no description (0% coverage). The description merely repeats the word 'indicator' without specifying the expected format (e.g., name, ID, code) or providing an example. It fails to compensate for the schema's lack of documentation.
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 clearly states the tool explains an indicator, specifying the version (v0.1) and what the explanation includes (source metadata and verification status). This distinguishes it from sibling tools like list_indicators, which lists indicators rather than explaining a single one.
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 offers no guidance on when to use this tool over alternatives, such as list_indicators or validate_source_coverage. It neither states when to use it nor provides exclusion criteria. The usage context is only implicit from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_universitiesExplore UniversitiesBResolve universities and return factual side-by-side local indicator data.
| Name | Required | Description | Default |
|---|---|---|---|
| indicators | No | ||
| university_queries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds minor context ('resolve', 'factual', 'side-by-side') but does not disclose details like resolution behavior, error handling, or output format. No contradiction with 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?
The description is a single, tightly worded sentence with no irrelevant content. It front-loads the action and output, making it easy to scan.
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?
Despite the tool's apparent simplicity, the description leaves important gaps: what does it mean to 'resolve' universities, what constitutes 'local indicator data', and how do the input arrays relate to the output? With no output schema and no parameter descriptions, this short text is insufficient for reliable invocation.
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?
With 0% schema coverage, the description carries full responsibility for explaining parameters. It mentions 'universities' and 'indicator data' which loosely map to the parameter names, but gives no specifics on accepted formats, value enumerations, or how queries should be structured. The description fails to compensate for the missing schema details.
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 specifies a clear action ('resolve universities') and output ('return factual side-by-side local indicator data'), making the core purpose understandable. However, 'resolve' is slightly opaque, and the description does not significantly differentiate from sibling tools like compare_universities, which likely also produces comparisons.
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?
No guidance is provided on when to use this tool versus alternatives such as compare_universities or search_university. The description lacks any contextual cues about intended use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_university_metricsGet University MetricsAReturn verified local metrics for one university when available.
| Name | Required | Description | Default |
|---|---|---|---|
| indicators | No | ||
| university_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds context about 'verified' and 'local' metrics and the condition 'when available,' providing some behavior insight. However, it does not disclose return format, empty results handling, or other potential edge behaviors.
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 a single concise sentence with no filler words. It front-loads the core action and object, achieving maximum efficiency.
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?
The tool is simple, and the readOnly annotation covers safety, but without an output schema or parameter descriptions, the description leaves gaps about return values, the meaning of 'verified local metrics,' and behavior when no data is available. It is minimally adequate but not fully complete.
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?
With schema description coverage at 0%, the description must compensate, but it only implicitly references 'one university' (university_name) and 'metrics' (possibly indicators). It does not explain the indicators array, required vs optional, or expected value formats.
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 clearly states a specific verb ('Return') and resource ('verified local metrics for one university'). It distinguishes itself from siblings like compare_universities and explore_universities by focusing on a single university.
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 university' implies when to use this tool, but it does not explicitly mention alternatives or provide when-not-to-use guidance. No exclusions or comparisons to sibling tools are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_indicatorsList IndicatorsAList v0.1 file-first indicators enabled by default.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark the tool as read-only, and the description adds useful context about version and default filtering. No contradiction with annotations, but lacks deeper behavioral 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?
A single, front-loaded sentence with no wasted words. Every element adds specificity, though 'v0.1 file-first' may be jargon.
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?
As a simple list tool with no output schema, the description gives the essential scope but does not explain what an indicator is or what the returned list contains, leaving some gaps.
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?
The tool has zero parameters, so schema coverage is trivially 100% and the baseline of 4 applies. No parameter explanation needed.
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 clearly states the tool lists indicators, with specific scope ('v0.1 file-first' and 'enabled by default'), distinguishing it from siblings like list_sources and explain_indicator.
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?
No explicit guidance on when to use this tool versus alternatives. The phrase 'enabled by default' implies a subset but does not clarify use cases or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesList SourcesAList bundled file-first academyinfo sources available in v0.1.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be non-destructive. The description adds useful behavioral context by specifying sources are bundled, file-first, and limited to v0.1, which informs the agent about scope and availability. It does not detail return format, but that is acceptable given the simplicity.
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 a single sentence, front-loaded with the verb 'List', and contains no redundant wording. Every word adds value, making it highly concise and well-structured.
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 listing tool with zero parameters and readOnly annotations, the description provides sufficient context: it states what is listed (sources), their characteristics (bundled, file-first, academyinfo), and the version (v0.1). No output schema is needed for a straightforward list, and the description is complete for the tool's simplicity.
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?
The tool has zero parameters, so schema coverage is 100% and the description does not need to explain any parameters. The baseline for zero-parameter tools is 4, and the description does not add redundant information.
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 clearly states the verb 'List' and the specific resource 'bundled file-first academyinfo sources', along with version scope 'v0.1'. This differentiates it from sibling tools like list_indicators, which lists indicators, and validate_source_coverage, which validates sources.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The applicability is implied by the verb and resource, but the description does not mention alternatives like list_indicators or validate_source_coverage, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_universitySearch UniversityASearch local file-first university records without guessing ambiguous matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint and openWorldHint annotations: it reveals a 'local file-first' search strategy and explicitly says it does not guess ambiguous matches. This helps set expectations for edge cases. No contradiction with 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?
The description is a single, well-structured sentence that is front-loaded with the core action and resource. It contains no filler or 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?
For a simple search tool with one parameter and no output schema, the description gives key context about scope and behavior. It could mention what the return value looks like or when no match is found, but the current information is largely sufficient for a basic search tool.
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?
The input schema has one param ('query') with no description, and schema description coverage is 0%. The description does not explain what the query should contain or provide format guidance, leaving a significant gap in parameter understanding.
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 clearly states the action ('Search'), the resource ('university records'), and scope ('local file-first'), and differentiates from siblings like explore_universities by emphasizing exact matching ('without guessing ambiguous matches'). This is specific and distinguishes the tool.
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 when to use this tool (when you need local, exact university records) and contrasts with ambiguous searching. However, it does not explicitly name alternatives or state when not to use it, so it just misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_source_coverageValidate Source CoverageAValidate v0.1 source coverage, key policy, and bundled data boundaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict it. The description adds context about what is validated (source coverage, key policy, bundled data boundaries), which goes beyond the annotations, but it does not disclose output format or potential side effects beyond a read-only operation.
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 a single, compact sentence that packs multiple scoping elements. It is concise and front-loaded, but the phrase 'v0.1' and 'key policy' are slightly jargon-heavy and could be clearer.
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 tool with no parameters and no output schema, the description provides a reasonable scope (three validation areas) but lacks detail on what 'validate' means operationally or what the result will be. It leaves the agent with an incomplete picture of expected behavior.
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?
The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain parameters. It adds no parameter-specific meaning, but that is appropriate given the parameterless design; baseline for zero params is 4.
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 clearly states a specific action ('Validate') with a defined scope ('v0.1 source coverage, key policy, and bundled data boundaries'). This distinguishes it from sibling exploration/list tools by indicating a validation-oriented purpose rather than data retrieval.
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 validating coverage and boundaries, but it does not explicitly state when to use this tool versus alternatives like list_sources or explore_universities. No exclusions or alternative suggestions are provided, leaving the context to inference.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.