US parcels and building permits from public sources. No owner data. Pay per record or monthly plan.
Scored across 13 tools
Most tools have clearly distinct purposes: search (query_parcels, query_permits), location reports (site_screen, mortgage_precheck), and billing/lifecycle tools are separable. The one borderline pair is site_screen vs mortgage_precheck, which both return parcel facts plus FEMA flood zone for a single location; the descriptions differentiate them (environmental screening vs mortgage/loan-limit context) but an agent could still hesitate.
Names are uniformly snake_case with a predictable verb_noun shape for most tools (get_credit_balance, list_credit_packs, query_parcels, cancel_subscription). A few are noun/verb-only (subscribe, site_screen, mortgage_precheck), which is a minor deviation but still readable and unambiguous.
13 tools is well-scoped: three data tools, two composite report tools, a fetch-job poller, and a coherent billing/key-lifecycle group. Each tool earns its place with no obvious filler or missing slot.
Core lifecycle is covered: search parcels/permits, single-location reports, async job polling, credits/subscription purchase, status, cancel, and key claiming. Minor gaps: no direct get-parcel-by-id detail tool separate from reports, and no usage/transaction history, but agents can work around these via query_parcels and status tools.
Create a Stripe Checkout link to buy a credit pack (see list_credit_packs). A human must open the link and pay; this tool charges nothing. With an API key, the credits go to that key. Without a key, a new key is created after payment: call claim_api_key with the returned session_id to receive it (once).
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint, non-idempotent, non-destructive), it discloses the crucial behavior that the tool itself performs no charge and that fulfillment is human-driven and asynchronous. It also discloses a side effect not visible anywhere else: a new API key is created after payment and is claimable only once.
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?
Three tight sentences, with the most important correction ('this tool charges nothing') front-loaded ahead of the fulfillment details. No sentence is redundant or restates the title.
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 one-parameter, no-output-schema tool, it covers everything an agent needs: what is produced (a checkout link plus a session_id), who completes it, and how to redeem the result. Nothing essential is left to inference.
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% and the single `pack` parameter is documented nowhere in the schema, but the description redirects the agent to list_credit_packs as the source of valid pack identifiers, which resolves most of the ambiguity. It stops short of stating the identifier format or whether the pack determines the price.
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?
Specific verb + resource: 'Create a Stripe Checkout link to buy a credit pack,' and it immediately corrects the misleading name/title by noting 'this tool charges nothing.' It explicitly points to the sibling list_credit_packs for the pack values, so an agent can separate it from claim_api_key and get_credit_balance without opening 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?
States the precondition (a human must open the link and pay) and branches the follow-up path clearly: with an API key the credits attach to that key; without one, the agent must call claim_api_key with the returned session_id, exactly once. Explicit alternative/next-step routing is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel your monthly plan at the end of the current paid period. No further charges; remaining monthly credits stay usable until the period ends and pack credits are kept. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true, and the description meaningfully fleshes out what 'destructive' does and does not mean: no further charges, monthly credits usable until period end, pack credits retained, and free of cost. This is exactly the consequence-level detail an agent needs before invoking a destructive mutation.
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?
Three short sentences, front-loaded with the action and timing, followed by the effects. No redundant restatement of the title and every clause carries new 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 zero-param mutation with annotations covering the safety profile and no output schema, the description supplies the key billing and credit consequences. It could go slightly further on edge cases (e.g., behavior when no active subscription exists), but it is broadly complete.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. Nothing in the description misleads about inputs.
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 ('Cancel your monthly plan') plus the exact timing scope ('at the end of the current paid period'). An agent can distinguish this from the sibling subscribe tool 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?
The timing and effect ('end of the current paid period') imply when this is appropriate, but the description never explicitly contrasts with siblings like get_subscription_status or subscribe, nor does it state a when-not condition. Usage is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After paying a buy_credits checkout without a key, claim the new API key with the checkout 'session_id' (starts with cs_). The key is shown only once: store it securely and send it as 'Authorization: Bearer'.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: the secret is returned once only, must be stored, and is used as an 'Authorization: Bearer' token — critical for an agent handling a secret. The non-idempotent annotation is not elaborated, so it is unclear what a second claim with the same session_id returns (error vs. same key).
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?
Two sentences, no filler, front-loaded with the trigger condition followed by the security-critical handling instruction. Every clause adds information an agent needs.
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 still conveys that the return value is the API key itself and that it is unrecoverable afterward. Minor gaps remain around error/repeat-claim behavior and any auth requirements for calling it before a key exists.
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 carry the parameter burden, and it does: session_id is identified as the checkout session and its 'cs_' prefix is given as a recognizable format. It does not say where the agent obtains the session_id (which field of the buy_credits response).
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?
Specific verb+resource ('claim the new API key') plus the exact triggering condition ('after paying a buy_credits checkout without a key'), which distinguishes it from the sibling buy_credits call it depends on. An agent can tell what this does and where it sits in the flow without opening the 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 states the precondition (a completed buy_credits checkout that generated no key) and names the sibling that creates that state, so the ordering is unambiguous. It stops short of stating when NOT to call it, e.g. what to do if a key already exists or how to recover a lost key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the remaining credit balance for your API key. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety bar is low. The description adds genuinely useful non-annotation context: the balance is scoped to 'your API key' and the call itself is 'Free' (no credit consumption). It does not say what the returned value looks like, which keeps it from 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?
Two sentences, front-loaded with the resource, zero redundant repetition of the title or schema. 'Free' is a terse fragment but carries real 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?
A zero-param, annotated read tool with no output schema needs little more than what is here. The one gap is that an agent cannot tell the return shape (numeric balance, currency, units), though for a simple balance check this is a minor omission.
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?
Zero parameters, so per the baseline this scores 4. Nothing about the empty schema needs further explanation, and the description correctly implies 'your API key' is supplied implicitly via auth rather than as an argument.
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 ('Show') and resource ('remaining credit balance for your API key'), which cleanly separates it from siblings like buy_credits, list_credit_packs, and get_subscription_status. It does not explicitly name those siblings, so it stops short of a 5.
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?
Usage is implied: check how much credit is left, presumably before making metered calls. There is no explicit when-to-use guidance, no exclusions, and no pointer to buy_credits when the balance runs low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an on-demand fetch job started by query_parcels (status queued/running/done/failed). Free. When it is done, repeat the same query_parcels search.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds real value by disclosing the four status values and that calls are free (no credit consumption), which matters given the buy_credits/get_credit_balance siblings. It does not say whether job records expire or how often to poll.
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?
Three short sentences, front-loaded with the action and ending with the next-step instruction. The 'Free.' fragment is terse but carries genuine cost information in a toolset that sells credits, so it earns its place.
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 one-parameter status tool with a fully-specified safety annotation set and no output schema, the description covers what it does, the status domain, cost, and the follow-up action. Missing only polling cadence and terminal-state handling (expired/failed jobs), which are minor against the overall coverage.
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 job_id parameter has no schema description (0% coverage), so the description carries some burden. It implicitly tells the agent where job_id comes from — a fetch job started by query_parcels — but gives no format, length, or error behavior for an invalid ID.
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 ('Check an on-demand fetch job') and anchors it to the sibling that creates it ('started by query_parcels'), which lets an agent place it in the workflow. It also enumerates the possible states (queued/running/done/failed), narrowing the concept further. It stops short of explicitly ruling out jobs created by other query siblings such as query_permits.
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?
'When it is done, repeat the same query_parcels search' gives concrete follow-up behavior, so an agent knows this is a polling tool rather than a data-retrieval tool. There is no explicit 'do not call before starting a job' or guidance for what to do on 'failed', but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your monthly plan (plan, status, renewal time, cancel_at_period_end) and your credit balances (subscription credits vs pack credits). Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context by disclosing the returned content and noting it is 'Free' (no cost impact), which is useful behavioral information not in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that packs the resource, the returned fields, and the cost note with no waste. Everything earns its place.
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 parameters and no output schema, the description usefully enumerates what is returned, covering the main completeness gap. It stops short of clarifying the boundary with get_credit_balance, which would round it out fully.
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 tool takes zero parameters, so there is nothing to document and the baseline is 4. The description doesn't need to compensate for any parameter gap.
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 ('show') and resource (monthly plan and credit balances) and even enumerates returned fields (plan, status, renewal time, cancel_at_period_end). It overlaps conceptually with the sibling get_credit_balance but doesn't explicitly differentiate itself from it.
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?
Usage is only implied ('show your monthly plan') with no explicit when-to-use or when-to-use-instead-of guidance. It does not point to siblings like get_credit_balance or list_subscription_plans, leaving the agent to infer which tool covers which slice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the credit packs you can buy (name, credits, price). Free; no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, but the description adds something they don't: the call is free and requires no API key, which materially affects how an agent plans a call sequence. It stops short of describing result ordering or whether the list is complete versus paginated.
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?
One short sentence plus a two-word auth note — the payload fields and the no-key condition are both front-loaded with zero filler. Nothing could be removed without losing 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 read-only, zero-param listing with no output schema, the definition gives enough to call it correctly: what it returns, that it's free, and that no key is needed. The only missing piece is where the agent should go next (buy_credits) after inspecting packs.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is empty and fully specified. Baseline 4 applies, with no parameter-level value the description could have added.
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 ('List the credit packs you can buy') and previews the payload fields (name, credits, price), so the agent knows exactly what comes back. It does not explicitly contrast with siblings like list_subscription_plans or buy_credits, which keeps it out of the top band.
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?
'Free; no key needed' signals this is a safe entry-point call that needs no credentials, implying a browse-before-buy flow. However, it never says when to prefer this over get_credit_balance or list_subscription_plans, or that buy_credits is the follow-up step — usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the monthly subscription plans (name, credits per month, price). Monthly credits reset each billing cycle and do not roll over; pack credits are separate and never expire. Free; no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so credit goes for the business rules added on top: monthly credits reset each cycle and do not roll over, pack credits never expire, and there is no cost or auth. It does not say anything about caching or ordering of results, which keeps 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?
Two sentences, front-loaded with what is listed, then the non-obvious credit-expiry rule, then the cost/auth fact. No filler and every clause carries information an agent would otherwise have to discover by calling.
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 parameters and no output schema, the description carries the return-shape burden and does so by naming the three fields, and it clarifies the billing semantics that would otherwise confuse a follow-up subscribe or buy_credits call. Nothing needed 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?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The parenthetical field list gives a hint of what comes back without pretending to document inputs.
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 ('List the monthly subscription plans') and enumerates the returned fields (name, credits per month, price). The clause about pack credits being separate implicitly separates it from list_credit_packs, though that sibling is never named.
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?
'Free; no key needed' removes a common prerequisite but never says when to call this instead of list_credit_packs, get_subscription_status, or subscribe. The distinction from credit packs is implied through the credit-expiry remark rather than stated as routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mortgage property pre-check for one location (informational): county + Census tract, FFIEC tract income level (low/moderate/middle/upper) and CRA flags, FHFA conforming and HUD FHA county loan limits (1-4 units), USDA Rural Development area eligibility, FEMA flood zone and parcel facts (no owner data; value and last sale only where stored). Property data only: do NOT send borrower names, income, SSN or loan amounts. Locate by lat+lon, address+state, or parcel_id+state. Costs 5 credits when complete, 3 if a source fails or a reference file is not loaded, 0 if the point cannot be resolved. Not a flood determination, not a consumer report; verify before any Loan Estimate or credit decision.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| zip | No | ||
| city | No | ||
| state | No | ||
| units | No | ||
| address | No | ||
| parcel_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: a tiered credit cost (5 complete / 3 on source failure or missing reference file / 0 if the point cannot be resolved), partial data availability ('value and last sale only where stored'), and scope limits ('no owner data', 'not a flood determination, not a consumer report'). This is exactly the behavioral detail annotations cannot express.
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, then outputs, privacy constraint, input modes, cost, and disclaimers — a sensible ordering with almost no filler. It is dense and long-ish for a single block, but each clause adds a distinct fact 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?
With no output schema, the description still enumerates the returned data categories and flags partial availability, and it documents cost and failure modes. Remaining gaps are the response shape (field names/structure) and behavior for ambiguous or incomplete location inputs (e.g., zip alone, or conflicting lat/lon plus address).
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% for 8 parameters, so the description carries the burden and does explain the three valid locating combinations. However, zip, city, and units are never mentioned or constrained (e.g., units only appears obliquely via 'loan limits (1-4 units)'), and it does not say what happens if only zip or city is supplied.
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 ('Mortgage property pre-check for one location') and then enumerates the exact outputs: county/tract, FFIEC income level and CRA flags, FHFA/HUD loan limits, USDA eligibility, FEMA flood zone and parcel facts. This is clearly distinguishable from siblings like query_parcels and site_screen 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 input modes (lat+lon, address+state, parcel_id+state) and hard exclusions ('Property data only: do NOT send borrower names, income, SSN or loan amounts'), plus a downstream-usage caveat ('verify before any Loan Estimate or credit decision'). It stops short of naming when to prefer a sibling such as query_parcels or site_screen, so the alternative routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search US property parcels. Requires 'state' (2-letter code) plus optional 'county' (exact county name, e.g. 'Harris' or 'Harris County'), 'city' (prefix) and 'address' (prefix, e.g. '123 MAIN'). Returns parcel_id, site_address, county, state, zip, year_built, lat, lon (WGS84 parcel centroid) and source attribution; never owner data. Optional 'zip' (5-digit) filters by site ZIP code; optional min_lat/max_lat/min_lon/max_lon (all four, at most 0.5 degrees each way) filter by bounding box. Costs 1 credit per record returned (minimum 1 per search; timeouts are free). If the area is not loaded yet, returns status 'fetch_queued' with a job_id: poll get_fetch_job, then search again. limit 1-100; use offset to page. Colorado (CO): a county, city or address filter is required, offset is capped at 1000 and each key gets at most 5000 CO rows per day; CO responses carry an 'attribution' field that must be kept.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| city | No | ||
| limit | No | ||
| state | Yes | ||
| county | No | ||
| detail | No | basic | |
| offset | No | ||
| address | No | ||
| max_lat | No | ||
| max_lon | No | ||
| min_lat | No | ||
| min_lon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantial non-obvious behavior: credit cost of 1 per record with a 1-credit minimum, free timeouts, the async 'fetch_queued' state, CO offset cap of 1000 and 5000-row/day quota, and the obligation to retain the CO 'attribution' field. These are exactly the operational constraints annotations cannot express.
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 required parameter, and nearly every clause carries unique operational information. It loses a point because the zip and bounding-box filters are described after the return-field list rather than grouped with the other filters, making the sentence order harder to scan than the content warrants.
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 12-parameter tool with no output schema, the description covers return fields (parcel_id, site_address, lat/lon as WGS84 centroid, attribution), cost model, pagination, async recovery, and per-state quotas. An agent could call this correctly and handle the queued case without consulting anything else; only 'detail' is unaccounted for.
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?
With 0% schema description coverage, the description carries the full burden and mostly succeeds: it defines state as a 2-letter code, county as an exact name with sample values, city and address as prefixes with an example format, zip as 5-digit, the bbox as all-four-or-nothing with a 0.5-degree cap, and limit 1-100 with offset paging. The clear gap is the 'detail' parameter, which is never mentioned anywhere and defaults to 'basic'.
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 ("Search US property parcels") and immediately narrows scope with the required 'state' parameter and the explicit exclusion "never owner data." An agent knows exactly what domain this touches; the only missing piece is an explicit contrast with near-neighbors like query_permits or site_screen, so it stops short of a 5.
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 concrete when-to-use routing: "If the area is not loaded yet, returns status 'fetch_queued' with a job_id: poll get_fetch_job, then search again" — a full recoverable-workflow instruction naming the sibling to call. It also states the Colorado-specific prerequisite (county/city/address filter required) and how to page with offset, so nothing about invocation order 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.
Search building permits from cleared open-data sources. Requires 'state'; optional 'city', 'county', 'address' (prefix), 'permit_type', 'issued_after' / 'issued_before' (YYYY-MM-DD). Applicant and contractor personal data are stripped. Results include license and attribution per source. 1 credit per record (minimum 1 per search).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| state | Yes | ||
| county | No | ||
| offset | No | ||
| address | No | ||
| permit_type | No | ||
| issued_after | No | ||
| issued_before | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds materially: PII stripping, per-source attribution requirements, and cost of 1 credit per record with a 1-credit minimum per search. Pagination behavior via limit/offset is not described.
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?
Four compact sentences, all front-loaded with the search semantics first, then filters, then privacy, then cost. 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?
With no output schema, the description tells the agent what comes back (license and attribution per source). The only meaningful gap is pagination guidance for limit/offset, which the schema lists but the description never explains.
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 carries the burden and largely does: it names the required 'state', the optional filters, that 'address' is prefix-matched, and the YYYY-MM-DD date format. Only 'limit' and 'offset' are left undocumented.
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 building permits') plus the source constraint ('cleared open-data sources'), which is enough to distinguish it from sibling query_parcels.
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 states the required and optional filters and the credit cost, implying usage, but never says when to prefer it over query_parcels or when a search is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Site screen for one location: parcel facts (parcel id, address, acres, land use, year built, appraised value and last sale where available; never owner data) plus FEMA flood zone, EPA-regulated sites nearby (Superfund, TRI, NPDES, air, RCRA hazardous waste, brownfields; epa_radius_mi default 1, max 3), USFWS wetlands at/near the point and the Census tract. Locate by lat+lon, address+state, or parcel_id+state. Federal layers are returned even where no parcel is available. Costs 5 credits when every section succeeds, 3 if some federal source fails, 0 if the point cannot be resolved or all sources fail. Screening information only: not a Phase I ESA, not an official flood determination, not a wetland delineation. Colorado parcels carry an 'attribution' field that must be kept.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| zip | No | ||
| city | No | ||
| state | No | ||
| address | No | ||
| parcel_id | No | ||
| epa_radius_mi | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent profile, and the description adds materially new behavior: a tiered cost model (5 credits full success, 3 on partial federal failure, 0 on unresolvable point), failure semantics, an explicit exclusion ('never owner data'), a Colorado attribution obligation, and three scope disclaimers. These are exactly the operational facts an agent cannot infer from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded block that leads with what the screen returns before costs and disclaimers. Dense but nearly every clause carries operational value; only the parcel-field enumeration is slightly over-detailed relative to the rest.
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 and no required parameters, the description does the work of describing return sections, cost outcomes, and legal caveats. The remaining gap is the unaddressed zip/city parameters and the absence of any hint about response shape beyond the section list.
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% across 8 parameters, so the description must carry the load. It explains epa_radius_mi (default 1, max 3) and three valid location combinations, but leaves zip and city entirely undocumented and gives no format hints for lat/lon or state codes.
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 ('Site screen for one location') and then enumerates exactly what the screen returns: parcel facts, FEMA flood zone, EPA-regulated sites, USFWS wetlands, and Census tract. The enumeration of parcel fields versus federal layers makes it clearly distinct from a parcel-only sibling like query_parcels.
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 concrete locating modes ('lat+lon, address+state, or parcel_id+state') and a fallback rule ('Federal layers are returned even where no parcel is available'), which tells the agent when the tool still succeeds. It does not explicitly route against siblings such as query_parcels or mortgage_precheck, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Stripe Checkout link to start a monthly plan (see list_subscription_plans). A human must open the link and pay; this tool charges nothing. With an API key, the plan attaches to that key. Without a key, a new key is created after payment: call claim_api_key with the returned session_id to receive it (once).
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: the tool itself charges nothing, a human must open the link and pay, and a new key is created after payment when no key is supplied. It also warns that claim_api_key should be called once, which is important workflow 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 description is three dense sentences, front-loads the core action, and then covers payment behavior and the post-payment key workflow. Every sentence contributes operational 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 one-parameter tool with no output schema, the description supplies the essential context an agent needs: the human payment step, key attachment behavior, and the claim_api_key follow-up using the returned session_id.
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 carry the burden for the single plan parameter. Pointing the agent to list_subscription_plans is useful, but it does not explain the expected plan value format or valid identifiers.
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: create a Stripe Checkout link to start a monthly plan. It also names list_subscription_plans, making the tool distinguishable from related subscription and credit 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?
It clearly explains when to use the tool, that a human must complete payment, how the plan attaches to an existing API key, and what to do without a key by calling claim_api_key with the returned session_id. This gives both prerequisites and the follow-up path.
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.
mortgage_precheckquery_parcels6 fields changedInput schema / properties / detailAdded value: +{
+ "default": "basic",
+ "title": "Detail",
+ "type": "string"
+}Input schema / properties / max_latAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Lat"
+}Input schema / properties / max_lonAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Lon"
+}Input schema / properties / min_latAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Min Lat"
+}Input schema / properties / min_lonAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Min Lon"
+}Input schema / properties / zipAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Zip"
+}site_screencancel_subscriptionget_subscription_statuslist_subscription_planssubscribebuy_creditsclaim_api_keyget_credit_balanceget_fetch_joblist_credit_packsquery_parcelsquery_permitsUS parcels, owners, sales, zoning rules, building permits and zoning cases.
US parcel records plus utilities, power, grid, environmental and logistics data by address or point.
Real estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
US property register: 92M parcels, deeds, violations, CMBS filings, county sales, market series.
Add one secure layer between your agents and this server.
