Skip to main content
Glama
Sign In

lawmadi-os

by io.github.peter120525-cmd
OverviewDiscussionsAdmin

verify_citations

[KEY REQUIRED · 1 credit] 아무 텍스트에 담긴 한국 법률 인용을 검증합니다 — 다른 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

NameRequiredDescriptionDefault
textYesText containing Korean legal citations (max 20000 chars).
client_tagNo선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / text / maxLength
      Added value: +20000
  2. Changed1 schema field changed
    • addedInput schema / properties / client_tag
      Added value: +{
+  "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+  "type": "string"
+}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full burden and does so: it declares the cost (1 credit per call), the auth requirement (key required), determinism with no LLM call, and the precise meaning of each returned status including a warning against misreading not_in_corpus as proof of fabrication. It also pre-empts a subtle statistical misread by explaining that findings==0 is scoped to an axis and denominator rather than a global 'correct' verdict — behavior no annotation or schema could convey.

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?

Front-loaded with the two things an agent must know before deciding to call: key required and 1 credit, then the operation, then the caveat. The status and axis glossaries earn their space. The main cost is that the entire payload is duplicated in Korean and English back to back, roughly doubling length with no new information for a single reader.

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?

There is no output schema, so the description must describe returns — and it does, enumerating all four citation statuses with their exact semantics and describing the four extra axes with their scope/denominator reporting. Combined with cost, determinism, and the anti-misinterpretation caveat, an agent has everything needed to call this correctly and to interpret the result honestly.

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% and the client_tag field is documented in exhaustive detail in the schema itself (length, allowed characters, log-only, non-rejecting). The description adds nothing about 'text' beyond what the schema states (max 20000 chars), so the baseline 3 applies — the schema is doing the parameter work.

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?

States a specific verb and resource — verifying Korean legal citations embedded in arbitrary text — and immediately widens the scope to 'text another LLM produced', which is exactly the disambiguation an agent needs against lookup_statute/lookup_precedent (single-artifact lookups vs. whole-text verification). The output unit (per-citation status + source links) is named up front.

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?

Clearly establishes the context of use (you have prose containing citations and want to check them) and adds an explicit interpretation guardrail: not_in_corpus means 'check manually at law.go.kr', not 'fabricated'. It stops short of naming an alternative sibling or stating exclusions (e.g., 'for a single statute lookup use lookup_statute'), so it is clear but not fully routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All lawmadi-os toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources