submit_delegated_job_from_file

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: file content is read server-side and sent P2P so it never appears in model output, text files go to stdin, binary files via ELISYM_INPUT_FILE, the prompt rides inline encrypted, and metered cards only charge what the job consumed. It also discloses the non-publishing confirmation path when max_price_lamports is omitted. There is no contradiction with annotations because no annotations exist.

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 long but information-dense, and every sentence contributes a distinct fact: the differentiator, the preferred alternative, prerequisites, file transport mechanics, prompt transport, and price-confirmation behavior. It is front-loaded with the core purpose and the main sibling comparison. It could be broken into clearer sections, but there is no filler.

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 complex tool with no output schema and no annotations, the description is quite complete: it covers the payment model, prerequisites, file delivery, and the quote-only path. It does not explain what happens after a job is actually submitted or how to retrieve results, and provider_npub is left as a bare string, but these may be inherited from submit_delegated_job. An agent can safely select and invoke it for the described use case.

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 only 50%, so the description needed to compensate. It adds useful semantics for prompt (inline encrypted, keep short), input_path (text vs binary handling), and max_price_lamports (omitting it produces a quote without publishing). However, provider_npub, capability, kind_offset, and timeout_secs are not explained in the description, leaving half the parameters underspecified. This is partial compensation rather than complete coverage.

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 'Same as submit_delegated_job, but' and immediately names the differentiator: the job input is read from a file by the MCP server and sent peer-to-peer via iroh, with the file content never entering the model's output tokens. It also distinguishes the tool from submit_and_pay_job_from_file by payment model, so an agent can tell the closest siblings apart. The verb is specific and the resource is clear.

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?

Explicitly says 'Prefer this over submit_and_pay_job_from_file whenever the capability advertises delegation' and explains why: this tool pulls from your delegation after delivery, while the alternative pays the full listed price up front. It also lists prerequisites (active delegation, persistent agent, iroh addon) and points to get_delegation for verification. The no-max-price behavior as a quote-only confirmation is also clearly stated.

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