Skip to main content
Glama
daviddme

TradingView Unified MCP

by daviddme

alert_resume

Resume specified TradingView alert IDs and poll their server state independently to check eventual changes, without asserting a trigger or delivery.

Instructions

Resume explicit alert IDs and independently poll their eventual server state. Does not claim a trigger or delivery occurred.

Input Schema

NameRequiredDescriptionDefault
alert_idsYes
target_idYesExact Chrome tab target ID from browser_list_tabs. Required for changes.
timeout_msNo
expected_layout_idYesExpected 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.3/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, open-world, non-idempotent operation. The description adds useful behavioral context by saying it independently polls eventual server state and explicitly avoids claiming a trigger or delivery occurred, which is valuable transparency beyond the 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?

Two compact sentences, front-loaded with the action and followed by an important behavioral caveat. There is no filler and every sentence contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core caveat that resume does not guarantee a trigger or delivery, which is important for an asynchronous mutation. However, it omits relevant details such as the expected_layout_id guard behavior and timeout semantics, and there is no output schema to fill those gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description does little to compensate: it references "explicit alert IDs" but does not clarify target_id, expected_layout_id, or timeout_ms semantics beyond the schema. The schema itself documents target_id and expected_layout_id, but alert_ids and timeout_ms remain undescribed in both places.

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 states a specific verb and resource: "Resume explicit alert IDs," and adds the polling behavior. It clearly distinguishes resume from pause or verify, though it does not explicitly name an alternative sibling.

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?

It implies use when alerts are paused by mentioning "Resume explicit alert IDs," but gives no explicit guidance on when to choose this over alert_verify, alert_reconcile, or other alert tools. No exclusions or prerequisites are stated.

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