AginxBrowser

Overview Schema Source Related Servers Discussions Admin

session_input

Type text into a specified input field by index, focusing it and dispatching input/change events. Supports full key-by-key typing and reports reasons if the field is disabled, readonly, or detached.

Instructions

Type text into an input/textarea element by its index (from session_state output), focusing it and dispatching input/change events. events:"full" is the complete human typing gesture: per-character keydown/keypress/input/keyup cycles, trailing change, then blur — the tail blur commits on forms that save in onBlur (React capture listeners, #100). A disabled, readonly, or detached field answers filled:false with a reason instead of a silent write. Hidden inputs are legitimate targets and are filled normally.

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>",
      "index": "<index>",
      "text": "<text>"
    },
    "name": "session_input"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Text to type into the input field
`index`	Yes	Element index (from /state output)
`events`	No	Event fidelity: "full" types one character at a time with a keydown/keypress/input/keyup cycle per character, for pages whose listeners key on keyboard events (e.g. keypress-Enter login forms). Default fires a single input+change pair after the value is set.
`session_id`	Yes	Session ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.1Sep 20, 2026
- removedInput schema / title
```
Removed value: -"SessionInputParams"
```

Changed1 schema field changedv0.3.0Sep 9, 2026

addedInput schema / properties / events

Added value: +{
+  "default": null,
+  "description": "Event fidelity: \"full\" types one character at a time with a\nkeydown/keypress/input/keyup cycle per character, for pages whose\nlisteners key on keyboard events (e.g. keypress-Enter login forms).\nDefault fires a single input+change pair after the value is set.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only provide a title, so the description carries the full behavioral burden and does so thoroughly. It discloses focusing, event cycles, trailing blur semantics, the filled:false with reason response for disabled/readonly/detached fields, and the special case for hidden inputs. This is far beyond the minimal schema information.

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

Conciseness4/5

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

The description is dense but every sentence earns its place: purpose, event fidelity, failure behavior, and hidden-input edge case. It loses a point for awkward formatting ('events:"full"' with stray punctuation) and the unexplained '#100' reference, which slightly muddies an otherwise efficient structure.

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

Completeness4/5

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

There is no output schema, yet the description provides the key response signal (filled:false with a reason) and covers important edge cases. It does not describe what a successful call returns, but the operation and failure behavior are specified well enough for an agent to invoke it correctly.

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

Parameters4/5

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

The schema already covers all parameter descriptions at 100%, giving a baseline of 3. The description adds meaning beyond the schema by clarifying that the index comes from session_state output and by explaining the practical consequences of the events parameter, especially the blur behavior that commits onBlur forms.

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 opens with a specific verb and resource ('Type text into an input/textarea element by its index') and clearly scopes the operation to focused typing plus event dispatch. This distinguishes it from siblings like session_click or session_set_files without needing to inspect the schema.

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

Usage Guidelines3/5

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

It gives useful contextual usage guidance: index comes from session_state output, 'full' events are for pages with keyboard listeners, and hidden inputs are valid targets. However, it never says when to prefer this tool over nearby alternatives such as session_eval or session_click, so the when-vs-alternatives guidance is only implied.

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