Skip to main content
Glama

task_submit

Submit a task to the Kart sandboxed execution queue and receive a task_id for polling. Tasks run network-isolated by default; network or database access requires operator-signed authorization envelopes and explicit capability flags.

Instructions

Submit a task to the Kart sandboxed execution queue. Returns task_id for polling.

Tasks run network-isolated by default. Egress needs the task_net capability, standing consent.internet, a live operator lease, and an operator-signed per-task envelope passed as network_authorization. The envelope binds the submitter, task id, agent, normalized task hash, network scope, expiry, and nonce. The signed task id is the queue primary key, preventing the envelope from authorizing a second row. # allow_net and # allow_localhost remain requests, never authority.

Local Postgres access (socket mount + PG/POSTGRES env) requires allow_db=True and the separate task_db manifest capability — not granted by task_queue or full_access. # allow_db in task text is a request, never authority. When the operator sets WILLOW_MCP_ENFORCE_DB_PERIMETER (off by default), allow_db additionally requires an operator-signed per-task db_authorization envelope (db scope) from willow-mcp sign-db-task — mirroring the network perimeter, so a task_db holder can no longer submit arbitrary psql.

The Kartikeya executor verifies all host gates and the signed envelope again immediately before shell launch. Missing attribution or envelope, an invalid signature, expiry, replay, task mutation, unavailable verifier, or a strict trust-root failure denies network. Signing is available only through the local interactive willow-mcp sign-net-task CLI; no MCP tool can mint authority.

Task text is security-scanned at SUBMIT time (defense-in-depth): a task the Kart scanner would refuse — destructive, exfiltration, secret access, obfusc- ation, or resource-exhaustion (fork bomb / spin / disk-fill) — is rejected here before it ever occupies a queue slot, not only when the worker later picks it up. The worker re-scans at execution regardless; this just denies earlier and keeps a bomb from sitting pending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
laneNofast
taskYes
agentNokart
app_idYes
allow_dbNo
allow_netNo
allow_localhostNo
db_authorizationNo
network_authorizationNo
Behavior3/5

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

Provides details about security scanning, network isolation, and authorization requirements, but no clear statement on side effects or error handling. Repetitive text may confuse.

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

Conciseness1/5

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

Very long and repetitive, with similar paragraphs repeated three times, making it verbose and inefficient.

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

Completeness2/5

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

Covers security context but lacks explanation of output format, error conditions, and parameter semantics; incomplete for a complex tool.

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

Parameters1/5

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

No description of parameters; schema has zero coverage; only vague mentions of authorization fields in security text, but not systematic explanation.

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?

States specific verb 'Submit' and resource 'task to Kart sandboxed execution queue'. Clear and distinct from siblings.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives; only mentions that signing is via CLI, not MCP, but doesn't direct agent when to call this.

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/willow-memory/willow-mcp'

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