Skip to main content
Glama
Sign In
Cat Burglar

Cat Burglar

by DrMkdaddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Type text

type

Enter text into form fields with human-like per-character delays, targeting elements by ref, selector, text, or role+name for keystroke-driven interfaces.

Instructions

Type into a field with humanized per-character delays. Target one of: ref (preferred), selector, text, or role+name. Use fill for long values or speed; use type for keystroke-driven UIs.

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": "type"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNoElement ref from the latest snapshot, e.g. e12. Preferred over selectors.
nameNoAccessible name to combine with role.
roleNoARIA role, e.g. button, link, textbox, checkbox, combobox.
textYesText to type.
clearNoClear the field first.
exactNoRequire exact text/name match.
submitNoPress Enter after typing.
confirmNoConfirm a high-impact action when the server policy is ask.
observeNoReturn a compact change observation after the action (default true).
delay_msNoFixed delay per char.
selectorNoCSS selector (use when no ref is available).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false; the description adds real behavioral detail that the typing is simulated with per-character delays, which matters for UIs that react to keystrokes. It does not cover the confirm/ask policy for high-impact actions, whether Enter firing via `submit` can submit a form, or what happens on failure to locate the target — gaps the description should carry given how thin the annotations are.

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?

Three sentences, zero filler, with the core behavior front-loaded and the alternative-tool routing placed at the end where it belongs. Every clause carries information an agent needs for selection or invocation.

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 an 11-parameter browser-automation tool with no output schema, this covers the two things that matter most: which targeting parameter to use and when to choose a sibling. Remaining shortfall is only the confirmation-policy behavior and error semantics, and the `confirm`/`observe` schema descriptions partially cover those.

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 would be 3, but the description adds meaning the schema does not: that the four targeting parameters are mutually exclusive alternatives with `ref` preferred over `selector`. That mutual-exclusivity rule is a genuine semantic contribution beyond the per-property schema text.

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?

"Type into a field with humanized per-character delays" gives a specific verb, resource, and distinguishing behavior. The second sentence enumerates the four accepted targeting modes, so an agent understands the addressing model 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?

Names the sibling alternative `fill` and the exact condition that selects it ("long values or speed") versus this tool ("keystroke-driven UIs"). It also ranks the targeting strategies with an explicit preference for `ref`, so selection is not left to inference.

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