Skip to main content
Glama
omnara-ai

omnara

Official
by omnara-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Send agent input

agents_input

Send text, files, or steering commands to an Omnara AI agent. Create queued or steering input with optional cancellation of open interactions.

Instructions

Create agent input

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorNoIdentity 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.
orgIDYes
agentIDYes
projectIDYes
delivery_modeNo
content_blocksYesAt 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_interactionsNoOnly 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.

  1. First observed

TDQS

D1.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, so the mutation profile is partly known. The description adds nothing beyond that: it does not explain delivery_mode behavior, the auto-upsert of actors, or what cancel_open_interactions destroys, all of which are non-obvious side effects.

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

Conciseness2/5

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

Three words are not concise so much as under-specified. Front-loading is irrelevant when there is no content; the single fragment carries no information an agent can act on.

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

Completeness1/5

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

For a complex 7-parameter mutation with nested content blocks, media size limits, delivery modes, and a conditional cancel flag — and with no output schema to lean on — a three-word description is completely inadequate.

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?

Schema description coverage is only 43% across 7 parameters with nested objects, so the description must compensate — yet it mentions no parameter at all. Critical semantics like queued vs steering delivery, or the meaning of actor identity upsert, are left entirely to the schema.

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

Purpose2/5

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

"Create agent input" is essentially a restatement of the tool name (agents_input) and title ("Send agent input"). It conveys no specific verb-plus-resource distinction and gives no hint of what an "agent input" means versus sibling operations like agents_launch or agents_interactions_resolve.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool, no prerequisites (delivery_mode semantics, agent state requirements), and no mention of alternatives among the many agents_* siblings. The agent must infer everything from the name.

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

Deploy Server

Other Tools