pinescript-mcp is an MCP server providing Pine Script v6 documentation, validation, and AI-assistance tools to enable accurate Pine Script code generation and prevent hallucinations.
Documentation Access & Navigation:
list_docs() — Browse all available Pine Script v6 documentation files
list_sections(path) — List section headers within a doc file
get_doc(path) — Read a full documentation file
get_section(path, header) — Read a specific section by its header
Search & Lookup:
resolve_topic(query) — Fast lookup for exact API terms (e.g., ta.rsi, strategy.entry) or concepts (e.g., repainting)
search_docs(query) — Grep-style search across all documentation
Function Validation & Reference:
get_functions(namespace) — List all valid Pine Script v6 functions, optionally filtered by namespace (e.g., ta, strategy, request)
validate_function(name) — Check whether a function exists in Pine Script v6, with suggestions if invalid
Linting & Code Editing:
lint_script(script) — Static analysis for syntax errors, style issues, and undeclared identifiers
edit_and_lint(script_id, edits) — Apply line-level edits to a previously linted script and re-lint (note: removed in v0.7.0; available in earlier versions)
Resources & Prompts:
list_resources() / read_resource(uri) — Access documentation resources by URI (e.g., docs://manifest, docs://functions)
list_prompts() / get_prompt(name, arguments) — Use built-in prompt templates for debugging errors (debug_error), converting v5 to v6 (convert_v5_to_v6), and explaining functions (explain_function)
The server supports multiple integration methods (stdio, HTTP, SSE) and is compatible with clients like Claude, ChatGPT, and Windsurf.
Provides comprehensive access to Pine Script v6 documentation, technical analysis functions, and syntax validation tools, enabling AI agents to accurately generate, debug, and convert TradingView scripts.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PineScript Docs convert this v5 script to v6 syntax"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server providing Pine Script v6 documentation for AI assistants (Claude, etc.).
Enables AI to:
Look up Pine Script functions and validate syntax
Access official documentation for indicators, strategies, and visuals
Understand Pine Script concepts (execution model, repainting, etc.)
Generate correct v6 code with proper function references
Works with Claude Code, Claude Desktop, Gemini CLI, and any MCP client that supports stdio:
{
"mcpServers": {
"pinescript-docs": {
"type": "stdio",
"command": "uvx",
"args": ["pinescript-mcp"]
}
}
}Related MCP server: TradingView MCP Server
No Python or uvx needed — connect directly to the hosted server.
Streamable HTTP — Claude Code, mcpServers with type field):
{
"mcpServers": {
"pinescript-docs": {
"type": "http",
"url": "https://pinescript-mcp.fly.dev/mcp"
}
}
}Windsurf — uses its own shape (see Windsurf docs). Edit ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"pinescript-docs": {
"serverUrl": "https://pinescript-mcp.fly.dev/mcp"
}
}
}ChatGPT — no config file. In ChatGPT, go to Settings → Connectors → Create and paste https://pinescript-mcp.fly.dev/mcp into the Server URL field. Developer Mode must be enabled (see OpenAI Developer Mode guide).
Claude.ai — add via the web UI's MCP connector settings, not a JSON file.
Documentation is bundled in the package — each version contains a frozen snapshot. For reproducible agent behaviour, pin to a specific version:
{
"mcpServers": {
"pinescript-docs": {
"command": "uvx",
"args": ["pinescript-mcp==0.7.6"]
}
}
}Without pinning, uvx pinescript-mcp gets the latest version.
Tool | Description |
| Fast lookup for exact API terms ( |
| Grep for exact strings across all docs |
| List all documentation files with descriptions |
| List |
| Read a specific documentation file |
| Read a specific section by header |
| List valid functions (ta, strategy, etc.) |
| Check if a function exists in Pine v6 |
| Browse available documentation resources |
| Read a doc resource by URI (e.g. |
| List available prompt templates |
| Render a prompt template with arguments |
Prompt | Description |
| Analyze a Pine Script compilation error |
| Convert Pine Script v5 code to v6 syntax |
| Explain a Pine Script function in detail |
URI | Description |
| Start here — routing guide for Pine Script questions |
| Complete Pine Script v6 function list (JSON) |
| Any doc file by path (e.g. |
"How do I create a trailing stop in Pine Script?"
"What's the difference between var and varip?"
"Is ta.supertrend a valid function?"
"How do I avoid repainting with request.security?"
The server bundles comprehensive Pine Script v6 documentation:
Concepts: Execution model, timeframes, colors, methods, objects, common errors
Reference: Types, variables, constants, keywords, operators, annotations
Functions: Technical analysis (ta.*), strategies, requests, drawings, collections
Visuals: Plots, fills, shapes, tables, lines, boxes, backgrounds
Writing Scripts: Style guide, debugging, optimization, limitations
AI models often hallucinate Pine Script functions or use deprecated v5 syntax. This MCP server grounds the AI in actual v6 documentation, preventing:
Made-up function names (e.g., ta.hull doesn't exist, use ta.hma)
Deprecated syntax from v4/v5
Incorrect parameter orders
Missing required arguments
Combine with skills for even more control available at bouch.dev/products/pine-strategy-builder.
# Clone and install locally
git clone https://github.com/paulieb89/pinescript-mcp
cd pinescript-mcp
pip install -e .
# Run the server
pinescript-mcpMIT
Read a specific Pine Script v6 documentation file.
For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) prefer list_sections() + get_section() to avoid loading 1000-2800 line files into context.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative path to the documentation file (e.g., "reference/functions/ta.md") | |
| limit | No | Maximum characters to return. Use 30000 for large files to avoid token limits. | |
| offset | No | Character offset to start reading from (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about large file handling but does not elaborate on other behavioral aspects like error handling or return format. Still, it adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and no wasteful words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description sufficiently explains what the tool does and how to use it effectively. It could mention the return format, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for path, limit, and offset. The description does not add further parameter details beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a Pine Script v6 documentation file, with a specific verb 'Read' and resource 'documentation file'. It distinguishes from siblings like list_sections() and get_section() by implying this is for the whole file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer list_sections() + get_section() for large files to avoid loading 1000-2800 line files, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get valid Pine Script v6 functions, optionally filtered by namespace.
Use before writing Pine Script to see which functions exist. For checking a single function name, use validate_function() instead.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Filter by namespace (e.g., "ta", "strategy", "request"). Empty string returns all functions grouped by namespace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about grouping by namespace and optional filtering, which is helpful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no extraneous information. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not specify the output format (e.g., list of function names). However, the grouping hint and simple parameter set make it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description largely repeats the schema's parameter description ('Empty string returns all functions grouped by namespace'). No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Get valid Pine Script v6 functions', clearly stating the verb and resource. It distinguishes from sibling 'validate_function' by noting the alternative for single function checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before writing Pine Script to see which functions exist' and provides a direct alternative: 'For checking a single function name, use validate_function() instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a prompt by name with optional arguments.
Returns the rendered prompt as JSON with a messages array. Arguments should be provided as a dict mapping argument names to values.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the prompt to get | |
| arguments | No | Optional arguments for the prompt |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It explains the return format (JSON with a messages array) and clarifies how arguments should be structured (dict mapping names to values). It does not cover error cases or side effects, but for a simple get operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Get a prompt by name'), followed by concise return-format and argument-format details. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, an output schema, and no annotations, the description covers the essential behavioral aspects: what it retrieves, how to pass arguments, and what the return shape looks like. It is sufficiently complete for an agent to invoke the tool correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (name and arguments), giving 100% coverage. The description adds extra meaning by specifying that arguments must be a dict mapping argument names to values, which is not fully detailed in the schema. This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a prompt by name, with optional arguments. This distinguishes it from sibling tools like list_prompts (which would enumerate prompts) and call_tool (which invokes tools). The verb-resource pair is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you know the prompt's name and want its rendered output. It does not explicitly mention alternatives or provide 'when not to use' guidance, but the context is clear enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific section from a documentation file by its header.
Use after list_sections() shows available headers, or after resolve_topic() / search_docs() identifies the relevant file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation file path (e.g., "reference/functions/strategy.md") | |
| header | Yes | Header text to find (e.g., "strategy.exit()" or "## strategy.exit()") | |
| include_children | No | Include nested subsections under the header (default: True) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description does not contradict these and adds no further behavioral context, but consistency is maintained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives usage context. No fluff, perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 3 well-documented params and no output schema, the description provides workflow guidance and is complete. Annotations support safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so description does not need to add param details. It doesn't add beyond schema, which is adequate meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific section from a documentation file by its header,' specifying the verb 'Get,' resource 'section,' and qualification 'by its header.' It distinguishes from siblings like get_doc (whole doc) and list_sections (list headers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use after list_sections() shows available headers, or after resolve_topic() / search_docs() identifies the relevant file.' Provides clear context and mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Pine Script v6 documentation files with descriptions.
Returns files organised by category with descriptions. For small files use get_doc(path). For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) use list_sections(path) then get_section(path, header).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that it returns files organized by category, which is useful context. No contradictions or missing behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. Every sentence adds value: first states the purpose, second provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, but the description adequately describes the output (files with descriptions organized by category). The sibling tools and usage guidelines provide full context for the user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so schema coverage is 100%. The description does not need to add parameter details. A baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available Pine Script v6 documentation files with descriptions, organized by category. This is a specific verb+resource, and it distinguishes from siblings like get_doc (single file) and list_sections (sections within a file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to list all files) and when to use alternatives: for small files use get_doc, for large files use list_sections then get_section. It even names the specific large files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available prompts.
Returns JSON with prompt metadata including name, description, and optional arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the tool returns JSON metadata, which is useful, but it does not explicitly state that this is a read-only operation with no side effects, nor does it mention any limitations like pagination. For a simple list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences: the first delivers the primary action, the second clarifies the return format. Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an existing output schema, the description covers the essential purpose and return type. It is complete, but could be slightly more helpful by explicitly connecting to get_prompt for retrieving specific prompts, which would aid discoverability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meaning. The description adds a small amount of value by mentioning that the output includes 'optional arguments', but per the guideline, 0 params warrants a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all available prompts'), making the purpose unambiguous. It also distinguishes from siblings like list_resources by specifying prompts, and from get_prompt by listing rather than retrieving a specific prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to enumerate all available prompts. It does not explicitly mention alternatives or exclusions, but the context is clear for a list operation with no parameters. A brief note on using it before get_prompt would elevate this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all section headers in a doc file. Use before get_section() to find the right header.
Especially useful for large files like ta.md, strategy.md, collections.md, drawing.md, general.md which have 50-115 sections each.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation file path (e.g., "reference/functions/ta.md") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so description doesn't need to repeat. It adds useful context about file sizes and specific files, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first states purpose and usage, second provides context. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers purpose, usage, and practical examples. No output schema needed given the straightforward return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the single parameter 'path' (100% coverage). Description adds no additional meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all section headers in a doc file' using a specific verb and resource. It distinguishes itself from sibling tools by noting it should be used before get_section().
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use before get_section() to find the right header' and provides concrete examples of when it's especially useful (large files like ta.md, strategy.md).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast lookup for exact Pine Script API terms and known concepts.
Use for exact function names and Pine Script vocabulary (e.g., "ta.rsi", "strategy.entry", "repainting", "request.security").
For natural language questions, read the docs://manifest resource for routing guidance, then use get_doc() or list_sections() + get_section().
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exact Pine Script term or known concept keyword. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that it is a 'fast lookup,' giving context on performance. No contradiction. Additional behavioral details like return format or error handling are not needed given the simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no extraneous information. Purpose is stated first, followed by usage examples and routing guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required param, clear annotations, output schema exists), the description is complete. It covers purpose, usage boundaries, and alternatives, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description. Description reinforces the parameter's purpose and provides examples, adding value beyond the schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a fast lookup for exact Pine Script API terms and known concepts, with specific examples. It distinguishes from sibling tools by specifying that for natural language questions, other tools like get_doc or list_sections should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (exact function names and Pine Script vocabulary) and when not to use (natural language questions), providing direct guidance to route to other tools like get_doc or list_sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Pine Script v6 documentation and return matching sections.
Finds sections containing the query and returns previews with get_section() call hints so you can read the full content.
Multi-word queries use AND logic: all terms must appear in the section (not necessarily on the same line).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms (case-insensitive). Multi-word queries match sections containing ALL terms. | |
| max_results | No | Maximum sections to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior. The description adds value by explaining that results are previews with hints to read full content via get_section(), and that query terms must all appear in a section. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Each sentence adds essential information: purpose, result structure, and query behavior. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a good overview of behavior and result format, but lacks explicit details on the structure of previews or call hints (no output schema). It is nearly complete for a search tool but could be slightly more precise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description repeats the AND logic already in the query parameter description and does not add new meaning. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Pine Script v6 documentation and returns matching sections. It uses specific verbs ('Search', 'return') and identifies the resource ('Pine Script v6 documentation'). It distinguishes from siblings like 'get_section' and 'get_doc' by focusing on search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit query syntax guidance ('Multi-word queries use AND logic') and hints for further action ('get_section() call hints'). However, it does not explicitly state when to use this tool versus alternatives (e.g., 'get_section' for a specific section), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a Pine Script v6 function name is valid.
| Name | Required | Description | Default |
|---|---|---|---|
| fn_name | Yes | Function name to validate (e.g., "ta.sma", "strategy.entry", "plot") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the tool is safe and idempotent. The description adds that it checks validity, but does not elaborate on return format, error cases, or behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that immediately communicates the tool's purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with one parameter and an output schema, the description adequately conveys purpose. Some additional context about valid function name conventions (e.g., must be from Pine Script v6) could enhance completeness, but schema examples mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description of 'fn_name' and examples. The description adds no additional parameter meaning, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a Pine Script v6 function name, using a specific verb ('Check') and resource. This distinguishes it from sibling tools like get_functions (which lists functions) and search_docs (which searches documentation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as get_functions or search_docs. The purpose is self-explanatory, but no exclusions or context for when validation is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.7.5resolve_topic7 fields changedOutput schema / descriptionRemoved value: -"Result of resolving a topic query."Output schema / properties / matchesRemoved value: -{
- "items": {
- "description": "A matched documentation topic.",
- "properties": {
- "matched_keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "path": {
- "type": "string"
- },
- "read_with": {
- "default": [],
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "score": {
- "type": "integer"
- }
- },
- "required": [
- "path",
- "matched_keywords",
- "score"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / queryRemoved value: -{
- "type": "string"
-}Output schema / properties / resultAdded value: +{
+ "type": "string"
+}Output schema / properties / suggestionRemoved value: -{
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "matches",
- "query",
- "suggestion"
-]New value: +[
+ "result"
+]Output schema / x-fastmcp-wrap-resultAdded value: +truevalidate_function8 fields changedOutput schema / descriptionRemoved value: -"Result of validating a Pine Script function name."Output schema / properties / functionRemoved value: -{
- "type": "string"
-}Output schema / properties / resultAdded value: +{
+ "type": "string"
+}Output schema / properties / suggestionRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
-}Output schema / properties / typeRemoved value: -{
- "anyOf": [
- {
- "enum": [
- "namespaced",
- "toplevel"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
-}Output schema / properties / validRemoved value: -{
- "type": "boolean"
-}Output schema / requiredPrevious value: -[
- "valid",
- "type",
- "function"
-]New value: +[
+ "result"
+]Output schema / x-fastmcp-wrap-resultAdded value: +trueget_docget_functionsget_promptget_sectionlist_docslist_promptslist_sectionsresolve_topicsearch_docsvalidate_functionv0.7.4get_docget_functionsget_promptget_sectionlist_docslist_promptslist_sectionsresolve_topicsearch_docsvalidate_functionedit_and_lintget_doc3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum characters to return. Use 30000 for large files to avoid token limits."Input schema / properties / offset / descriptionAdded value: +"Character offset to start reading from (default: 0)"Input schema / properties / path / descriptionAdded value: +"Relative path to the documentation file (e.g., \"reference/functions/ta.md\")"get_functions1 field changedInput schema / properties / namespace / descriptionAdded value: +"Filter by namespace (e.g., \"ta\", \"strategy\", \"request\").\n Empty string returns all functions grouped by namespace."get_section3 fields changedInput schema / properties / header / descriptionAdded value: +"Header text to find (e.g., \"strategy.exit()\" or \"## strategy.exit()\")"Input schema / properties / include_children / descriptionAdded value: +"Include nested subsections under the header (default: True)"Input schema / properties / path / descriptionAdded value: +"Documentation file path (e.g., \"reference/functions/strategy.md\")"lint_scriptlist_resourceslist_sections1 field changedInput schema / properties / path / descriptionAdded value: +"Documentation file path (e.g., \"reference/functions/ta.md\")"read_resourceresolve_topic1 field changedInput schema / properties / query / descriptionAdded value: +"Exact Pine Script term or known concept keyword."search_docs2 fields changedInput schema / properties / max_results / descriptionAdded value: +"Maximum sections to return (default: 5)"Input schema / properties / query / descriptionAdded value: +"Exact string to search for (case-insensitive)."validate_function1 field changedInput schema / properties / fn_name / descriptionAdded value: +"Function name to validate (e.g., \"ta.sma\", \"strategy.entry\", \"plot\")"v0.6.17edit_and_lintget_docget_functionsget_promptget_sectionlint_scriptlist_docslist_promptslist_resourceslist_sectionsread_resourceresolve_topicsearch_docsvalidate_functionScored across 10 tools
Every tool has a clearly distinct purpose: reading full docs, listing docs/sections/prompts, searching, resolving specific terms, validating function names. No overlap in functionality.
All tools follow a consistent verb_noun snake_case pattern (e.g., get_doc, list_sections, validate_function). No mixing of conventions.
With 10 tools, the server is well-scoped for its documentation purpose. Covers browsing, reading, searching, and utility without being excessive or insufficient.
The tool surface covers all major documentation needs: listing, reading, searching, and validating. There are no obvious gaps for a Pine Script docs server.
LuxAlgo Library — the encyclopedia of trading & technical analysis for AI agents. Free, keyless.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
