hukum-id-mcp

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation4/5
Most tools target distinct actions and resources: source health, metadata search, article lookup, citation verification, and regulatory tracing are clearly separated. The only mild boundary is verify_citation vs analyze_uploaded_document, both check citations in text, though one handles drafts and the other extracted uploads.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern such as get_, search_, lookup_, verify_, trace_, research_, and analyze_. The verbs are descriptive and match each tool's purpose, with repeated analyze_ used consistently for the two analysis tools.
Tool Count5/5
Ten tools is well within the ideal range for a legal-research server, and each tool covers a distinct step in the research and verification workflow. No tool feels redundant or decorative.
Completeness5/5
The tool set covers source health, metadata search, exact document retrieval, article lookup, citation verification, regulatory timeline tracing, jurisprudence search, sharia research, and evidence-based legal analysis. This provides an end-to-end legal research surface with no obvious dead ends.
Average 3.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on September 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by saying source status is provided per court and that partial failures are visible, which helps an agent interpret incomplete responses. There is no contradiction with the 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 compact sentence that front-loads the main action and target courts. It avoids filler, though 'kegagalan parsial yang terlihat' is awkwardly phrased and slightly reduces clarity.
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?
For a read-only search tool with an output schema and supportive annotations, the description is adequate but not complete. It conveys the core domain and partial-failure visibility, yet it leaves sibling selection and pageSize/query semantics to inference, which is a meaningful gap given the overlapping sibling tools.
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%, so the description must compensate for missing parameter documentation. It only hints at the 'court' parameter by naming MA/MK and implies a query through 'Cari'; pageSize and query constraints are entirely absent, leaving the agent to infer their meaning from the schema names alone.
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 uses a specific verb ('Cari' = search) and names the resource ('putusan MA dan MK' = Supreme Court and Constitutional Court decisions), so an agent can identify this as a jurisprudence-search tool. It also adds scope via 'status sumber per pengadilan', though the phrase 'kegagalan parsial yang terlihat' is somewhat ambiguous and it does not explicitly contrast with search_legal_sources.
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 given about when to prefer this tool over closely related siblings such as search_legal_sources or get_source_status. The distinctive features ('per pengadilan', 'kegagalan parsial yang terlihat') are implied rather than stated as selection criteria.
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 the annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context: it only retains evidence-backed claims and abstains when evidence is insufficient. This goes beyond the annotations, though it does not clarify what an abstention looks like in the output.
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 one compact sentence that front-loads the main action and includes the key constraint. Every word earns its place with no redundant filler.
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?
The tool is simple (one parameter) and the annotations plus the presence of an output schema cover much of the behavioral and return contract. The description adds the core evidence-filtering and abstention behavior. A slight gap remains around what 'abstain' means operationally and when to reach for this tool instead of a sibling, but overall it is adequate.
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%, so the description must compensate, but it never explicitly documents the 'question' parameter. The tool name and title imply the parameter is the legal problem to analyze, but this is implicit rather than stated.
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 states a specific verb ('Susun' / compile) and a clear resource ('research result'), with the qualifier 'hanya mempertahankan klaim dengan evidence' making the evidence-first nature explicit. It does not explicitly differentiate from sibling tools like research_sharia_issue or analyze_uploaded_document, so it stops short of a 5.
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?
The description provides no guidance on when to choose this tool over alternatives, such as search_legal_sources or analyze_uploaded_document. The phrase 'abstain bila sumber belum cukup' is a behavioral instruction, not a tool-selection guideline.
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?
Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond those hints: the search returns metadata, and results are not evidence of article content. This is a meaningful disclaimer that helps the agent set correct expectations about the tool's output.
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 two short sentences with no filler. The core purpose is front-loaded, and the limitation about search results not being proof of article content is stated compactly in the second sentence. Every word earns its place.
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 presence of an output schema means return-value documentation is not required, and the description gives the essential search limitation. However, the acronym HES is unexplained, the optional filters are not described, and no guidance is given on how to use the sources enum. This is a minimally viable definition but leaves clear gaps for an agent operating in an unfamiliar legal domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it mentions none of query, year, number, sources, or pageSize. The phrase 'Cari metadata' only restates the general purpose and adds no meaning to the parameter fields. The agent receives no guidance on how to form a valid query beyond the schema's basic types and constraints.
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 uses a specific action and resource: 'Cari metadata sumber resmi hukum nasional dan HES' (search metadata of official national legal sources and HES). It clearly communicates that this is a metadata search, not a content retrieval tool. However, it does not explicitly differentiate itself from the sibling tool search_jurisprudence, so it misses the top score.
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 implies the tool is for finding legal source metadata rather than retrieving full content or proving article wording ('Hasil pencarian belum menjadi bukti isi pasal'). This gives the agent some basis for choosing it, but it never states when to use this tool instead of search_jurisprudence, lookup_article, or verify_citation, nor any exclusions or alternatives.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds a bit of context by specifying that it returns complete metadata for a single regulation or MA decision, aligning with the read-only hints. It doesn't disclose error behavior or what happens for unknown refs, which is acceptable given the output schema.
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?
A single, direct sentence in Indonesian that front-loads the core action ('Ambil metadata lengkap') then specifies the scope and condition. No filler or redundant content – every word earns its place.
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?
For a simple, read-only retrieval tool with an output schema and rich annotations, the description covers the core use case. But it leaves gaps: what counts as an 'exact reference' is undefined, and the distinction from search_legal_sources/lookup_article is only implicit. An agent would need schema enum and sibling names to fully contextualize.
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%, so the description must compensate. It only hints at 'ref' via 'rujukan persis' and leaves 'source' to be understood from enum values. No format for the exact reference is given, and no per-parameter explanations are provided, leaving the agent to guess what constitutes a valid citation.
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 states a specific action ('Ambil metadata lengkap' = get complete metadata), a specific resource type (one regulation or MA decision), and the condition ('dari rujukan persis' = from exact reference). It distinguishes from search-oriented siblings by emphasizing exact reference, though it doesn't name any sibling explicitly.
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 phrase 'dari rujukan persis' clearly indicates the tool is for exact-reference lookups, implying it should be used when a precise citation is available rather than for open-ended search. However, it doesn't explicitly state when not to use it or name alternative sibling tools.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context that document contents are treated as data, not instructions ('Isi dokumen diperlakukan sebagai data, bukan instruksi'), which is a meaningful behavioral disclosure about prompt-injection handling beyond what annotations provide.
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?
Two short sentences with no filler. The primary purpose is front-loaded, and the safety-relevant note about data-vs-instructions is placed second, making the description easy to parse quickly.
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 one-parameter tool with rich annotations and an output schema, the description covers the core purpose and an important behavioral trait. The main missing piece is guidance on when to choose this over verify_citation, but the tool is simple enough that this is a minor gap.
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?
With 0% schema description coverage, the description carries the burden of explaining the single 'text' parameter. It clarifies that the parameter should contain extracted document text and that it will be treated as data, which is useful but does not specify format, encoding, or other details an agent might need.
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 states a specific action ('Periksa sitasi') and a clear resource ('teks hasil ekstraksi dokumen'), so an agent knows this analyzes citations in extracted document text. However, it does not explicitly distinguish itself from the sibling tool verify_citation, which likely has overlapping functionality.
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?
There is no guidance on when to use this tool versus alternatives. The phrase 'hasil ekstraksi dokumen' implies use with uploaded-document extraction output, but no exclusions or sibling comparisons are provided, leaving the agent to infer the appropriate 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 cover the safety profile (readOnly, idempotent, non-destructive) and open-world semantics. The description adds the useful context that empty results should be checked against source health/freshness, but it does not add operational details such as pagination, response shape, or rate behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states what the tool does and why it matters, with no filler or repetition of schema/annotations. Every phrase earns its place.
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?
With an output schema covering return values and annotations covering safety/open-world behavior, the description is largely complete for a simple status tool. The only notable gap is the unexplained 'importantOnly' parameter, but that is already penalized under parameter semantics.
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 single optional boolean parameter 'importantOnly' is never mentioned in the description. The parameter name gives a weak hint, but the description does not clarify what 'important' means, how it affects output, or the default behavior. The description should have compensated for the missing schema documentation.
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 uses a specific verb ('Laporkan') and resource ('kesehatan dan freshness sumber'), clearly stating that the tool reports source health/freshness rather than performing legal search. It also explains the purpose: preventing empty results from being misinterpreted as absence of law. It does not explicitly name a sibling, so it loses the top score.
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 phrase 'agar hasil kosong tidak disalahartikan sebagai ketiadaan hukum' clearly signals when to use this tool: when a legal search returns empty and the agent should check whether source availability/freshness explains it. It gives clear context but no explicit when-not-to-use instructions or named alternatives.
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 read-only, open-world, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful context by enumerating the mapped categories (DSN fatwa, hukum positif, KHES, dalil, putusan), but it does not disclose additional behavioral traits such as breadth of search or ranking of results.
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?
A single sentence that is front-loaded with the action verb and immediately specifies the full scope of what is mapped. There is no redundant or filler content; every word contributes to purpose.
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?
The tool is simple with one required parameter and has an output schema, so the description only needs to convey what the mapping covers, which it does. Slight gaps remain around expected topic format and how results are organized, but these are not critical given the output schema presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify that the 'topic' parameter can also be an 'akad' (contract), which adds meaning beyond the schema, but it lacks examples, formatting hints, or guidance on how specific the topic should be.
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 uses a specific verb, 'Petakan' (map), and identifies the resource: topics or contracts (akad) mapped to DSN fatwa, positive law, KHES, dalil, and related rulings. This is clear and distinct from generic search tools, though it does not explicitly name sibling tools to draw a contrast.
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 implies the tool is for mapping a topic or akad across multiple legal source categories, which signals when it is appropriate, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the sibling tools.
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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds useful scope (which citation types are checked) but does not disclose any behavioral details beyond that, such as whether it queries live sources or how it handles ambiguous citations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action verb and lists the key objects. Every word earns its place; there is no fluff or repetition.
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?
The tool has an output schema, safe annotations, and a single parameter, so much context is already structured. The description adequately conveys what the tool does and what input is expected. It could be more explicit about when to use it versus siblings, but that gap is already scored under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by implying that the 'text' parameter is the draft containing the citations ('dalam draf'), which gives the parameter contextual meaning. However, it never explicitly explains the parameter's expected content, format, or any constraints beyond what the schema already states.
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 states a clear verb ('Periksa' / Check) and a specific resource: citations in a draft, enumerating the types checked (references, validity status, articles, court decisions, fatwas). It is clear and specific, and the unique focus on 'draf' (draft) helps distinguish it from siblings, though it does not explicitly name an alternative.
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 implies its use case: verifying legal citations mentioned in a draft. However, it gives no explicit guidance on when to choose this tool over siblings like get_source_status, lookup_article, or analyze_uploaded_document, and it does not state any exclusions or conditions.
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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations by disclosing that the tool fails closed when the phrase is absent or the reference is ambiguous, which is important for an agent deciding whether the result is reliable.
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 dense sentence that front-loads the main action and then states the failure behavior. Every part earns its place, with no redundant filler or repetition of schema details.
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 the simple two-parameter schema, the presence of an output schema, and annotations covering the safety profile, the description covers the core behavior well. However, it lacks explicit parameter semantics and guidance on selecting this tool over related siblings, so the overall context is adequate but not fully complete.
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%, so the description must compensate by clarifying parameter usage, but it does not define what forms 'regulation' and 'article' should take or how they relate to the 'frasa' (phrase) mentioned. The parameter names are intuitive but the description leaves the accepted input semantics ambiguous.
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 states a specific verb and resource: find the exact wording of an article ('bunyi pasal') along with page and provenance. It also distinguishes itself from search-oriented siblings by emphasizing exact-phrase lookup and fail-closed behavior on ambiguity or absence.
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 implies when to use the tool: when an exact article phrase or reference must be resolved with provenance, and it should fail closed if not found or ambiguous. However, it does not explicitly name alternative tools or state when not to use this tool, leaving the routing decision somewhat implicit.
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?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds a meaningful behavioral boundary: it returns a timeline/trail and deliberately avoids guessing consolidated text.
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 entire definition is one focused sentence with no filler. It front-loads the action and scope and ends with a meaningful limitation.
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?
Annotations and output schema cover safety and return-shape concerns, and the core purpose is clear. However, the 0% parameter coverage and lack of explicit sibling routing leave gaps an agent would have to infer.
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%, so the description must compensate, but it only alludes to 'pasal' (article) and 'peraturan' (regulation). The 'asOf' parameter is never explained or clearly linked to the timeline concept, leaving its format and semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Periksa') and resource: the applicability timeline and article amendment trail. It also distinguishes itself from sibling tools by explicitly stating that it does not reconstruct consolidated text.
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 phrasing implies the tool is for history/timeline questions and warns against using it to obtain consolidated text, which is a useful contextual cue. However, it names no sibling tools and gives no explicit when-to-use/when-not-to-use conditions.
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

hukum-id-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![hukum-id-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/y3nnthekid-prog/hukum-id-mcp/badges/card.svg)](https://glama.ai/mcp/servers/y3nnthekid-prog/hukum-id-mcp)

Score Badge

Copy to your README.md:

[![hukum-id-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/y3nnthekid-prog/hukum-id-mcp/badges/score.svg)](https://glama.ai/mcp/servers/y3nnthekid-prog/hukum-id-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![hukum-id-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fy3nnthekid-prog%2Fhukum-id-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/y3nnthekid-prog/hukum-id-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/y3nnthekid-prog/hukum-id-mcp'

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