Semantic retrieval across 292,000+ Indonesian regulations and 5.4M+ legal provisions, updated daily. Give AI direct access to Indonesian regulatory knowledge before reasoning.
Scored across 6 tools
Each tool has a distinct purpose: title search, semantic regulation discovery, semantic pasal search, single pasal read, batch pasal read, and data report. However, the boundary between cari_pasal_terkait and cari_peraturan_terkait can be subtle, and baca_isi_pasal vs baca_isi_pasal_batch is explicitly clear. The extensive descriptions help but also hedge, slightly reducing clarity.
All tool names follow a consistent verb_noun pattern in Indonesian (baca_isi_pasal, cari_judul_peraturan, etc.), using lowercase with underscores throughout. No deviations.
6 tools provide well-scoped coverage: two search methods, two read methods (single and batch), one discovery tool, and one reporting tool. This is appropriate and each tool earns its place.
The surface covers discovery (both by title and semantically), reading (single and batch), and error reporting. The batch read tool ensures efficient handling of multiple pasal. No obvious gaps for legal retrieval on this domain.
Baca teks lengkap satu Pasal ketika regulation_id dan nomor Pasalnya sudah diketahui.
Untuk beberapa Pasal yang ID dan nomornya sudah diketahui dan diperlukan pada tahap analisis yang sama, prioritaskan baca_isi_pasal_batch.
Tool ini terutama digunakan untuk membaca norma setelah regulasi ditemukan melalui cari_peraturan_terkait, atau untuk direct read setelah regulasi tertentu ditemukan melalui cari_judul_peraturan.
Jika pengguna sejak awal menyebut regulasi tertentu dan nomor Pasal tertentu, jalur yang dianjurkan adalah: cari_judul_peraturan → baca_isi_pasal.
Jika discovery dilakukan melalui cari_peraturan_terkait, pilih regulasi dan nomor Pasal yang relevan dari semantic_hit_pasals, kemudian baca teks Pasal yang diperlukan melalui tool ini atau baca_isi_pasal_batch.
Hasil cari_pasal_terkait tidak perlu dibaca ulang melalui tool ini secara default karena tool tersebut sudah melakukan retrieval pada tingkat Pasal. Hindari pemanggilan ulang yang tidak menambah evidence atau informasi baru.
Jangan memakai ID yang dibuat sendiri dan jangan mengirim judul regulasi, shard, atau path lokal.
Gunakan pasal_url untuk membuka halaman Pasal.
Args:
regulation_id: ID enam digit dari item hasil cari_peraturan_terkait atau cari_judul_peraturan.
pasal: Nomor Pasal dari semantic_hit_pasals, misalnya 1, 5A, atau
1336.
| Name | Required | Description | Default |
|---|---|---|---|
| pasal | Yes | ||
| regulation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses input constraints (do not use self-made IDs; do not send regulation title, shard, or local path), warns against redundant retrieval, and points to pasal_url. It does not state permissions or rate limits, but the read-only nature and presence of an output schema reduce the need for those details.
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?
The core purpose is front-loaded in the first sentence, and the rest is organized into usage paths and constraints. Some workflow detail is verbose, but each paragraph adds routing or anti-pattern guidance rather than 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?
Given a simple two-parameter read tool, the description covers purpose, usage alternatives, parameter meaning, and common pitfalls. An output schema exists, so return values need not be explained; nothing critical for correct invocation 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 0%, so the description must compensate. It explains regulation_id as a six-digit ID from cari_peraturan_terkait or cari_judul_peraturan, and pasal as the article number from semantic_hit_pasals with examples '1', '5A', and '1336', adding format and source context beyond the bare 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?
States a specific verb ('baca') and resource ('teks lengkap satu Pasal'), along with the precondition that regulation_id and nomor Pasal are known. It explicitly distinguishes this tool from baca_isi_pasal_batch, which is the sibling for multiple articles.
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?
Provides explicit routing: use baca_isi_pasal_batch when several articles are needed, use this tool after cari_judul_peraturan for a known regulation/article, and avoid rereading results from cari_pasal_terkait. Covers when-to-use and alternatives clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Baca teks lengkap beberapa Pasal ketika regulation_id dan nomornya sudah diketahui.
Gunakan untuk 1–20 Pasal, boleh lintas regulasi. Untuk satu Pasal gunakan baca_isi_pasal.
Tool ini terutama digunakan setelah discovery melalui cari_peraturan_terkait: pilih regulasi yang relevan, ambil regulation_id dan nomor Pasal kandidat dari semantic_hit_pasals, lalu baca beberapa norma yang diperlukan dalam satu batch.
Tool ini juga dapat digunakan setelah cari_judul_peraturan apabila regulasi sudah diketahui dan beberapa nomor Pasal perlu dibaca sekaligus.
Hasil cari_pasal_terkait tidak perlu dibaca ulang melalui tool ini secara default karena tool tersebut sudah melakukan retrieval pada tingkat Pasal. Jangan mengumpulkan hasil cari_pasal_terkait lalu membacanya kembali secara batch kecuali terdapat alasan khusus untuk melakukan direct read berdasarkan regulation_id dan nomor Pasal yang sudah diketahui.
Jangan mengarang regulation_id atau nomor Pasal. Jika alamat norma belum diketahui dan tujuan riset adalah menemukan regulasi yang relevan untuk kemudian dibaca normanya, gunakan cari_peraturan_terkait terlebih dahulu.
Jika beberapa Pasal sudah diketahui dan diperlukan pada tahap analisis yang sama, prioritaskan satu pemanggilan batch hingga 20 item daripada memanggil baca_isi_pasal berulang atau membaginya menjadi beberapa batch kecil tanpa kebutuhan.
Kirim hanya Pasal yang relevan; jangan menambah item atau menunda pembacaan hanya untuk memenuhi kapasitas 20. Jika lebih dari 20 Pasal diperlukan, bagi menjadi beberapa batch, masing-masing maksimal 20 item.
Hasil mengikuti urutan input: identitas item, ok, serta data atau error. Periksa ok setiap item. Gunakan hanya hasil yang berhasil dibaca sebagai sumber bunyi norma; jangan menganggap seluruh batch berhasil hanya karena pemanggilan selesai.
Jika kredit tidak cukup, item tersebut dan item berikutnya yang belum diterima tidak melakukan retrieval. Item in-flight tetap selesai; tidak ada retry otomatis setelah refund.
Satu pemanggilan batch memakai satu slot scheduler akun; kredit tetap per item.
Contoh: {"items": [{"regulation_id": "004967", "pasal": "1"}]}. Jangan sertakan title, url, atau metadata lain pada item.
Args:
items: Array 1–20 objek dengan regulation_id string ID enam digit dan
pasal string nomor Pasal, misalnya 1, 5A, atau 1336.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses per-item ok checking, partial-failure semantics under insufficient credits, no automatic retry after refund, and that one batch consumes one scheduler slot with credits charged per item. It also restates return ordering, which the output schema likely already covers, so this is not fully additive.
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?
Purpose and scope are front-loaded, and the sentence-by-sentence content is mostly load-bearing guidance. However the batch-size rule is stated twice and the discovery-workflow admonitions run long, so there is mild redundancy rather than tight economy.
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 batch-read tool with an output schema, the description supplies everything the output schema cannot: when to prefer it over baca_isi_pasal, the credit/scheduler cost model, partial-failure handling, and item fabrication warnings. An agent has all it needs to call 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?
The single nested 'items' parameter is given real semantic depth beyond the schema: 1–20 range, cross-regulation allowance, concrete examples ('1', '5A', '1336'), and an explicit exclusion ('Jangan sertakan title, url, atau metadata lain pada item'). It overlaps somewhat with the schema's own field descriptions, so not a 5.
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 opening sentence states a specific verb (baca) and resource (teks lengkap beberapa Pasal) plus the precondition (regulation_id dan nomornya sudah diketahui). It explicitly distinguishes itself from its closest sibling: 'Untuk satu Pasal gunakan baca_isi_pasal.' 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?
It names the upstream discovery tools (cari_peraturan_terkait, cari_judul_peraturan), states an explicit when-not (do not re-read cari_pasal_terkait results by default), and gives the ordering priority (prefer one batch up to 20 over repeated single reads). This is a complete routing guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cari judul regulasi secara literal/as-is untuk intent nomor, tahun, atau nama dokumen spesifik.
Gunakan bila pengguna meminta keberadaan atau nama regulasi tertentu, misalnya
UU 30 Tahun 2009, PP 45 Tahun 2009, atau sebagian judul resmi. Ini adalah
pencarian FTS judul, bukan pencarian semantik dan bukan dasar untuk menyimpulkan
isi norma. Setiap item memiliki regulation_id dan pdf_download_link (link baca
PDF di viewer lokal; tampilkan sebagai "Baca PDF", bukan ajakan download). Bila user
meminta Pasal tertentu, pilih regulasi yang tepat lalu panggil baca_isi_pasal
dengan regulation_id itu dan nomor Pasalnya.
Args:
query: Nomor, tahun, jenis, atau kata dalam judul regulasi (1–2.000 karakter).
top_k: Jumlah judul kandidat, antara 1 dan 20.
sort: relevance (default), newest, atau oldest.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral burden – and it does: it discloses the return shape (each item has regulation_id and pdf_download_link), gives UI guidance ('tampilkan sebagai Baca PDF', not a download prompt), and specifies the link opens a local PDF viewer. It also warns the tool cannot be used to infer norm content, a substantive behavioral constraint.
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?
The description is front-loaded with purpose and when-not before the useful behavioral detail, with zero filler sentences. It runs slightly long – the pdf_download_link display instruction could arguably live elsewhere – but every clause carries information.
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 3-param search tool with no annotations and an existing output schema, this description covers purpose, when to use it, when not to, sibling routing, parameter bounds, and the meaning of returned fields. Nothing an agent needs to invoke 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 0%, so the description must compensate, and it does: query is defined as number/year/type/title word with a length constraint (1–2.000 characters), top_k is bounded (1–20), and sort options are enumerated with the default ('relevance', 'newest', 'oldest'). No parameter is left ambiguous.
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 ('Cari judul regulasi'), narrows scope to literal/as-is title matching, and explicitly disclaims semantic search and norm-content inference. This distinguishes it from siblings like cari_pasal_terkait and cari_peraturan_terkait without needing to open their schemas.
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 triggers ('bila pengguna meminta keberadaan atau nama regulasi tertentu') with concrete examples (UU 30 Tahun 2009, PP 45 Tahun 2009), states when-not ('bukan pencarian semantik dan bukan dasar untuk menyimpulkan isi norma'), and routes correctly to baca_isi_pasal for Pasal lookups with the required regulation_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cari Pasal yang relevan secara semantik ketika alamat normanya belum diketahui.
Gunakan untuk mencari norma berdasarkan makna—misalnya syarat, kewajiban, larangan, tenggat, sanksi, hak, kewenangan, atau alat bukti—ketika nomor Pasal dan/atau regulasi yang memuat norma tersebut belum diketahui.
Jangan gunakan tool ini untuk menemukan kembali Pasal apabila regulasi dan
nomor Pasalnya sudah diketahui. Untuk kasus seperti Pasal 34 UU Arbitrase,
gunakan cari_judul_peraturan untuk memperoleh regulation_id lalu
baca_isi_pasal secara langsung.
Hasil tool ini adalah semantic retrieval pada tingkat Pasal dan dapat langsung digunakan sebagai evidence untuk mengidentifikasi, membandingkan, mengutip, atau menganalisis norma yang relevan. Jangan membaca ulang hasil melalui baca_isi_pasal hanya karena Pasal tersebut akan dikutip, ditafsirkan, atau dijadikan dasar kesimpulan.
Gunakan baca_isi_pasal hanya apabila memang diperlukan pembacaan langsung berdasarkan regulation_id dan nomor Pasal yang sudah diketahui, misalnya karena pengguna secara eksplisit meminta Pasal tertentu atau terdapat alasan khusus untuk memeriksa kembali teks sumber.
Args: query: Pertanyaan atau topik hukum spesifik, WAJIB minimal 3 kata (1–2.000 karakter). top_k: Jumlah kandidat Pasal yang diminta, WAJIB antara 8 dan 20.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose the return semantics: semantic retrieval at Pasal level that can be used directly as evidence, with an explicit warning against reflexive re-reading via baca_isi_pasal. It omits finer behavioral traits such as error handling or behavior when candidates are weak, so it stops 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?
Purpose and usage are front-loaded well, but the definition is padded: the point about not re-reading results via baca_isi_pasal is made across two separate paragraphs, and the final paragraph largely repeats the routing already established in the second. Tightening the baca_isi_pasal caveat into one sentence would lose nothing.
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 need not explain return values, and it still covers the query semantics, the top_k bounds, the alternative tools, and the follow-up workflow. Nothing an agent needs to call this 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 coverage is 0%, so the description must compensate, and it does: query is a specific legal topic, mandatory, minimum 3 words, 1–2,000 characters; top_k is mandatory between 8 and 20. The query constraints are genuinely new (the schema declares no bounds for query), though top_k's 8–20 range merely restates the schema's min/max.
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: 'cari Pasal yang relevan secara semantik', and immediately scopes it to the case where the norm's address is unknown. It explicitly names the sibling it is not (cari_judul_peraturan, baca_isi_pasal), so an agent can distinguish it 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?
Gives explicit when-to-use (unknown nomor Pasal/regulation, searching by meaning such as syarat, kewajiban, sanksi), when-NOT-to-use with a worked example ('Pasal 34 UU Arbitrase' → cari_judul_peraturan then baca_isi_pasal), and the routing back to baca_isi_pasal for direct reads. Nothing 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.
Temukan regulasi relevan beserta Pasal kandidat untuk riset hukum bertahap.
Ini adalah titik awal yang dianjurkan saat perlu memahami payung regulasi, memetakan landscape hukum, membandingkan regulasi, atau menemukan regulasi yang normanya perlu dibaca lebih lanjut.
Respons menyimpan hasil dalam groups (kategori → hierarki → daftar regulasi).
Hasil tool ini terutama berfungsi sebagai discovery regulasi. semantic_hits
hanya preview maksimal 10 Pasal, sedangkan semantic_hit_pasals memuat seluruh
nomor Pasal kandidat unik.
Setelah regulasi yang relevan ditemukan, pilih Pasal kandidat dari
semantic_hit_pasals yang diperlukan untuk analisis, lalu gunakan
baca_isi_pasal untuk satu norma atau prioritaskan baca_isi_pasal_batch apabila
beberapa norma perlu dibaca pada tahap analisis yang sama. Inilah jalur utama
untuk memperoleh teks Pasal setelah discovery melalui cari_peraturan_terkait.
Jangan membaca seluruh Pasal kandidat secara otomatis. Pilih hanya regulasi dan Pasal yang relevan dengan isu hukum agar retrieval tetap efisien.
Jangan membuat sendiri regulation_id, judul, shard, atau path. ID hanya sementara pada registry gateway; ulangi pencarian ini jika ID tidak lagi dapat dibaca pada langkah berikutnya.
Args: query: Pertanyaan atau topik hukum yang ingin diteliti, WAJIB minimal 3 kata (1–2.000 karakter). top_k: Jumlah kandidat retrieval, antara 20 dan 200 (default 40, disarankan 100); nilai lebih tinggi memperluas cakupan tetapi dapat menambah waktu dan ukuran respons.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does well: it discloses the response shape (groups, semantic_hits capped at 10 preview articles, semantic_hit_pasals with all unique candidates), warns that IDs are ephemeral in the gateway registry and may need re-search, and notes that higher top_k increases time and response size. It stops short of stating read-only/safety characteristics, but the retrieval nature is obvious.
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?
It is front-loaded with the recommended-entry-point framing and organized into clear blocks, but it is long and repetitive — the baca_isi_pasal/baca_isi_pasal_batch routing and the 'main path' claim are restated, and the do-not-read-all warning overlaps with the selection guidance. Several sentences could be tightened without losing meaning.
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, yet the description still clarifies the meaning of its key fields (semantic_hits as a capped preview vs semantic_hit_pasals as the full candidate set), which is exactly the ambiguity an agent would hit. Combined with the routing, the ephemeral-ID warning, and parameter bounds, nothing an agent needs to invoke this 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 0%, so the description must compensate, and it does: query requires at least 3 words (1–2000 chars) and top_k is bounded 20–200 with default 40, a recommended 100, and an explicit trade-off between coverage and latency/payload size. Only minor syntax guidance (e.g. query format) is missing.
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: finding relevant regulations plus candidate Pasal for stepwise legal research, and frames itself as the recommended starting point. It clearly separates itself from the downstream read tools (baca_isi_pasal, baca_isi_pasal_batch) by routing to them. However it never distinguishes itself from the other search siblings (cari_judul_peraturan, cari_pasal_terkait), leaving that boundary implicit.
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?
Explicit when-to-use cases are given (understanding a regulatory umbrella, mapping legal landscape, comparing regulations, finding norms to read further), and it names the alternatives and the routing condition: pick Pasal from semantic_hit_pasals then use baca_isi_pasal for one norm or baca_isi_pasal_batch for several. It also gives an exclusion — do not auto-read all candidate Pasal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laporkan dugaan data Aturan.org yang perlu diverifikasi oleh reviewer manusia.
Tool ini gratis, tidak mengubah corpus, tidak melakukan retrieval/PDF fetch, dan tidak memberi kredit otomatis. Gunakan hanya setelah ada evidence yang cukup dari hasil Aturan.org atau sumber hukum yang dapat ditelusuri. Jangan membuat sendiri regulation_id, dan jangan melapor hanya karena sebuah peraturan pernah diubah: jelaskan dugaan masalah pada data Aturan.org.
Args:
regulation_id: ID enam digit dari hasil cari_judul_peraturan atau cari_peraturan_terkait.
issue_type: Salah satu: pasal_berubah, status_tidak_terkini,
teks_tidak_sesuai, peraturan_perubahan_belum_terhubung,
pasal_hilang, metadata_tidak_sesuai, atau lainnya.
description: Uraian factual mengenai data yang diduga perlu diperiksa (1–2.000 karakter).
pasal: Nomor Pasal opsional, misalnya 1, 5A, atau 1336.
evidence_url: URL HTTP(S) publik opsional menuju sumber bukti, tanpa kredensial.
evidence_note: Catatan bukti opsional, misalnya bagian sumber yang relevan (maksimal 1.000 karakter).
| Name | Required | Description | Default |
|---|---|---|---|
| pasal | No | ||
| issue_type | Yes | ||
| description | Yes | ||
| evidence_url | No | ||
| evidence_note | No | ||
| regulation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it discloses the tool is free, does not mutate the corpus, performs no retrieval/PDF fetch, and grants no automatic credit. Missing only auth requirements and rate limits, which prevents 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?
Front-loaded purpose followed by a clean Args block; every parameter gets one line. Slightly verbose in the negative-capability sentence but nothing is truly wasted.
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 no explanation. With all six params documented, usage gated on evidence, and side-effect behavior disclosed, an agent has everything needed to invoke 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 0%, so the description must compensate fully, and it does: it documents all six parameters, including the seven-value issue_type enum (which the schema lacks), the source of regulation_id, and length/format constraints (1–2000 chars, HTTP(S) no credentials, max 1000 chars).
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: reporting suspected Aturan.org data for human reviewer verification. This is clearly distinguishable from the read/search siblings (baca_isi_pasal, cari_*), which retrieve rather than report.
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?
Explicitly states when to use ('hanya setelah ada evidence yang cukup') and gives concrete exclusions: don't fabricate regulation_id, don't report merely because a regulation was amended. This is textbook when/when-not guidance.
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.
baca_isi_pasalbaca_isi_pasal_batchcari_judul_peraturancari_pasal_terkaitcari_peraturan_terkaitlapor_data_rusakSearch Indonesian laws, resolve citations, read articles, and find Constitutional Court decisions.
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Add one secure layer between your agents and this server.
