record_stream_tick

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

Without any annotations, the description carries the burden of explaining the tool's behavior. It discloses the key nuance that this only applies to MICRO_TRANSFER streams and that Superfluid is handled automatically, which adds important context. However, it does not mention any side effects, error conditions, or what happens after submission, leaving gaps for a write operation.

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 two sentences long, front-loaded with the main verb and resource, and contains no fluff. Every clause serves a purpose: the first sentence states the action, the second provides crucial scope limitations. It is ideal for an AI agent to quickly grasp the tool's purpose.

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?

Given the tool's simplicity (3 required parameters, no output schema), the description is reasonably complete. It explains the specific scenario (micro-transfer tick payment), the input required (transaction hash), and the distinction from Superfluid streams. It could mention the outcome or potential failure modes, but the core context is sufficient 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?

The schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds extra meaning to the tx_hash parameter by specifying it is for the 'current pending tick', which clarifies how to use it. The other parameters (job_id, agent_key) gain no additional context from the description, but overall the description enriches the parameter semantics slightly.

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's function: 'Record a micro-transfer stream payment' with a specific verb and resource. It distinguishes itself from siblings by specifying that it is 'Only for MICRO_TRANSFER streams' and clarifying that 'Superfluid streams are verified automatically', which sets it apart from other stream-related tools like start_stream or stop_stream.

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 explicitly says when to use this tool ('Only for MICRO_TRANSFER streams') and when not ('Superfluid streams are verified automatically'). It provides a clear exclusion but does not name an alternative tool for Superfluid streams, so it falls slightly short of a 5 that would require explicit alternatives.

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