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

With no annotations, the description carries the full burden and does so thoroughly: it discloses plain-HTTPS fetching, per-keyword match counts and snippet context, on-demand sandbox execution, no recurring scheduler yet, testnet semantics, and Ed25519-signed deliverables. This goes well beyond the bare schema.

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 front-load the core purpose and output, then add environment and limitation context without 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 no-output-schema, no-annotation tool with two actions and a nested input object, the description is missing action-specific parameter requirements: it doesn't state that register needs url/label or that check consumes tripwire_id. The output summary is covered, but the calling contract is incomplete.

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 description clarifies the meaning of action, keywords, and URL, and implies tripwire_id through the register/check workflow. However, it never explains the label parameter or which fields are required for register versus check, so the agent must infer key input semantics from the schema.

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 a concrete action and resource: 'Watch a public URL ... for keywords,' then names the register and check actions and what the check reports. This clearly distinguishes it from unrelated siblings like citation_audit or structured_extraction.

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?

It gives a clear workflow: register a tripwire first, then trigger a check, and notes checks are on-demand with no background scheduler yet. It doesn't explicitly describe alternatives or when-not-to-use, but no sibling is an obvious alternative, so the usage context is sufficient.

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