WOZ values (official Dutch property valuations) for Dutch addresses, one lookup or a whole list.
Scored across 9 tools
Most tools have clearly distinct purposes: trial start, trial email, single lookup, list start, list status, prices, balance, and two distinct payment link types. However, create_list_payment_link and start_address_list overlap—both can yield a list payment page—which could cause misselection in some contexts.
All tool names use consistent snake_case with predictable verb_noun patterns (create_*, get_*, start_*, lookup_*, add_*). The single 'lookup_woz_value' deviates slightly in verb but remains clear and follows the same structural convention.
Nine tools is well-scoped for a WOZ lookup API with trials, credits, address lists, and payments. Each tool earns its place without obvious redundancy or missing core operations.
The surface covers the full trial-to-payment lifecycle for single lookups and address lists, including pricing, balance, and payment links. Minor gaps exist, such as no way to list past or cancel address lists, but core workflows are complete.
Adds the user's own e-mail address to a trial. The trial grows to 10 addresses in total and the user gets a WozApi account without a password (they log in with a code sent by e-mail). Only use an address the user typed.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Optional. The user's own e-mail address, only if the user typed it. Never invent one. | ||
| trial_code | Yes | The trial_code from start_trial. Leave empty when the user is signed in to WozApi or the connection has a WozApi API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower, yet the description still contributes real behavioral context: the trial grows to 10 addresses and the user receives a passwordless WozApi account with e-mail-code login. It does not mention idempotency or the 10-address cap being a hard limit.
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 core action, followed by consequences and the key guardrail. No filler or repetition; every sentence carries 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?
With no output schema, the description usefully explains the outcome of the call (account creation, login mechanism, address count). It is sufficient for correct invocation, though it omits what happens when the address is already present or the trial is full.
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 100%, so both parameters are already fully documented. The description only restates the email constraint ('only an address the user typed'), adding no syntax or format detail beyond the schema baseline.
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 precise verb+resource: adds an e-mail address to an existing trial. It does not, however, explicitly distinguish itself from the sibling start_trial or explain the relationship between starting a trial and adding addresses to it, so an agent must infer the boundary.
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 one clear constraint ('Only use an address the user typed'), which is genuine usage guidance, but says nothing about when to call this versus start_trial or other sibling tools, nor any prerequisites beyond what the schema already states for trial_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a page where the user buys WozApi credits for single lookups and pays with iDEAL. This tool moves no money. Works when the user is signed in to WozApi, with the connected API key, or with a trial_code that has the user's e-mail address.
| Name | Required | Description | Default |
|---|---|---|---|
| credits | No | Optional. Number of credits; leave empty for the suggested amount. | |
| trial_code | No | The trial_code from start_trial. Leave empty when the user is signed in to WozApi or the connection has a WozApi API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=true, and the description reinforces idempotency implicitly while adding genuinely valuable context beyond the annotations: 'This tool moves no money' disambiguates a payment-named tool, and the stated auth paths clarify prerequisites. It does not cover failure modes or what happens on retry, keeping it 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?
Three tight sentences with the core purpose front-loaded, followed by the money clarification and the auth conditions. Every sentence carries information and nothing is 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?
For a 2-parameter, no-output-schema tool with supporting annotations, the description covers purpose, the no-money behavior, and the three valid auth states. It lacks only a clear sibling distinction against create_list_payment_link, which is the one meaningful gap.
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 both parameters are fully documented in the schema itself, establishing the baseline of 3. The description's mention of the trial_code auth path adds a little framing but no syntax or format detail beyond 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 (returns a page) and resource (buying WozApi credits for single lookups) paid via iDEAL. It is clearly distinguishable from lookup_woz_value and get_account_balance, though it never explicitly contrasts itself with the sibling create_list_payment_link, which is the closest ambiguity.
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 describes the auth conditions under which the tool works (signed in, API key, or trial_code), which is useful context. But it gives no explicit guidance on when to choose this versus create_list_payment_link (a credits purchase vs a list purchase), leaving the key 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.
Returns the page where the user reviews the trial and the price of the list and pays with iDEAL. This tool moves no money: payment only happens when the user pays on that page. Optionally stores the user's own e-mail address for delivery of the file and the invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional. The user's own e-mail address for delivery of the file and the invoice, only if the user typed it. | ||
| list_token | Yes | The list_token from start_address_list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, and the description meaningfully builds on them: 'This tool moves no money: payment only happens when the user pays on that page.' That is exactly the kind of behavioral caveat an agent needs before calling a payment-link creator, and it is not derivable from the annotations alone.
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 primary outcome and followed by the critical 'no money moves' caveat. No filler, though the e-mail sentence largely duplicates the schema and could be trimmed.
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, and the description says only that it 'returns the page' without making clear it is a URL/link the caller must hand to the user. Combined with no stated auth or expiry considerations, the definition is adequate but leaves the return-shape and delivery expectations slightly ambiguous.
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 100%, so both parameters (email, list_token) are already fully documented, including the 'only if the user typed it' constraint. The description's mention of the optional e-mail address for file/invoice delivery restates the schema rather than adding format or syntax detail, 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 states a specific outcome: it returns the page where the user reviews trial/price and pays with iDEAL, which is more than a restatement of the name. It distinguishes itself from the credit-payment sibling only implicitly via 'the list' versus 'credit', so an agent must infer the split from the tool names rather than the text.
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 (create a payment page for a list, with the list_token coming from start_address_list), but there is no explicit when-to-use, when-not-to-use, or named alternative such as create_credit_payment_link. The agent can infer the context but is not steered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the remaining credits of the user's own WozApi account. Needs the user to be signed in to WozApi, or a WozApi API key on the connection; when neither is there, the client asks the user to sign in first. Read-only and free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the authentication requirement, the sign-in prompt fallback behavior, and that the call is free (no credit consumed).
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 what is returned, followed by the auth condition and the cost/read-only note. Every clause earns its place with no repetition of annotation content.
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-parameter read tool with no output schema, the description covers everything an agent needs: the returned value (remaining credits), the auth precondition with fallback, and the cost/safety profile. No meaningful gap remains.
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 per the baseline there is no parameter semantics for the description to supply and no schema gap to compensate for. Nothing is misstated or omitted.
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 (Returns) and resource (remaining credits of the user's own WozApi account), scoping it to the caller's own account. No sibling tool returns balance, so the purpose is unambiguous 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 a clear precondition for use: the user must be signed in or an API key must be on the connection, and explains the fallback (client prompts sign-in). It does not name alternatives or exclusions, but no sibling tool competes for this capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the status of an address list: trial rows, number of addresses found, price, payment link, progress, and after payment the result rows (at most 50 per call; use offset for more) and a download link for the Excel file. Can wait up to 20 seconds for the trial or the processing to finish.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Optional. First result row to return after delivery, starting at 0. | |
| list_token | Yes | The list_token from start_address_list. | |
| wait_seconds | No | Optional. Seconds to wait for a change while the trial or the processing runs, 0 to 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral facts beyond the annotations: a hard cap of 50 result rows per call with offset-based paging, and a bounded 20-second blocking wait during trial/processing.
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 dense sentences with the return payload front-loaded and the operational constraints (row cap, offset, wait) appended. Every clause carries information, though the enumeration of return fields makes the first sentence long.
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 carry the return-value burden, and it does: it lists the returned fields, the pagination cap, the download link, and the blocking-wait semantics. Nothing an agent needs to call and interpret this read-only tool 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?
Schema coverage is 100%, so all three parameters are documented in the schema, giving a baseline of 3. The description adds meaning beyond the schema by disclosing the 50-row-per-call cap that motivates offset, and by tying wait_seconds to the trial/processing lifecycle.
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 a specific verb (returns the status of) and resource (an address list), then enumerates exactly what status fields come back: trial rows, address count, price, payment link, progress, result rows, and Excel download link. The reference to 'list_token from start_address_list' implicitly distinguishes it from the sibling that creates lists.
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 note that it 'can wait up to 20 seconds for the trial or the processing to finish' implies a polling pattern after start_address_list, but the description never states when to call this versus the sibling tools or what to do if the list is still not ready. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns WozApi prices: credits for single lookups by quantity, the price of an address list by size, and the trial terms. Read-only and free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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's 'Read-only and free' largely restates that, though 'free' adds a small piece of cost information not present in structured fields; it adds no detail on caching, freshness, or response shape.
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 sentence, front-loaded with the resource and immediately followed by the enumerated return categories, then closed with the safety/cost note. No filler or redundancy.
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 input parameters, no output schema, and annotations covering the safety profile, the description carries the full burden of explaining returns - which it does by naming the three price categories. It stops short of format/currency or unit details, but is adequate for a parameterless read of a small price table.
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 of 4 applies. Describing the returned price categories is a bonus but not parameter 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 (Returns) plus the exact resource (WozApi prices) and enumerates the three price categories returned: credit cost per single lookup quantity, address-list price by size, and trial terms. This is far more specific than siblings like get_account_balance or get_address_list, so an agent can distinguish it without opening a 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?
Usage is only implied by the content: an agent can infer this is the tool to consult before buying credits or starting a trial. However, no sibling is named as an alternative and there is no explicit when-to-use/when-not-to-use guidance (e.g., use get_account_balance for current credits instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the WOZ values of one Dutch address for all available years, with the address as matched. Costs one trial address or one credit per unique address; the same address again within 7 days, an answer without WOZ values and an error cost nothing. For questions about properties, not to assess or profile people. Needs a trial_code unless the user is signed in to WozApi or the connection has a WozApi API key.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A full Dutch address with house number and postcode or city, for example 'Spuistraat 36C, 1012 TT Amsterdam'. | |
| trial_code | No | The trial_code from start_trial. Leave empty when the user is signed in to WozApi or the connection has a WozApi API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the billing model (one trial address or credit per unique address), the free cases (same address within 7 days, answer without WOZ values, errors), and the auth requirement (trial_code unless signed in or an API key is configured). These are exactly the side-effect and prerequisite details an agent needs before calling a billed lookup.
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-loads the purpose, then packs cost model, usage restriction, and auth into three tight sentences with no filler. It is dense and slightly crammed, but every clause carries operational information an agent would otherwise have to guess at.
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 two-parameter lookup with no output schema, it covers purpose, return scope ('all available years, with the address as matched'), billing, caching, and authentication. Nothing an agent needs in order to invoke it correctly appears to be 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?
Schema description coverage is 100%, so both parameters are already documented, and the description's statement that a trial_code is needed adds auth context but largely echoes the schema's own note about trial_code and signed-in state. Per the baseline rule, 3 is appropriate when the schema carries the parameter detail.
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 ('Returns the WOZ values of one Dutch address for all available years') and immediately scopes it to a single address with the address as matched. This clearly separates it from sibling tools like get_address_list or start_trial, which are about lists, trials, and payments rather than a single property valuation.
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?
Explicit when-to-use and when-not-to-use: 'For questions about properties, not to assess or profile people', plus the cost/eligibility condition that one trial address or one credit is consumed. It does not name a sibling as an alternative for cases where the address is unknown (e.g. get_address_list), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts WOZ lookups for a whole list of Dutch addresses, for example from a spreadsheet the user shared. Runs a free trial on 5 addresses, then gives the price of the full list and a payment page for the user. Returns a list_token for get_address_list. Sending the same list again within an hour returns the same list.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional. The user's own e-mail address for delivery of the file and the invoice, only if the user typed it. | ||
| place | No | Optional. The city for all addresses that have no postcode or city. | |
| addresses | Yes | The addresses, one string per row in the original order, each with house number and postcode or city. | |
| trial_code | No | The trial_code from start_trial. Leave empty when the user is signed in to WozApi or the connection has a WozApi API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, and the description sharpens the idempotency with a concrete 1-hour window rather than just restating the hint. It also discloses side effects the annotations don't: a free 5-address trial, a generated price, and a payment page, which tells the agent this is not a pure read despite being non-destructive.
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 tight sentences, front-loaded with the core action, then the trial pricing flow, then the return value, then the dedupe rule. No filler or repetition of 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?
With no output schema, the description correctly names the key return value (list_token for get_address_list) and the billing flow, which is the essential information for this multi-step tool. It leaves some minor gaps, e.g. what happens on invalid addresses or how the token is used downstream, but covers what an agent needs to invoke 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 description coverage is 100%, so all four parameters (addresses, email, place, trial_code) are already documented in the schema. The description adds no parameter-level detail such as address formatting rules or how the trial_code interacts with the trial flow, so it merely meets the baseline.
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 (starts WOZ lookups for a whole list of Dutch addresses) and scopes it against the single-address sibling by emphasizing the batch nature. It also names the follow-up tool get_address_list, so an agent can place it in the workflow without opening a 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?
Clear usage context is given – whole address lists, e.g. from a spreadsheet the user shared – and it explains the trial-then-pricing flow the caller should expect. It never explicitly states when NOT to use it (e.g. single lookups go to lookup_woz_value), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a free WozApi trial without an account and returns a trial_code. The trial covers WOZ value lookups for 5 unique Dutch addresses, or 10 when the user's own e-mail address is given. Pass the trial_code to lookup_woz_value and start_address_list. Call it once per conversation, and not when the user is signed in to WozApi or the connection already has a WozApi API key.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional. The user's own e-mail address, only if the user typed it. Never invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the quota (5 unique Dutch addresses, 10 with the user's own e-mail), the returned credential, and the once-per-conversation constraint, which is consistent with the declared non-idempotent, non-read-only profile. The 'without an account' framing clarifies that no auth is required.
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 sentences, zero filler, and the sequence is well front-loaded: what it does, what it produces, how to use the result, then when to avoid it. Every clause carries information an agent must act on.
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 single-optional-param setup tool with no output schema, the description covers the return value, its downstream consumers, the limits, and the invocation constraints. Nothing needed to call it 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?
Schema coverage is 100% and the schema already warns 'only if the user typed it. Never invent one.' The description still adds value by explaining the consequence of supplying the e-mail (quota doubles to 10), which the schema does not state.
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 ('Starts a free WozApi trial without an account') plus the return artifact ('returns a trial_code'), which is exactly what an agent needs to identify a setup/onboarding action. It is clearly distinct from payment-link and lookup siblings.
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 names the conditions for use ('Call it once per conversation') and the exclusions ('not when the user is signed in to WozApi or the connection already has a WozApi API key'). It also routes the agent forward by naming which tools consume the trial_code.
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.
add_trial_emailcreate_credit_payment_linkcreate_list_payment_linkget_account_balanceget_address_listget_priceslookup_woz_valuestart_address_liststart_trialDutch address dossier, vehicle, building, elevation, holidays, demographics. Free samples first.
Danish address & property lookup: BBR, Matriklen, DAR, CVR. A DAWA/Datafordeler-compatible source.
German land values (Bodenrichtwerte) by address + land-use type. Coverage varies; not in SH/SN/BY.
Dutch property report by address: build year, energy label, neighbourhood, monument, schools.
Add one secure layer between your agents and this server.
