Proto

Collect a run that outlived its connection, using the job_id run_tool handed back. Safe to call repeatedly. While the run is going this reports where it got to; once it has finished this returns the result. Download links are minted fresh on every call, so a link that has expired is replaced simply by asking again. For a run on your own Modal workspace, this polls Modal and persists any new status or result. It also renews the retention period for an ephemeral stored result.

get_run_status

Build a tool's Modal app in your own workspace, so run_tool can dispatch to it. Takes several minutes and costs a build on your Modal account, so confirm with the user before calling it. A tool only needs this once; afterwards it stays deployed. Calling it again after a completed deploy replaces the existing deployed app with the version currently published by proto-tools. **This usually returns before the build finishes, and may not return at all.** The build runs on your Modal account and does not need this connection: if the call times out, the deploy has neither failed nor stopped. Ask `get_deploy_status` how it is going. Do not call this again to find out -- a second call joins the build already running rather than starting another, so it is safe, but it answers nothing the status call would not. What gets built is proto-tools as published. Nothing belonging to this service is added to the image, and no secret of this service's is attached to it. If the tool needs gated model weights, create a Modal secret holding your HuggingFace token and send its name as the `modal-hf-secret` header; the token is resolved in your workspace and never reaches here.

deploy_tool

How a deploy started by deploy_tool is going. Safe to call repeatedly, and the right thing to call when deploy_tool timed out: a build outlives the connection that began it. `tracked: false` means nobody is tracking a deploy for this tool -- **not** that it did not happen. Progress is held for an hour, and a deployment outlives that. Whether the tool ended up deployed is answered by `list_tools`, which asks Modal itself.

get_deploy_status

Return a stored output's content here, instead of a link you have to go and fetch. Use this when a download link cannot be reached. A sandboxed client whose egress policy refuses the storage host gets the content over this connection instead, which is already open. Text comes back as text; anything else is base64 with `encoding` saying so. Large assets are still refused rather than pasted into the conversation: raise inline_if_under_bytes if you genuinely want more, up to 1 MB. Fetching an ephemeral output or upload renews its retention period.

get_asset

List bioinformatics tools, flagged by whether they can run for you. Defaults to what your workspace actually serves. Pass deployed_only=False for the full catalogue, which also shows what you could deploy. Entries arrive under `tools`, the same as search_tools, each carrying the key to run under `tool_key`.

list_tools

Run a tool and return the result. Required workflow: Call get_tool_schema(tool_key) and get_tool_example(tool_key) before constructing inputs. Tool inputs vary and may use nested biological entity structures; never guess their shape. Calls to these metadata tools are discovery calls, not tool executions. Pass `use_example=true` to run the canonical example unchanged. Blocks while it runs. A first call after a few minutes idle pays a container start and a model load, and some tools legitimately run for many minutes. A run that outlives the connection returns `pending` with a `job_id` instead of a result. The run is unaffected and keeps going; call get_run_status with that id to collect it. Pure CPU tools and explicitly network-backed modes run in this hosted process without a deployment. A tool that would have to build its environment here is refused with a reason rather than attempted, because that build takes minutes and belongs in a deployment.

run_tool

Find tools by keyword, matching the tool key and its description.

search_tools

Get a known-good example input for a tool, or null if it declares none. Step 2 of the workflow: get_tool_schema, then get_tool_example when available, then one run_tool call. Use its structure as the template for the request rather than as illustration. `run_tool(use_example=true)` runs it unchanged.

get_tool_example

Where a tool comes from: who built the model, how to cite it, and the code that runs it. Deliberately not part of get_tool_schema. That call answers "what arguments does this take" and happens before every run; this one answers "what is this and who should be credited", which is wanted when reporting a result rather than producing one. Folding a bibtex entry into the schema would enlarge the most frequent call for the sake of the least frequent need. `source` is Proto's implementation -- the wrapper, environment, and example. `links` are the model's own: its authors' repository, paper and weights.

get_tool_info

Get the input, config and output schemas for a tool, and whether you can run it. Step 1 of the workflow: get_tool_schema, then get_tool_example when available, then one run_tool call. `has_example` says whether step 2 has anything to return.

get_tool_schema