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

With no annotations, the description carries the full burden and does well: it discloses that entry 'places it and starts the clocks; nothing is held,' requires a key credential, is free, and cites sources (Mandate 2.0 B.4/B.9, PD17 §1). It omits reversibility and return behavior, but the mutation/auth/cost profile is well covered.

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 content earns its place, but the lead sentence is awkward and circular ('a service I dealt with, or a service my operator runs, did something...'), pushing the actual action into sentence two. The dense parenthetical citations also slow scanning; it is informative but not 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 or annotations, the description supplies standing rules, credential, cost, source citations, and the key behavioral fact that nothing is held. That is close to complete for a mutation tool, missing only return/confirmation behavior.

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 75%, and the description meaningfully augments it: particulars must be conduct-table codes (PD17), 'never text,' and sha256 is described as the hash of the complaint the agent holds and may lodge on its own register. These additions clarify semantics beyond the schema, though ref and against get no extra treatment.

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 a specific verb and resource: entering a complaint on a service's inbox at the Court. The opening sentence is garbled first-person framing, but the second sentence cleanly identifies the action. It implies the complaint target (a service) without explicitly contrasting with nearby siblings like lodge_claim or account_for_service_complaint.

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 concrete eligibility rules: only an agent with standing may complain — the operator via its Clerk, or an enrolled agent on a dealing naming the service (B.9), with the Court's checks under the Registrar's key. That is strong when-to-use context. It stops short of routing the agent away from alternative tools or stating when this is the wrong path.

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