Free demo of the audit (fixed sample, no payment)
demo_auditRuns the scanner on a small built-in bad-bot sample and returns the findings. Free; no x402 payment.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
demo_auditRuns the scanner on a small built-in bad-bot sample and returns the findings. Free; no x402 payment.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It usefully discloses that no payment is required and that the run uses a fixed built-in sample, which reduces risk of expecting a paid or user-supplied audit. However, it does not state limitations beyond the fixed sample, such as whether this is read-only, time-limited, or what exactly 'findings' covers.
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 state the action, resource, outcome, and cost behavior. No filler, and the most important qualifiers ('Free', 'no x402 payment') are prominent.
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 no-argument demo tool, this is nearly complete: it identifies what runs, what input is used, and that findings are returned. The lack of an output schema is mitigated by 'returns the findings' and the demo's low stakes, though a bit more detail on the findings format would make it fully self-contained.
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 has zero parameters and 100% coverage, so the description has no parameter burden. The 'built-in sample' phrase reinforces that no user input is needed, which is useful context.
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?
Description states a specific verb ('Runs the scanner'), a concrete resource ('a small built-in bad-bot sample'), and an outcome ('returns the findings'). The title emphasizes 'Free demo ... fixed sample, no payment', which clearly distinguishes this from the sibling audit_bot_code.
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 and title give clear context for when to use it: it is a free no-payment demo on a fixed sample. It does not explicitly name the alternative audit_bot_code or state when not to use it, but the 'no x402 payment' and 'built-in sample' cues strongly imply trial-before-paid 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.