Skip to main content
Glama
pineforge-4pass

PineForge-Codegen

Check a Pine feature

check_pine_feature
Read-onlyIdempotent

Check if a Pine v6 identifier or namespace is supported before using it, or to diagnose silent strategy misbehavior. Returns status and notes without running the engine.

Instructions

Answer "does PineForge support X?" for a specific Pine v6 identifier or namespace (e.g. 'ta.supertrend', 'alert', 'array.new', 'request.financial'). Use it (a) BEFORE relying on any function you are unsure about while writing a strategy, and (b) to DIAGNOSE a backtest that compiled but behaved wrong or empty — plots, tables and alerts (plot, bgcolor, table, alert) are accepted and produce NO effect, while line, box and label objects are data the strategy can read back. Resolves by exact feature match, then longest namespace prefix, then alias, returning {query, status, topic, note} where status is supported / partial / unsupported / via_transpiler / not_found (via_transpiler = works end-to-end; unsupported = refused, not compiling, stopping the run, or no effect) and the note quotes the catalog entry, which says what THIS server can and cannot do (e.g. request.security on another symbol). Local, free, no engine run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
featureYesPine identifier or namespace to look up, e.g. 'ta.supertrend', 'alert', 'array.new', 'strategy.entry', 'request.dividends'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds substantial behavioral detail beyond that: the resolution order (exact, longest prefix, alias), the return shape and status vocabulary, and the semantics of via_transpiler vs unsupported. It doesn't discuss rate limits or latency, but for a local lookup those are moot.

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?

Front-loads the core question, then the two usage scenarios, then matching/return details. Dense but every clause carries content. Slightly long, with the long parenthetical enumerations making it a touch harder to scan.

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 single-param, no-output-schema lookup tool, the description covers purpose, timing, matching algorithm, and full status vocabulary including the via_transpiler/unsupported boundary. An agent has everything needed to call it and interpret results.

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

Parameters4/5

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

Schema coverage is 100% and the schema already documents the single 'feature' parameter with its own examples. The description restates the input domain (identifier or namespace) and supplies the resolution matching rules, which adds meaning beyond the schema. Baseline is 3, raised to 4 for the matching semantics.

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?

States a precise question it answers ('does PineForge support X?') for a specific input type (Pine v6 identifier or namespace) with concrete examples. Clearly distinguishable from siblings like transpile_pine or check_tradingview_parity.

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?

Gives two explicit when-to-use scenarios: (a) before relying on an unsure function, (b) to diagnose a compiled-but-wrong backtest. Also implicitly routes away from engine-running siblings by noting it runs locally with no engine run.

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