resolve_organizationTurn an owner, manager, lender or servicer name into canonical DFX entity ids. A name is treated as a blocking key and never as an identity, so all candidates are returned rather than a guess. Free. Person lookup is deliberately not offered.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds valuable behavioral nuance: a name is treated as a blocking key, not an identity, and all candidates are returned rather than a single guess. It also mentions the service is free, which is beyond what annotations convey.
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 short sentences with no filler. The core action is front-loaded, followed by the key matching behavior and the important person-lookup exclusion. Every sentence adds distinct value.
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, idempotent resolver with two parameters, the description is mostly complete: it explains what inputs are expected, what the output represents, and the main exclusion. The main gap is the undocumented limit parameter and how it interacts with the 'all candidates' behavior, but overall this is sufficient for an agent to call it correctly.
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-meaning burden. It explains the semantic role of 'name' well (company or role-holder names, blocking key). However, it does not clarify the 'limit' parameter at all, and the claim about returning all candidates sits awkwardly with the default limit of 10.
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 clearly states the tool's function: it turns an owner, manager, lender, or servicer name into canonical DFX entity IDs. It also distinguishes itself from person lookup by explicitly saying that is not offered, which helps disambiguate from sibling resolvers.
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 description gives clear context for when to use the tool: resolving organization-related role names to DFX entity IDs. It also states a when-not case (person lookup is not offered), though it does not name a specific alternative tool such as resolve_address.
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.