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 "Install 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?
Despite no annotations, the description discloses return format (JSON with messages array) and argument structure (dict mapping names to values). Lacks details on error handling, safety (read-only), or missing names, but provides core behavioral context.
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 fluff, front-loaded with purpose, then return format and argument structure. Every sentence earns its place.
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?
With an output schema present, the description covers input and output adequately. However, it omits potential error cases (e.g., missing name) and does not connect to siblings like list_prompts for discoverability. Overall sufficient for a simple retrieval tool.
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 parameter descriptions. The description reinforces that arguments should be a dict, adding minimal value beyond the schema. The mention of 'rendered prompt' relates to output, not parameters.
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 'Get a prompt by name' and mentions optional arguments. It distinguishes from siblings implicitly (e.g., get_doc retrieves documents, list_prompts lists all prompts), but does not explicitly differentiate.
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?
Implied usage for retrieving a specific prompt by name, but no explicit guidance on when to use this tool versus alternatives like list_prompts or other get_ tools. No exclusions or prerequisites mentioned.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns JSON with prompt metadata, but it does not state whether the operation is read-only, any authentication requirements, or potential side effects. Given that this is a list operation, more transparency about rate limits or pagination would be helpful.
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 with no extraneous information. It is well front-loaded and every sentence adds value.
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 list tool with no parameters and an output schema, the description is mostly complete. However, it could mention if there is any implicit filtering (e.g., all prompts in the workspace) or refer to the output schema for more detail, since output schema exists but is not referenced.
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 zero parameters, so description does not need to add parameter details. According to guidelines, with 0 params the baseline is 4, and the description is adequate in this regard.
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 available prompts' which is a specific verb and resource, and it distinguishes from sibling tools like 'get_prompt' (which retrieves a single prompt) and other list tools (list_docs, list_sections).
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 usage by stating it lists all prompts, but it does not provide explicit guidance on when to use this tool vs alternatives, such as 'get_prompt' for a specific prompt or 'search_docs' for searching within prompts. No exclusions or context are provided.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulieb89/pinescript-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
