Skip to main content
Glama

AQL PropertyCheck — check one exact address (Gold Coast & Brisbane)

Get the full PropertyCheck report

get_full_report
DestructiveIdempotent

Full structured PropertyCheck JSON (propertycheck/2) for one covered address: identity, coverage, capabilities, a summary and up to twelve sections, with status and source details where available. Call after check_address shows a full report is available. Free vs paid: check_address returns at most five findings and two unverified items; this tool returns the full sections listed in sections_available (for example hazards, roads and traffic, parking and access, mobility, planning, education and area), each item with its own status. No account or API key is required for one-off purchase: x402 returns a standard PaymentRequired (A$1.39 incl. GST); retry the same call with params._meta['x402/payment']. Coverage is checked before any charge, an address outside coverage is never charged, and retrying with the same idempotency_key or the same payment never charges twice. If the user has no wallet, ask for explicit agreement to the A$4.95 card price, then call the same tool with payment_method='card'; give checkout_url only to the human and poll this same tool with the returned purchase_id and access_token. Never create a second checkout for that purchase. Existing B2B API-key accounts remain supported. After an API-key or x402 purchase, pass report_id instead of address to re-view the same report at zero cost; x402 re-view also carries the original payment proof. Optional sections limits the output; detail='full' restores heavy enumerations from the same stored report, with no second charge.

Input Schema

NameRequiredDescriptionDefault
detailNoOptional. standard (default) keeps all decision-useful facts; full also restores available heavy enumerations from the same stored report.
addressNoOne street address in the City of Gold Coast or Brisbane City, with the street number and suburb (and the unit number for an apartment), for example "9 Hamilton Avenue, Surfers Paradise QLD 4217" or "26 Lomandra Place, Chapel Hill QLD 4069".
sectionsNoOptional. Only these sections (identity, coverage, summary and sources are always included). Same price.
report_idNoAn already purchased report to re-view at zero cost. Use address OR report_id, never both.
purchase_idNoPrivate card-report purchase id returned by this tool. Poll with purchase_id plus access_token; do not send the address again.
access_tokenNoPrivate card-report retrieval token. Keep it inside the agent session and use only with its purchase_id.
payment_methodNoOptional for a new address. Default x402 (A$1.39). Use card only after the human explicitly agrees to A$4.95.
idempotency_keyNoOptional, API-key path. Reusing it returns the same report without a second charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / address / description
      Previous value: -"One street address with number and suburb, e.g. \"9 Hamilton Avenue, Surfers Paradise QLD 4217\" or \"222 Margaret Street, Brisbane City QLD 4000\"."New value: +"One street address in the City of Gold Coast or Brisbane City, with the street number and suburb (and the unit number for an apartment), for example \"9 Hamilton Avenue, Surfers Paradise QLD 4217\" or \"26 Lomandra Place, Chapel Hill QLD 4069\"."
  2. Changed3 schema fields changed
    • addedInput schema / properties / access_token
      Added value: +{
      +  "description": "Private card-report retrieval token. Keep it inside the agent session and use only with its purchase_id.",
      +  "pattern": "^[A-Za-z0-9_-]{43}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / payment_method
      Added value: +{
      +  "description": "Optional for a new address. Default x402 (A$1.39). Use card only after the human explicitly agrees to A$4.95.",
      +  "enum": [
      +    "x402",
      +    "card"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / purchase_id
      Added value: +{
      +  "description": "Private card-report purchase id returned by this tool. Poll with purchase_id plus access_token; do not send the address again.",
      +  "pattern": "^acr_[a-f0-9]{32}$",
      +  "type": "string"
      +}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond annotations: pricing, coverage-before-charge behavior, idempotency guarantees, x402 PaymentRequired flow, card checkout handling, zero-cost re-view, and the fact that detail='full' does not trigger a second charge. These details are important because the tool can initiate paid purchases despite being a report retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and key usage rule are front-loaded, and most sentences carry operational information needed for payment, re-view, and polling flows. It is dense and somewhat overpacked into a single paragraph, but the complexity of the paid-report flow justifies most of the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no output schema, the description explains the report contents, section behavior, payment paths, idempotency, re-view flow, and card-checkout polling. This is sufficient for an agent to use the tool correctly without needing to infer critical behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the baseline is 3. The description nevertheless adds useful cross-parameter meaning: report_id re-views at zero cost, sections limits output at the same price, detail='full' restores enumerations from the stored report, and purchase_id plus access_token are used for polling a card purchase.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and format: full structured PropertyCheck JSON report for one covered address, including identity, coverage, capabilities, summary, and up to twelve sections. It also distinguishes the tool from its sibling by explaining that it should be called after check_address shows a full report is available.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: call after check_address indicates a full report is available, use report_id to re-view an already purchased report, and use address for a new report. It also distinguishes payment paths, including when to use x402 versus card and how to poll an existing card checkout.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources