what_can_dfx_answerDescribe an objective in natural language and get back whether DFX can help, which tool to call, the arguments to call it with, and a free sample of the result. Says no clearly when the answer is no, and records what was asked so unmet demand shapes what DFX builds next. Call this first if you do not know what to ask for.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | ||
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool 'records what was asked so unmet demand shapes what DFX builds next,' implying a write/logging side effect, while annotations declare readOnlyHint=true and idempotentHint=true. Recording on each call would not be idempotent either. This is an annotation contradiction, capping the score at 1.
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, all informative: core capability, no-answer/recording behavior, and usage trigger. Front-loaded with what the tool returns, with no filler or repetition.
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?
The description covers the return contract (yes/no, tool, arguments, sample) and the no-case, which matters because there is no output schema. However, the `constraints` parameter is completely undocumented, and the description does not explain how constraints influence routing or sampling. It is a usable minimal definition, but not fully complete for safe invocation.
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 define parameters. It gives meaning to `objective` via 'Describe an objective in natural language,' but never mentions `constraints`, an optional object with no property schema, leaving agents to guess what constraints can contain.
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 concrete verb ('Describe an objective... and get back whether DFX can help'), names the resource (DFX's capabilities), and describes the output (which tool to call, arguments, sample result). The closing 'Call this first if you do not know what to ask for' clearly distinguishes it from the domain-specific sibling tools as the meta-routing entry point.
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 says 'Call this first if you do not know what to ask for,' giving a clear trigger condition. It does not, however, name sibling tools or state explicit exclusions for when a known domain tool should be used directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct task: exact address resolution versus filter-based parcel search, subscription delta versus event search, coverage status versus natural-language routing, and the account lifecycle is split into open/fund/status. Even the closest pairs, changes_since and search_property_events, are explicitly disambiguated in their descriptions.
The dominant pattern is verb_noun, e.g. resolve_address, search_parcels, get_property_record, but several tools break it: dfx_coverage, dfx_payment_status, debt_maturity_schedule, changes_since, and what_can_dfx_answer. These names are still readable and semantically clear, so the naming is mixed rather than chaotic.
Twelve tools is well within the ideal range and each tool earns its place: discovery, coverage, resolution, search, records, event subscription, paid maturity schedules, and the account/payment lifecycle all have a distinct role. No tool feels redundant or ornamental.
The read-only real estate intelligence surface is well covered: coverage checks, address and organization resolution, property records, parcel search, event search, delta subscription, paid loan schedules, and account funding. The main gap is that resolve_organization returns entity IDs without an obvious downstream tool for organization detail, and there is no separate event detail endpoint, but agents can work around these.