Skip to main content
Glama

selector_hint_get

Look up a saved selector by key and domain, returning it ready for click, type, or get_text tools. Check selector_hint_list if no hint exists.

Instructions

Look up a saved selector by key for a site and return it, ready to pass as the selector of click, type, get_text, and similar tools. Fails if no hint with that key exists for the domain; use selector_hint_list to see what is saved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesShort name for the element, e.g. 'login_button' or 'search_box' (1-128 chars).
domainNoSite hostname, e.g. 'www.saucedemo.com'. Defaults to the hostname of the page currently open.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / domain / description
      Added value: +"Site hostname, e.g. 'www.saucedemo.com'. Defaults to the hostname of the page currently open."
    • addedInput schema / properties / key / description
      Added value: +"Short name for the element, e.g. 'login_button' or 'search_box' (1-128 chars)."
  2. Addedv0.2.0

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses the missing-key failure mode and that the returned value is directly consumable by click/type/get_text, but says nothing about persistence scope, session coupling, or whether the hint can be stale.

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 tight sentences: the lookup semantics and downstream use come first, then the failure/alternative guidance. No filler or repetition of structured data.

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?

With no output schema, the description compensates by stating what is returned (a selector ready for other tools) and what happens on miss. An agent has everything needed to call it correctly.

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 description coverage is 100%, covering both 'key' and 'domain'. The description only restates that the lookup is per-site/domain; it adds no format or constraint detail beyond the schema, so the 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?

The description names a specific verb+resource (look up a saved selector by key for a site) and states the output's purpose: it is ready to pass as the selector of click, type, get_text. This distinguishes it from selector_hint_list and the hint-mutation siblings without opening any 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?

It gives the failure condition ('fails if no hint with that key exists for the domain') and an explicit alternative ('use selector_hint_list to see what is saved'), which is exactly the when-to-use/alternate-route guidance an agent needs.

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