Skip to main content
Glama

Type text

text

Types characters into the focused field on Android or iOS devices. Handles non-ASCII input on Android via clipboard and needs a one-time runner install on iPhone.

Instructions

Type into the focused field. Any text; on Android, text beyond ASCII is pasted through the clipboard and the old clip put back. An iPhone needs install_runner once.

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

Input Schema

NameRequiredDescriptionDefault
textYes
deviceNoId or name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses the Android non-ASCII clipboard path and that the previous clipboard is restored, plus the iPhone prerequisite. It does not describe error behavior when no field is focused or per-device return/effect details, but the side-effect disclosure is strong.

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?

The core action is front-loaded in the first sentence, and the platform caveats are short and relevant. There is little waste; the extra sentences earn their place by covering clipboard restoration and the iPhone prerequisite.

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 non-destructive text-entry action with annotations and no output schema, the description covers the main operational constraints: focus, Android clipboard handling, and iPhone setup. The remaining gap is minor because device identity is documented in the schema.

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 only 50%: 'device' is documented in the schema as 'Id or name,' but the required 'text' parameter has no schema description. The description adds 'Any text' and platform caveats for non-ASCII input, but does not explain the 'device' parameter's role beyond what the schema already says.

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

Purpose4/5

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

The description names a specific action ('Type') and target ('the focused field'), so the agent knows it inputs text rather than key events. It does not explicitly contrast with the sibling 'key' tool, so it is clear but not fully differentiated.

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

Usage Guidelines4/5

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

It gives the key precondition (a field must already be focused) and notes the iPhone one-time install_runner prerequisite. It does not explicitly say when to use 'key' instead or how to focus a field, so some routing is left to inference.

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