Skip to main content
Glama
Sign In
vibatchium

vibatchium

by trueoriginlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

type

Enters text keystroke by keystroke into a selected element so suggestion lists populate, making it suitable for address boxes and other autocomplete fields instead of filling all at once.

Instructions

Type text key by key into an element. Use this rather than fill when the field offers suggestions as you type, such as an address box.

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": {
      "target": "<target>",
      "text": "<text>"
    },
    "name": "type"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesText to type.
indexNoType into the Nth match (0-based, document order).
leaseNoOptional lease token to present if the target session is leased (0.7.0). Threaded per-call; never read from the server's env.
targetYes@eN ref or selector.
sessionNoOptional session name to target (omit for the shared 'default'). On a daemon shared with other agents, pass a UNIQUE name for stateful multi-step work (go→click→fill) so you don't collide on 'default'.
delay_msNoPer-keystroke delay (ms).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.21.0
    • changedInput schema / properties / index / description
      Previous value: -"Type into the Nth match (0-based, from `candidates`)."New value: +"Type into the Nth match (0-based, document order)."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose the key trait that matters — per-keystroke input rather than a single value set, which is what triggers suggestion handlers — but it says nothing about whether existing text is cleared, whether the element must be focused first, or how the session/lease parameters affect execution.

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, no filler, with the core action stated first and the disambiguation second. Every clause earns its place.

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?

For a six-parameter input tool with fully described schema fields and no annotations, the description covers purpose and tool selection well. The remaining gap is post-typing behavior (does it clear prior content, does it trigger blur/change events), which an agent may still have to discover empirically.

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 text, target, index, delay_ms, session, and lease in detail. The description adds no meaning beyond those definitions (e.g., it does not explain that delay_ms exists to let debounced suggestion lists settle), so baseline 3 applies.

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 a specific verb and mechanism ("Type text key by key") against a specific resource ("into an element"), and explicitly contrasts itself with the sibling `fill`. An agent can tell which of the two input tools to pick without opening either schema.

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?

Gives a concrete when-to-use rule — fields that offer suggestions as you type, with an example (address box) — and names the alternative tool (`fill`) plus the condition that selects it. This is the exact decision boundary an agent needs.

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