Omnara

Send agent input

agents_input

Sends a message to an agent and returns the stored input. Queued messages (the default) wait until the agent is ready for new work; steering messages reach it at its next model call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agentID": "<agentID>",
      "content_blocks": "<content_blocks>",
      "orgID": "<orgID>",
      "projectID": "<projectID>"
    },
    "name": "agents_input"
  }
}

Input Schema

Name	Required	Description
`actor`	No	External actor to attribute this input to, upserted by (provider_tenant_id, provider_user_id) atomically with the input; a rejected request writes no actor. Only allowed for non-user principals; requests authenticated as a user must omit it and are attributed to the user's omnara actor. When a non-user request omits it, the input has no actor attribution.
`orgID`	Yes	Organization ID (org_...).
`agentID`	Yes	Agent ID (agt_...).
`projectID`	Yes	Project ID (proj_...).
`delivery_mode`	No
`content_blocks`	Yes	At most 20 inline media blocks per submission, each holding up to 10 MiB of decoded media and up to 24 MiB decoded across the submission. Non-media blocks may hold up to 1 MiB combined. The whole request body is capped at 48 MiB.
`cancel_open_interactions`	No	Only valid when delivery_mode is steering. When true, atomically cancels open interactions associated with the current turn's unfinished tool calls before creating the steering input. Their parent tool calls complete as canceled; the turn, runtime, and unrelated tool calls are preserved.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / actor / description

Previous value: -"Identity and attributes of an external actor. Actors are upserted by (provider_tenant_id, provider_user_id) with the external provider. Omitted attributes keep their stored values; provided attributes are overwritten, including empty values. omnara actors are implicit and hosted integrations own their own actor identities."New value: +"External actor to attribute this input to, upserted by (provider_tenant_id, provider_user_id) atomically with the input; a rejected request writes no actor. Only allowed for non-user principals; requests authenticated as a user must omit it and are attributed to the user's omnara actor. When a non-user request omits it, the input has no actor attribution."

Changed3 schema fields changedOct 17, 2026
- addedInput schema / properties / agentID / description
```
Added value: +"Agent ID (agt_...)."
```
- addedInput schema / properties / orgID / description
```
Added value: +"Organization ID (org_...)."
```
- addedInput schema / properties / projectID / description
```
Added value: +"Project ID (proj_...)."
```
First observedOct 13, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the mutation/safety profile is structured. The description adds the queued-vs-steering timing semantics, which annotations cannot convey. It omits, however, any warning that calls are non-idempotent (re-sending creates a second input) and says nothing about the 'stored input' response beyond that phrase.

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

Conciseness5/5

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

Two sentences, zero filler, and the default behavior is stated before the non-default. Each sentence carries distinct information: the action plus return, then the mode semantics.

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

Completeness3/5

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

For a 7-parameter mutation with nested content blocks and no output schema, the definition covers the main behavioral fork but not the retry/duplication risk implied by idempotentHint=false or the shape of the returned stored input. The heavy schema documentation compensates for much of the rest.

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

Parameters3/5

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

Schema description coverage is 86%, so the baseline is 3. The one genuine addition is explaining what delivery_mode's enum values mean at runtime, which the schema leaves as a bare enum. Everything else the description says about parameters is already documented in the schema (actor attribution, cancel_open_interactions, content_blocks size caps).

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

Purpose4/5

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

The description uses a specific verb and resource ('Sends a message to an agent and returns the stored input') and immediately characterizes the two delivery behaviors. It is clearly distinguishable from read-oriented siblings (agents_get, agents_list) or lifecycle siblings (agents_cancel, agents_archive), though it never names an alternative tool.

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

Usage Guidelines4/5

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

It gives explicit guidance for the key decision the caller faces: queued messages (default) wait for the agent to be ready, steering messages land at its next model call. That is real when-to-use guidance for the delivery_mode choice, but there is no guidance on when to send input versus launching an agent or resolving an interaction.

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

All Omnara tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.