MCP server providing Pine Script v6 documentation.
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 referencesScored across 10 tools
Most tools have clearly distinct purposes (reading docs vs. listing sections vs. validating functions). However, resolve_topic and search_docs both return doc references with slightly different query styles, which could cause minor confusion. Overall the descriptions sufficiently delineate each tool's role.
All tools follow a consistent snake_case verb_noun pattern (list_docs, get_section, validate_function, etc.). The naming convention is uniformly applied and predictable.
With 10 tools, the server is well-scoped for a documentation and function-lookup service. Each tool fills a clear niche without redundancy, and the count fits comfortably within the ideal range.
The tool set covers the full documentation workflow: discovery, navigation, targeted lookup, full-text search, and function validation. There are no obvious dead ends or missing operations for the stated purpose of browsing Pine Script v6 docs.
USE WHEN reading the full content of a Pine Script v6 documentation file. Returns the file content; when limit is set, a header shows the char range and offset to continue reading. AFTER calling this tool, use offset= to continue if the header indicates more content is available. For large files (ta.md, strategy.md, collections.md, drawing.md, general.md), prefer list_sections() + get_section() instead. Data sourced from bundled Pine Script v6 documentation.
| 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. 0 = no limit. | |
| offset | No | Character offset to start reading from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds useful behavior: when limit is set, a header shows the char range and offset to continue reading, and it clarifies data source. Some detail about return format/errors is absent, but the added context is valuable.
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 compact and front-loaded with a clear conditional ('USE WHEN'). Three sentences cover purpose, continuation behavior, and alternative strategy without waste. Every sentence contributes new 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 file-read tool with no output schema, the description provides essential context: return behavior, chunked reading, large-file alternative, and data source. It lacks explicit error-handling notes, but the guidance is sufficient for reliable invocation.
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%, so baseline is 3. The description adds semantics beyond the schema by explaining the interplay of limit and offset ('use offset=<end> to continue'), which helps the agent understand how to handle pagination. It also mentions the large-file threshold implicitly. This lifts it above 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's purpose: reading the full content of a Pine Script v6 documentation file. It specifies a distinct resource (documentation files) and implies differentiation from sibling tools like get_section and list_sections by focusing on full-file content.
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 provides usage context: 'USE WHEN reading the full content' and gives an alternative strategy for large files, recommending list_sections() + get_section() instead. It also instructs on chaining reads with offset=<end> to continue, which is actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE WHEN browsing valid Pine Script v6 functions, optionally filtered to a namespace. Returns function names grouped by namespace (e.g. ta., strategy.) or filtered to the requested namespace. AFTER calling this tool, call validate_function(fn_name) to check a specific name, or get_section() to read its documentation. Data sourced from bundled pine_v6_functions.json.
| 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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds that data is sourced from a bundled JSON file and that results are grouped by namespace. It also clarifies that only function names are returned, not documentation. This provides useful context without contradicting the 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 concise, consisting of three sentences that front-load the purpose ('USE WHEN'), then describe the return behavior, and end with next-step actions. Each sentence provides distinct value with no unnecessary 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 simple read-only tool with one optional parameter and no output schema, the description adequately explains the return behavior (function names grouped by namespace), gives examples of namespaces, and provides follow-up actions for obtaining detailed information. It is complete within the context of the toolset.
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 description reinforces that the namespace parameter is optional and filters results, but the input schema already fully describes the parameter, including the empty string behavior. With 100% schema coverage, the description adds little extra meaning beyond what is already 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 that the tool browses valid Pine Script v6 functions and returns function names grouped by namespace, with optional filtering. It distinguishes itself from sibling tools by explicitly instructing the user to call validate_function or get_section afterward, establishing its role as a listing entry point.
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 begins with 'USE WHEN browsing valid Pine Script v6 functions,' giving a clear context for use. It also mentions calling validate_function and get_section as follow-up actions, indicating alternatives for validation and documentation. However, it lacks an explicit 'do not use when' exclusion, so it provides context but not full when-not guidance.
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.
USE WHEN reading a specific named section from a Pine Script v6 documentation file. Returns the section content from the matched header to the next same-level header, with file path and line range. AFTER calling this tool, call list_sections(path) if the header was not found, or get_section() again with a child header for a narrower subsection. Data sourced from bundled Pine Script v6 documentation.
| 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 matched header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral details: it returns content from the matched header to the next same-level header, includes file path and line range, and indicates that data comes from bundled documentation. It also implicitly discloses that the header must be found, as suggested by the follow-up instruction. While it doesn't explicitly state the behavior when a header is not found, the guidance covers it sufficiently.
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 concise, front-loaded with the primary use case, and every sentence earns its place. It includes the purpose, return behavior, follow-up instructions, and data source in just three sentences without redundant information. The structure is logical and easy to parse.
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 moderate complexity, full schema coverage, and helpful annotations, the description is complete. It explains what the tool does, how to use it, what to do if the header isn't found, and where the data comes from. No output schema exists, but the description already conveys the return format. This is sufficient for an agent to select and invoke the tool correctly.
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 provides 100% coverage with clear descriptions for all three parameters (path, header, include_children). The description adds some context around the 'header' parameter by referencing "child header" for narrower subsections, but it does not meaningfully enhance the schema's explanations. Since the schema already does the heavy lifting, a baseline score of 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's purpose: "reading a specific named section from a Pine Script v6 documentation file." It distinguishes from siblings by emphasizing that it reads a named section, contrasting with tools like list_sections or search_docs. The return behavior is also specified (content from matched header to next same-level header, with file path and line range), making the purpose 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 opens with "USE WHEN" to explicitly indicate the appropriate condition for using this tool. It also provides follow-up guidance: call list_sections(path) if the header is not found, or call get_section() again with a child header for a narrower subsection. This gives clear direction on when to use the tool and what to do afterward, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE WHEN discovering what Pine Script v6 documentation is available. Returns a categorised list of doc file paths with one-line descriptions. AFTER calling this tool, call get_doc(path) for small files or list_sections(path) then get_section(path, header) for large files (ta.md, strategy.md, collections.md, drawing.md, general.md). Data sourced from bundled Pine Script v6 documentation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral context: it returns a categorized list, sources data from bundled docs, and implies a non-destructive read operation. No contradictions. Slightly more than baseline but not rich in edge-case disclosures.
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 reasonably concise but carries some redundancy with the 'USE WHEN' framing and the listing of specific file names. However, every sentence provides useful guidance for tool selection and subsequent calls, so it earns its length.
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 parameters, no output schema, but the description fully explains the return format, data source, and offers a clear decision tree for subsequent tool usage. It is complete for the agent to select and invoke correctly.
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?
There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and there is nothing to add beyond the schema. The description effectively communicates that no input is required.
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 returns a categorised list of doc file paths with one-line descriptions, and explicitly frames its use case as discovering available Pine Script v6 documentation. This distinguishes it from sibling tools like get_doc or 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?
Excellent guidance: it says when to use (when discovering available docs) and provides a follow-up workflow (call get_doc for small files, or list_sections then get_section for specific large files). This explicitly names alternatives and directs the agent to the appropriate next steps.
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.
USE WHEN navigating a large documentation file before reading a specific section. Returns a newline-separated list of # and ## headers (### excluded) in the file. AFTER calling this tool, call get_section(path, header) with a header from this list. Data sourced from bundled Pine Script v6 documentation.
| 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral nuance by specifying the output format ('newline-separated') and the exact header levels included/excluded ('# and ## headers (### excluded)'), which is not inferable from annotations or the parameter schema. This goes beyond the baseline, though it doesn't disclose additional side effects or dependencies beyond the documented workflow.
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 compact and front-loaded with the most important usage signal ('USE WHEN'). It contains only three sentences, each serving a distinct purpose: when to use, what it returns, and what to do next. No wasted words or redundancy.
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?
This is a simple one-parameter tool with strong annotations (readOnly, idempotent) and no output schema. The description fully covers the tool's purpose, usage context, output format, and follow-up action. For a tool of this complexity, the description is complete and leaves no critical ambiguity.
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 schema covers the single 'path' parameter with a clear example, achieving 100% coverage. The description adds no new syntax or format details for the parameter itself, but it does show how 'path' is used together with get_section, which provides mild contextual value. Baseline 3 is appropriate given full 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 states a specific action: 'Returns a newline-separated list of # and ## headers (### excluded) in the file.' This clearly identifies the tool as a list operation on headers within a documentation file. It distinguishes from sibling tools by explicitly framing when to use it (before reading a specific section) and pointing to get_section for subsequent retrieval.
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 usage guidance: 'USE WHEN navigating a large documentation file before reading a specific section.' It also prescribes the next step: 'AFTER calling this tool, call get_section(path, header) with a header from this list.' This clearly tells an agent when to use this tool and how to follow up, differentiating it from alternatives like get_section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE WHEN looking up an exact Pine Script API term or known concept keyword. Returns the best-matching doc paths with matched keywords and a retrieval suggestion (get_doc or list_sections + get_section). AFTER calling this tool, follow the suggestion: call get_doc() for small files or list_sections() + get_section() for large files. For natural language questions use search_docs() instead. Data sourced from bundled TOPIC_MAP and doc file content scan.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exact Pine Script term or known concept keyword (e.g., 'ta.rsi', 'strategy.entry', 'repainting'). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, and the description adds valuable context: the data source (bundled TOPIC_MAP and doc file content scan) and the output shape (best-matching doc paths with matched keywords and a retrieval suggestion). This goes beyond the annotation and clarifies what the tool returns and how it works internally.
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 front-loaded with 'USE WHEN' and packs essential information into four sentences: purpose, output, follow-up guidance, alternative usage, and data source. Every sentence contributes value, with no fluff or redundancy.
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 single-parameter tool with a rich schema and annotations, the description covers purpose, when to use/avoid, output, data source, and next steps. The presence of an output schema means return values need not be detailed further. No significant context is missing.
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 schema already provides 100% coverage for the single query parameter with a description and examples. The tool description reiterates the 'exact term' nature but does not add significant new semantic meaning beyond what the schema already states. 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 resolves exact Pine Script API terms or known concept keywords into matching doc paths and a retrieval suggestion. It distinguishes itself from search_docs (natural language) and get_doc (retrieval), making its specific purpose 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 explicitly says when to use it (exact term lookup) and when not to (natural language questions should use search_docs instead). It also provides a concrete follow-up plan: call get_doc for small files or list_sections + get_section for large files, guiding the agent on the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE WHEN finding documentation sections that match specific terms across all Pine Script v6 docs. Returns up to max_results sections ranked by match count, each with a preview and a get_section() call hint. AFTER calling this tool, call get_section(file, header) for each result you want to read in full. Data sourced from bundled Pine Script v6 documentation.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds behavioral details beyond annotations: returns up to max_results sections ranked by match count, includes previews and get_section() call hints, and mentions the data source. This provides useful context for what to expect from the tool.
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 four sentences, front-loaded with 'USE WHEN', and every sentence earns its place: purpose, return behavior, next-step action, and data source. There is 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's simple interface (two parameters, no output schema), the description is complete: it explains what the search does, what results look like, how to proceed, and where data comes from. The sibling context and annotations further fill in the picture, so nothing critical is missing.
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 meaningful descriptions for both parameters (query and max_results). The description reinforces the behavior of max_results ('Returns up to max_results sections') but does not add substantial new semantic information beyond what the schema already provides. A baseline of 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's function: finding documentation sections matching specific terms across Pine Script v6 docs. The verb 'search' and resource 'docs' are specific, and it distinguishes itself from siblings like get_section (which retrieves a section by file/header) and list_sections (which likely lists all 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 starts with 'USE WHEN', making the intended usage explicit, and provides a clear follow-up: 'call get_section(file, header) for each result you want to read in full.' This gives the agent a concrete workflow and effectively contrasts with the sibling get_section tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE WHEN confirming a Pine Script v6 function name is valid before using it in code. Returns a valid/invalid verdict with namespace suggestions or known replacement hints (e.g. ta.adx → ta.dmi, security → request.security). AFTER calling this tool, call get_functions(namespace) to list all valid functions in the relevant namespace if the function is invalid. Data sourced from bundled pine_v6_functions.json.
| 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 declare readOnlyHint=true and idempotentHint=true, so the description adds value by disclosing the return type (valid/invalid verdict), namespace suggestions, replacement hints, and the data source (bundled pine_v6_functions.json). No contradiction with annotations, though more detail about output structure could be beneficial.
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 concise (two sentences plus a data source note), front-loaded with the key usage directive, and every sentence contributes value. It includes examples and a follow-up instruction without any fluff.
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 tool with a rich output schema and clear annotations, the description covers purpose, usage conditions, follow-up actions, and data provenance. It is fully sufficient for the agent to select and invoke the tool correctly.
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 schema covers the only parameter (fn_name) with a description and examples, so the description does not significantly add meaning beyond what's already in the input schema. The examples in the description overlap with the schema's, providing no new parameter-level information.
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 validates Pine Script v6 function names, using a specific verb ('confirming') and resource. It distinguishes from sibling get_functions by referencing it as a follow-up action, and provides concrete examples (ta.adx → ta.dmi) that illustrate the tool's purpose.
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 begins with 'USE WHEN confirming a Pine Script v6 function name is valid before using it in code,' setting a clear usage condition. It also directs the agent to call get_functions(namespace) if the function is invalid, providing an explicit alternative path and when-not-to-use context.
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.
get_doc5 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum characters to return. Use 30000 for large files to avoid token limits."New value: +"Maximum characters to return. Use 30000 for large files. 0 = no limit."Input schema / properties / limit / minimumAdded value: +0Input schema / properties / offset / descriptionPrevious value: -"Character offset to start reading from (default: 0)"New value: +"Character offset to start reading from."Input schema / properties / offset / minimumAdded value: +0Input schema / properties / path / descriptionPrevious value: -"Relative path to the documentation file (e.g., \"reference/functions/ta.md\")"New value: +"Relative path to the documentation file (e.g., 'reference/functions/ta.md')."get_functions1 field changedInput schema / properties / namespace / descriptionPrevious value: -"Filter by namespace (e.g., \"ta\", \"strategy\", \"request\").\n Empty string returns all functions grouped by namespace."New value: +"Filter by namespace (e.g., 'ta', 'strategy', 'request'). Empty string returns all functions grouped by namespace."get_section3 fields changedInput schema / properties / header / descriptionPrevious value: -"Header text to find (e.g., \"strategy.exit()\" or \"## strategy.exit()\")"New value: +"Header text to find (e.g., 'strategy.exit()' or '## strategy.exit()')."Input schema / properties / include_children / descriptionPrevious value: -"Include nested subsections under the header (default: True)"New value: +"Include nested subsections under the matched header."Input schema / properties / path / descriptionPrevious value: -"Documentation file path (e.g., \"reference/functions/strategy.md\")"New value: +"Documentation file path (e.g., 'reference/functions/strategy.md')."list_sections1 field changedInput schema / properties / path / descriptionPrevious value: -"Documentation file path (e.g., \"reference/functions/ta.md\")"New value: +"Documentation file path (e.g., 'reference/functions/ta.md')."resolve_topic2 fields changedInput schema / properties / query / descriptionPrevious value: -"Exact Pine Script term or known concept keyword."New value: +"Exact Pine Script term or known concept keyword (e.g., 'ta.rsi', 'strategy.entry', 'repainting')."Input schema / properties / query / minLengthAdded value: +1search_docs5 fields changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum sections to return (default: 5)"New value: +"Maximum sections to return."Input schema / properties / max_results / maximumAdded value: +20Input schema / properties / max_results / minimumAdded value: +1Input schema / properties / query / descriptionPrevious value: -"Search terms (case-insensitive). Multi-word queries\n match sections containing ALL terms."New value: +"Search terms (case-insensitive). Multi-word queries match sections containing ALL terms."Input schema / properties / query / minLengthAdded value: +1validate_function2 fields changedInput schema / properties / fn_name / descriptionPrevious value: -"Function name to validate (e.g., \"ta.sma\", \"strategy.entry\", \"plot\")"New value: +"Function name to validate (e.g., 'ta.sma', 'strategy.entry', 'plot')."Input schema / properties / fn_name / minLengthAdded value: +1resolve_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: +truesearch_docs1 field changedInput schema / properties / query / descriptionPrevious value: -"Exact string to search for (case-insensitive)."New value: +"Search terms (case-insensitive). Multi-word queries\n match sections containing ALL terms."get_docget_functionsget_promptget_sectionlist_docslist_promptslist_sectionsresolve_topicsearch_docsvalidate_function
Add one secure layer between your agents and this server.