australian-ai-governance-framework

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the transparency burden. It discloses the free vs paid content, instructs to present the document verbatim and never summarise, mentions both view_url and purchase_url, their two-hour expiry, and explicitly states 'There is no payment through this endpoint' and 'Informational only'. This is exceptional behavioral disclosure.

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 long but every sentence earns its place. It front-loads the core purpose, then provides essential user-interaction instructions (present verbatim, provide links, expiry). There is no fluff or repetition; the length is proportional to the tool's complexity.

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?

Without an output schema, the description fully explains all return elements: the structuredContent field 'framework_markdown', the view_url, the purchase_url, and their intended use. It also covers timing, pricing, and the tool's informational nature—everything an agent needs to invoke and handle the result 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?

The schema already covers session_id with a clear description. The tool description adds value by explaining the session's lifecycle ('Both links expire two hours after the profile was created') and its linkage to the start tool, giving the agent useful context beyond the schema itself.

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 'Returns the framework' — a specific verb and resource — and goes on to detail exactly what the framework contains (preview vs complete, practices, legislative mapping). It distinguishes from sibling tools by referencing 'Session ID returned by start_australian_ai_governance_framework', making it clear this is the retrieval step.

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 context is provided: the user must supply a session_id from the start tool, and the description explains when to provide the purchase_url ('when they ask about the full framework'). However, it doesn't explicitly state alternatives or exclusions (e.g., 'do not use this if...'), so it falls short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses that the tool is 'Informational only' and 'presents a framework, not advice', and explains the return value (session ID and profiling questionnaire). It does not mention any side effects or data retention, but the zero-parameter, session-start nature is reasonably transparent.

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 longer than minimal but every sentence earns its place: scope, legislative coverage, use cases, caveat, output, and disclaimer. It is well-structured and not verbose, though slightly dense.

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 complex domain with no output schema, the description is remarkably complete. It names specific legislation and dates, describes triggering factors (industry, size, turnover, data types), states return values, and includes a limitation disclaimer. This is sufficient for an agent to select and invoke the tool 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?

Input schema has zero parameters, so the baseline is 4. The description goes further by explaining that the tool returns a profiling questionnaire and session ID, implying the profile is provided later, which adds meaningful context about the tool's stateless initiation.

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 uses specific verbs ('Identifies', 'builds') and clearly defines the resource (Australian AI governance framework). It distinguishes from sibling tools by framing 'start' as the initiation step that returns a session ID and questionnaire, versus 'get' or 'submit'.

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 states 'Use this when an Australian business asks what AI governance it needs...' and lists four concrete trigger scenarios. It also warns that the legislative mapping is specific to the supplied profile and not reliably produced by a general answer, providing clear guidance on when to prefer this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and does so thoroughly: it discloses that it writes to the session, stores a contact record, overwrites rather than duplicates on re-submission, discards any previously generated framework, returns only session ID and status, and notes no authentication or charge. These are important side effects and limitations beyond the basic operation.

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 detailed but every sentence serves a purpose: core action, data flow, return behavior, idempotency, side effects, and next step. It is well-structured with clear reasoning for re-submission, and no redundant or filler 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?

Given the tool's complexity (nested objects, enums, no output schema) and lack of annotations, the description is exceptionally complete. It covers the full workflow, return format, side effects, and provides guidance on correct usage and when to call the sibling tool.

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 67%, and the description adds meaning for key parameters. It explains that answers are question IDs from the start tool and emphasizes the importance of turnover relative to the Privacy Act threshold, and that contact details are stored. It does not detail every nested field, but the schema already provides enums and descriptions.

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 the verb 'Submits' and the resource 'organisation profile and contact details' for an Australian AI governance framework. It clearly distinguishes from siblings by referencing start_australian_ai_governance_framework for the session ID and get_ai_governance_framework as the retrieval step.

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 explains when to use: after starting the framework with the session ID and questionnaire answers. It also provides exclusions and caveats, such as re-submitting discards any existing framework and should only be done to correct an answer, and directs that the framework is retrieved with get_ai_governance_framework.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.