datagokr

by datagokr-dev

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct roles, but search and fields overlap because search already accepts a fields parameter, and preview/fetch/get all return row-level data with access-dependent behavior. The detailed descriptions help disambiguate, but an agent could still select the wrong retrieval tool without careful reading.
Naming Consistency3/5
Most tools are short bare verbs (search, show, preview, fetch, get, apply, download), but fields is a noun and login_status uses snake_case, breaking the overall pattern. Names are readable but do not follow a consistent verb_noun or systematic convention.
Tool Count5/5
Nine tools is well within the ideal range for a public-data portal MCP server. Each tool maps to a meaningful step in the workflow—search, inspect, preview, fetch, get, apply, download, and auth status—without bloating the surface.
Completeness4/5
The set covers the main data lifecycle: catalog search, metadata inspection, row preview/retrieval, access application, and file download. Minor gaps remain, such as no MCP login command (only login_status) and no way to list or track past application statuses.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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 passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: no application or file saving, the API key is sent in X-DataGoKr-Key header, and the return includes access instructions if not authorized. These details go beyond the annotation and are not contradicted by it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, repeating the same content in Korean and English. While structured with '반환 / Returns' and clear notes, the duplication adds length without adding informational value. It is not overly long, but the bilingual redundancy could be streamlined to a single language.
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?
The description covers the return format (access_kind, data.columns/rows, total or access instructions) and mentions the key header behavior. With an output schema available, it does not need to detail the exact response structure. It lacks explicit error handling or pagination notes, but for a preview tool with annotations and output schema, it is sufficiently complete.
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%, so the description must compensate for parameter meanings. It mentions 'up to 20 rows' which hints that 'n' controls the row count, but it does not explicitly explain 'dataset_id' or the exact role of 'n'. The mapping is left to inference, making this a weak compensation 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 states a clear verb (preview) and resource (remote server's first rows and access instructions). It specifies a row limit of 20, which distinguishes it from generic 'fetch' or 'get'. However, it does not explicitly name a sibling tool or contrast with alternatives, so it misses the highest bar for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any when-to-use guidance or exclusions. It does not mention alternatives like 'show' or 'fetch', nor does it indicate scenarios where preview would be preferred over other tools. The usage context is only implied by the word 'preview'.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the return fields (ranked id, title, org_nm, etc.), which is helpful, but doesn't disclose other behavioral aspects like pagination, rate limits, or how the search ranking works. It adds some value beyond annotations but not a full behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose front-loaded, followed by parameter hints and an example. It is not overly verbose and avoids redundancy, though it mixes languages (Korean and English) which slightly complicates parsing but remains clear.
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?
The description covers the essential aspects: purpose, parameter meanings, return fields, and an example. Since there is an output schema, return values are already documented. It lacks details on edge cases or error conditions, but for a simple search tool it is fairly complete. Minor omissions like pagination behavior prevent a perfect score.
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 explain parameters. It does so: query (natural language/topic), n (1-20), dtype (FILE/API/STD), org (provider), fields (required columns). This gives meaningful context beyond the bare schema, though it could be more detailed (e.g., exact allowed values for dtype).
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 the tool searches a remote catalog by topic, using a verb ('search') and a resource ('remote catalog'). It provides a specific context (public data) and an example query. However, it doesn't explicitly differentiate from siblings like 'fetch' or 'get', which might also retrieve data, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does and lists parameters, but doesn't mention scenarios where it should be preferred or avoided. No exclusions or alternative tool names are provided.
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?
The description discloses important behaviors beyond the destructiveHint annotation: it explicitly states that files are overwritten ('overwriting the same path') and that probe=True performs a dry-run without saving ('probe checks without saving'). It also describes the return format (files with path, version, etc.). These details add value beyond the annotations, though it doesn't cover authentication or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph mixing Korean and English, which is a bit cluttered but front-loaded with the core purpose. It contains some redundancy (both languages for the same idea) and could be tightened, but it's not excessively long. The structure is acceptable but not exemplary.
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?
Given the tool has an output schema, the description still covers the main behavior, parameter semantics, and return details. It explains the overwriting behavior and probe mode, which are crucial for safe usage. It lacks guidance on when to use this tool vs siblings, which prevents a perfect score, but overall it's reasonably complete for a download operation.
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 explain parameters, and it does for most: version/all_versions (mutually exclusive choice), out (destination directory, with default), utf8 (CSV UTF-8 conversion), and probe (dry-run). It doesn't explicitly explain dataset_id, but that's the required identifier and is fairly obvious from context. It also mentions the special case of STD_FILE being saved as a full CSV, adding nuance.
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 the tool's primary action: saving originals locally ('Save originals locally'). It also notes overwriting behavior, which is a specific detail. However, it doesn't differentiate this tool from sibling tools like 'fetch' or 'get', which might also retrieve files, so it loses a point for lacking sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter-level guidance (e.g., 'choose version or all_versions') but provides no guidance on when to use this tool versus alternatives. It doesn't mention any exclusion criteria or conditions that would route an agent to a sibling tool. This is a significant gap for a tool with many siblings.
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?
Annotations already declare readOnlyHint=true, and the description adds valuable context: it returns API data or request_templates, status_code=401 signals access must be requested, and it doesn't save files or apply for access. This goes beyond the annotation and clarifies error semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by defaults, returns, and special cases. It is slightly redundant due to bilingual repetition, but each sentence adds value and the structure is logical.
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?
Given the tool has an output schema and low parameter complexity, the description covers the essential behaviors: fetch semantics, default version, return types, error code, and exclusions. It is adequate for an agent to call the tool correctly.
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 0%, so the description must compensate. It explains version defaults to latest and implies n is the number of rows via '첫 n행', but it doesn't explicitly describe dataset_id or provide detailed syntax for any parameter. It adds some meaning but not complete compensation.
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 the verb 'fetch' and resource 'odcloud first n rows', and specifies it queries locally with an API key. It hints at differentiation by noting that STD_FILE should use get/download, which distinguishes it from those siblings, though it doesn't explicitly name all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides partial guidance: it says it does not apply for access or save files, and that STD_FILE should use get/download. However, it doesn't explicitly state when to use this tool versus search, show, or preview, leaving some ambiguity for an agent.
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?
The description adds useful behavioral details beyond the annotations: it discloses that cookies are sent only to the portal, and that a 'manual' status indicates login is required. This goes beyond the minimal readOnlyHint/destructiveHint flags, which are false (write operation, not destructive). It does not contradict the annotations; the 'submit' action aligns with readOnlyHint=false. The disclosure of cookie scope and login requirement is valuable for an agent assessing side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. It then covers parameters, return values, and cookie behavior in a structured sequence. While bilingual repetition adds slight redundancy (e.g., both Korean and English for the same idea), the overall length is appropriate and each sentence adds information. No extraneous content.
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?
The description explains the return values (id, status, portal_status, page_url) and the meaning of 'manual' status, which is important for interpreting results. It also mentions the login requirement and cookie scope. Given the tool's complexity (a submission action with session reliance), this is fairly complete. However, it does not cover edge cases like invalid session or rate limits, but these are not essential for basic invocation. The presence of an output schema (not shown) further reduces the need to detail return formats.
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?
With schema description coverage at 0%, the description carries the full burden for parameter explanation. It explicitly defines 'ids' as dataset IDs (1~50개) and 'purpose' as intended use (활용 목적 / intended use), adding meaning beyond the raw schema fields. This is a clear compensation for the schema's lack of descriptions, though it could be more detailed about the exact format of ids (e.g., are they numeric or strings?) but the provided clarity 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 purpose: 'Submit access applications with saved login' (활용신청을 제출합니다). It specifies the verb 'submit' and the resource 'access applications', and it is distinct from sibling tools like search, show, download, etc., none of which handle submissions. The bilingual phrasing reinforces the core action without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about login ('로그인: datagokr login') and the meaning of 'manual' status, which hints at prerequisites. However, it does not explicitly say when to prefer this tool over siblings, nor when not to use it. The guidance is implied rather than explicit, leaving the agent to infer the use case from the action of submitting applications.
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?
The description adds behavioral context beyond the readOnlyHint annotation: it specifies the matching logic ('ALL named columns') and the return type ('ranked metadata as in search'). This gives the agent a clear expectation of the tool's behavior and output without contradicting the read-only annotation. The description does not repeat the annotation but enriches it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by parameter examples and return info. Each sentence serves a purpose, though the bilingual repetition (Korean then English) adds slight redundancy. Overall, it is efficient and well-structured.
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?
Given the presence of an output schema and the readOnlyHint annotation, the description does not need to elaborate on return values or safety. It covers parameter semantics, matching logic, and return type. It does not mention pagination or ordering, but these are minor for a search tool. The description is sufficiently complete for an agent to invoke the tool 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?
Schema description coverage is 0%, but the description compensates by providing concrete examples and constraints for each parameter: 'names 예시 / Example: ['위도', '경도']; n: 1~20; dtype: FILE/API/STD; org: 기관명.' This clarifies the format, allowed values, and meaning of parameters, which the schema alone does not convey. It does not explain what 'STD' stands for, but the given options are sufficient for basic usage.
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 purpose: 'Find datasets matching ALL named columns.' This is a specific verb (find) + resource (datasets) + condition (matching ALL named columns). It distinguishes itself from siblings like search by focusing on column-based matching, making its intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples for parameters (names, n, dtype, org) and mentions it returns metadata 'as in search,' implying it is used when you have specific column names. However, it does not explicitly state when to use this tool over alternatives like search or when not to use it. The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as potentially destructive, but the description adds crucial specifics: it may save files locally (original file fallback) and can submit an application on the user's behalf when no_apply=False. It also explains probe as a safe check. This exceeds the annotation signal and fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and structured logically (main purpose, side-effect warning, probe explanation, return summary). It is slightly verbose due to bilingual repetition, but every sentence adds value. Good organization.
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?
The output schema exists, so return values don't need detailed explanation, and the description still gives a concise return summary. It covers side effects, probe behavior, and fallback logic. The only gap is the meaning of n, which the schema may already describe. Overall, it's complete for the tool's complexity.
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?
With 0% schema description coverage, the description must explain parameters. It explains no_apply and probe clearly, but gives no meaning for n (likely row count) or dataset_id beyond being required. It partially compensates but leaves key parameters undocumented.
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 it returns rows, links, or API templates depending on access method, which is a specific verb-resource combination. It also distinguishes itself from siblings by the mention of access_kind and the fallback behavior, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use probe and no_apply, but does not explicitly contrast with sibling tools like search, preview, or fetch. The guidance is present for specific scenarios (401 fallback, avoiding side effects) but not for general selection between 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?
Annotations provide readOnlyHint=true, and the description adds important behavioral details: it explicitly states that keys and cookies are never returned, which is critical security context. It also discloses the return fields (authenticated, message) and the behavior on missing/expired sessions. This goes beyond the annotation and gives the agent a clear picture of what the tool does and does not expose.
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 concise and front-loaded: the purpose is stated first, then returns, then behavioral notes. It uses both Korean and English but is not verbose. Every sentence earns its place, and there is no redundant fluff.
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 parameterless, read-only tool with an output schema, the description is complete. It states the purpose, the return structure, the edge-case behavior (missing/expired session), and a security guarantee. An agent has everything needed to call it correctly and interpret the result.
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 the schema covers 100% (empty). According to the rubric, baseline for 0 params is 4. The description does not need to elaborate on parameters, and it doesn't. It appropriately focuses on behavior and returns.
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: checking the validity of a saved portal session. It uses a specific verb ('확인' / 'Check') and a specific resource (portal login). It is distinct from siblings like search, fetch, or download, which perform different operations. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to verify login status before performing other operations) but does not explicitly state when not to use it or mention alternatives. The line about guiding to login if session is missing/expired hints at usage context, but there is no explicit comparison with sibling tools. Given the tool's self-contained nature, this is adequate but not exemplary.
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?
The readOnlyHint annotation is consistent with the description, which describes an inspection operation. The description adds value by enumerating the returned metadata fields and clarifying that it does not return row data (implied by 'use get for actual rows'). This goes beyond the annotation by specifying what the tool returns and what it deliberately omits.
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 compact, with three sentences that lead with the purpose, then the return list, then the parameter guidance. There is no redundant wording, and the bilingual format does not obscure clarity. It is appropriately front-loaded and every sentence adds information.
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 metadata-inspection tool with one parameter and an output schema, the description covers the essential usage context: what it does, what it returns, where the id comes from, and how it relates to 'get'. There are no gaps that would prevent an agent from calling it correctly.
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?
With 0% schema description coverage, the description fully compensates by explaining that dataset_id is the id from search results. This gives the agent both the source and the meaning of the parameter, which the schema alone does not provide. For a single-parameter tool, this is complete.
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 inspects dataset metadata and lists the exact return fields (title, org_nm, access_kind, etc.). It explicitly contrasts with 'get' for actual rows, distinguishing it from a key sibling. The verb 'inspect' and resource 'dataset metadata' are specific and unambiguous.
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 advises to inspect metadata before use and explicitly says to use 'get' for actual rows, providing clear routing between two tools. It also instructs to use the dataset_id from search results. However, it does not mention other siblings like fields, preview, or fetch, so guidance is partial but sufficient for the primary alternative.
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

datagokr MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![datagokr MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/datagokr-dev/datagokr/badges/card.svg)](https://glama.ai/mcp/servers/datagokr-dev/datagokr)

Score Badge

Copy to your README.md:

[![datagokr MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/datagokr-dev/datagokr/badges/score.svg)](https://glama.ai/mcp/servers/datagokr-dev/datagokr)