school-record-validator-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct action: single validation, batch validation, searching guidance, retrieving source excerpts, explaining specific rules, listing fields, and rule pack info. The overlap between search_record_guidance and get_source_excerpt is clearly sequential (search then retrieve context).
Naming Consistency4/5
Most tools follow a verb_noun pattern (validate_record_text, validate_record_batch, search_record_guidance, get_source_excerpt, explain_record_rule, list_record_fields). The exception is rule_pack_info, which uses a noun_noun pattern, but it's still understandable and consistent in style.
Tool Count5/5
Seven tools is well within the ideal range for a domain-specific server. Each tool serves a clear purpose in the validation workflow, and there is no unnecessary redundancy.
Completeness4/5
The tool set covers the core lifecycle: validating single and batch records, searching and retrieving guidance, explaining findings, listing supported fields, and checking rule pack metadata. Minor gaps might include a tool for fetching raw validation reports or comparing rule packs, but the surface is generally complete.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about the output's non-authoritative status and the role of provenance in confirming observations. However, it does not describe search behavior (e.g., whether it searches all sources, ranking, or pagination), auth requirements, or side effects. The read-only nature is implied but not stated.
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 three short sentences with no filler. It front-loads the primary use case, then adds necessary caveats about output authority and provenance limitations. Every sentence earns its place; the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a output schema (which can explain return values), the description covers the main purpose and usage context. However, it leaves a major gap in explaining the advanced search parameters (sourceIds, sourceRoles), which are likely crucial for effective use. The caveats about provenance are helpful, but overall the description is not fully complete for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the tool description does not compensate. The query parameter is obvious, but limit, sourceIds, and sourceRoles are completely unexplained. sourceRoles has an enum, but without explanation the agent cannot correctly choose values. The description adds zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it is called for general questions about regulations or to find grounds not present in verification results. It distinguishes itself from sibling tools like validate_record_text and explain_record_rule by focusing on searching guidance rather than validating or explaining. However, it does not explicitly name the resource (e.g., 'student records entry guidelines' from the title), instead using the broader term 'regulations'.
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 conditions for use: 'call when there are general questions about regulations' or 'when finding grounds not present in verification results.' It also clarifies limitations (not official/legal judgment, provenance dependency), which helps the agent decide when not to rely solely on this tool. It could be strengthened by explicitly mentioning when NOT to use it (e.g., for direct validation, use validate_record_text), but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results are not official approval or legal judgment, and that missing provenance prevents confirming observation and writing background. These are useful caveats beyond the schema, but the actual validation behavior is not described. With no annotations, the description carries a heavy burden that is only partially met.
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 concise sentences, front-loaded with the use case, followed by important caveats. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool's complexity (nested entries with many properties) demands more context. The description provides a basic use case and two caveats but omits the actual validation purpose, what rules are checked, and how to structure inputs correctly. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only highlights provenance as a critical factor but does not explain the entries array, entryId, field, text, or other parameters. Since the schema alone is complex, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool is for batch review of multiple independent texts, distinguishing it from sibling validate_record_text which presumably handles a single text. However, it emphasizes providing a stable entryId rather than explicitly stating the validation logic, making the core purpose slightly ambiguous.
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?
It provides a clear use case: invoke when reviewing multiple independent texts at once. This gives context but does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the result is not an official approval or legal judgment and that provenance absence blocks confirmation. But it does not cover other behavioral aspects such as read-only nature, output structure, or error behavior.
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 two short sentences, front-loading the key 'call first' directive and then adding a necessary caveat. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 8 parameters, nested objects, enums, and no annotations or schema descriptions, yet the description only provides timing and a caveat. It omits input semantics, examples, field categories, and relationships to sibling tools, leaving the agent under-equipped for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, and the description only mentions provenance as a limiting condition. It adds no semantic meaning for the required field/text parameters or nested activityContext/volunteerContext objects, so it fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly frames the tool as a required pre-check before reviewing, correcting, or writing a 생활기록부 narrative, and the title confirms '문안 검증'. It does not explicitly differentiate this tool from the sibling validate_record_batch, so it stops short of full sibling distinction.
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?
It gives explicit timing guidance: call this before reviewing, correcting, or writing. It also provides a condition of use by warning that missing provenance prevents confirming observation/writing circumstances. However, it does not mention alternative tools or explicitly say 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses that the result is not official/legal and that absence of input provenance prevents confirming observation details. This adds meaningful behavioral context beyond a simple lookup, though it does not explicitly state read-only or side-effect-free behavior.
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 three short sentences, front-loaded with the purpose, followed by a caveat and a limitation. Every sentence adds value with no redundancy or 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?
For a simple one-parameter tool with an output schema, the description covers the core purpose, usage timing, and a critical limitation about provenance. It is adequately complete, though it could further clarify what the tool returns if the output schema were not present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'ruleId' in passing as part of a validation finding, without explaining its format, source, or how to obtain valid values. The description adds minimal semantic value beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is to be called before explaining a ruleId from a validation finding, clearly indicating its purpose. It distinguishes from sibling tools like validate_record_text and search_record_guidance by focusing on explaining a specific rule ID.
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 clear context for when to use the tool ('before explaining to the user') and adds a caveat that the result is not official or legal. It does not explicitly mention alternatives, but the context implies it is for rule explanation rather than validation or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two important behavioral caveats: the result is not official approval/legal judgment, and missing provenance prevents confirming observation and authorship. This goes beyond the schema and offers useful transparency.
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 three sentences with no redundancy. It front-loads the purpose in the first sentence, followed by two concise caveats that earn their place. It is appropriately sized and well-structured.
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 simple one-parameter tool with an output schema present, the description covers purpose, usage condition, and key limitations. There are no significant gaps; return values are handled by the output schema.
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?
Schema description coverage is 0%, so the description must compensate. It explicitly mentions chunkId and ties it to search results, adding meaning to the bare string type. It could explain where chunkId originates, but for a single parameter this is sufficient.
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's function: retrieve the full original source context for a search result using a chunkId. It distinguishes from sibling tools by focusing on source text retrieval rather than validation, explanation, or field listing.
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 a clear usage condition: 'when full context of the original text from search results is needed.' It does not explicitly mention alternative tools or when not to use, but the context is specific enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that results are not official approval or legal judgment and notes the dependency on input provenance for confirming observation/writing context, adding valuable caveats.
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 short, front-loaded sentences: purpose first, followed by two caveats. No wasted words, every sentence contributes meaning.
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 zero-parameter tool with an output schema, the description fully covers purpose, when to use, and inherent limitations. Nothing critical is missing for an agent to select and invoke it correctly.
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?
The tool has zero parameters, so no parameter explanation is needed. The description's reference to field names and limits pertains to the output, not parameters, and the baseline for zero-param tools is 4.
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's function: to check support field names and 2026 input limits before validation. This specific verb+resource pairing distinguishes it from sibling validation 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?
Explicitly says to call 'before validation', providing clear context for when to use. Does not name alternatives or exclusions, but the timing clue effectively differentiates from validation and guidance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds valuable behavioral context: the result is not official/legal judgment, and without provenance the observation details cannot be confirmed. This informs the agent about limitations beyond what an output schema would show. Slightly deducting for not explicitly stating the return format, though the output schema is said to exist.
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?
Two concise sentences, front-loaded with the call trigger and followed by important caveats. Every sentence earns its place, with no redundancy or filler.
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 zero-parameter info tool with an output schema, the description is complete: it states the purpose, when to call, and key limitations. The caveats about official status and provenance add necessary context for the agent's decision-making.
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?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per the guidelines, a baseline of 4 applies because there are no parameter semantics to explain. The description does not need to add parameter detail.
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 retrieves the currently active school level, school year, source, and data hash. The verb '확인' (check) plus the specific resource makes the purpose unambiguous and distinguishes it from sibling tools focused on validation, search, or explanation.
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 explicitly says when to call it ('when checking...') and adds contextual caveats about the result not being official approval and the provenance limitation. It does not explicitly name alternatives or when not to use, but the sibling tool names imply different use cases, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![-school-record-validator-mcp MCP server](https://glama.ai/mcp/servers/ARTHONG1/-school-record-validator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ARTHONG1/-school-record-validator-mcp)

Score Badge

Copy to your README.md:

[![-school-record-validator-mcp MCP server](https://glama.ai/mcp/servers/ARTHONG1/-school-record-validator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ARTHONG1/-school-record-validator-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ARTHONG1/-school-record-validator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server