vn-luat-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct but there is potential confusion between semantic search (tim_ngu_nghia) and keyword search (tra_luat, tra_van_ban). Descriptions clarify usage, but slight overlap exists.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., liet_ke_an_le, tra_luat, xem_dieu_luat). No mixed conventions.
Tool Count5/5
12 tools is well-scoped for a legal research server, covering searching, viewing, listing, statistics, and term lookups without being overwhelming.
Completeness4/5
The tool set covers core CRUD operations for legal documents and case law. Minor gaps exist, such as no direct tool to list all documents by date or type, but semantic search compensates.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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?
No annotations are provided, so the description must fully convey behavioral traits. It only states the action without mentioning performance, error handling, case sensitivity, or whether it is read-only. This is insufficient transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. No extraneous information, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, and with only minimal description of the tool's function, the context is incomplete. Important details such as what the tool returns, how to interpret results, and the effect of 'gioi_han' are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameters 'tu' or 'gioi_han'. While 'tu' is likely the term, and 'gioi_han' likely a result limit, no meaning is added beyond the parameter names. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a dictionary lookup tool for Vietnamese-English legal terminology, specifying the verb 'tra' (look up) and the resource 'từ điển thuật ngữ pháp lý Việt–Anh'. However, it does not distinguish itself from sibling tools like 'tra_van_ban' or 'tra_luat', which could have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives such as 'tim_ngu_nghia' or 'tra_van_ban'. The description lacks explicit context for when this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions listing 90 items but does not disclose behavioral traits such as return format details (e.g., pagination), authentication needs, or whether it is read-only. The description adds minimal behavioral context beyond the basic listing capability.
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?
The description is concise with two sentences. The first sentence front-loads the core purpose and output fields. The second adds filtering instructions and references to sibling tools. No wasted words, though the parameter information is sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return fields (number, title, year, illustrative judgments) but omits important details like the meaning of the limit parameter, pagination behavior, or any ordering. Given the absence of an output schema, more completeness could be expected, but the description provides adequate basic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its two parameters (nam, gioi_han). The description only partially explains the 'nam' parameter by mentioning 'Lọc theo năm nếu cần' (filter by year if needed). The 'gioi_han' parameter is not explained at all; its default of 100 is stated in the schema but no meaning is added.
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 clearly states the tool lists 90 official Vietnamese precedents with specific fields (number, title, year, illustrative judgments). It distinguishes from sibling tools by referencing xem_an_le_ct and tra_an_le_ct for full text and keyword search.
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 explicitly mentions filtering by year and directs users to other tools for full text (xem_an_le_ct) and keyword search (tra_an_le_ct), providing clear context on when to use alternatives. However, it lacks explicit when-not-to-use guidance.
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?
No annotations provided. The description implies a read-only operation but does not explicitly state idempotency, side effects, or access requirements. For a simple listing tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; the description partially explains the return includes topics and counts but lacks details on format or structure. More complete for a simple list tool, but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, so schema coverage is 100%. The description implicitly indicates the tool returns all topics, which is sufficient given zero parameters.
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 clearly states the tool lists topics and the number of items in the Legal Code, using specific Vietnamese terms. It distinguishes from siblings like 'liet_ke_an_le' (list case law) by specifying 'topic' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'thong_ke' (statistics) or other list tools. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses truncation behavior, the option for full text via day_du, and handling of multiple illustrative judgments. This covers key behavioral traits, though it could mention any side effects or prerequisites (e.g., authentication).
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?
The description is concise, using bullet points and brief explanations. It efficiently communicates key points without unnecessary verbosity. Could be slightly more structured, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers input identification, parameter usage, and output behavior for multiple results. However, it lacks details about the output format for single results (e.g., whether full text is returned directly) and exact character limits for truncation. Fairly complete for a simple tool but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'dinh_danh' parameter by giving examples of valid identifiers (official numbers vs doc_name) and clarifies the 'day_du' parameter's effect. This adds meaning beyond the schema titles, though exact format rules could be more precise.
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 clearly states the tool is for viewing full text of a precedent/judgment. It distinguishes between official precedents and illustrative judgments based on input format, and mentions behavior when multiple results are found. This is specific and leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to format input identifiers and notes the default truncation behavior with the day_du parameter. However, it does not explicitly compare to sibling tools like 'tra_an_le' or 'liet_ke_an_le', nor does it say when not to use this tool. Some context provided, but lacks comparative guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns counts based on parameters, implying a read-only operation. However, it does not mention potential errors, rate limits, or what happens with invalid inputs, leaving some opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for the main purpose followed by bullet-pointed examples. It front-loads the core action and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low schema coverage, the description covers the main functionality but lacks details on return format, error handling, or boundary conditions. While adequate for simple counting, it leaves gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining parameters through examples. It defines 'loai' values (tong_quan, dieu_luat, ban_an) and 'nhom_theo' options for specific types. This adds significant meaning, though not all possible values are enumerated.
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 clearly states the tool's purpose: counting/statistics on data ('Đếm/thống kê số lượng trong kho dữ liệu'). It distinguishes from sibling tools like 'liet_ke_an_le' (listing) by focusing on aggregation, and the examples clarify the exact operations.
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 provides explicit usage patterns with parameter combinations (e.g., loai='tong_quan', loai='dieu_luat' with nhom_theo). This helps the agent decide when to use the tool, though it lacks explicit 'when not to use' or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses pagination bounds (gioi_han â‰¤50, offset), response structure (tong_so, offset, so_tra, con_nua, ket_qua), and possible empty results with hints. It also details the return fields for each loai. Minor omission: no explanation of scoring ('diem') mechanism.
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?
The description is structured with a general statement followed by a bullet-like breakdown of each loai. All sentences are informative with no redundancy. Slight improvement could be explicit section separation, but overall efficiently communicates key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the full return structure. It covers pagination, loai options, and empty result behavior. Missing minor details: error conditions, scoring explanation. Still, for a search tool with multiple modes, it offers sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage). The description compensates by explaining all four parameters: tu_khoa as the search keyword, loai with three enumerated values and their return differences, gioi_han with max 50, offset default 0. Each parameter's purpose is clarified beyond the schema titles.
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 clearly states the tool searches for Vietnamese precedents (ÃN Lá») by keyword with full-text ranking. It distinguishes three modes (loai) with specific return fields, making it distinct from sibling tools like liet_ke_an_le.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three modes (chinh_thuc, ban_an, cau) and their typical use cases (full precedent, illustrative judgment, precise sentence). However, it doesn't explicitly compare with sibling tools or advise when to choose this over liet_ke_an_le or tim_ngu_nghia.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It discloses that the tool searches full text and can find parts omitted in codified versions (preambles, appendices, etc.). It also clarifies that the chu_de filter is for groups not yet codified. While it doesn't mention rate limits or authentication, the read-only nature is implied and additional context like pagination defaults (offset/gioi_han) are not explained but are present in schema.
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?
The description is concise enough, with most sentences adding value. It is front-loaded with the main purpose. Some redundancy exists (e.g., repeating the contrast with tra_luat), but overall efficient. The warning about missing topics is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description explains the core functionality and differentiates from siblings. However, it lacks details on the return format (e.g., list of documents, structure) and does not cover pagination parameters. It is adequate but not fully complete for an agent to fully understand inputs and outputs.
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 coverage is 0%, so the description must explain parameters. It explains 'loai' with examples (Nghị định, Thông tư, Luật) and 'chu_de' with specific values (Đất đai, Thi đua) and its purpose. However, 'tu_khoa', 'offset', and 'gioi_han' are not described. The keyword parameter is obvious but pagination details are missing.
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 clearly states it searches full text of original documents (Official Gazette) and explicitly contrasts with the sibling tool tra_luat which searches codified articles. The verb 'Tìm' and resource 'văn bản gốc' are specific. It differentiates by stating it can find omitted parts like preambles and appendices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Khác tra_luat... dùng khi cần bản gốc đầy đủ' (use when needing full original documents). It also gives a concrete example for land/emulation topics that are not in codified law, instructing to use this tool with chu_de='Đất đai'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a list if multiple matches exist, defaults to truncating at ~15,000 characters, and offers a 'day_du' option for full text. It also mentions the source (Công báo Chính phủ). No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is fairly concise but could be better structured (e.g., using bullet points). It front-loads the purpose and adds important notes. It is not overly verbose, but some organization would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the tool's purpose, usage, parameter explanations, and special cases (duplicates, truncation). It does not mention error handling or rate limits, but for a retrieval tool with 3 parameters, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains 'so_hieu' with an example, clarifies 'loai' as a disambiguation parameter with concrete types, and describes 'day_du' as a boolean to retrieve full text. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves official documents by number, including metadata and full text from the Government Gazette. It uses a specific verb 'Xem' and resource 'VĂN BẢN GỐC'. While it mentions the uniqueness issue, it does not explicitly differentiate from sibling tools like 'tra_van_ban' or 'xem_dieu_luat'.
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 provides guidance on when to use the tool and how to handle duplicate results by using the 'loai' parameter. It also explains the default behavior (truncation) and how to get full text. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses input format, outputs (original text, citation, amendment status), and list behavior for multiple matches. No mention of error cases or limitations, but sufficient for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description explains return components. Briefly covers multi-match case. Could specify format (e.g., structured vs plain text) but adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description provides an example ('9.1.LQ.385') and explains behavior for multiple matches, adding significant meaning beyond schema.
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?
Description clearly states mapping from codified article code to original text, standard citation, and amendment status. Uses specific verbs and distinguishes from siblings by focusing on source referencing.
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?
Explicitly states when to use: for standard citations or checking amendments. Mentions multi-match behavior. Lacks explicit exclusions or alternatives but provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses the key behavioral trait: if a code matches multiple articles, it returns a list with anchors for re-selection. This adds transparency beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with structured bullet points. Every sentence serves a purpose, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers input formats and multiple-match behavior. It does not explain output format (assumed full text) or error handling, but remains sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains the three valid input formats for 'ma_dieu' (code with/without prefix, anchor with/without hash). This compensates fully for the schema gap.
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 clearly states the verb 'Xem' (view) and resource 'một điều luật' (a legal article). It specifies three accepted input formats, distinguishing this tool from siblings that search or list articles.
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 provides explicit input format options and behavior for multiple matches. It lacks explicit when-not-to-use or alternative tool references, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: ranking priority (title matches get higher 'diem'), possibility of empty results with suggestions (goi_y) for weak matches, and that long queries may yield low scores. This provides good transparency for a search tool.
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?
Description is fairly concise and well-structured with bullet points and emphasis. Some Vietnamese phrasing is slightly verbose, but overall effective. Could be tightened slightly but not overly long.
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?
Lacking an output schema, the description includes the return structure (tong_so, offset, so_tra, con_nua, ket_qua) and mentions empty results with goi_y. It covers pagination and error behavior, making it comprehensive for a 4-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates fully. It explains all parameters: tu_khoa (keyword), chu_de (optional topic, example 'Dân sự'), gioi_han (max 50), offset for pagination. Also describes return structure, adding value beyond the schema.
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 clearly states the tool searches for legal articles (ĐIỀU LUẬT) by keyword, specifying full-text search with diacritic-insensitive support. It differentiates from sibling tools like tra_an_le by emphasizing 'luật thành văn' (written law).
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?
Provides explicit guidance: use short, precise keywords; avoid long descriptions; if empty, reduce to core terms or add chu_de. Also explains pagination limits. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses hybrid search (vector+full-text with weighted RRF), sources (an_le/dieu_luat), potential misinterpretations (e.g., 'nợ lương' → 'nợ công'), and return format (tong_so, ket_qua with do_tuong_dong, trich_doan, keys). This is comprehensive behavioral disclosure.
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?
The description is verbose but well-structured with sections: purpose, usage steps, and alternatives. It is front-loaded with the key idea and then detailed guidance. While every sentence adds value, the length could be slightly reduced without losing essential information.
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?
Given no output schema, no annotations, and 3 parameters, the description fully covers behavior, best practices, return structure, and common pitfalls. It even provides a concrete example of reformulating queries. The tool is complex (semantic search with hybrid method), and the description equips the agent sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by explaining 'cau_hoi' as the query, 'nguon' with specific values (an_le/dieu_luat) and default, and 'gioi_han' as result limit with default 8. Could explicitly mention that 'cau_hoi' is required and 'nguon' default is 'an_le' in the description, but current text implies these through examples and context.
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 clearly states the tool performs semantic search, understanding meaning beyond keyword matches. It distinguishes itself from sibling tools like tra_luat (FTS) and tra_an_le (exact lookup). The verb 'Tìm theo NGỮ NGHĨA' and explanation of hybrid search provide specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (semantic understanding needed) and when not to (exact terms/numbers available, then use tra_luat/tra_an_le). Offers two-step best-use guidance for Claude: reformulating queries in legal terms and filtering results. This fully addresses when-to-use vs alternatives.
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:

[![vn-luat-mcp MCP server](https://glama.ai/mcp/servers/phuocnguyen1308-creator/vn-luat-mcp/badges/card.svg)](https://glama.ai/mcp/servers/phuocnguyen1308-creator/vn-luat-mcp)

Score Badge

Copy to your README.md:

[![vn-luat-mcp MCP server](https://glama.ai/mcp/servers/phuocnguyen1308-creator/vn-luat-mcp/badges/score.svg)](https://glama.ai/mcp/servers/phuocnguyen1308-creator/vn-luat-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/phuocnguyen1308-creator/vn-luat-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server