Skip to main content
Glama
daviddme

TradingView Unified MCP

by daviddme

browser_screenshot

Read-only

Capture the current TradingView tab as a PNG image for local inspection or sharing. Images are returned directly to the caller and are not uploaded to an external service.

Instructions

Capture the current TradingView tab as a PNG image. May contain chart/account information; images are returned to the caller and are not uploaded to an external service.

Input Schema

NameRequiredDescriptionDefault
target_idNoExact Chrome tab target ID from browser_list_tabs. Required for changes.
expected_layout_idNoExpected saved-layout ID. A mismatch stops the operation before writing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-obvious context — that images may contain chart/account information and stay local rather than being uploaded. However, with no output schema, it never explains how the PNG is delivered (inline payload versus file path) or any size limits, which is the key remaining behavioral gap.

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 sentences, zero waste: purpose first, privacy/data-handling second. Nothing is padded or restated from the title or schema.

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 two-optional-parameter read tool with full schema coverage and no output schema, the definition covers purpose and data-handling adequately. The missing return-format detail is the one thing an agent would still want, but the core call decision is supported.

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%, so both parameters are documented in the schema and the baseline is 3. The description adds nothing about target_id (e.g., that omitting it captures the active tab) or about why a read-only capture would need expected_layout_id, leaving a meaningful semantic gap unfilled.

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?

"Capture the current TradingView tab as a PNG image" gives a specific verb, resource, and output format, which is enough for an agent to know what it gets back. It does not distinguish itself from nearby capture-style siblings such as ui_snapshot, layout_snapshot, or strategy_capture, so an agent must infer the boundary from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this instead of ui_snapshot, layout_snapshot, or drawing_export, and no prerequisites such as requiring the tab to be activated first. The phrase "current tab" only weakly implies that context, leaving routing to guesswork.

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