Search Indonesian laws, resolve citations, read articles, and find Constitutional Court decisions.
Scored across 7 tools
Each tool has a clearly distinct role, and the descriptions explicitly disambiguate decision points (resolve_law for known citations vs search_legal for unknown laws; get_law_context for outline/status vs read_law for full text). The 'WHEN' framing in each description further reduces misselection risk.
Six of seven tools follow a clean verb_noun pattern (get_law_context, read_law, report_issue, resolve_law, search_court_decisions, search_legal). 'ping' is a single-word outlier, though it follows a universally recognized health-check convention.
Seven tools sit squarely in the ideal range, and each earns its place: a resolve/context/read pipeline for known laws, two distinct search surfaces, a reporting tool, and a health check. Nothing feels redundant or missing at the count level.
The surface covers the core read-oriented legal workflow well: resolving citations, retrieving context and full text, searching legal text, and searching court decisions, plus issue reporting. Minor gaps exist (no browse/list-by-taxonomy or cross-reference operation), but search covers most discovery needs.
WHEN a law is known, get compact status, structure outline, or relationships before reading text. Budget: summary <= ~3KB, outline <= 15KB, relationship groups capped at 20 each. law.source has the official link; if source.verified is false, say quoted text is unverified.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Canonical law_id or citation string accepted by resolve_law, e.g. 16 or 'UU 27 tahun 2022'. | |
| detail | No | One of summary, outline, relationships. | summary |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful operational context the annotations cannot: per-mode size budgets (3KB/15KB/20 groups) and the instruction to flag quoted text as unverified when source.verified is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the usage trigger, with zero filler. Every clause (modes, budgets, verification caveat) carries information an agent acts on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description still covers the important caveat about unverified source text plus size expectations. Minor gap: it never says what happens when the law identifier is unresolvable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both params, so baseline is 3. The description goes further by tying each detail mode to a concrete budget and describing the source/verification fields returned, giving the agent meaning beyond the bare enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and names the three payload modes (status, outline, relationships), which distinguishes it from read_law (full text) and search_legal. It does not however name those siblings explicitly, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"WHEN a law is known ... before reading text" gives a clear triggering condition and sequencing guidance. It does not mention the alternative for an unknown law (resolve_law) or when to skip context and go straight to read_law, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cek kesehatan untuk client yang sudah terautentikasi.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint true and destructiveHint false, so the safety profile is fully covered elsewhere. The description adds the one genuinely new behavioral fact: the call assumes an authenticated client. It says nothing about rate limits, failure modes, or latency expectations beyond what the annotations imply. With the annotations carrying the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler, repetition, or hedging. The precondition (authenticated client) is the one detail included, and it is exactly the detail that matters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool with an output schema describing the return and annotations covering the safety profile, the description supplies the key scope qualifier (authenticated client). No return-format or pagination detail is needed given the output schema. It is complete for its complexity, though not elaborative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline this dimension starts at 4. There is genuinely nothing to document, and the description introduces no misleading parameter hints. It does not rise to a 5 only because there is no substantive meaning to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action and scope: a health check for an already-authenticated client. That is clearly distinguishable from the strict legal-research siblings. It does not explicitly name or contrast a sibling, but none is similar enough to be confused with it, so a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus alternatives, nor any mention of how often or at what point in a session to use it. The phrase 'client yang sudah terautentikasi' hints at a precondition but states no usage condition. A ping's usage is largely self-evident, which keeps this from being a 1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN a law is known and text is needed, read by forgiving selector strings such as 'pasal 27', 'pasal 27-30', 'pasal 13-16, pasal 27-37, pasal 40-41', 'bab III', 'menimbang', 'lampiran', or 'all'. For parsed-text gaps, 'source find Pasal 65' locates standalone headings in the canonical archived PDF (up to 100 physical pages per scan); 'source pages 29' reads up to 5 physical PDF pages. Stored node page hints are unverified. Budget: max_chars default 30000, hard cap 100000, cursor pagination. law.source has the official link; if source.verified is false, say quoted text is unverified.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Canonical law_id or citation string accepted by resolve_law. | |
| versi | No | asli (default) = naskah asli yang diindeks; terkini = versi konsolidasi tidak resmi, hanya jika law.consolidation.available. | asli |
| cursor | No | Cursor from a prior truncated response. | |
| selector | Yes | Selector string: all, pasal 27, pasal 27-30, pasal 13-16, pasal 27-37, pasal 40-41 (multi-range), bab III, menimbang, mengingat, penjelasan umum, penjelasan pasal 5, lampiran; source find Pasal 65, source find penjelasan Pasal 65, source pages 29 (1-based physical PDF pages, at most 5). | |
| max_chars | No | Maximum aggregate characters. Default 30000, minimum 1000, hard cap 100000. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly/idempotent), while the description adds operational context the annotations cannot: scan limits (100 physical pages, 5 pages for source pages), that stored node page hints are unverified, the pagination cursor, character budgets, and the instruction to flag text as unverified when source.verified is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the WHEN precondition and the primary selector contract, then layers fallback behavior and budget caveats. Efficient overall, though the selector enumeration is dense and partially repeats the schema's selector list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described; the description instead supplies everything else an agent needs — version/consolidation relevance via schema, verification caveat, pagination, and hard character caps. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds behavioral meaning beyond the schema: the 'source find'/'source pages' selector modes and their per-scan caps, the practical budget behavior of max_chars, and cursor-based continuation across truncated responses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('read' a 'law') and the precondition ('WHEN a law is known and text is needed'), which cleanly distinguishes it from resolve_law (used when the law is not yet known) and get_law_context. Selector examples make the retrieval unit unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN a law is known and text is needed' clause gives clear usage context and implicitly routes unknown-law cases to resolve_law. It also explains the fallback paths ('source find', 'source pages') for parsed-text gaps, though it never names sibling tools explicitly to force the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laporkan masalah data Pasal.id dari alur MCP saat pengguna meminta pelaporan. Panggil jika teks Pasal yang diambil tampak rusak/terpotong/tidak konsisten karena OCR, atau jika pengguna menyatakan isinya salah, atau jika peraturan/Pasal yang seharusnya ada tidak ditemukan (OCR salah, peraturan hilang, Pasal hilang, tautan rusak, konten usang, kegagalan pencarian). Jangan spam pada zero-result eksplorasi pencarian biasa. Hanya report_type yang wajib; judul diturunkan otomatis jika kosong.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tahun peraturan. | |
| title | No | Judul pendek dalam Bahasa Indonesia. Opsional — jika kosong, judul diturunkan otomatis dari report_type dan kutipan peraturan/Pasal. | |
| law_id | No | law_id Pasal.id jika sudah diketahui. | |
| node_id | No | node_id dari section yang bermasalah pada hasil read_law untuk koreksi OCR; jangan menebak ID ayat yang tidak dikembalikan. | |
| law_type | No | Jenis peraturan, misalnya UU atau PP. | |
| law_number | No | Nomor peraturan. | |
| description | No | Konteks tambahan. Jelaskan apa yang pengguna harapkan dan langkah yang sudah dicoba. | |
| report_type | Yes | Jenis masalah yang dilaporkan. Salah satu nilai: ocr_correction, missing_regulation, missing_pasal, incorrect_content, broken_link, outdated_content, search_failure, other. | |
| pasal_number | No | Nomor Pasal yang bermasalah jika relevan. | |
| contact_email | No | Email kontak opsional jika pengguna ingin dapat dihubungi. | |
| reference_url | No | URL sumber pendukung, misalnya PDF resmi. | |
| current_content | No | content_text dari section yang sama dengan node_id pada hasil read_law. Wajib untuk ocr_correction. | |
| expected_citation | No | Kutipan peraturan yang seharusnya muncul untuk report_type=search_failure, misalnya 'UU No. 27 Tahun 2022'. | |
| suggested_content | No | Teks koreksi yang disarankan. Wajib untuk ocr_correction. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write (readOnlyHint=false), non-destructive, non-idempotent, open-world. The description adds useful behavior beyond that: only report_type is mandatory, the title is auto-derived when empty, and current_content/suggested_content become required for ocr_correction. It does not say where the report lands or whether there is deduplication, but the added conditional-context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph that front-loads the purpose, then conditions, then the anti-spam caveat, then the required-parameter note. Every sentence carries weight, though the enumeration of failure modes is slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter write tool with an output schema and full schema coverage, the description supplies the decision context an agent needs to decide whether to file a report. It omits only downstream details (where the report goes, expected response), which the output schema partially covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters, including the ocr_correction requirements for current_content and suggested_content. The description mostly restates what the schema says (report_type required, title auto-derived), adding little beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: reporting data problems with Pasal.id content encountered during the MCP flow. It is clearly distinguishable from all siblings (read_law, search_legal, resolve_law), none of which are reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-call conditions (corrupted/truncated OCR text, user says content is wrong, missing regulation/Pasal, broken link, outdated content, search failure) and an explicit when-not-to: don't spam reports on ordinary zero-result search exploration. Alternatives and exclusions are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN you have a citation, title, or partial reference and need one canonical law_id. Budget: <= ~2KB. Use this before get_law_context or read_law when the law is named. law.source has the official link; if source.verified is false, say quoted text is unverified.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Optional region hint for regional regulations, e.g. 'DKI Jakarta'. | |
| reference | Yes | Citation or title-like reference, e.g. 'UU 27 tahun 2022' or 'UU PDP'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavior beyond them: a response budget ("<= ~2KB") and an output-handling rule about source.verified that governs how the agent must phrase quoted text. It does not, however, describe failure behavior when no canonical law is matched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded: the trigger condition leads, followed by budget, ordering, and output handling. The telegraphic style ("Budget: <= ~2KB") is dense but each clause carries distinct information, so there is little waste. Slightly compressed phrasing costs it a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be spelled out, and the description instead covers what the schema cannot: the size budget, the canonical-id purpose, and how to treat unverified sources. It is complete enough to call correctly, though it omits what happens on no-match or ambiguous references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (reference, region) are already documented with examples in the schema. The description restates the reference concept ("citation, title, or partial reference") without adding format or matching semantics beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (resolve) and the exact output (one canonical law_id) for a specific input class (citation, title, or partial reference). It also names the siblings it precedes (get_law_context, read_law), so an agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger condition ("WHEN you have a citation, title, or partial reference and need one canonical law_id") and gives an ordering rule versus two named alternatives ("Use this before get_law_context or read_law when the law is named"). When-to-use, when-not, and alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cari putusan Mahkamah Konstitusi (judicial review/PUU, SKLN, PHPU, PHPKADA). Saring berdasarkan UU yang diuji (reviewed_law), jalur (lane), amar putusan, tahun, jenis pengujian, ada dissenting opinion, atau nama hakim; query untuk kata kunci topik/klasifikasi. Pakai untuk pertanyaan seperti 'UU mana yang dibatalkan MK tahun 2024' atau 'putusan dengan dissenting opinion'. source_url/source berisi tautan resmi mkri.id (PDF putusan); jika source.verified=false, sebutkan sekali bahwa teks putusan belum terverifikasi.
| Name | Required | Description | Default |
|---|---|---|---|
| amar | No | Amar putusan, misalnya dikabulkan_sebagian, ditolak, inkonstitusional_bersyarat; '__ketetapan__' untuk putusan tanpa amar. | |
| lane | No | Jalur perkara: puu, skln, phpu, phpkada. | |
| year | No | Tahun putusan. | |
| judge | No | Nama hakim konstitusi (dicocokkan di ketua/anggota/pemberi dissent). Pencocokan lewat roster hakim MK terkurasi + normalisasi ejaan; nama di luar roster mengembalikan kosong. | |
| limit | No | Jumlah maksimum hasil (1-50), server clamp ke 50. | |
| query | No | Kata kunci topik/klasifikasi opsional, misalnya 'pemilu' atau 'kebebasan berserikat'. | |
| has_dissent | No | True untuk hanya putusan dengan dissenting opinion; False untuk tanpa dissent. | |
| reviewed_law | No | UU yang diuji, misalnya 'uu 13 2003' atau 'UU No. 13 Tahun 2003' atau law_id kanonik. | |
| jenis_pengujian | No | Jenis pengujian, misalnya materiil atau formil. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description adds real value: source_url/source carries the official mkri.id PDF link, and it instructs the agent to disclose once when source.verified=false that the text is unverified. That is behavioral context the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Opens with the domain and the lanes, then the filter list, then examples, then the source-handling note – a sensible front-loaded order. The middle clause re-listing filters that the schema already documents is mildly redundant but not wasteful enough to drop below a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description focuses on what structured fields omit – lane taxonomy, example queries, and the verified/unverified source caveat. It omits result pagination/clamping behavior, but that is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine filters with examples and semantics. The description largely restates the same filter names (reviewed_law, lane, amar, tahun, jenis_pengujian, dissent, hakim) without adding syntax the schema lacks, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Cari) and resource (putusan Mahkamah Konstitusi) and enumerates the case lanes (PUU, SKLN, PHPU, PHPKADA), which pins the scope precisely. It does not explicitly contrast itself with siblings like search_legal or read_law, so an agent must infer the boundary, keeping it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete example questions ('UU mana yang dibatalkan MK tahun 2024', 'putusan dengan dissenting opinion') that make the intended use obvious. However, it never states when NOT to use this tool or points to an alternative sibling for other legal queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN the relevant law is unknown, search Indonesian legal text with validated filters. Budget: limit <= 20 results, approximately <= 30KB. If a law is known, prefer resolve_law then get_law_context/read_law.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Exact enactment year filter. If also given with year_from/year_to, year takes precedence. | |
| limit | No | Maximum results, clamped to 1-20. | |
| query | Yes | Indonesian legal search terms or topic. Required. | |
| law_id | No | Optional canonical law_id for within-law search. When set, other filters are not applicable. | |
| region | No | Region/locality filter for LOCAL regulations (Perda/Pergub/Perbup/Perwali) — a province, city, or regency, e.g. 'DKI Jakarta', 'Jawa Barat', 'Kota Bekasi'. Pass this whenever the user names a place for a regional regulation. | |
| status | No | Optional status filters: berlaku, diubah, dicabut, tidak_berlaku. | |
| year_to | No | Inclusive end year filter. | |
| year_from | No | Inclusive start year filter. | |
| issuing_body | No | Optional issuing body filter, e.g. DPR, Presiden, OJK. | |
| regulation_types | No | Optional list of regulation types, e.g. ['UU', 'PP'] or ['Peraturan Pemerintah']. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered structurally. The description adds a genuine operational budget (~30KB, limit <= 20) that is not derivable from the annotations, though it does not describe pagination or result-shape behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the WHEN condition and the sibling-routing rule front-loaded; the budget constraint is stated compactly and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, a fully described parameter set, and annotations covering the safety profile, the description only needs to supply routing and budget context — both of which it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters including the year/year_from/year_to precedence rule and the region filter semantics are documented in the schema itself. The description adds no parameter meaning beyond echoing the limit ceiling, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('search Indonesian legal text') and adds the qualifying condition ('WHEN the relevant law is unknown'), which separates it cleanly from resolve_law/get_law_context/read_law in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('law is unknown') and when-not-to-use with named alternatives ('If a law is known, prefer resolve_law then get_law_context/read_law'). The routing decision is fully specified with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
read_law1 field changedInput schema / properties / versi / enumAdded value: +[
+ "asli",
+ "terkini"
+]read_law1 field changedInput schema / properties / versiAdded value: +{
+ "default": "asli",
+ "description": "asli (default) = naskah asli yang diindeks; terkini = versi konsolidasi tidak resmi, hanya jika law.consolidation.available.",
+ "type": "string"
+}read_law1 field changedInput schema / properties / selector / descriptionPrevious value: -"Selector string: all, pasal 27, pasal 27-30, pasal 13-16, pasal 27-37, pasal 40-41 (multi-range), bab III, menimbang, mengingat, penjelasan umum, penjelasan pasal 5, lampiran."New value: +"Selector string: all, pasal 27, pasal 27-30, pasal 13-16, pasal 27-37, pasal 40-41 (multi-range), bab III, menimbang, mengingat, penjelasan umum, penjelasan pasal 5, lampiran; source find Pasal 65, source find penjelasan Pasal 65, source pages 29 (1-based physical PDF pages, at most 5)."report_issue2 fields changedInput schema / properties / current_content / descriptionPrevious value: -"Teks saat ini dari get_pasal. Wajib untuk ocr_correction."New value: +"content_text dari section yang sama dengan node_id pada hasil read_law. Wajib untuk ocr_correction."Input schema / properties / node_id / descriptionPrevious value: -"node_id dari get_pasal untuk koreksi OCR."New value: +"node_id dari section yang bermasalah pada hasil read_law untuk koreksi OCR; jangan menebak ID ayat yang tidak dikembalikan."get_law_contextget_law_overviewget_law_partget_law_statusget_law_structureget_pasallist_lawsread_lawread_law_sectionreport_issue18 fields changedInput schema / properties / contact_email / descriptionAdded value: +"Email kontak opsional jika pengguna ingin dapat dihubungi."Input schema / properties / current_content / descriptionAdded value: +"Teks saat ini dari get_pasal. Wajib untuk ocr_correction."Input schema / properties / description / descriptionAdded value: +"Konteks tambahan. Jelaskan apa yang pengguna harapkan dan langkah yang sudah dicoba."Input schema / properties / expected_citationAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Kutipan peraturan yang seharusnya muncul untuk report_type=search_failure, misalnya 'UU No. 27 Tahun 2022'."
+}Input schema / properties / law_id / descriptionAdded value: +"law_id Pasal.id jika sudah diketahui."Input schema / properties / law_number / descriptionAdded value: +"Nomor peraturan."Input schema / properties / law_type / descriptionAdded value: +"Jenis peraturan, misalnya UU atau PP."Input schema / properties / node_id / descriptionAdded value: +"node_id dari get_pasal untuk koreksi OCR."Input schema / properties / pasal_number / descriptionAdded value: +"Nomor Pasal yang bermasalah jika relevan."Input schema / properties / reference_url / descriptionAdded value: +"URL sumber pendukung, misalnya PDF resmi."Input schema / properties / report_type / descriptionAdded value: +"Jenis masalah yang dilaporkan. Salah satu nilai: ocr_correction, missing_regulation, missing_pasal, incorrect_content, broken_link, outdated_content, search_failure, other."Input schema / properties / suggested_content / descriptionAdded value: +"Teks koreksi yang disarankan. Wajib untuk ocr_correction."Input schema / properties / title / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / title / defaultAdded value: +nullInput schema / properties / title / descriptionAdded value: +"Judul pendek dalam Bahasa Indonesia. Opsional — jika kosong, judul diturunkan otomatis dari report_type dan kutipan peraturan/Pasal."Input schema / properties / title / typeRemoved value: -"string"Input schema / properties / year / descriptionAdded value: +"Tahun peraturan."Input schema / requiredPrevious value: -[
- "report_type",
- "title"
-]New value: +[
+ "report_type"
+]resolve_lawsearch_court_decisionssearch_lawssearch_legalsearch_within_lawread_law_sectionget_law_overviewget_law_partget_law_statusget_law_structureget_pasallist_lawspingreport_issuesearch_lawssearch_within_lawSearch and read Indonesian court cases. Filter by court, year, and case type.
Indonesian law — national statutes and regulations, and Constitutional Court (Mahkamah Konstitusi)…
Semantic retrieval across 295,000+ Indonesian regulations and 5.6M+ legal provisions, updated daily. Give AI direct access to Indonesian regulatory knowledge before reasoning.
Resolve, search and verify legal citations against the official sources, with provenance.
Add one secure layer between your agents and this server.
