Skip to main content
Glama

SiteCheck Crypto & Finance

Finance Tradingview Screener

finance_tradingview_screener
Read-only

TradingView stock screener results for one market (default america): symbol, last price and daily change, in TradingView's default order. Read-only scanner query; no filters beyond market and count. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many rows, 1 to 50 (default 10)
marketNoamerica (default), crypto, forex or global

Output Schema

NameRequiredDescriptionDefault
rowsNo
marketNo
sourceNo
checkedAtNo
totalCountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag readOnlyHint/openWorldHint, and the description adds genuinely non-obvious context: per-call cost of $0.002 USDC via x402 on Base/Solana/Arc and that failed calls are not charged. It still omits things like pagination or freshness/rate limits, but the payment/auth behavior is the key disclosure an agent needs.

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 short sentences, front-loaded with what the tool returns, followed by scope constraints, then pricing. No filler or repetition; each sentence carries distinct information.

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?

With an output schema present and 100% schema coverage, the description needn't explain return shapes or parameter values, and it correctly spends its words on scope and billing. Minor gap: no note on data freshness or result ordering semantics beyond "TradingView's default order."

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 limit (1-50, default 10) and market (america/crypto/forex/global) are documented structurally. The description only echoes the default market and the row count, adding no extra syntax or behavioral meaning beyond the schema.

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?

States a concrete verb+resource (TradingView stock screener for one market) and enumerates the returned fields (symbol, last price, daily change, default order). It is distinguishable from finance_tradingview_ideas (ideas, not screener rows), though it does not explicitly name that sibling as an alternative.

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?

"Read-only scanner query; no filters beyond market and count" implies the intended lightweight screening use and bounds expectations, but there is no explicit when-to-use/when-not or comparison to the many other quote/screener siblings (finance_finviz, finance_stockanalysis, finance_yahoo_finance).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources