GISDB

join_waitlist

Idempotent

Add a homeowner or investor's email to the priority launch waitlist for properties outside the initial launch area, with optional subscriptions for county launch alerts and tax strategies.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>",
      "street_address": "<street_address>"
    },
    "name": "join_waitlist"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	Homeowner email address
`notes`	No	Optional notes or estimated assessment
`opt_in_updates`	No	Subscribe to county launch alerts and property tax calendar deadline reminders (default: true)
`street_address`	Yes	Property street address
`referral_source`	No	Where the homeowner heard about Untax (e.g. 'muse', 'claude', 'chatgpt', 'google', 'twitter', 'friend')
`opt_in_marketing`	No	Subscribe to property tax saving strategies, market reports, and updates (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds that the write is a waitlist enrollment with two optional subscription side effects, which is useful. It does not say what happens after submission (confirmation, dedupe behavior despite idempotentHint, notification flow).

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?

It is a single front-loaded sentence with no filler, leading with the action and subject. The trailing 'with optional subscriptions...' clause is somewhat compressed but still earns its place by flagging side effects.

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?

For a straightforward signup tool with a fully documented six-parameter schema, no output schema, and annotations carrying the mutation/idempotency profile, the description covers purpose, scope, and optional side effects adequately. Only the post-submission outcome and duplicate handling are left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters including defaults for the two opt-in booleans. The description restates the subscriptions at a summary level ('county launch alerts and tax strategies'), adding only mild mapping value beyond the schema's own wording.

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 gives a concrete verb+resource ('Add ... email to the priority launch waitlist') and narrows scope to 'properties outside the initial launch area', which distinguishes it from the audit_* siblings and get_waitlist_analytics. It stops short of naming any alternative tool for in-area properties, so it is clear but not sibling-differentiating.

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

Usage Guidelines3/5

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

The phrase 'properties outside the initial launch area' implicitly tells the agent when this tool applies, and the mention of optional subscriptions hints at the opt-in flow. However, there is no explicit when-not guidance (e.g., what to do for in-area properties) and no named alternative, leaving the routing decision to inference.

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

All GISDB tools Inspect

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.