Skip to main content
Glama

Type text into the console

gma3_type

Type Unicode text into the grandMA3 command line or a text field, requiring you to confirm focus. It does not press Enter; commit with a separate key tap.

Instructions

Type Unicode text as one character event per code point into an EXPLICIT context. Which element receives characters cannot be observed from Lua, so acknowledge_focus: true is always required: you state that the command line (context 'command-line') or a text field (context 'text-field') is focused. 'command-line' is admitted only while the operator has disabled keyboard shortcuts (F10; with shortcuts enabled, characters never reach the command line and nothing is substituted) and is read back from the command line: matched when it shows the text; when it does not within the readback window the step is UNKNOWN and nothing after it runs. 'text-field' cannot be read back (verification unavailable) and must not be followed by PLEASE/Enter in the same sequence. Text is refused while an exclusive long-press is held or a held key's route changed. Text is typed in chunks by the bridge loop with the context rechecked between chunks; it stops with its progress (unknown) when shortcuts are toggled, a route changes or a long-press starts meanwhile. Newlines, tabs and other control characters are refused (up to 256 characters); text NEVER presses Enter, changes focus, opens an editor or toggles shortcuts: commit it with a separate gma3_hardkey PLEASE tap. Same gate and busy rules as gma3_hardkey (input OFF until the operator runs Plugin "gma3_mcp_bridge" "input=keyboard"; commands from every client are [busy] while it types). Nothing is retried or replayed; a character whose dispatch raised is reported as unknown at that position.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe text (UTF-8, no control characters, at most 256 characters).
contextYesWhere the characters are meant to go; validated and read back where possible.
displayNoDisplay index passed to the console as API context only. It must exist; input is NOT display-scoped on onPC 2.5.1 (no routing, focus or pop-up placement is promised).
interactionNoId from gma3_input_interaction acquire. Required for a standalone hold (press). A bounded tap, chord tap, text or sequence may run without one (it owns an interaction for its duration) but must pass the id while this server has one open.
acknowledge_focusNoMust be true: you state that the named context (command line or a text field) is what currently receives characters; this cannot be observed from Lua.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers rich behavioral context beyond the schema: readback semantics (UNKNOWN when unmatched), chunked typing with context rechecks, refusal conditions (exclusive long-press, changed route, control characters), busy/gate rules, no retry/replay, and per-position unknown reporting. This is unusually complete disclosure for a mutation tool.

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

Conciseness3/5

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

The content is valuable but front-loaded with dense parenthetical and clause-heavy sentences that pack multiple rules together, making it harder to scan quickly. It is not padded with filler, but the wall-of-text structure is not optimally parsed by an agent skimming for the key constraint.

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 mutation tool with no annotations and no output schema, the description covers preconditions (explicit context, acknowledge_focus), failure modes (UNKNOWN, refusal conditions), interaction with siblings (gma3_hardkey for commit), and gate/busy rules. An agent has everything needed 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it explains why acknowledge_focus is always required (focus is unobservable from Lua), ties 'command-line' to the F10 shortcuts-disabled precondition, and states 'text-field' cannot be read back. Slight deduction because display and interaction parameters are addressed only via cross-reference.

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 (type) and resource (Unicode text as code-point character events into an explicit context), and distinguishes itself from siblings like gma3_hardkey and gma3_keyboard by clarifying it never presses Enter or changes focus. An agent can tell exactly what this does without opening 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 Guidelines5/5

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

Gives explicit when-to-use rules: 'text-field' must not be followed by PLEASE/Enter in the same sequence; commit text with a separate gma3_hardkey PLEASE tap; requires acknowledge_focus true; requires the keyboard bridge with input=keyboard. Names the sibling (gma3_hardkey) needed for committing, so alternatives and exclusions are clear.

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