Skip to main content
Glama

verify_citations

아무 텍스트에 담긴 한국 법률 인용을 검증합니다 — 다른 LLM이 쓴 답변도 됩니다. 조문과 사건번호를 전부 추출해 검증 자산과 대조하고, 인용별 상태(verified_in_corpus 본문까지 대조 / verified_in_index 정본 색인에서 실재 확인 / absent_in_index 그 법령을 결번 없이 아는데 이 조문이 없음 / not_in_corpus 덮지 못함)를 출처 링크와 함께 돌려줍니다. 1회에 크레딧 1개를 사용합니다. LLM 미호출·결정론. 주의: not_in_corpus는 '이 코퍼스에 없다'는 뜻이지 '지어낸 인용'이라는 증명이 아닙니다 — law.go.kr에서 직접 확인하라는 표시입니다. 인용 실재(L1) 외에 네 축을 더 돌립니다: doctrine(법리 모순 — 조문이 실재해도 적용이 어긋나는 경우), currency(폐지·개명된 법령 인용), precedent_currency(이후 전원합의체가 견해를 변경하며 참조한 판례), support(인용 조문 본문에 그 수치가 실제로 있는가). 각 축은 검사 범위(scope)와 분모(examined·known_count·index_size)를 함께 냅니다 — findings 0 은 '정확하다'가 아니라 '그 축에서 안 잡혔다'는 뜻입니다. 전부 결정론이며 LLM을 부르지 않습니다. / Fact-check the Korean legal citations inside any text — including text another LLM produced. Returns per-citation status (verified_in_corpus = body matched, verified_in_index = existence confirmed in the authoritative index, absent_in_index = the law is indexed gaplessly and this article is not in it, not_in_corpus = not covered) with source links. Costs 1 credit per call. Deterministic, no LLM. IMPORTANT: Beyond citation existence (L1) it runs four more axes: doctrine (misapplied rule even when the provision exists), currency (repealed or renamed statutes), precedent_currency (cases referenced by a later en banc decision that states a change of position), and support (whether the figure claimed actually appears in the cited provision's text). Each axis reports its scope and denominator — findings==0 means 'nothing caught on that axis', not 'correct'. All deterministic, no LLM call. 'not_in_corpus' means the citation is NOT in this corpus — it is a flag to check manually at law.go.kr, not proof that the citation is fabricated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesText containing Korean legal citations (max 20000 chars).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.3/5.0
Behavior5/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, and it delivers substantially: deterministic operation, no LLM call, credit cost per call, and the exact semantics of not_in_corpus. It also explains that findings==0 means 'nothing caught on that axis' rather than 'correct', which is critical for interpreting results.

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 information-dense and well-structured, front-loading status definitions and the credit cost. However, the full Korean and English duplication roughly doubles the length, and the same semantics are repeated across languages, so it is not as concise as it could be.

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?

Without an output schema, the description must explain return semantics, and it does so thoroughly: per-citation status values, source links, four verification axes, scope and denominator reporting, and the meaning of zero findings. It also covers cost, determinism, and the practical implication of not_in_corpus, leaving no critical gap for an agent invoking this tool.

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 description coverage is 100%, so the schema already documents the single text parameter and its 20000-character limit. The description adds context about accepting arbitrary text and mentioning LLM-produced content, but no additional parameter-level syntax or format details beyond what the schema provides.

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 names a specific verb and resource: 'Fact-check the Korean legal citations inside any text' and enumerates per-citation statuses. It clearly distinguishes this verification tool from sibling search/lookup tools by focusing on validating citations in arbitrary text rather than retrieving statutes or precedents.

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 makes the input context explicit: any text, including text produced by another LLM, and explains what results are returned. It does not explicitly name sibling alternatives or state when not to use this tool, but the use case is clear 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools target clearly distinct resources (statutes, precedents, bar exam, documents, content, account), and cross-references in descriptions explicitly disambiguate similar actions like search vs lookup_statute vs lookup_precedent. A few close pairs exist (ask vs ask_expert, latest_content vs get_daily_content, bar_exam_search vs get_exam_answer), but each pair has clear differentiators.

Naming Consistency4/5

The set predominantly follows snake_case verb_noun naming (get_account, lookup_statute, verify_citations, generate_document). Minor deviations like latest_content (no verb) and bar_exam_search (noun-first) break the pattern, but the overall convention is readable and predictable.

Tool Count4/5

At 19 tools, the surface is on the heavier side but each tool addresses a distinct need across a broad legal domain (Q&A, research, document generation, bar exam corpus, content, account management). The count feels justified for the stated scope, though it approaches the upper boundary of reasonable.

Completeness4/5

The server covers the main legal workflows well: Q&A (ask, chat_leader), research (lookup_statute, lookup_precedent, search, verify_citations), document drafting (generate_document), and bar exam prep (bar_exam_search, get_exam_answer). Minor gaps exist, such as no browse/list-all endpoints for statutes or precedents and no way to manage generated documents, but agents can work around these.

Resources