Persil Bhumi ATR/BPN, HGU, konsesi tambang, zonasi RDTR OSS.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 11 tools
Each tool targets a distinct entity and action: parcels, HGU rights, mining licences, villages, zoning, flood hazard, and overlaps are cleanly separated. Related fields inside Parcel_get (zona, znt, banjir) are explicitly distinguished from dedicated Flood_get/Zoning_get tools, so an agent can select correctly.
Most tools follow an Entity_Action snake_case pattern (HGU_get, HGU_search, Mining_get, Mining_search, Parcel_get, Parcel_search, Zoning_get). Minor deviations exist: Parcel_find_village uses a compound action, while Parcel_overlaps and Zoning_summary are noun-like rather than verb-like.
Eleven tools is well within the ideal 3–15 range and each tool has a clear role in the land-data workflow. There is no obvious padding or missing basic operation for the stated read-only purpose.
The surface covers parcel lookup, full parcel records, overlaps, HGU and mining search/get, village lookup, zoning point/zone and aggregate views, and flood hazard. Minor gaps remain: no standalone RTRW tool, no direct spatial search for HGU/mining outside a parcel context, and conservation areas only appear through Parcel_overlaps.
BNPB InaRISK flood hazard (bahaya banjir) at a location: kelas 1 rendah (low), 2 sedang (medium) or 3 tinggi (high), BNPB's three classes of its national 0–1 flood hazard index, cut at 1/3 and 2/3. Pass query as 'latitude, longitude' (e.g. -6.4601, 107.0093). For a parcel, Parcel_get's banjir gives the classes over its whole area. banjir is null where BNPB maps no flood hazard (dry ground or sea), not proof that it never floods. The map has 100 m cells and is a national model, not a record of past floods: use it to screen a location, not to judge a single plot.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 'latitude, longitude' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low; the description instead adds the interpretive behavior that matters — null means BNPB maps no hazard (dry ground or sea), 100 m cells, national model rather than a historical flood record. That is substantive context an agent cannot get from structured fields.
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 class semantics are front-loaded, and nearly every sentence carries distinct information (classes, input format, sibling alternative, null meaning, accuracy caveat). It is one dense paragraph with a slightly crowded middle sentence, but nothing is 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?
There is no output schema, so the description must explain return values, and it does: the three kelas values, the underlying 0-1 index and its cut points, and what null signifies. Combined with the accuracy caveats, an agent has everything needed to call and interpret it.
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 'latitude, longitude', so the baseline is 3. The description earns an extra point by supplying a concrete example pair (-6.4601, 107.0093), which removes ordering ambiguity, though it adds no new constraint or edge-case handling.
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 (BNPB InaRISK flood hazard at a location) and immediately defines the return vocabulary (kelas 1 rendah, 2 sedang, 3 tinggi) with the index cut points. It also names the sibling that serves a different scope (Parcel_get's banjir for a whole parcel), so an agent can distinguish it without opening 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?
Explicitly routes: use Parcel_get's banjir for a parcel, use this for a single location. It also gives the when-not condition ('screen a location, not judge a single plot') and warns that null is not proof of no flooding, which is exactly the misread an agent could make.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record of one HGU right by id (from HGU_search or Parcel_overlaps): right number, NIB, province and land office, holder as recorded and as first written (pemeganghakasli), domicile (kedudukan), holder type (tipepemilik: BUMN, BUMS private company, BUMD, individual…), land use, aktif, validsejak (in the data since) and berakhirhak (expiry), survey letter (su), area on the certificate (luastertulis) and on the map (luaspeta), both m², and the decrees: grant (skpemberian), extension (skperpanjangan) and renewal (skpembaruan), each with its date. Set include_geometry for the boundary as GeoJSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | HGU id | |
| include_geometry | No | Include the boundary as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context by explaining the full-record contents and the include_geometry option, though it does not cover error behavior or permissions.
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 purpose is front-loaded in the opening phrase, and the field list earns its space because there is no output schema. It is dense and could be more scannable, but it is not padded.
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 no output schema, the description carries the return-value burden and does so thoroughly by enumerating the record fields. Combined with annotations covering safety and schema covering parameters, 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 baseline is 3, but the description adds meaning: id comes from HGU_search or Parcel_overlaps, and include_geometry returns the boundary as GeoJSON. This goes beyond the schema's brief parameter descriptions.
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 and resource: fetching one HGU right by id. It also distinguishes this from HGU_search and Parcel_overlaps by making clear this is the single-record lookup used after those 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?
The parenthetical '(from HGU_search or Parcel_overlaps)' gives clear usage context: this tool is for retrieving a record once an id is known. It does not explicitly say when not to use it, but the retrieval-by-id scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current HGU (Hak Guna Usaha) rights, the long leases for plantations and other agriculture, largest first. Filters combine with AND; pass at least one. pemegang matches anywhere in the holder's name (e.g. 'Perkebunan Nusantara', 'Sinar Mas'); provinsi is a province name or BPN's 2-digit province office code; kantah a land office (regency/city) name; penggunaan the land use as BPN writes it (SAWIT oil palm, Karet rubber, Teh tea, Tebu sugar cane, Tanah Perkebunan plantation land, TAMBAK fish ponds…; often empty). aktif false finds rights BPN marks as no longer active. Each result has id, nomorhak (right number), holder, province (kanwil) and land office (kantah), land use, aktif, berakhirhak (expiry date), luastertulis (area on the certificate, m²) and bbox; total is the number of matches. Use HGU_get with an id for decrees and the boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| aktif | No | Only active (true) or inactive (false) rights | |
| limit | No | Maximum results | |
| kantah | No | Land office (regency/city) name | |
| offset | No | Results to skip, for paging | |
| nomorhak | No | HGU right number | |
| pemegang | No | Holder name or part of it | |
| provinsi | No | Province name or 2-digit BPN code | |
| penggunaan | No | Land use, e.g. SAWIT, Karet, Teh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the description only needs to add operating context; it does so with default ordering by size, AND-combination of filters, and a caution that penggunaan is 'often empty'. It does not mention paging behavior or result caps beyond what the schema says, so it falls 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?
Front-loaded with the core action and ordering, and each clause about filters or result fields carries information. It is a single dense paragraph of specialized vocabulary that an agent must parse, which slightly hurts skimmability.
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?
No output schema exists, yet the description enumerates every returned field (id, nomorhak, holder, province, kantah, land use, aktif, expiry, area, bbox) and explains that total is the match count. Combined with the filter semantics and the HGU_get handoff, an agent has everything needed to call and interpret results.
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?
Coverage is 100%, so baseline is 3, but the description adds real meaning: pemegang matches anywhere in the holder name with examples, provinsi accepts a name or BPN 2-digit office code, and penggunaan values are enumerated (SAWIT, Karet, Teh, Tebu, TAMBAK) despite no enums in the schema. It omits any guidance on nomorhak, limit, and offset semantics.
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 current HGU ... rights'), adds scope ('long leases for plantations and other agriculture') and ordering ('largest first'). It also distinguishes itself from the sibling HGU_get by pointing to it for decrees and boundaries.
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 combination semantics ('Filters combine with AND; pass at least one') and a clear alternative route: 'Use HGU_get with an id for decrees and the boundary.' The agent knows both when to use this tool and when to switch to the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record of one concession by id (from Mining_search or Parcel_overlaps): holder, group, licence type (izin) and stage (tahap), commodity as normalised (komoditas, komoditasEn) and as the source wrote it (komoditasasli), start and end dates, regency, province, source, luas (m², from the boundary) and hutansisa (m² of natural forest left inside, Nusantara Atlas's estimate). Also returns HPH (natural-forest logging) and HTI (pulpwood) concessions, with their decree (nomorsk). Boundaries are accurate to ~11 m. Set include_geometry for the boundary as GeoJSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Concession id | |
| include_geometry | No | Include the boundary as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: boundaries accurate to ~11 m, luas derived from the boundary, hutansisa is an estimate, and include_geometry toggles a GeoJSON MultiPolygon. It stops short of noting payload size or cost of requesting geometry.
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 id provenance are front-loaded, then the return fields are enumerated compactly with parenthetical glosses. It is a dense, long single block, but nearly every clause carries information an agent would otherwise have to guess.
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?
There is no output schema, so the description deliberately documents the returned fields and their units, which is exactly what an agent needs. Combined with the geometry toggle explanation, nothing material is missing for calling 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 baseline is 3, but the description adds provenance for id and clarifies that include_geometry yields the boundary as GeoJSON. It goes beyond restating the schema fields without fully specifying geometry output shape.
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?
Opens with a specific verb+resource+scope: 'Full record of one concession by id'. It names the sibling tools that produce the id (Mining_search, Parcel_overlaps) and even covers HPH/HTI, so an agent can separate it from the search siblings immediately.
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 tells the agent where the required id comes from ('from Mining_search or Parcel_overlaps'), which is the key routing signal. It does not state a when-not-to-use case or contrast against Parcel_get/Zoning_get beyond the shared id source, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ESDM mining licences, largest first. Filters combine with AND; pass at least one. pemegang matches anywhere in the holder's name (stored without the legal form, e.g. 'Vale Indonesia'); grup the corporate group (e.g. 'Harita', 'Mind Id'); komoditas a commodity in Indonesian or English (Nikel/Nickel, Batubara/Coal, Emas/Gold, Timah/Tin, Bauksit/Bauxite, Pasir Besi/Iron sand, Sirtu/Sand and gravel…); izin the licence type: IUP, IUPK, KK (contract of work), PKP2B (coal contract), IPR (people's mining), or WIUP/WIUPK, a licence area not yet licensed; tahap the stage: EKSPLORASI, OPERASI PRODUKSI, PENCADANGAN (reserved area), LELANG (auction), PASCATAMBANG (post-mining); provinsi and kabupaten match the names anywhere; berakhir true for licences whose end date has passed, false for the rest. Each result has id, holder, group, izin, tahap, komoditas, mulai/berakhir (start and end dates), kabupaten, provinsi, luas (m², from the boundary) and bbox; total is the number of matches. Use Mining_get with an id for the full record and boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| grup | No | Corporate group | |
| izin | No | Licence type | |
| limit | No | Maximum results | |
| tahap | No | Stage | |
| offset | No | Results to skip, for paging | |
| berakhir | No | true: end date passed; false: not ended or no end date | |
| pemegang | No | Holder name or part of it | |
| provinsi | No | Province name | |
| kabupaten | No | Regency/city name | |
| komoditas | No | Commodity, Indonesian or English |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add operational context — which it does: result ordering ('largest first'), AND filter semantics, substring matching behavior for pemegang/provinsi/kabupaten, and the contents of each result. It stops short of discussing rate limits or paging behavior beyond the total count, keeping it at 4.
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 with the verb/resource and ordering before the dense parameter glossary. It is a single long paragraph, but each clause earns its place by disambiguating an enum or match rule; it could be marginally more scannable but wastes little.
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 no output schema, the description takes on the burden of documenting returns and does so fully — enumerating id, holder, group, izin, tahap, komoditas, dates, location, luas, bbox, and the total count. Combined with the filter semantics, an agent has everything needed to call and interpret it.
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?
Despite 100% schema coverage, the description meaningfully enriches every parameter: it expands enum values (KK=contract of work, PKP2B=coal contract, WIUP=unlicensed area; tahap stages glossed), gives bilingual commodity examples, and explains that pemegang is stored without the legal form. This is genuine meaning beyond the schema's terse descriptions.
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 ESDM mining licences') plus ordering scope ('largest first'), and clearly distinguishes itself from Mining_get for full records. An agent can immediately tell what this tool returns versus its sibling.
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 the AND-combination rule and the constraint 'pass at least one' filter, and names the alternative ('Use Mining_get with an id for the full record and boundary'). The condition that selects the sibling is spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up BPN villages (desa/kelurahan) by name, code or certificate number. Names match as substrings and are often ambiguous (hundreds of villages share a name), so combine nama with kecamatan, kabupaten or provinsi. Names don't tell a Kota from a Kabupaten (both stored as e.g. 'Bogor'); the 4-digit code prefix does. kode accepts a prefix: 2 digits (province office), 4 (land office), 6 (kecamatan) or 8 (village). nomor decodes a 14-digit certificate number into its parts and returns the village it was registered in. Returns each village's 8-digit code, names, type and bbox; a code occasionally appears on more than one village after a split.
| Name | Required | Description | Default |
|---|---|---|---|
| kode | No | BPN code or code prefix | |
| nama | No | Village name | |
| limit | No | Maximum villages | |
| nomor | No | Certificate number to decode (14 digits) | |
| provinsi | No | Province name | |
| kabupaten | No | Regency or city name | |
| kecamatan | No | District name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuine behavior beyond that: the 14-digit decode path, the occasional duplicate code after a village split, and the fields returned per village. It omits pagination/limit behavior, keeping it below 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 with purpose and the ambiguity caveat before the parameter mechanics. Sentences are dense and every one carries information, though the mid-section runs long and could be split for faster scanning.
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 no output schema, the description correctly shoulders the return-value burden by listing 8-digit code, names, type and bbox, and warns about duplicate codes. The only gap is pagination/limit semantics for a 7-parameter search that can return hundreds of matches.
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 baseline is 3, but the description goes further than the schema by explaining that kode is a prefix whose length (2/4/6/8 digits) selects province office, land office, kecamatan or village, and that nomor must be 14 digits. The nama+kecamatan/kabupaten/provinsi combination advice also clarifies how filters interact.
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?
Opens with a specific verb+resource ('Look up BPN villages') and immediately states the three lookup keys (name, code, certificate number). The mention of what is returned (code, names, type, bbox) confirms the resource is a village record, not a parcel, distinguishing it from Parcel_get/Parcel_search.
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 real operational guidance: names are substring-matched and ambiguous, so combine nama with kecamatan/kabupaten/provinsi, and use nomor to decode a certificate. It stops short of naming a sibling (e.g. Parcel_search) as the alternative for parcel-level queries, so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record of one parcel by id: certificate number, NIB, right type, declared area (luas) next to the area of the mapped polygon (luasHitung) and their difference in percent, year, survey method (alatukur), mapping accuracy (akurasibidang, unit unknown), the village, perimeter and side lengths in metres, and center, a [longitude, latitude] point inside the parcel. zona lists the RDTR zoning sub-zones covering the parcel (kodzon/namzon zone, kodszn/namszn sub-zone, share of the parcel 0–1), largest first; empty where no detailed spatial plan is loaded. znt lists the land value zones (Zona Nilai Tanah) covering the parcel from each land office's latest year: kelas 1–9 stands for a range in Rp/m² (1 < 100k, 2 100k–200k, 3 200k–500k, 4 500k–1M, 5 1M–2M, 6 2M–5M, 7 5M–10M, 8 10M–20M, 9 > 20M), with tahun and share of the parcel; empty where no ZNT is loaded. banjir lists the BNPB flood hazard classes covering the parcel (kelas 1 rendah/low, 2 sedang/medium, 3 tinggi/high, with share of the parcel), largest first; empty means BNPB maps no flood hazard there. The hazard map has 100 m cells, so it rates the neighbourhood rather than the exact plot. A large area difference can point to a mapping error or an outdated certificate. nilai is almost always empty in the source. Set include_geometry for the boundary as GeoJSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Parcel id from Parcel_search | |
| include_geometry | No | Include the boundary as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safe read-only/idempotent behavior. The description adds substantial beyond that: empty-case meanings for zona/znt/banjir, ZNT class ranges, the 100m flood-cell caveat, interpretation of area difference, and that nilai is usually empty.
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 with the core purpose and dense with field semantics because there is no output schema. It is long and one paragraph, but most clauses earn place by explaining return fields; minor structural issue.
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?
No output schema, so description carries return-value burden; it comprehensively explains fields, empty states, and caveats. For a read-only getter with annotation coverage, it is complete enough.
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 both parameters are already documented in schema. Description reinforces id scoping and include_geometry but adds little syntax/semantic detail beyond schema; baseline 3.
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 opens with 'Full record of one parcel by id', which states the resource and scope precisely and implies retrieval. It does not explicitly name Parcel_search or another sibling as the alternative, so it is clear but lacks explicit sibling differentiation.
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 implies use when you have a parcel id and want the full record, and notes include_geometry for boundary retrieval. It does not state when to use this versus Parcel_search/Parcel_overlaps or any prerequisites/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Other parcels, HGU (plantation lease) rights, concessions and conservation areas whose boundaries overlap a parcel, largest overlap first. overlap is the shared area in m²; shareOfParcel and shareOfOther are that area as a fraction (0–1) of this parcel and of the other one. Both near 1 means two certificates on the same land (or a duplicate record); a small share is usually a mapping offset between neighbours. Slivers under 1% of the smaller polygon are left out, since neighbouring BPN boundaries rarely line up exactly. A Hak Guna Usaha parcel usually overlaps its own HGU record. konsesi are mining licences (jenis TAMBANG; izin IUP, IUPK, KK, PKP2B, IPR, or WIUP/WIUPK for a licence area not yet licensed; berakhir is the licence end date, often past; komoditas is the commodity as ESDM names it, komoditasEn the same in English), natural-forest logging licences (HPH) and pulpwood plantations (HTI). konservasi are national parks, nature reserves and other conservation areas (fungsi as KLHK names it). Their boundaries are accurate to ~11 m only, so a parcel within a few metres of the edge may be either side. Set include_geometry for the overlapping areas as GeoJSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Parcel id from Parcel_search | |
| include_geometry | No | Include each overlapping area as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, idempotent, closed-world call, so safety is covered; the description then adds substantial behavior on top: result ordering, the meaning of overlap, shareOfParcel and shareOfOther, the sliver filter, and the ~11 m boundary inaccuracy for konservasi. It also explains what include_geometry changes about the response.
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 behavior and the ordering are front-loaded in the first sentence, and the rest is dense but earns its place given there is no output schema. The long run of parenthetical glosses on izin codes and ESDM naming is heavy, but deleting it would lose real interpretive value.
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 two parameters, no output schema and no nested objects, the description carries the full burden of explaining return values, and it does so thoroughly: field meanings, ordering, filtering threshold, and accuracy limits. An agent can interpret a response without further documentation.
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 id ("Parcel id from Parcel_search") and include_geometry are already documented. The description reinforces include_geometry's effect (overlapping areas as GeoJSON) but adds no syntax or format detail beyond the schema, 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?
The description names the resource and the operation precisely: parcels, HGU rights, concessions and conservation areas overlapping a given parcel, returned largest-overlap-first. It is clearly distinguishable from siblings like HGU_search or Mining_search, though it never explicitly names them and reads as a result description rather than a verb-led statement of what the tool does.
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 substantive interpretive guidance: both shares near 1 means two certificates on the same land or a duplicate, a small share is usually a mapping offset, and a Hak Guna Usaha parcel usually overlaps its own HGU record. It also states the <1% sliver exclusion and the ~11 m accuracy caveat, so an agent knows how to read results. It stops short of saying when to prefer this over Parcel_get or the *_search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find parcels by certificate number, NIB or location. query takes a certificate number (nomor, 14 digits; dots or spaces allowed, e.g. 22.01.05.03.1.00123), a NIB (parcel number, e.g. 02007), the village code plus NIB as certificates print it (13 digits, e.g. 22.03.09.03.04753 = village 22030903, NIB 04753), or coordinates as 'latitude, longitude' (e.g. -6.4601, 107.0093). A NIB is only unique within a village, so pass desa to narrow it; otherwise matches come from all over the country. With coordinates it returns the parcels containing the point (distance 0), then the nearest within radius metres, closest first, plus the village containing the point. To search an address, geocode it first; geocoded points are often tens of metres off, so a radius of 25–100 m helps. No parcels at a location means BPN publishes no parcel there, not that the land is unregistered. Each parcel has id, nib, nomor, tipehak, declared area (luas, m²), year (tahun) and bbox; number searches also give the village (wilayah: via 'nomor' = the village coded in the certificate number, 'lokasi' = the village containing the parcel). Use Parcel_get with an id for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| desa | No | 8-digit BPN village code to search a NIB within (from Parcel_find_village) | |
| limit | No | Maximum results | |
| query | Yes | Certificate number (14 digits), village code + NIB as printed on certificates (13 digits, e.g. 22.03.09.03.04753), NIB, or 'latitude, longitude' | |
| radius | No | Search radius in metres around coordinates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses key behavioral traits: NIB is only unique within a village, coordinate search returns containing parcels first then nearest within radius, and no results mean BPN publishes no parcel there (not that land is unregistered). This is substantial added context.
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 information is front-loaded with the core purpose and query formats. Each sentence adds value (e.g., NIB uniqueness, geocoding advice, result fields). However, it is a dense single paragraph that could be more scannable with structure.
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 search tool with four parameters and no output schema, the description covers query semantics, result fields, behavioral caveats, and alternatives (Parcel_get). Combined with annotations that cover safety, an agent has everything needed 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful detail: it explains the 13-digit village+NIB format, why `desa` narrows NIB searches, and how coordinates are interpreted. It also clarifies that `radius` applies only to coordinate searches. These additions go beyond the schema descriptions.
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 opens with a specific verb and resource: 'Find parcels by certificate number, NIB or location.' It also names the sibling tool Parcel_get for full records, so the agent can distinguish the search scope from retrieval. There is no ambiguity about what the tool does.
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 clear usage context: geocode addresses first, use a radius of 25–100 m for imprecise points, and pass `desa` to narrow a NIB. It also points to Parcel_get for full details. It lacks an explicit 'when not to use' statement, but the conditions for each query form are well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RDTR zoning (detailed spatial plan) at a location, or one zone by id (Parcel_get's zona.ids). Pass query as 'latitude, longitude' (e.g. -6.4601, 107.0093), or id. Each zone has kodzon/namzon (zone, e.g. R Zona Perumahan), kodszn/namszn (sub-zone, e.g. R-2 Perumahan Kepadatan Tinggi), lindung (true = protected zone, false = cultivation zone), the planning hierarchy (kodewp planning area, kodswp sub-area, kodblk block, kodsbl sub-block), kecamatan and desa as the plan names them, luas (m², the whole zone polygon) and rdtr, the plan with its regulation (peraturan) and a link to it (pp). ketentuan holds the special provisions that apply, keyed by code: krb disaster-prone, lp2b protected food farmland, kkop airport flight safety, ksmpdn setback, teb disaster evacuation, tod transit-oriented development, cagbud cultural heritage, resair water catchment, hankam defence, kkarst karst, ptbgmb mining, mgrsat wildlife migration, rdbumi underground space, puslit research centre, tpz zoning technique (TPZ). An empty result at a point means no RDTR plan covers it in this data, not that the land is unzoned: the regional plan (RTRW) still applies. Where plans overlap, more than one zone is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Zone id, e.g. 21A5-125300 | |
| query | No | 'latitude, longitude' | |
| include_geometry | No | Include each zone's boundary as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it explains that an empty point result means no RDTR plan covers the location rather than unzoned land, and that overlapping plans return multiple zones. That is exactly the kind of edge-case behavior an agent cannot infer from structured fields.
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 is front-loaded in the first clause, and almost every sentence carries information an agent needs. The long enumeration of ketentuan codes and hierarchy fields is dense prose that would be more scannable as a list, which keeps it from a 5.
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 no output schema, the description takes on the burden of explaining return fields and does so field by field (kodzon/namzon, lindung, hierarchy codes, luas, rdtr/peraturan/pp, ketentuan codes), plus the empty-result and overlap semantics. An agent can interpret the response without further documentation.
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; the description adds value by supplying a concrete coordinate example for the query string and by stating that ids come from Parcel_get's zona.ids. It does not mention include_geometry, leaving that 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?
States a specific verb and resource — retrieving RDTR zoning at a location or a single zone by id — and distinguishes itself from Parcel_get by referencing its zona.ids for id lookup. The parenthetical '(detailed spatial plan)' disambiguates the domain term RDTR.
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 clear invocation guidance for both modes: 'Pass query as latitude, longitude ... or id', and points to Parcel_get as the source of zone ids. It lacks explicit guidance on when to prefer it over the sibling Zoning_summary, so it stops short of full when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much of a village or regency/city the RDTR plans zone for each use: area by zone, and within each zone by sub-zone, largest first. Pass desa, an 8-digit BPN village code (from Parcel_find_village), or kabupaten, a regency/city name or 4-digit Kemendagri code. Regency names are bare for a kabupaten and prefixed for a city: 'Bogor' or 'Kabupaten Bogor' is the regency, 'Kota Bogor' the city; an ambiguous name returns the candidates to choose from. luasWilayah is the area of the village or regency (m²), luasZonasi the area its RDTR zones cover and shareZonasi the fraction covered; plans are usually for towns, so a rural regency is often mostly unplanned. Zone share is of the zoned area, not of the whole area. For a village, zones are clipped to its boundary. For a regency, it counts the plans assigned to it in full, even where one crosses into a neighbour. plans lists the RDTR plans involved with their regulations. Zone codes are named the same across plans but names vary, so each code shows its most common name. A large regency can take a second or two.
| Name | Required | Description | Default |
|---|---|---|---|
| desa | No | 8-digit BPN village code | |
| kabupaten | No | Regency/city name or 4-digit Kemendagri code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent annotations, the description discloses important behavior: ambiguous names return candidates, village zones are clipped to the boundary, regency plans are counted in full even if they cross boundaries, zone codes show their most common name, and large regencies may take a second or two. These details materially help an agent understand the tool's 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?
The description is dense but front-loaded with the tool's output and primary parameters. Every sentence contributes useful semantics, caveats, or performance expectations, and there is no 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?
With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: area by zone/sub-zone, luasWilayah, luasZonasi, shareZonasi, zone share basis, plans list, and zone code naming. It also covers ambiguity, spatial clipping semantics, and performance, leaving little an agent needs to infer.
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 already 100%, but the description adds substantial meaning: desa is an 8-digit BPN village code from Parcel_find_village, kabupaten accepts a regency/city name or 4-digit Kemendagri code, naming conventions distinguish kabupaten from kota, and ambiguous names return candidates. This goes well beyond the schema text.
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 clearly states that this tool returns zoned area by zone and sub-zone, largest first, for a village or regency/city. It is specific about the resource and output structure, but it does not explicitly distinguish itself from the sibling Zoning_get tool.
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 clear usage context: pass desa or kabupaten, how regency/city names are interpreted, and what happens for ambiguous names. It also explains village clipping versus regency plan counting and notes that rural regencies may be mostly unplanned, but it does not state when to prefer this over Zoning_get or clarify behavior when both or neither parameters are supplied.
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.
Flood_getHGU_getHGU_searchMining_getMining_searchParcel_find_villageParcel_getParcel_overlapsParcel_searchZoning_getZoning_summaryIndonesian land parcels (ATR/BPN), HGU, mining concessions, RDTR zoning and flood hazard.
Indonesian ATR/BPN land parcels by certificate number, NIB or coordinates, with overlaps.
Indonesian OSS RDTR zoning: zone and sub-zone at a point, special provisions, area summaries.
Indonesian ESDM mining licences (IUP, IUPK, KK, PKP2B): holder, commodity, area, expiry.
Add one secure layer between your agents and this server.
