Course Drift Oracle

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

With no annotations provided, the description carries the full burden and it does well by disclosing the cost ($0.25), the granularity (every finding), the fields included, and verifiability against the free summary's hash. It does not mention output format or any rate limits, but for a parameterless report tool this is solid 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?

Two tightly packed sentences front-load the most important operational detail (paid $0.25), then list the report contents and the verification hook. Every sentence earns its place 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?

For a parameterless report tool with no output schema, the description fully explains what the agent will get (all drift findings with locations, issues, and fixes), why it is worth paying for, and how to verify it against the free summary's hash. Nothing essential is missing for an agent deciding to invoke it.

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 tool accepts zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.

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 identifies the resource as drift findings and specifies the exact contents: file path, line number, problem, and suggested fix. It distinguishes itself from the free summary by emphasizing its paid, comprehensive nature, though it lacks an explicit verb like 'returns' or 'generates' and does not differentiate from drift_report_x402.

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 'free summary's findings_hash' reference implies the workflow of using drift_summary first, then drift_report for full details, and 'enough to open a PR' signals when the detailed output is needed. However, it never explicitly states when to use this tool instead of alternatives or when not to use it.

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 the burden of behavioral disclosure. It openly states that the tool is paid ($0.25 in x402/USDC) and that it returns the same content as drift_report. It could mention what happens on payment failure, but the key side-effect and output behavior are disclosed.

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 concise and front-loaded: it opens with the payment requirement, then defines the output, then gives the sibling routing. Every sentence earns its place with no filler.

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 parameterless tool with no output schema, the description fully explains the report content, the cost, the payment rails, and the alternative tool. Nothing essential is missing for an agent to decide whether to invoke it.

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 tool has zero parameters, so there is no parameter semantics to explain. The description correctly focuses on behavior rather than inputs, which is appropriate for a parameterless tool.

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 what the tool does: it produces the same full drift report as drift_report, with every finding including file path, line number, the problem, and the suggested fix. It also distinguishes itself from the sibling drift_report by the payment method, so an agent can tell them apart without inspecting schemas.

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 explicit routing guidance: use this tool when paying with x402/USDC, and use drift_report when paying by card or other MPP methods. This directly answers when to choose this tool over its alternative.

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 the burden of behavioral disclosure. It reveals a notable return behavior ('signed receipt committing to the full findings set') and the free-cost property, but it leaves side effects, authentication, and the meaning of the signed receipt unexplained.

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 short and front-loaded with the core scope, which is good. However, 'Free.' and 'No payment required' are redundant, adding noise without new information.

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 zero-parameter tool with no output schema, the description adequately covers what is measured, how results are grouped, and the return mechanism. It could elaborate on the severity scale or signed-receipt semantics, but these are minor gaps for selecting and invoking the 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?

The tool has zero parameters and the schema property list is empty, so there is nothing for the description to add at the parameter level. The baseline 4 applies.

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 that the tool reports counts of drifting pinned models/package versions in the ai-agents-for-beginners course, broken down by lesson and severity. It lacks an imperative verb, but the query phrasing makes its purpose unambiguous.

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?

No explicit guidance is given on when to use drift_summary over its siblings such as drift_report, model_status, or site_audit. The 'Free' and 'No payment required' notes hint at a cost distinction but do not specify use cases or exclusions.

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 are provided, so the description carries the full burden. It discloses a critical behavioral guarantee: unknown IDs return a distinct 'unknown: not in catalog' rather than being conflated with 'current', and it mentions the signed receipt. It does not cover error conditions or auth, but the operation is a simple read.

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 compact and information-dense, opening with 'Look up one model id' and covering statuses, unknown handling, and signed receipt in four short sentences with no filler. Every sentence earns its place.

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 one-parameter, read-only lookup with no output schema, the description adequately covers the key behavioral case and return content. It could improve by explicitly directing multi-id use cases to model_status_batch, but that is not needed to invoke this 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?

The schema fully documents the single model_id parameter with 100% coverage, including an example ('gpt-4o'). The description adds only the context of the signed catalog and unknown handling, contributing modest value beyond the schema's existing documentation.

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 a specific verb ('look up') with a clear resource ('one model id in the signed catalog') and enumerates the returned status values (current, deprecated, retired) plus additional fields. Its single-id scope implicitly distinguishes it from sibling model_status_batch.

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 clearly scopes the tool to a single model lookup, which differentiates it from batch siblings. However, it does not explicitly name alternative tools or state when to prefer them, so guidance is clear context without explicit exclusions.

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 the full burden and handles it well: it discloses the $0.10 cost, the honest 'unknown: not in catalog' per-id behavior, and the any_action_needed aggregation rule. It does not detail exact response fields or error behavior, but the core operational traits are clear.

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 dense sentences with no filler: cost is front-loaded, behavior is specific, and the use case is provided last. Every sentence earns its place.

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 single-parameter batch status tool, the description gives enough to invoke it and interpret the result: input, per-id outcome, unknown handling, and the boolean gate. Minor gaps around exact entry shape and error conditions remain, but the tool is not complex enough to require more.

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 100%, so the parameter is already documented. The description adds context ('signed catalog', 'pinned-model set') that clarifies intent, but does not provide essential meaning beyond the schema, so the baseline 3 applies.

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 specific verb ('Look up'), a resource ('model ids in the signed catalog'), and a precise output ('one entry per id... plus any_action_needed'). It also distinguishes itself from a per-item lookup flow by emphasizing the batch, single-answer design.

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 frames the intended use case: a CI pipeline's pinned-model set, producing one signed answer and one boolean to gate a build. It contrasts with 'parsing an array of free lookups by hand', giving clear context, though it does not name a specific alternative tool or list exclusion criteria.

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?

Annotations are empty, so the description carries the full burden. It discloses the cost ($0.10), the payment currency (x402/USDC), and the exact return structure (one entry per input id plus any_action_needed). While it doesn't mention read-only status or potential side effects, for a 'lookup' tool the disclosed behaviors are sufficient for an agent to understand the call's implications.

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?

Two efficient sentences that front-load the cost and functional equivalence, then provide clear payment alternative. No wasted words; every sentence adds 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 single-parameter batch lookup without an output schema, the description fully covers the essential context: cost, payment route, output shape, and when to choose the sibling tool. Nothing an agent needs to invoke it correctly is missing.

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 describes the only parameter (model_ids) at 100% coverage. The description adds no additional semantic meaning beyond a reference to the sibling tool's behavior. Baseline of 3 is appropriate given high schema coverage; there's nothing to compensate for.

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 performs a 'batch model status lookup' and specifies the output shape ('one entry per input id plus any_action_needed'). It also distinguishes from the sibling model_status_batch by payment method, making the tool's purpose unambiguous.

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 when to use this tool ('if you hold USDC') and when to use the alternative ('use model_status_batch to pay by card or other MPP methods'). This is clear, actionable guidance with a named sibling alternative.

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 provided, the description carries the full burden and does so thoroughly. It discloses the cost, live Ed25519 signing, the unsigned-unprovisioned edge case with a guarantee of 'never a fabricated signature', and the limitation that the signature proves only what was checked and when, not that the site is good.

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?

Every sentence earns its place: cost, output contents, signature behavior, verification path, and signature limitation. The key billing fact is front-loaded, and there is no filler or redundant restating of the schema.

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 tool with one required parameter, no annotations, and no output schema, this description is remarkably complete. It covers cost, return shape (status and detail per check, dated receipt), security edge cases, and how to verify the result, leaving nothing essential for invocation unexplained.

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 only parameter, url, is already fully described in the schema with an example. Schema description coverage is 100%, so the description adds no extra parameter-level meaning beyond restating that a site URL is submitted.

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 exactly what it does: returns all 12 agent-legibility checks for a submitted site URL with status and detail as a dated receipt. It mentions verify_report for verification, but does not explicitly contrast with site_audit_x402 or site_audit_summary, so it stops short of full sibling differentiation.

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?

Implies use when a complete, signed URL audit is needed and notes the $0.25 cost, plus directs the agent to verify_report afterward. However, it gives no explicit guidance for choosing between this tool and its siblings like site_audit_x402 or site_audit_summary.

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 are present, so the description carries the full burden. It transparently covers bounded fetches, refusal of private addresses, per-target rate limiting, and the returned values (count, target, date). It doesn't explicitly mention auth or side effects, but the audit nature and constraints make it 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?

Two dense sentences with a clear structure: cost indicator ('Free'), action, constraints, and return value. No filler; every clause carries useful information, and the most important framing (free + decision use case) is front-loaded.

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?

With no output schema, the description still explains what the result contains and how to act on it. For a single-parameter tool, it covers the workflow, safety constraints, and decision context sufficiently for an agent to invoke 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 description coverage is 100% for the url parameter, so the baseline is 3. The description adds a meaningful constraint by mentioning 'private addresses refused' and 'bounded fetches,' but doesn't significantly expand on the schema's own description. Baseline is appropriate.

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 specific action ('runs 12 agent-legibility checks'), a clear resource ('site URL'), and differentiates from the paid detail tool by framing the return value as 'enough to decide whether the paid per-check detail is worth it.' This distinguishes it from sibling site_audit tools effectively.

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?

Clearly signals this is a free, quick triage tool and hints at the paid per-check alternative for deeper detail. It doesn't explicitly name the sibling or state when NOT to use it, but the cost-decision context is strong and actionable.

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 present, the description carries the full behavioral burden. It discloses the cost, the fact that payment settles before the target is checked, the output form (signed dated receipt with status and detail for all 12 checks), and a caveat about rate limiting. This is strong, though it does not cover failure modes of the payment step itself.

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 dense sentences with no wasted words. The most decision-relevant facts—cost, equivalence to site_audit, and payment method—are front-loaded, followed by the important preflight warning.

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 single-parameter paid tool with no output schema, the description covers what the tool produces, how payment works, how to avoid wasted payment, and how it relates to sibling tools. An agent has enough context to invoke it correctly and interpret the result.

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 only parameter, url, is fully described in the schema with a format example at 100% coverage. The description adds little new meaning beyond referring to the target being checked, so the baseline 3 applies.

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 identifies the tool as the paid x402 version of site_audit, performing the same 12-check audit with status and detail in a signed dated receipt. It explicitly differentiates itself from site_audit and site_audit_summary by payment method and preflight usage, so an agent can select it correctly.

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 precise routing guidance: use this tool when paying via x402/USDC, use site_audit for card or other MPP methods, and run the free site_audit_summary first to validate the URL and avoid paying for a failed check. This is explicit when-to-use and alternative selection guidance.

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 are provided, so the description carries the full behavioral burden. It discloses the cost ('Free.'), which is meaningful given the _x402 siblings, and implies a non-mutating read operation by describing verification. However, it omits auth requirements, rate limits, and failure/return behavior, leaving an agent to infer what happens on signature mismatch.

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 short sentences front-load the most decision-relevant fact (free), then the core operation, then usage timing. Every sentence earns its place with zero redundancy — model quality for a tool description of this 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?

For a two-parameter tool with nested objects and no output schema, the description covers what the tool does, when to use it, and why, and the schema fully documents both parameters. The main omission is the return/error format, which is largely inferable for a verification operation but would be more critical given the absence of annotations.

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 100%: receipt is documented as 'the receipt object from any report' and findings as 'the findings array to check against findings_hash,' so the schema already carries parameter meaning. The description adds cryptographic framing (Ed25519, 'the hash the receipt committed to') that clarifies how the two params interrelate, but the agent's invocation requirements are unchanged.

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 precise operation — verifying a report receipt's Ed25519 signature — plus an optional secondary check that the findings array matches the committed hash. The verb 'verify' plus the specific resource (report receipt) makes the purpose unambiguous and clearly distinct from the sibling tools, which are all report/model/site-audit producers rather than verifiers.

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?

Provides two explicit invocation contexts: before paying to confirm the seller is describing real work, and after paying to confirm receipt of all work. It gives clear, scenario-based usage context, though it doesn't name alternatives or state when not to use the tool — a minor gap since no sibling is a natural alternative for verification.

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