Skip to main content
Glama
Sign In
Sora Commander

Sora Commander

by kurojack-jp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

send_input

Requests Owner GUI approval to submit one exact numeric line to an approved interactive Python process, returning a pending ID for result tracking.

Instructions

DEV_ONLY: ask the local Owner GUI to send one exact numeric line ONCE to this manager's previously approved interactive Python process. Returns pending_id; observe through await_command_result or review_status only. No arbitrary code, secrets, PID attachment, input logging or retries. UNKNOWN stops the session.

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": {
      "session_id": "<session_id>",
      "input_text": "<input_text>",
      "input_id": "<input_id>"
    },
    "name": "send_input"
  }
}

Input Schema

NameRequiredDescriptionDefault
input_idYesUnique 32 lowercase hex input ID consumed before GUI review; NEVER resend after timeout, error or UNKNOWN, even with a different ID.
input_textYesOne UTF-8 numeric Python expression or print(expression), ending in newline, at most 1024 bytes; no secrets or other controls.
session_idYesExact OWN active interactive JobManager session ID (48 lowercase hex); never a PID or foreign session.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations supplied, the description itself discloses GUI mediation, prior approval, single submission, asynchronous pending_id behavior, prohibited capabilities, absence of input logging, and the session-ending UNKNOWN outcome. These details communicate the important side effects, safety constraints, and failure behavior needed for correct invocation.

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?

Four compact sentences front-load the DEV_ONLY restriction and core action, then efficiently cover the result, observation path, prohibitions, and failure behavior. The emphatic capitalization is reserved for critical operational constraints, and there is no filler.

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?

For a sensitive, asynchronous, human-mediated input tool, the definition covers prerequisites, permitted payload class, approval mediation, result handling, follow-up tools, retry policy, and terminal failure behavior. The presence of an output schema makes further return-shape documentation unnecessary, and no material invocation gap is apparent.

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 coverage is 100%, and the schema already documents the formats and constraints for all three required parameters in substantial detail. The description adds useful workflow context such as prior approval and exact-once submission, but most parameter-related wording reinforces the existing input_text and input_id rules rather than adding substantial new per-parameter semantics.

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 specifies the exact action and target: asking the local Owner GUI to send one numeric line to this manager's previously approved interactive Python process. The DEV_ONLY, numeric-only, and exact-once qualifiers clearly distinguish it from general execution siblings such as run_command.

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?

It defines a narrow usage context and explicit exclusions: only a previously approved process, with no arbitrary code, secrets, PID attachment, or retries. It also names await_command_result and review_status as the only observation routes and explains that UNKNOWN stops the session.

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