Skip to main content
Glama

submit_and_pay_job_from_file

Submit a job using a file from disk as input, bypassing inline data transfer for large or binary files. The file is sent directly peer-to-peer, with optional text instructions.

Instructions

Same as submit_and_pay_job, but the job input is read from a file on disk by the MCP server instead of being passed inline by the LLM. Use this when the input is large or binary (images, logs, captured output) and the LLM only needs to forward it - the file content never enters the model's output tokens. input_path may be absolute or relative to the MCP server's working directory. The file is ALWAYS transferred peer-to-peer via iroh, so this needs: a persistent agent, a PAID provider skill (free skills reject file inputs), and the iroh addon. Text files reach the skill on stdin; binary files via ELISYM_INPUT_FILE. Pass an optional prompt to send a text instruction alongside the file (e.g. how to edit an image); it rides inline (encrypted) while the file rides P2P.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptNoOptional text instruction sent alongside the file (e.g. how to edit an image: "make it night", "add a hat"). It rides inline (NIP-44 encrypted) in the job event while the file travels peer-to-peer via iroh. The single attachment slot holds the file, so the prompt cannot spill to a second transfer - keep it short.
capabilityNogeneral
input_pathYesPath to a regular file whose contents become the job input. Absolute or relative to the MCP server's working directory.
session_idNoConversation control. Omit for automatic session management (providers advertising context support get a conversation auto-started on first contact; an ongoing conversation triggers a continue/new/one-off question before anything is published). Pass "new" to force a fresh conversation, "none" to force a stateless one-off, or a session_id from a previous result to continue that conversation. The provider answers with the conversation context of prior exchanges under the same id.
kind_offsetNo
timeout_secsNo
provider_npubYes
allow_outside_cwdNoAllow reading a file outside the MCP server working directory. Off by default - the file content is forwarded to the provider before payment and is invisible in the transcript, so reads are confined to the working dir unless this is set. Sensitive files (secret keys, .env, SSH/keypair, ~/.elisym, /proc) are always refused.
max_price_lamportsNo
Behavior5/5

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

No annotations provided, so description carries full burden. It discloses peer-to-peer transfer via iroh, how text and binary files are handled (stdin vs ELISYM_INPUT_FILE), that prompt rides inline encrypted while file rides P2P, and that sensitive files are always refused. It also explains allow_outside_cwd security behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is fairly long but well-structured, front-loading purpose and usage, then parameter details. It uses dense but clear prose, though some information could be condensed. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no output schema), the description is thorough, covering transfer mechanism, prerequisites, security constraints, and parameter semantics for key fields. It complements the schema well and differentiates from sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 44% (4 of 9 params have descriptions). The description adds significant context for input_path (absolute/relative, transferred P2P), prompt (inline encrypted, single attachment slot), and allow_outside_cwd (sensitive file refusal). However, it does not explain capability, kind_offset, timeout_secs, provider_npub, or max_price_lamports beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is the same as submit_and_pay_job but reads input from a file, specifying use cases (large or binary input) and why (file content never enters LLM output tokens). It distinguishes itself from the sibling submit_and_pay_job by the file-based input mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: when input is large or binary and the LLM only needs to forward it. Lists prerequisites (persistent agent, paid provider skill, iroh addon) and warns about file size constraints. The sibling tool is mentioned by name, providing clear differentiation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elisymlabs/elisym'

If you have feedback or need assistance with the MCP directory API, please join our Discord server