Skip to main content
Glama
zhili663

browser-control-tencent-cloud

by zhili663
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

截取当前标签页截图

take_screenshot
Read-only

Capture the active Edge tab as a Base64 PNG to confirm page state, spot captchas, and verify form details after critical operations.

Instructions

截取 Edge 当前激活标签页的屏幕截图，以 Base64 PNG 返回（MCP image content）。用途：确认页面当前状态、识别滑动验证码/图形验证码、核对表单是否填写正确、排查操作失败原因。建议在每次关键操作后调用一次，作为"视觉反馈"闭环。为避免报文过大，整页截图超过约 3.5MB 时会自动降级为可视区域截图并在返回中标注。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cdpPortNo可选：CDP 调试端口。省略时沿用当前已连接的端口（从未连接过则为 9222）。
fullPageNo是否截取整页（含滚动区域）。默认 false，仅截取可视区域。
savePathNo可选：把截图同时另存到本地路径（相对路径按当前工作目录解析）。
pageUrlContainsNo可选：用 URL 片段指定要截图的标签页（例如 "orcaterm"）。多标签场景建议显式指定。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable behavior details: returns Base64 PNG, auto-degrades to viewport if full-page exceeds ~3.5MB, and notes this in the return. No contradiction.

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 structured: main function, use cases, usage recommendation, and degradation note. It's slightly wordy but each sentence contributes value, and key information is front-loaded.

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?

Covers return format, degradation behavior, and usage suggestions. It doesn't mention prerequisites like an active connection, but that's implied by sibling tools (connect_edge) and not essential. Overall, it's complete enough for an agent to call 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 coverage is 100%, so all four parameters are already documented in the schema. The description adds minimal extra meaning (e.g., the degradation note relates to fullPage), but doesn't go beyond the baseline for high coverage.

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?

Description states a specific verb (screenshot) and resource (Edge current active tab), and lists concrete use cases like verifying page state and detecting captchas. It clearly distinguishes from sibling tools, none of which handle screenshots.

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?

Provides clear usage context: recommended after every key operation, and lists specific scenarios. However, it doesn't explicitly state when not to use it or mention any alternatives, though none exist among siblings.

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