List Worthune's Concordance-tested financial calculation models (an independent second implementation must agree with the engine, per the published spec). Returns model names and spec versions. Call get_model_contract before running a model.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds that it 'Returns model names and spec versions' and explains the Concordance-testing requirement. This provides useful behavioral context about the listing criteria and output.
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 two sentences, front-loaded with the main purpose, and every sentence adds value: the first states what is listed, the second describes the return and next step. No wasted words.
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?
Given no output schema, the description adequately covers return values and provides a usage pointer to 'get_model_contract'. It is complete for a simple list operation, though it does not mention pagination or filtering (unlikely needed with 0 params).
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 zero parameters, the schema provides no parameter information, and the description also does not need to explain any. The baseline for 0 params is 4, and the description adds no confusing 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?
The description clearly states the tool lists 'Worthune's Concordance-tested financial calculation models', using a specific verb and resource. It distinguishes from siblings like 'get_model_contract' and 'run_model' by focusing on the enumeration of available models.
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 provides clear context for when to use the tool: before running a model, it suggests calling 'get_model_contract' first. It gives a logical sequence but does not explicitly exclude alternatives or state 'when not to use'.
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 distinct resource and action: household CRUD, bulk import/mapping, projection/decision, model contract/run/verify, and narrative generation. Even the superficially similar pairs (project_household vs decide_household; run_model vs verify_claim) are clearly separated by their descriptions.
All tool names use lowercase snake_case with imperative verb-first naming (create_, get_, patch_, replace_, run_, verify_). Pluralization follows natural semantics (list_models, import_households) without breaking the overall verb_noun pattern.
13 tools is within the ideal range for a domain server. Each tool earns its place: household lifecycle, import tooling, model contract/run/verify, projection/decision, and narration form coherent clusters without redundancy.
Core workflows are well covered: create/read/update households, project and decide, list/get/run/verify models, and narrate decisions. Minor gaps remain: there is no delete_household or list_households, and no dedicated get_decision tool for retrieving a stored decision object independently.
