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 referencesGlama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: get_doc reads full files, get_section reads specific sections, list_docs and list_sections provide navigation, search_docs and resolve_topic offer different search methods, get_functions and validate_function handle function lookup, and get_prompt/list_prompts cover prompts. No two tools overlap in functionality.
All tool names follow the verb_noun pattern consistently (e.g., get_doc, list_sections, search_docs). The naming convention is uniform with lowercase and underscores, making it predictable and easy for an agent to infer behavior.
With 10 tools, the count is well-scoped for a documentation and function lookup server. It provides sufficient coverage without being overwhelming, fitting within the ideal range of 3-15 tools.
The tool surface comprehensively covers documentation discovery, reading, searching, navigation, and function validation. There are no obvious gaps for the stated purpose of accessing Pine Script v6 documentation and functions.
get_docAUSE 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.
get_functionsAUSE 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_promptAInspectGet 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 burden of disclosing behavior. It does mention the return format ('Returns the rendered prompt as JSON with a messages array') and how arguments should be passed, offering some transparency. However, it does not explicitly state that the operation is read-only, what happens if the prompt does not exist, or any permission requirements. The information given is useful but incomplete for full behavioral transparency.
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 consists of three short, front-loaded sentences. The first sentence immediately states the core action and resource, the second clarifies the output structure, and the third clarifies argument formatting. Every sentence contributes meaningful information without any redundant or filler content.
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 (2 parameters, no nested objects), the presence of an output schema, and 100% schema parameter coverage, the description provides sufficient information for an agent to select and invoke the tool. It covers the input (prompt name and optional arguments) and output (JSON with messages array). It does not address error cases like missing prompts, but this is a minor gap for such a straightforward getter 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?
The input schema already provides complete descriptions for both parameters (name and arguments), achieving 100% schema description coverage. The description adds a marginal clarification that arguments must be a dict mapping names to values, but this is already implied by the schema's object type with additionalProperties. Thus, the description adds limited value beyond the schema, warranting the baseline score of 3.
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: 'Get a prompt by name with optional arguments.' This uses a specific verb and resource, and distinguishes it from siblings like get_doc or get_section by referencing 'prompt.' It also specifies the output format ('rendered prompt as JSON with a messages array'), leaving no ambiguity about what the tool does.
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 when you have a prompt name and want the rendered output, but it does not provide explicit guidance on when to use this tool versus alternatives like list_prompts or get_section. There are no exclusions or direct comparisons, so the usage context remains implied rather than clearly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sectionAUSE 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.
list_docsAUSE 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_promptsAInspectList 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, the description carries the full burden. It discloses the return format (JSON with prompt metadata) and scope ('all available prompts'), which are useful behavioral details. It does not mention side effects or limitations, but for a simple list 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 consists of two concise, front-loaded sentences. The first states the core action, and the second adds relevant output details. No redundant or filler language.
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 no-parameter list tool with an output schema, the description is sufficient. It clarifies that the tool returns metadata, not full prompt content, and uses 'all available prompts' to set scope. It lacks explicit relation to siblings but is complete for the tool's simplicity.
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, and the schema covers 100% of the (empty) parameter space. Per the rubric, the baseline for zero params is 4, and the description adds no parameter-specific information since there is none to add.
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 lists all available prompts, distinguishing it from siblings like get_prompt (which retrieves a specific prompt) and list_docs/list_sections (which list other resources). The verb 'list' and resource 'prompts' are 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 states what the tool does but provides no explicit guidance on when to use it versus alternatives like get_prompt. No alternatives are mentioned, nor any exclusions or prerequisites, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sectionsAUSE 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.
resolve_topicAUSE 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.
search_docsAUSE 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.
validate_functionAUSE 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
