Skip to main content
Glama
beSaif

zenpilot

by beSaif
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

type

Replace the content of a field (by ref) with text using real key events.

Instructions

Replace the content of a field (by ref) with text using real key events.

For a <select>, text picks the option starting with it. Date, time, color and range inputs take
their value format instead: date YYYY-MM-DD, time HH:MM (24-hour), datetime-local
YYYY-MM-DDTHH:MM, month YYYY-MM, week YYYY-Www, color #rrggbb. Newlines in text are typed as
Shift+Enter, so they don't send chat messages; submit=true presses Enter after.

Input Schema

NameRequiredDescriptionDefault
refYes
textYes
submitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden well: it says content is replaced (not appended), that real key events are emitted, that select/date/time/color/range inputs take their own value syntax, and that newlines become Shift+Enter so no accidental submit occurs. It omits edge behavior such as invalid refs, elements that reject typing, or rate/timing concerns.

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?

Front-loaded with the core action, then the format table, then the newline/submit nuance — every sentence adds information. The enumeration of input formats is dense but still readable; nothing is redundant.

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 3-parameter, no-annotation, no-output-schema browser tool, this covers the tricky parts (value formats, select matching, Enter vs Shift+Enter) that would otherwise cause failed invocations. The unresolved 'ref' provenance and undefined failure behavior keep it from being fully complete.

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 0%, so the description must compensate, and it does for two of three params: 'text' gets per-input-type format rules and newline handling, and 'submit' is defined as pressing Enter afterward. 'ref' is only glossed as 'by ref' with no indication of where refs come from, which is the one material gap.

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?

States a specific verb ('replace the content of a field') plus the mechanism ('using real key events') and the target identifier ('by ref'), which is clearly distinct from siblings like click or get_text. It does not explicitly name a sibling or say it operates on the current page, so it falls just short of 5.

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?

Usage is implied rather than stated: the input-format enumeration tells the agent this is for data-entry fields, but there is no explicit 'use this instead of click when…' guidance or precondition (e.g., that the field must already be visible/focused). The agent must infer the choice among read_page/click/type from context.

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