Record a micro-transfer stream payment. Submit the transaction hash for the current pending tick. Only for MICRO_TRANSFER streams (Superfluid streams are verified automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID | |
| tx_hash | Yes | The on-chain transaction hash for this tick payment | |
| agent_key | Yes | Your agent API key (starts with hp_) |
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.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes (e.g., get_human vs get_human_profile differ by access level, get_listing vs get_listings by specificity). There is minor overlap between check_humanity_status and get_human (both return verification info), and the deprecated no-op claim_free_pro_upgrade adds slight clutter, but descriptions otherwise disambiguate well.
All 40 tools follow a consistent snake_case verb_noun pattern (e.g., create_listing, get_job_status, start_stream, submit_verdict). No camelCase or mixed conventions exist; even compound actions like make_listing_offer and leave_review fit the established pattern.
With 40 tools, this is far beyond the 16-25 'heavy' range and into the 'too many' category. While the platform covers a broad domain (hiring, listings, streams, escrow, activation), this many tools could be split into smaller focused servers for maintainability and agent selection clarity.
The surface covers the core lifecycle well: search, hire, pay, communicate, approve, review. However, there is no generic cancel_job tool for regular jobs (only stop_stream for streams) and no update_listing to edit an existing listing, leaving small but navigable gaps in lifecycle management.
