x711

x711_agent_act

Destructive

Give any agent hands. Pass a URL + natural-language instruction → x711 executes it: fills and submits forms, follows links, extracts structured data (tables, lists, prices). No Playwright. No Puppeteer. No browser setup. Together with x711_agent_see this is a full browser in two tool calls — agents that can see + act can navigate the entire internet autonomously. Instruction examples: 'fill the email field with user@example.com and submit', 'extract all product prices', 'follow the login link and return the page'. Returns: { action_performed, result, page_status }. JS SPA warning included if detected. Cost: $0.05. Requires API key.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The URL to act on. Must be a public http/https URL.
`inputs`	No	Optional key-value pairs for form fields. Keys = field name attributes (e.g. {"email": "agent@x711.io", "q": "search query"}). Merged with any defaults found on the page.
`instruction`	Yes	Natural-language action to perform. Examples: 'fill the search box with "bitcoin" and submit', 'extract all table rows', 'click the Download button', 'scrape all product prices and names'.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations (destructiveHint, readOnlyHint), it discloses cost ($0.05), API key requirement, return fields (action_performed, result, page_status), JS SPA warning behavior, and that no browser setup is needed. It also clarifies the tool performs actions that could be destructive, consistent with destructiveHint.

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?

The description is well-structured and front-loaded, but slightly verbose with phrases like 'No Playwright. No Puppeteer. No browser setup.' repeating a single idea. Still, every sentence adds value (examples, cost, returns, pairing), and the length is justified by the tool's complexity.

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?

Despite no output schema, the description provides return fields, prerequisites (API key, public URL), cost, and the important caveat about JS SPA warnings. It also explains the relationship with x711_agent_see, giving an agent complete context to decide when and how to invoke this tool.

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. The description adds meaningful semantic context by explaining that 'instruction' is natural-language and providing examples that map to the schema, plus clarifies that inputs are merged with page defaults, which goes slightly beyond the schema description.

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 opens with 'Give any agent hands' and clearly states the tool executes a URL with a natural-language instruction, enumerating specific actions (fill/submit forms, follow links, extract data). It explicitly differentiates from sibling x711_agent_see by describing the pair as a complete browser in two tool calls.

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?

The description provides clear context: it is for acting on web pages, with concrete instruction examples. It mentions pairing with x711_agent_see for full browsing, implying when to use it, but does not explicitly state exclusions or compare against other sibling action-type tools.

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

All x711 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Many tools have overlapping purposes, such as multiple search tools (web_search, deep_search, data_retrieval) and multiple communication tools (agent_ping, agent_telegram, swarm_broadcast). The descriptions help differentiate, but the boundaries are not always clear.

Naming Consistency4/5

All tools consistently use the 'x711_' prefix and lowercase_with_underscores format. Submodules like agent, hive, and tx follow predictable patterns. Minor deviations (e.g., x711_ask_clerk) are rare and still descriptive.

Tool Count2/5

With 47 tools, the server is excessively large for a typical MCP service. While it aims to be a comprehensive platform, the high count makes navigation and selection cumbersome for an agent.

Completeness4/5

The tool set covers a wide range of agent needs: web access, memory, communication, on-chain transactions, code execution, and more. Minor gaps exist (e.g., no agent deletion tool), but overall it is remarkably complete for the stated purpose of an agent platform.

Resources

Need Help?