Skip to main content
Glama
Sign In

A-du: ADU rentals, plans and rules

by homes.a-du
OverviewDiscussionsAdmin

List or claim ADU plans on A-du

start_plan_listing
Read-onlyIdempotent

For an architect, designer, general contractor or builder who wants homeowners to find their ADU plans on A-du Build. Without plan_id it returns the link to list a new plan set. With the plan_id of a plan a city or county published that the person drew, it returns the link that opens the claim for that plan, so they manage its price, permitting service and buyer requests; plans an agency offers for free cannot be claimed, and the tool says so. Listing and claiming are free and it needs no account to call: the person signs in and finishes in the browser, which an assistant cannot do for them. Stripe verifies identity before the first payout. On A-du Build, the customer pays only the plan or permitting price, with no A-du service fee on top. A-du's 3% platform service fee on plan purchases and permitting services is deducted from the vendor's payout. The flat-fee permitting service that Chris Koss, AIA, a California-licensed architect who owns A-du, provides personally under a separate written agreement with the homeowner carries no A-du fee (A-du is not a party to that agreement and provides only the technology platform, payment orchestration and permit tracking for it), and neither do government permit fee reimbursements; free plans stay free. A credit card, when offered, adds the 2.99% surcharge on the amount paid, paid by the customer; debit and prepaid cards are not accepted. Example: {"plan_id": "ac178fff-d9ac-47d9-a28c-01ce5de46027"}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_plan_listing"
  }
}

Input Schema

NameRequiredDescriptionDefault
plan_idNoOnly to claim an existing plan: its A-du id, from search_plans or a a-du.homes/build/design/<id> URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

The annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, and the description adds substantial context beyond that: it returns links, requires no account to call, hands sign-in off to the browser, and explains claim eligibility and payment/identity constraints. Nothing in the description contradicts 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.

Conciseness2/5

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

The core behavior is front-loaded well, but the description becomes bloated with fee schedules, Stripe identity verification, named-architect details, surcharge rules, and card acceptance policies that are not needed to select or invoke this tool. For a one-parameter tool, several sentences do not earn their place.

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

Completeness4/5

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

With no output schema, the description does reasonably well by explaining that the tool returns a link and that browser sign-in is required to finish. It covers the key claim restrictions and account prerequisites, though the payment/fee tangents reduce focus without adding invocation-critical context.

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?

The schema already has 100% description coverage for plan_id, so the baseline is 3, but the description adds useful meaning about omission behavior and claim eligibility. It explains that plan_id should only be used to claim an existing plan that the person drew and that free agency plans cannot be claimed.

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

Purpose4/5

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

The description clearly states a specific verb and resource: it lists or claims ADU plans, with different behavior depending on whether plan_id is supplied. It distinguishes the no-plan_id listing path from the with-plan_id claim path, but it does not explicitly differentiate itself from sibling tools such as start_listing or draft_listing.

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

Usage Guidelines4/5

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

It gives concrete conditions for use: omit plan_id to get a new-plan listing link, or provide plan_id to claim a city/county-published plan the user drew. It also states a key exclusion that free agency plans cannot be claimed, but it does not name alternative tools or explain when to prefer them.

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

All A-du: ADU rentals, plans and rules toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources