LAWMADI is a Korean AI Legal Operating System that provides statute-verified legal analysis through 60 domain-specialized AI agents, with real-time cross-referencing against Korea's official legislative database (law.go.kr) using a fail-closed policy to prevent unverified citations.
Ask a legal question (ask): Submit queries in Korean or English, routed to the most relevant specialist among 60 AI legal agents, with multi-turn conversation history support.
Streaming legal Q&A (ask_stream): Receive real-time token-by-token responses via SSE, supporting general, leader chat, and expert modes.
Expert legal analysis (ask_expert): Run a full 4-stage pipeline for deep, comprehensive analysis with thorough statute verification — ideal for complex legal matters.
Search Korean law (search): Search across 14,601+ indexed Korean legal documents by topic or keyword (e.g., '근로기준법' / Labor Standards Act).
Suggest follow-up questions (suggest_questions): Get 3 AI-generated contextual follow-up questions based on your query and the assigned specialist's domain.
List all legal agents (get_leaders): Retrieve profiles, names, and specialties of all 60+ AI legal specialists covering labor, family, criminal, IP, tax, immigration, and more.
Chat with a specific agent (chat_leader): Have a 1:1 SSE streaming conversation with a specific legal specialist (e.g., 'L01', 'L32') for focused, domain-specific guidance.
Compatible with Claude Desktop, Cursor, and any MCP client.
Integrates with Paddle for payment processing, handling credit purchases for legal services.
법마디(Lawmadi)는 대한민국 AI 법률 운영체제(OS)이다. 60명의 분야별 전문 AI 법률 리더가 국가법령정보센터 법령을 실시간 검증하여 법률 분석을 제공한다.
Lawmadi is a Korean AI Legal Operating System. 60 domain-specialized AI legal leaders provide statute-verified legal analysis using Korea's official legislative database (law.go.kr) in real-time.
lawmadi.com · MCP Server · API Docs · llms.txt
Korean legal questions require answers grounded in actual statutes — not AI hallucinations. Lawmadi OS ensures every legal citation is verified against Korea's National Law Information Center (law.go.kr) in real-time. If verification fails, the system blocks the answer rather than providing unverified information (fail-closed principle).
Lawmadi is an OS, not an LLM wrapper. Answer quality is guaranteed by the verified-asset layer (SSOT) + grounding + fail-closed verification — not by which LLM happens to generate the text. Today Gemini powers responses, but the goal is that any LLM can be swapped in and produce the same quality of answer. The LLM is a replaceable component; the moat is the asset & verification layer. The verification pipeline sits after generation and rejects unverified citations regardless of the model that produced them.
법마디를 "OS"라 부르는 이유: 답변 품질은 어떤 LLM을 쓰는가가 아니라 검증 자산(SSOT) + 그라운딩 + fail-closed 검증 계층이 보장합니다. 지금은 Gemini가 응답하지만, 어떤 LLM으로 교체해도 동일 품질을 내는 것이 궁극 목표입니다. LLM은 교체 가능한 부품이고, 시스템의 해자는 자산·검증 레이어입니다.
Related MCP server: Korean Law MCP Server
60 Legal Domains — Labor, housing, divorce, criminal, tax, corporate, IP, immigration, and 52 more specialized areas
Real-time Statute Verification — Every cited law article is cross-checked against law.go.kr DRF API. Zero hallucination policy
Multi-Agent Architecture — NLU routes each question to the most relevant specialist among 60 AI legal leaders
Bilingual — Full Korean & English support (lang: ko / lang: en)
MCP Compatible — Works with Claude Desktop, Cursor, and any MCP client (6 tools available)
Free Credits — 3 free credits granted one time on login (non-recurring). Purchased credits never expire — use anytime
A dedicated study hub organizes Korean Bar Exam (변호사시험) answers by format × subject × round, so candidates can review everything in one place (lawmadi.com/exam-essays).
선택형 (MCQ) — All 15 exams to date (제1회~제15회, 2012–2026). Official Ministry of Justice question stems and choices are shown verbatim alongside the answer, per-option ○/× explanations, and the supporting statute/precedent for each item. Readable for direct study.
금답안 (Gold-Standard Answers) — 제615회 (2017–2026) 선택형 1,500문항: every option carries an inline citation (statute name + article, or the exact Supreme Court / Constitutional Court docket) with a working law.go.kr deep link (precSc.do / detcSc.do). Each docket is fail-closed verified against law.go.kr before publishing. Only gold-verified rounds are published — non-gold rounds (currently 제15회) are withheld from every published surface until they pass the gold gate.
판례번호·조문 검색 (Case-Number / Statute Search) — lawmadi.com/exam-search: a client-side search index over the published gold rounds (제6~15회 선택형 전과목 1,500문항·판례 2,312종). Look up any question by Supreme Court / Constitutional Court docket (e.g. 2014도6992), statute article (e.g. 형법 제310조), or keyword, with each docket linking to its law.go.kr source.
사례형 · 기록형 (Essay / Record) — Per-leader worked solution examples, organized by 공법 · 민사법 · 형사법 · 선택과목.
Exam-faithful structure — Scoring metadata follows the official 변호사시험법 시행령 layout (공법·형사법 선택형 40문항/100점, 민사법 70문항/175점; 총점 1,660점).
Every cited statute and precedent in a published answer is cross-checked against law.go.kr. A CI hard gate blocks publishing on any hallucinated citation. To stay independent of law.go.kr outages, cited statutes (361 laws cached) and precedents (10,777 cases cached) are pre-fetched, so verification runs offline and a transient network failure never publishes unverified content. The gate distinguishes infrastructure failures (re-run) from genuine hallucinations (block), and re-verifies only the items that changed via an incremental OK-set cache.
Because the answer pages render client-side, the build injects static ItemList JSON-LD (선택형 entries carry the official question stems) and registers every answer deep-link (view=choice / view=essay) in sitemap.xml, making each round/subject answer discoverable in search. The build also emits exam-search-index.json (published gold rounds only, with each question's docket/statute list) powering the /exam-search page, which exposes a WebSite + SearchAction schema so search engines surface the case-number search box directly. A gold publish gate (gold_rounds(), keyed on _lint_gold_format) excludes any non-gold round (currently 제1~5회) from every published artifact — exam-detail, exam-essays JSON-LD, the search index, and sitemap answer links — so only verified gold answers ever go live.
Two analytical tools complement the gold-standard answers:
출제·인용 히트맵 (Exam & Citation Heatmap) — lawmadi.com/heatmap: for every article across the 7 core laws, a dual bar compares bar-exam frequency (gold, confirmed exam appearances) against precedent-citation frequency (blue), so high-yield articles surface even when one signal alone would bury them. Supports citation-order / exam-order sorting and links each article to its representative precedent's law.go.kr source.
판례 생존율 (Precedent Survival) — lawmadi.com/case-survival: tracks whether a key precedent was later upheld, modified, or overruled, so you can tell whether a holding is still good law.
Each of the 60 legal leaders has a prerendered profile in both Korean (/leader-profile/L01) and English (/leader-profile-en/L01) at clean, crawlable URLs with per-leader metadata and hreflang alternates — no ?id= query parameters.
User Query → NLU Router (selects 1 of 60 specialists)
│
├─ Stage 0: Query Classification (intent + domain detection)
├─ Stage 1: RAG Statute Search (Vertex AI Search, 44,085+ docs) ← parallel
├─ Stage 2: Gemini 3.5 Flash Analysis (leader persona + 5-step legal framework)
└─ Stage 3: DRF Verification (real-time, exhaustive law.go.kr article + precedent check)
│
▼
Verified Legal Response (with statute citations + enforcement dates)Every response passes through a 4-stage pipeline. Stage 3 (DRF Verification) cross-references all cited statutes against the official Korean legislative database. If any citation cannot be verified, the system regenerates or blocks the response — never passes unverified legal information to the user.
Add to your MCP client configuration:
{
"mcpServers": {
"lawmadi": {
"url": "https://lawmadi.com/mcp"
}
}
}6 tools available: ask, ask_expert, search, get_leaders, chat_leader, suggest_questions
# Korean legal question
curl -X POST https://lawmadi.com/ask \
-H "Content-Type: application/json" \
-d '{"query": "부당해고를 당했는데 어떻게 해야 하나요?", "lang": "ko"}'
# English
curl -X POST https://lawmadi.com/ask \
-H "Content-Type: application/json" \
-d '{"query": "My landlord won't return my deposit", "lang": "en"}'git clone https://github.com/peter120525-cmd/lawmadi-os-v60.git
cd lawmadi-os-v60
cp .env.example .env # Fill in your API keys
pip install -r requirements.txt
python main.pyRequired: GEMINI_KEY, LAWGO_DRF_OC (law.go.kr API key), PostgreSQL
Layer | Component | Technology |
Backend | FastAPI + Uvicorn | Python 3.10, Cloud Run (Seoul) |
LLM | Gemini 3.5 Flash ( | Single model, automatic 429 exponential backoff + fallback |
RAG | Vertex AI Search | 44,085+ legal documents indexed (30,995 statutes · 10,840 precedents · 2,250 exam Q&A) |
Verification | DRF API (law.go.kr) | Real-time, exhaustive statute + precedent cross-check (361 laws / 10,777 cases cached offline) |
Database | Cloud SQL | PostgreSQL, encrypted connections |
Frontend | Firebase Hosting | Static HTML/CSS/JS (CSR), Korean + English |
MCP | custom JSON-RPC ( | HTTP/SSE transport, 6 tools |
Payments | Paddle | Credit packs: ₩2,100 / ₩7,000 / ₩13,800 |
Endpoint | Method | Description |
| POST | Legal question → verified analysis |
| POST | Same, SSE streaming |
| POST | Expert mode (full pipeline) |
| GET | List all 60 specialist agents |
| POST | 1:1 chat with a specific agent |
| GET | Search Korean legal topics |
| POST | AI-generated follow-up questions |
| SSE | MCP protocol endpoint |
| GET | Service health check |
Civil Law · Real Estate · Construction · Urban Redevelopment · Medical Law · Damages · Traffic Accidents · Lease & Housing · Government Contracts · Civil Enforcement · Debt Collection · Registry & Auction · Commercial Law · Corporate & M&A · Startup & Venture · Insurance · International Trade · Energy & Resources · Maritime & Aviation · Tax & Finance · IT & Cybersecurity · Criminal Law · Entertainment · Tax Appeals · Military Law · Intellectual Property · Environmental Law · Trade & Customs · Gaming & Content · Labor & Employment · Administrative Law · Fair Trade · Space & Aerospace · Privacy & Data Protection · Constitutional Law · Cultural Heritage · Juvenile Law · Consumer Protection · Telecommunications · Human Rights · Family & Divorce · Copyright · Industrial Accidents · Social Welfare · Education & Youth · Pension & Insurance · Venture & New Industries · Arts & Culture · Food & Health Safety · Multicultural & Immigration · Religion & Tradition · Media & Press · Agriculture & Livestock · Marine & Fisheries · Science & Technology · Disability Rights · Inheritance & Trust · Sports & Leisure · Data & AI Ethics · General Legal
pytest tests/ -v # 657 testsLawmadi OS uses a dual-licensing model — the software and the legal content are licensed separately.
Software / code — AGPL-3.0: You may use, modify, and distribute this software. If you run a modified version as a network service, you must release your source code under the same license. Software copyright (c) 2025-2026 Choe Jainam (최재남).
Legal content / data — Proprietary, All Rights Reserved: AGPL-3.0 covers the software, not the data or content. The bar-exam gold-standard answers (변호사시험 금답안 — 선택형·사례형·기록형 and their explanations/citation indexes), AI-generated legal analyses and leader-persona outputs, verified legal-asset compilations (SSOT statute & precedent datasets), and daily legal content are proprietary and are NOT licensed under AGPL-3.0. Content copyright (c) 2026 Choe Jainam (최재남). Scraping, bulk extraction, redistribution, AI/ML training, fine-tuning, embeddings, RAG ingestion, or creating derivative/competing products from this content requires prior written permission (peter120525@gmail.com).
Ask
Main legal question endpoint — routes to 1 of 60 specialist agents with real-time statute verification.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Legal question in Korean or English (max 2000 chars). Example: '부당해고를 당했는데 어떻게 해야 하나요?' | |
| history | No | Conversation history (max 6 recent turns). Each item: {role: 'user'|'model', content: '...'} | |
| lang | No | Response language: 'ko' (Korean) or 'en' (English). Auto-detected from query if omitted. | |
| current_leader | No | Current leader context for handoff/deliberation. | |
| is_first_question | No | Whether this is the user's first question in the session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it routes to specialist agents and performs real-time statute verification, which provides some behavioral context but does not disclose deeper details like authentication needs, rate limits, or potential selection logic. With strong annotations, the description adds moderate value.
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 cluttered with unnecessary response schema code blocks (e.g., for 200 and 422) that are not standard in MCP descriptions. The opening 'Ask' as a header feels redundant. Key information about the routing and verification is concise, but the overall structure is not efficient, with embedded JSON schemas adding noise.
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 5 parameters, nested objects, and no output schema, the description fails to explain the success response structure (the 200 output schema is empty). It does not confirm that the answer is returned in the response. The tool's behavior regarding history handling, language detection, and leader context is not elaborated. Completeness is insufficient for an agent to reliably invoke and interpret results.
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?
Input schema has full description coverage (100%), so baseline is 3. The description does not add new information about parameters; it focuses on overall functionality. The schema itself describes the query, history, lang, current_leader, and is_first_question with examples and constraints. The description's contribution to parameter understanding is negligible.
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 it is the 'main legal question endpoint' that routes to 1 of 60 specialist agents with real-time statute verification. This clearly identifies the tool's purpose: answering legal questions. The verb 'ask' and resource 'legal question' are specific, and the mention of 'main' helps distinguish it from sibling tools, though not explicitly.
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 implies this is the primary tool for legal questions but does not provide explicit guidance on when to use this tool versus siblings like ask_expert_ask_expert_post or ask_stream_ask_stream_post. No when-not or alternative recommendations are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Expert
Expert mode — full 4-Stage Legal Pipeline with deep analysis and comprehensive statute verification.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Legal question for expert analysis (max 2000 chars). | |
| original_response | No | Original /ask response for deeper expert analysis. | |
| lang | No | Response language: 'ko' or 'en'. Auto-detected if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about a '4-Stage Legal Pipeline' but does not expand on specific behavioral traits like rate limits, auth needs, or what 'deep analysis' entails. No contradiction with 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 overly verbose with detailed HTTP response schemas (200, 422) and example response objects. These are not essential for an AI agent to understand the tool's purpose and usage; the core description is only the first sentence. This hinders quick scanning.
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 the tool's complexity (deep legal analysis) and no output schema, the description does not explain what the successful response contains. It only shows a generic validation error schema. The agent is left without expectations for the return value, making the description incomplete.
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 input schema provides 100% coverage with descriptions for all three parameters (query, original_response, lang). The tool description adds no extra meaning beyond what the schema already states, so a baseline score of 3 is appropriate.
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 is for 'Expert mode — full 4-Stage Legal Pipeline with deep analysis and comprehensive statute verification.' This verb+resource combination (ask expert) distinguishes it from sibling tools like 'ask' which likely offers a simpler analysis.
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 implies this is for deeper analysis ('expert mode') compared to a regular ask, but does not explicitly state when to use this versus alternatives, nor are there any when-not-to-use or prerequisite conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Stream
SSE streaming legal question — real-time token-by-token response with statute verification.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Legal question in Korean or English (max 2000 chars). | |
| history | No | Conversation history (max 6 recent turns). | |
| lang | No | Response language: 'ko' or 'en'. Auto-detected if omitted. | |
| mode | No | Stream mode: 'general' (default), 'leader_chat', or 'expert'. | general |
| current_leader | No | Current leader context for handoff. | |
| leader_id | No | Specific leader ID (e.g. 'L01') for 1:1 chat mode. | |
| is_first_question | No | Whether this is the user's first question in the session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows it's a safe read operation. The description adds that it uses SSE streaming and statute verification, but lacks details on streaming behavior (e.g., event types, connection lifecycle) that would be helpful beyond 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 includes verbose response code sections and a full JSON error schema, which may be excessive. It could be more concise while retaining key streaming and verification context. Front-loading is adequate but could be improved.
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 the complexity of a streaming tool with 7 parameters (including nested objects and optional fields), the description does not explain how to handle the streaming response (e.g., event types, termination). Output schema for success is empty, leaving the agent without return structure information. Annotations provide some safety context but behavioral guidance is incomplete.
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?
Input schema has 100% coverage with descriptions for all 7 parameters, so the schema does the heavy lifting. The description does not add per-parameter details beyond what the schema provides, but the mention of 'statute verification' gives high-level context not in 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 identifies the tool as a streaming legal question tool with real-time token-by-token response and statute verification. It distinguishes itself from siblings by mentioning SSE streaming, though it doesn't explicitly compare to ask_ask_post which likely is non-streaming.
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?
No guidance is provided on when to use this streaming tool versus siblings like ask_ask_post, ask_expert, or chat_leader. The description does not mention context or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chat Leader
1:1 chat with a specific legal specialist leader via SSE streaming.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| leader_id | Yes | Leader identifier (e.g. 'L01', 'L32', 'CCO'). Use GET /api/leaders to see all available leaders. | |
| query | Yes | Question to ask the specific leader (max 2000 chars). | |
| history | No | Conversation history with this leader. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it uses SSE streaming, which is behavioral context. However, it lacks details on how state is managed or what side effects occur, so it provides only marginal extra value over 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 verbose, including unnecessary details about response codes and output schemas after the initial purpose statement. The core message is front-loaded, but the excess information reduces conciseness.
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?
The tool is a streaming chat with a leader, but the description does not explain how the SSE streaming works, how history is used, or what the response format is. The output schema is empty, leaving agents unaware of the response structure. This is incomplete for the tool's complexity.
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 description coverage is 100%, with each parameter already well-documented in the schema. The description adds no further parameter semantics, so it meets the baseline of 3.
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 '1:1 chat with a specific legal specialist leader via SSE streaming', specifying the action (chat) and the resource (legal specialist leader). However, the title in annotations is 'Chat with Legal Agent', which is clearer. The description could differentiate more from sibling 'ask' tools but is sufficient.
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?
No explicit guidance on when to use this tool versus siblings like ask_post or ask_expert_post. The description does not mention prerequisites or alternatives, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Leaders
List all 60+ specialist legal agents (leaders) with their names, specialties, and profiles.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it returns names, specialties, and profiles, but no further behavioral details such as pagination or ordering. No contradiction with 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 relatively short but includes a redundant 'Responses' section with output schema that is empty. Could be more concise by removing that section.
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 no parameters and a simple list operation, the description adequately covers what the tool returns. The presence of annotations compensates for missing details. The redundant response section does not detract significantly.
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 tool has zero parameters, so description does not need to add parameter meaning. Baseline score of 4 applies as per guidelines.
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 lists all 60+ specialist legal agents with names, specialties, and profiles. It uses a specific verb (list) and resource (leaders), and distinguishes itself from sibling tools which involve asking or searching.
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 implies the tool is for listing all leaders, but provides no explicit guidance on when to use it versus alternatives like search_search_get. It lacks exclusion criteria or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query for Korean law topics (min 2 chars, max 200 chars). Example: '근로기준법' | |
| limit | No | Maximum number of results to return (1-100, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond these, missing opportunities to mention rate limits, return format, or pagination.
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 very brief but includes irrelevant HTTP response schemas, making it cluttered. It fails to front-load key information.
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 simple search tool with 2 parameters and good annotations, the description should mention result format or behavior. It does not, leaving the agent underinformed.
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 covers 100% of parameters with clear descriptions for 'q' and 'limit'. The description adds no additional semantic information, so baseline score of 3 is appropriate.
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 is merely 'Search' followed by HTTP response documentation, failing to clearly state what the tool does. The title 'Search Korean Law' provides some clarity, but it's not in the description.
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?
No guidance on when to use this tool versus siblings like 'ask_ask_post' or 'chat_leader_api_chat_leader_post'. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest Questions
Suggest 3 contextual follow-up questions based on the current query and leader specialty.
200: Successful Response (Success Response) Content-Type: application/json
Output Schema:
{}422: Validation Error Content-Type: application/json
Example Response:
{
"detail": [
{
"loc": [],
"msg": "Message",
"type": "Error Type"
}
]
}Output Schema:
{
"properties": {
"detail": {
"items": {
"properties": {
"loc": {
"items": {},
"type": "array",
"title": "Location"
},
"msg": {
"type": "string",
"title": "Message"
},
"type": {
"type": "string",
"title": "Error Type"
}
},
"type": "object",
"required": [
"loc",
"msg",
"type"
],
"title": "ValidationError"
},
"type": "array",
"title": "Detail"
}
},
"type": "object",
"title": "HTTPValidationError"
}| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Current user question (max 500 chars). | |
| leader | No | Current leader name (e.g. '담우'). | |
| specialty | No | Current leader's legal specialty (e.g. '노동법'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the number of questions (3) and input context, but does not disclose additional behaviors like rate limits or validation responses beyond the 422 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 short but includes verbose OpenAPI response details (200, 422 schemas) that bloat the definition. It is not efficiently concise and could be streamlined.
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?
The description mentions success and error responses, but the success output schema is empty, leaving the agent uncertain about the response format. It does not explain how the 3 questions are returned (e.g., as a list). This is incomplete for a tool with no output schema.
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% with each parameter described. The description mentions 'query and leader specialty' aligning with schema, but does not add new meaning or examples beyond schema for 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 clearly states it suggests 3 contextual follow-up questions based on query and leader specialty. This is a specific verb+resource pair and distinguishes from sibling tools like ask or search.
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 implies usage (when follow-up questions are needed) but does not explicitly state when to use vs alternatives or when not to use. No exclusion criteria provided.
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.
v60.0.6chat_leader_api_chat_leader_postv60.0.5chat_leader_api_chat_leader_postv60.0.2ask_ask_postask_expert_ask_expert_postask_stream_ask_stream_postchat_leader_api_chat_leader_postget_leaders_api_leaders_getsearch_search_getsuggest_questions_suggest_questions_postThe tools are mostly distinct in purpose (basic query, expert mode, streaming, chat with leader, list leaders, search, suggest questions), though some overlap exists between the various 'ask' tools. Descriptions help differentiate but an agent might still be confused about which to use.
Tool names are inconsistent and awkward, often duplicating segments (e.g., 'ask_ask_post', 'ask_expert_ask_expert_post') and mixing path components. This auto-generated style lacks a clear, user-friendly pattern.
With 7 tools, the server is well-scoped for a legal Q&A system. Each tool serves a distinct function without being too few or too many.
The tool set covers core interactions: asking questions (multiple modes), listing specialists, searching, and suggesting follow-ups. Minor gaps exist (e.g., no history or feedback), but the main workflow is supported.
LawOracle — 20 legal AI tools: case law search, contracts, EU regulations, citation graph.
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Curated Korean AEC expertise for AI agents — codes, practice, and the reasoning between them.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/peter120525-cmd/lawmadi-os-v60'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
