Search Indonesian laws, resolve citations, read articles, and find Constitutional Court decisions.
Scored across 7 tools
Each tool occupies a clearly distinct niche: search_legal for unknown laws, resolve_law for citation-to-id resolution, get_law_context for metadata/outline, read_law for text, search_court_decisions for MK rulings, plus report_issue and ping utilities. The descriptions explicitly document the intended sequence (resolve before context/read), removing overlap between search_legal and search_court_decisions by scoping the latter to court decisions only.
Nearly all tools follow a consistent snake_case verb_noun pattern (get_law_context, read_law, report_issue, resolve_law, search_legal, search_court_decisions). The only deviation is the conventional 'ping' health check, which is universally understood and not confusing.
Seven tools is a tightly scoped set for a legal-research server, with each tool earning its place: two search paths, a resolver, a context/outline reader, a text reader, a reporting channel, and a health check. Nothing feels redundant or missing dimensionally.
The surface covers the core research lifecycle well: locate an unknown law, resolve a citation, inspect structure, read text, query court decisions, and report data issues. Minor gaps exist (e.g. no explicit listing/browsing or citation-export tool), but agents can work around these via search_legal.
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.
| 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?
With readOnly, idempotent, and non-destructive annotations already covering the safety profile, the description adds concrete output-size budgets (summary <= ~3KB, outline <= 15KB, relationship groups capped at 20 each). Those limits help an agent manage context, though the description does not describe what the returned status or relationship groups contain.
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 tightly written sentences, front-loaded with the when-condition and followed by the budget constraint. Every clause carries information without repetition or filler.
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-value structure need not be covered. The description supplies the trigger condition, the distinction from reading full text, the three detail modes, and concrete size limits; an agent has enough to invoke it correctly.
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 schema already documents both parameters and the law format. The description goes further by attaching size expectations to each detail mode (summary, outline, relationships), giving the detail parameter practical semantic weight beyond the schema's list of allowed values.
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 (get) and resource (law context), enumerating the three outputs: compact status, structure outline, or relationships. It also explicitly distinguishes from read_law by saying 'before reading text', so an agent can route without opening the sibling 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?
The leading 'WHEN a law is known' gives a clear trigger condition, and 'before reading text' implies this is a precursor to read_law. It does not explicitly state what to do when the law is unknown (resolve_law) or name read_law as the alternative, leaving a small inference gap.
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'. Budget: max_chars default 30000, hard cap 100000, cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Canonical law_id or citation string accepted by resolve_law. | |
| 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. | |
| 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the max_chars default of 30000, the 100000 hard cap, and cursor-based pagination for truncated responses. That is real operational detail beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences that front-load the usage condition, then the selector grammar and budget rules. Slight redundancy with the schema's selector and max_chars descriptions, but no filler or wasted sentences.
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, the description needn't explain return values, and it already covers the trigger condition, selector syntax, and pagination/budget limits. An agent has everything needed to invoke it correctly.
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 four parameters are already documented in the schema, including the selector and budget rules. The description largely restates those same selector examples and caps, adding little semantic meaning beyond what the structured fields provide. 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 (read) and resource (law) and defines the selector grammar with concrete examples like 'pasal 27-30' and 'bab III'. It doesn't explicitly distinguish itself from siblings like get_law_context or resolve_law, so it falls short of a 5, but the action is 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 a clear triggering condition, and the emphasis on 'forgiving selector strings' tells the agent what input style is expected. It stops short of naming alternatives or stating when-not to use it (e.g., when the law must first be resolved).
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.
| 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 declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds a genuinely useful operational trait — the <= ~2KB budget — that no annotation conveys. It still doesn't say how ambiguous or failed matches behave, which keeps it short of a 5.
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 tight sentences with the trigger condition front-loaded, then the constraint, then the sequencing against siblings. Every clause carries information; nothing is padding.
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 annotations carry the safety profile. The description covers trigger, ordering relative to siblings, and a budget. It is only slightly thin on what happens when a reference resolves to multiple or zero laws, which matters for a resolver.
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 both parameters are already documented and the baseline is 3. The description adds meaning beyond the schema by framing 'reference' as possibly partial/fuzzy rather than an exact citation, which is important call semantics; the 'region' hint is left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the input (citation, title, or partial reference) and the exact output (one canonical law_id), which is a specific, checkable purpose. It implicitly resolves against get_law_context and read_law, so an agent can place it without opening schemas. It loses a point only because the verb is implied rather than stated directly.
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 an explicit precondition ('WHEN you have a citation, title, or partial reference'), names the alternatives and the ordering ('Use this before get_law_context or read_law when the law is named'), and adds a budget. Nothing about when-to-use is left to inference.
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'.
| 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond filtering (no pagination, ranking, or result-shape notes), though the output schema partly relieves that 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?
Two sentences, front-loaded with the resource and scope, then the filter list and example queries. Efficient, though the filter enumeration partly duplicates the schema's own parameter 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, rich annotations, 100% schema coverage and zero required parameters, the description supplies exactly what is needed: scope, filters, and example use cases. Nothing an agent needs to call it correctly is missing.
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 parameters with examples. The description enumerates the filter dimensions (reviewed_law, lane, amar, year, jenis_pengujian, has_dissent, judge, query) but adds no syntax or matching details beyond the schema, so baseline 3 is correct.
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/search) and resource (putusan Mahkamah Konstitusi) plus the case lanes it covers (PUU, SKLN, PHPU, PHPKADA). This clearly separates it from siblings like search_legal and get_law_context without needing to open either 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?
Gives concrete example questions ('UU mana yang dibatalkan MK tahun 2024', 'putusan dengan dissenting opinion') and lists the filterable dimensions, which tells the agent when this tool fits. It stops short of naming alternatives or stating when NOT to use it versus search_legal.
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.
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
Resolve, search and verify legal citations against the official sources, with provenance.
Search and read Vietnamese law — 150,000+ documents, cited to the exact Điều and Khoản.
Add one secure layer between your agents and this server.
