Three tools with basic schemas and minimal descriptions. All tools have input schemas with type constraints (Zod validation), but descriptions are generic and lack context for LLM selection. No output schemas documented. Parameters lack detailed descriptions explaining format, constraints, or when to use each tool. Error handling returns plain text without recovery guidance. No tool annotations (readOnlyHint, etc.). Naming is reasonable (verb_noun pattern) but descriptions do not explain WHEN to use each tool vs. alternatives.
Use the abn number provided to search for business information
Use the acn number provided to search for business information
Search for ABN by entity name, returns up to 10 results
Tool descriptions lack context for LLM selection. 'Use the abn number provided to search for business information' does not explain WHEN to use abn-search vs. acn-search vs. name-search, or what data each returns. LLMs cannot distinguish between tools without comparative guidance.
No output schemas documented. Callers cannot know what fields the API returns, what structure to expect, or what IDs/references are available for chaining. The code returns raw API response as plain text, not structured JSON.
Parameter descriptions are minimal. 'ABN number (11 digits)' and 'ACN number (9 digits)' state the format but not the purpose, when to use, or what happens if invalid. 'name to search' lacks guidance on partial matches, case sensitivity, or result limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error messages are generic and non-actionable. 'failed to retrieve data from abn server' and 'abn number is not valid' do not guide the LLM on recovery steps. No error classification (retryable vs. user-fixable vs. fatal).
No tool annotations. Tools are read-only but lack readOnlyHint in schema. This prevents clients from optimizing caching, retry logic, or user confirmation flows.