Skip to main content
Glama
teifidebugger

Cloudflare Playwright MCP

by teifidebugger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

execute-code

Run custom Playwright JavaScript code to automate browser interactions, extract page data, and handle console logs for web automation tasks.

Instructions

Execute custom Playwright JS code against the current page

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe Playwright code to execute. Must be an async function declaration that takes a page parameter. Example: async function run(page) { console.log(await page.title()); return await page.title(); } Returns an object with: - result: The return value from your function - logs: Array of console logs from execution - errors: Array of any errors encountered Example response: {"result": "Google", "logs": ["[log] Google"], "errors": []}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it executes code asynchronously, requires a specific function structure (async with page parameter), and details the return format (result, logs, errors). It doesn't mention rate limits, auth needs, or destructive effects, but covers execution mechanics adequately for a tool with no annotations.

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 description is a single, front-loaded sentence that directly states the tool's purpose with zero waste. Every word earns its place by specifying the action, code type, and target, making it highly efficient and easy to parse.

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?

Given one parameter with full schema coverage and no output schema, the description is reasonably complete. It explains the execution process and return format, compensating for the lack of output schema. However, it doesn't address potential errors or side effects beyond the listed response fields, leaving minor gaps for a code execution 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 description coverage is 100%, so the baseline is 3. The description adds value by emphasizing the code must be 'Playwright JS' and executed 'against the current page', providing context beyond the schema's technical details. It doesn't elaborate on parameter syntax beyond the example, but enhances understanding of the tool's scope.

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 clearly states the verb ('execute') and resource ('custom Playwright JS code') with the target ('against the current page'). It distinguishes from siblings like get-context or get-screenshot by focusing on code execution rather than retrieval or capture. However, it doesn't explicitly differentiate from init-browser in terms of browser lifecycle management.

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?

The description implies usage for executing custom code on a page, suggesting it's for dynamic interactions beyond simple data fetching. No explicit guidance on when to use vs. alternatives like get-full-dom for static content or prerequisites (e.g., requires an initialized browser). The context is clear but lacks specific exclusions or named alternatives.

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