Skip to main content
Glama
FerroxLabs

TVControl

by FerroxLabs

watchlist_create

Create a new named watchlist and optionally populate it with symbols in one call. Use it when building a list from scratch, since other tools only write into an already active list.

Instructions

Create a NEW named watchlist, optionally populated in one call. Use this to build a user a list from scratch - watchlist_import and watchlist_add_bulk only write into whichever list is already active, so neither can make one. Returns the new id; pin by id, never by name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the new watchlist, e.g. "TC-TIDE"
symbolsNoExchange-prefixed symbols to populate it with, e.g. ["NASDAQ:AAPL","NYSE:GE"]. Duplicates are collapsed.
allow_duplicate_nameNoCreate it even when a list of that name already exists (default false). Names are not unique on TradingView and a duplicate cannot be told apart by name afterwards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.3

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly discloses that the tool creates a new list, optionally populates it, returns the new id, and warns against by-name references. It does not discuss duplicate-name behavior beyond what the schema covers, but the return-value and identity caveats are meaningful behavioral disclosures.

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?

Three sentences with no filler: the primary action and scope come first, then the sibling differentiation, then the return-value caveat. Every sentence earns its place and the most important guidance is front-loaded.

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?

For a three-parameter tool with no output schema and no annotations, the description plus schema covers all needed invocation knowledge: what it does, when to use it, the return id, and the pin-by-id caution. No critical gap remains for an agent to call it 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%, and the input schema already documents all three parameters with examples and defaults. The description adds no additional parameter-level meaning beyond framing the purpose, so the baseline of 3 applies.

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 states a specific verb and resource: 'Create a NEW named watchlist, optionally populated in one call.' It also distinguishes itself from sibling tools by noting that watchlist_import and watchlist_add_bulk cannot make a new list, only write into an already active one.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: 'Use this to build a user a list from scratch' and names the alternatives that are not appropriate for this purpose. The note 'pin by id, never by name' adds practical invocation guidance beyond basic selection.

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