LAWMADI
Server Quality Checklist
Latest release: v60.0.6
- Disambiguation4/5
The 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.
Naming Consistency2/5Tool 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.
Tool Count5/5With 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.
Completeness4/5The 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.
Average 3.1/5 across 7 of 7 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1315 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior2/5
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.
Conciseness2/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose2/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness2/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness3/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness2/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness2/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness2/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness3/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
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
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
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