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

With no annotations, the description carries the full burden, and it does disclose a few real traits: only the recorded author is paid, only public works are eligible, two caps apply, and a requestId is required (suggesting idempotent submission). However, 'Both caps apply' is never defined, and for a spend operation it omits the currency/source of funds, irreversibility, whether self-tipping is allowed, and what happens when a cap is hit.

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 tight clauses, front-loaded with the action and target, with the amount and requestId constraints in the second clause. Only 'Both caps apply' is under-specified filler that costs clarity without paying it back.

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?

This is an unannotated monetary mutation with no output schema, so the description should explain effects and results. It never states what is deducted, what is returned on success, or what happens on a repeated requestId, leaving the agent to guess at the consequences of an irreversible spend.

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 0%, so the description must compensate — and it does name all three parameters, adding that amount must be a positive whole number and requestId is a UUID. It still doesn't explain what requestId is for (idempotency/deduplication key) or what constraints the 'caps' place on amount, so the compensation is only partial.

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?

Specific verb + resource + domain: 'Tip the recorded author of a public Code Lab work by workId.' The 'Code Lab' qualifier implicitly disambiguates it from siblings like library_tip, workshop_tip, muse_tip, muse_tip and generic tip, though no sibling is named. An agent can tell what it does, but must infer which tip variant to pick from the domain wording alone.

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 phrase 'public Code Lab work' implies a prerequisite (the work must exist and be public, so workId likely comes from codelab_list/codelab_read) but never states it. There is no explicit when-to-use-versus-alternative routing among the many *_tip siblings, only an implied domain split.

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