Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
MyKIFRS MCP의 get_paragraph 도구는 기준서 문단 전문을 앞뒤 문맥과 함께 반환합니다.
[Purpose]
To quote a found 문단 exactly — the search snippet is never quotable evidence.
To check 조건절·예외 with neighbors — a lone 문단 invites misreading.
[Usage]
"1116호 33문단 원문" → unique_key="1116-33"
"앞뒤로 더 넓게 보여줘" → unique_key="1116-33", context=5
"이 문단만 딱" → unique_key="1115-B58", context=0
[Response]
{ standard:{std_num, title, category}, target, related_qnas:[doc_number], items:[…] }
items[]: { seq, item_type, unique_key, para_num, level, title, ref, content_text }
item_type: "paragraph" = 본문, "title" = 제목 행.
related_qnas: doc_number array (e.g. ["GKQA01-085"]) — feed each to get_qna.
Unknown key returns { error: "문단 없음: {unique_key}" }.
[Rules]
unique_key = "{기준서번호}-{문단번호}". 문단 numbers aren't digits-only (B58·AG12·SP1.2·6.1.1) — pass the value verbatim, never normalize it.
context expands within the same 기준서 part only — boundaries return fewer items; not an error.
Quote content_text, never a search snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | 앞뒤로 포함할 항목 수 (기본 2) | |
| unique_key | Yes | 문단 키 (예: '1116-33') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: response shape, item_type semantics, unknown-key error format, context boundary behavior within the same standard part, and the instruction to quote content_text rather than snippets.
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 structured into Purpose, Usage, Response, and Rules sections, each earning its place. The most critical guidance — exact quoting and the unique_key format warning — is front-loaded, and there is no filler or repetition.
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, the description fully documents the return structure including items fields, item_type values, related_qnas handling, and error responses. It also covers edge behavior such as context boundaries producing fewer items and non-numeric paragraph keys, making the tool safely callable without additional assumptions.
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 coverage is 100%, so both parameters are documented in the schema, but the description adds essential semantics: unique_key values are not always digits-only (B58, AG12, SP1.2) and must be passed verbatim, and context expands only within the same standards part. The examples directly tie the parameters to real user intent.
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 states a specific verb and resource: returns the full original text of an accounting standard paragraph with surrounding context. It clearly differentiates from search tools by stating that search snippets are never quotable evidence, which positions get_paragraph as the tool for exact quotation.
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 gives concrete usage examples ('1116호 33문단 원문', '앞뒤로 더 넓게 보여줘') and explains when to use context=0 versus context=5. It implies the alternative is any search tool's snippet output, but it does not explicitly name sibling tools like search_standards or search_qnas as the tools to use before get_paragraph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 get_qna 도구는 질의회신 전문을 반환합니다.
[Purpose]
The 회신 full text for a doc_number from search_qnas results or get_paragraph's related_qnas.
[Usage]
"2017-001 회신 전문" → doc_number="2017-001"
"GKQA01-085 원문" → doc_number="GKQA01-085"
[Response]
{ results:[{source, doc_number, date, title, rel_stds, full_content, org}] }
Miss returns { error: "문서번호 없음: {doc_number}", similar:[{source, doc_number, title}] } — up to 5 부분일치 candidates.
source / org / rel_stds carry the same meaning as in search_qnas.
[Rules]
results is an array and doc_number is NOT unique — the same 번호 can appear 2+ times (measured: "GKQA03-100" → 2 rows). Never answer from the first row alone.
번호 formats differ by series: "2021-G-KQA005" · "GKQA01-085" · "SSI-35551" · "2017-001" · "금감원사례-1". Pass the value as received — never alter case or separators.
On a miss, re-ask using similar rather than guessing another 번호.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_number | Yes | 질의회신 문서번호 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing that results is an array, doc_number is not unique, miss responses include a similar list with up to 5 candidates, and number formats must be preserved exactly. This gives an agent essential runtime expectations not inferable from the schema.
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 well-structured with Purpose, Usage, Response, and Rules sections, making important behavioral notes easy to find. The opening Korean sentence is somewhat redundant with the [Purpose] section, but the overall organization and front-loaded purpose keep it efficient.
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 one-parameter tool with no output schema, the description fully covers input semantics, response shape, error behavior, duplicate-row risk, and number-format variability. Nothing needed to invoke the tool correctly is missing.
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?
Even though schema coverage for doc_number is 100%, the description adds substantial meaning with usage examples and critical formatting rules such as passing the value exactly as received and never altering case or separators. This is more than a restatement of the schema.
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 that get_qna returns the full text of a 질의회신 for a given doc_number, sourced from search_qnas results or get_paragraph's related_qnas. This distinguishes it from sibling search/paragraph tools by naming the resource and the source context.
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 [Usage] section provides concrete natural-language-to-parameter examples and says the doc_number comes from search_qnas or get_paragraph. It gives clear context for when the tool is appropriate, though it does not explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 get_usage_stats 도구는 이 MCP 서버의 도구 사용량 통계를 반환합니다.
[Purpose]
Per-tool usage·latency (avg/percentiles)·error rate·daily trend.
[Usage]
"최근 30일 사용량" → (인자 없음)
"지난 7일만" → days=7
"전체 기간" → days=0
[Response]
Both tiers: { visibility, period:{days, since, until}, overview:{total_calls, unique_users, errors, error_rate, p50_ms, p90_ms, p99_ms}, by_tool:[{tool, calls, errors, error_rate, avg_ms, p99_ms, users}], by_day:[{day, calls}] }
visibility="public" adds note; period.days = "all" when days=0.
visibility="operator" adds users:[{user, is_owner, calls, distinct_tools, first_seen, last_seen, tools:[{tool, calls, avg_ms}]}] and top_targets:[{target, tool, calls, users}].
[Rules]
Tier by requester: admin token·local stdio → "operator", else "public".
users·top_targets exist only at operator tier — absence ≠ 0.
user is a truncated SHA-256 of the 접속 토큰 — not a person. stdio calls (no hash) never appear.
Timings = server-side handler time (no network).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 최근 N일 윈도 (0이면 전체 기간, 기본 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds substantial behavioral context: the public vs operator tier distinction, that users/top_targets are omitted at public tier where absence is meaningful, that user IDs are truncated SHA-256 hashes of tokens rather than person identifiers, and that timings are server-side handler times. This goes far beyond the 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 well-organized into Purpose, Usage, Response, and Rules sections, with the main purpose front-loaded first. Although it is longer than average, every section earns its place by adding operational detail that the schema and annotations do not provide, and it avoids redundancy.
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, the description fully compensates by specifying the complete response shape for both tiers, including field-level detail for overview, by_tool, by_day, users, and top_targets. It also covers tier determination, privacy implications of hashed users, and timing semantics, making the tool fully callable and interpretable by an agent.
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 schema already documents days with 100% coverage, including default 30 and 0 meaning the full period. The description adds practical usage mapping and clarifies that period.days becomes 'all' when days=0, which enriches the parameter's meaning beyond the raw schema.
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 returns usage statistics for the MCP server, with a specific bulleted list of what it measures: per-tool usage, latency percentiles, error rate, and daily trends. Sibling tools are all content lookups (paragraphs, QNA, standards), so this tool is unambiguously distinct as a metrics/statistics 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 gives explicit natural-language invocation scenarios ('recent 30 days' with no arguments, 'last 7 days' with days=7, 'entire period' with days=0), which clarifies when to call the tool and how to shape the request. It does not name alternatives or exclusions, but no sibling tool offers comparable usage statistics, so this level of guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 list_standards 도구는 수록된 기준서 카탈로그를 반환합니다.
[Purpose]
Which 기준서 are in the corpus, and which numbers feed search_standards' std_num filter.
[Usage]
"수록된 기준서 전부" → (인자 없음)
"감사기준서만" → category="audit"
"내부회계관리제도 관련" → category="icfr"
[Response]
{ count, standards:[{std_num, title, category}] }
category values: kifrs(한국채택국제회계기준) · interpretation(해석서) · concept(재무보고를 위한 개념체계) · kgaap(일반기업회계기준) · audit(감사기준서) · icfr(내부회계관리제도) · esg(KSSB 지속가능성 공시기준) · translation(번역본) · special(특수분야).
[Rules]
Lists 수집 성공(crawl_status='ok') 기준서 only — an absent 기준서 means "미수집", not "존재하지 않음".
category is a free-form string, not an enum: an unknown value returns count=0, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 카테고리로 필터 (생략 시 전체) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavior beyond annotations: it discloses that only crawl_status='ok' standards are listed and that an absent standard means '미수집' (not collected), not 'exists nowhere' — a crucial completeness caveat. It also documents that category is a free-form string where an unknown value yields count=0 rather than an error, plus the full response shape. All of this is consistent with readOnlyHint=true and idempotentHint=true; the openWorldHint=false annotation is not contradicted because the description clarifies exactly what absence means rather than asserting standard AI completeness semantics.
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 longer than average but every section earns its place: [Purpose], [Usage], [Response], [Rules] each carry distinct, non-redundant information. The core purpose is front-loaded in the first sentence, and the rules section condenses two subtle behavioral traps (crawl-status semantics, free-form category) into one compact block.
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 one optional parameter, annotations that already cover safety/idempotency, and no output schema, the description covers everything needed: response shape ({count, standards:[{std_num,title,category}]}), all category values, error semantics, completeness semantics, and sibling routing. Nothing an agent needs to call this tool correctly is missing.
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?
Even though schema coverage is 100%, the description goes far beyond the schema's terse '카테고리로 필터 (생략 시 전체)' by enumerating all eight accepted category values (kifrs, interpretation, concept, kgaap, audit, icfr, esg, translation, special) and the count=0-not-error behavior. Usage examples tie Korean phrasings to parameter values, which the schema alone does not provide.
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 opening line states a specific verb and resource: '수록된 기준서 카탈로그를 반환합니다' (returns the catalog of included standards). The embedded question 'Which 기준서 are in the corpus, and which numbers feed search_standards' std_num filter' explicitly positions it as the catalog feeder to the search sibling, making differentiation immediate.
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 Usage section maps natural-language intents to concrete invocations ('감사기준서만' → category="audit", '내부회계관리제도 관련' → category="icfr"), which is actionable guidance an agent can follow directly. The purpose statement names search_standards as the consumer of its output, clearly separating catalog enumeration from content search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 search_qnas 도구는 회계기준원·금융감독원·신속처리질의·IFRS 해석위원회 질의회신 3,669건을 전문검색합니다.
[Purpose]
Official 회신 for practice issues the 기준서 text alone cannot settle.
For 회신 tied to a specific 기준서 문단, get_paragraph's related_qnas is more precise.
[Usage]
"전환사채 콜옵션 회계처리 질의회신" → query="전환사채 콜옵션"
"리스료 재측정 회신 30건까지" → query="리스료 재측정", limit=30
[Response]
{ hits, results:[{source, doc_number, date, title, rel_stds, org, snippet}] }
source: "v2" = 현행 질의회신DB, "legacy" = 구 QnA. This is the 수록 세대, NOT the 회신 기관.
org: 회신 기관 — 회계기준원 / 금융감독원 / 신속처리질의 / IFRS 해석위원회 논의결과 / 구 QnA.
rel_stds is raw HTML: → unique_key "1109-6.1.1".
Empty query returns { error: "검색어가 비어 있음" }.
[Rules]
Tokenization matches search_standards (≥3 chars → FTS AND + rank, 1~2 chars → LIKE).
Never present source as the 회신 기관 — use org for that.
Strip the HTML tags in rel_stds before showing it; read data-std/data-id to build 문단 키.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수 (기본 10) | |
| query | Yes | 검색 키워드 (공백 구분) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the readOnly/idempotent/destructive annotations: tokenization rules (≥3 chars → FTS AND + rank, 1~2 chars → LIKE), empty-query error behavior, the fact that source indicates DB generation not 회신 기관, and that rel_stds is raw HTML requiring tag stripping and data-attribute parsing. No contradiction with annotations exists.
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 longer than typical, but every section earns its place given the tool's subtle field semantics (source vs org, raw HTML in rel_stds) that would otherwise mislead agents. Purpose is front-loaded and the [Purpose]/[Usage]/[Response]/[Rules] structure makes the density navigable.
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, the description carries the full burden of explaining return values, and it does: the response shape is given, each non-obvious field (source, org, rel_stds) is clarified, the empty-query error case is documented, and the tokenization contract is specified. Nothing an agent needs to call this correctly is missing.
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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by showing how to convert natural-language requests into effective queries ('전환사채 콜옵션 회계처리 질의회신' → query='전환사채 콜옵션'), demonstrating limit usage, and explaining query tokenization semantics. Concrete examples add real meaning the schema alone lacks.
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 first sentence states a specific verb (전문검색/full-text search) and a precise resource (3,669건의 질의회신 from four named authorities). It also differentiates from the sibling get_paragraph by noting that related_qnas is more precise for paragraph-specific 회신, so an agent can select correctly without opening schemas.
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 [Purpose] section states when to use this tool ('practice issues the 기준서 text alone cannot settle') and explicitly names the alternative (get_paragraph's related_qnas) with the condition that selects it. The [Usage] section gives two concrete query-building examples with exact parameter values, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 search_standards 도구는 K-IFRS·일반기업회계기준·감사기준서·내부회계관리제도·ESG(KSSB) 기준서 본문을 전문검색합니다.
[Purpose]
Find the 기준서 문단 grounding a treatment ("사용권자산 손상 is which 문단?").
For a hit's 원문·문맥, pass its unique_key to get_paragraph.
[Usage]
"사용권자산 손상 관련 기준" → query="사용권자산 손상"
"1116호 안에서만 리스료 재측정" → query="리스료 재측정", std_num=1116
"수익 인식 5단계 문단 30개까지" → query="수익 인식 단계", limit=30
[Response]
{ hits, results:[{std_num, std_title, category, unique_key, snippet}] }
unique_key = "{std_num}-{문단번호}" (e.g. "1116-33", "1109-6.1.1", "2-2.7") — feed to get_paragraph.
snippet marks matches with ⟦…⟧ and elides with "…".
Empty query returns { error: "검색어가 비어 있음" }.
[Rules]
Tokens of ≥3 chars go to FTS (AND-joined, rank-ordered); 1~2 char tokens become LIKE filters. Short-token-only queries work but are ordered by std_num, not relevance.
Body 문단 only (item_type='paragraph') — 제목 rows are excluded, so a hit is always body text.
snippet is a fragment, never the whole 문단 — do not quote it as 기준서 원문.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수 (기본 10) | |
| query | Yes | 검색 키워드 (공백 구분) | |
| std_num | No | 특정 기준서로 한정 (예: 1116) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, the description discloses token-length behavior (>=3 chars FTS vs 1-2 char LIKE), ordering behavior, item_type filtering, snippet truncation semantics, unique_key formatting, and the empty-query error contract. This is substantial behavioral detail far beyond what the annotations provide.
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 organized into clear sections ([Purpose], [Usage], [Response], [Rules]) and every sentence carries actionable information. It is reasonably long only because it documents edge cases and integration behavior, which is necessary for correct invocation.
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 search tool with three parameters and no output schema, the description covers input semantics, output shape, error behavior, filtering constraints, and downstream usage via get_paragraph. The response structure is explicitly documented, so an agent has enough information to call the tool and interpret its results correctly.
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?
Although the input schema already documents all parameters, the description adds operational meaning: query tokens are space-separated with different matching behavior by token length, std_num constrains to a specific standard such as 1116, and limit is shown with example values like 30. The unique_key format and snippet behavior also clarify how results relate to parameters.
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 begins with a specific verb and resource: full-text search across K-IFRS, general accounting standards, audit standards, internal accounting control, and ESG(KSSB) standard text. It clearly distinguishes itself from get_paragraph (which retrieves full metadata/context by unique_key) and from the Q&A-focused sibling search_qnas by stating that it searches 기준서 본문 only.
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 [Usage] section provides concrete query examples that map natural-language requests to parameter values, including query, std_num, and limit. It also explicitly tells the agent to pass a hit's unique_key to get_paragraph for full text, and the [Rules] section states exclusions such as title rows being filtered out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_paragraphget_qnaget_usage_statslist_standardssearch_qnassearch_standardsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Full-text search over FSS/FSC accounting supervision documents for Korean accounting professionals
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
IFRS engine: 31 standards, 21 tools. Journal entries, XBRL tags, ECL, CGU impairment, deferred tax.
Add one secure layer between your agents and this server.
The verb prefixes (get/search/list) plus distinct nouns (paragraph, qna, standards, usage_stats) make each tool's purpose unmistakable. search_standards and search_qnas target different corpora, and get_paragraph/get_qna retrieve by unique key versus full-text search, so no two tools overlap.
Every tool follows the verb_noun snake_case pattern: get/retrieves by key, search/does full-text queries, list/returns the catalog. The naming perfectly mirrors the tool behavior, making the set predictable and easy to navigate.
Six tools is well-scoped for a standards/Q&A reference server: catalog (list_standards), full-text search over two corpora (search_standards, search_qnas), keyed retrieval for each (get_paragraph, get_qna), and one telemetry tool. Each tool earns its place with no redundancy.
The core retrieval workflow is complete: list catalog → search corpus → fetch full text, and search Q&A → fetch Q&A response, with get_paragraph even linking to related Q&As. Minor gaps exist such as no way to browse a standard's full paragraph structure or enumerate Q&A documents without a search query, but agents can work around these.
