Pine Script
Server Details
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 references- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama 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.
Tool Definition Quality
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.
Available Tools
10 toolsget_docARead-onlyIdempotentInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safety (readOnlyHint, idempotentHint). Description adds valuable behavioral context: pagination header behavior, continuation instruction, and data source. No contradiction.
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?
Four sentences, each necessary: usage condition, output behavior, continuation, alternative for large files, data source. Front-loaded with core purpose.
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?
Despite no output schema, description fully covers pagination, large file alternatives, and data source. Agent has enough context to use tool effectively.
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 3. Description adds concrete usage hints (e.g., 'Use 30000 for large files', explains offset mechanism) that enhance parameter understanding beyond 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?
Description clearly states tool reads full content of a Pine Script v6 documentation file, with specific verb 'reading' and resource. Distinguishes from siblings by naming alternative tools for large files.
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 (reading full content) and when not (for large files, prefer list_sections+get_section). Provides pagination guidance with offset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_functionsARead-onlyIdempotentInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context beyond annotations by explaining that data is sourced from a bundled JSON file, and that it returns function names grouped by namespace. No contradictions.
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 (four sentences) and front-loaded with the use case. Every sentence adds value: usage condition, return format, follow-up suggestions, and data source. No wasted 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?
Given the tool's simplicity (one optional parameter, read-only, no output schema), the description covers all necessary aspects: what it does, what it returns, how to use it, and how it fits with sibling tools. It is complete enough for an 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?
Schema coverage is 100% with the parameter already well-described ('Filter by namespace...'). The description reinforces the parameter's purpose but adds no new semantic information beyond 'optionally filtered to a namespace' which is already implied by the schema's default and description.
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 is for browsing valid Pine Script v6 functions, optionally filtered by namespace. It uses specific verbs and resources, and distinguishes from siblings like validate_function and get_section by positioning itself as the initial browsing step.
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 states 'USE WHEN browsing valid Pine Script v6 functions' and provides follow-up tool suggestions (validate_function, get_section), giving clear context for when to use this tool versus alternatives. However, it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_promptAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the burden is on the description. It explains the return format ('rendered prompt as JSON with a messages array') and how to provide arguments ('dict mapping argument names to values'). No mention of errors or permissions, but adequate for a read operation.
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, front-loaded with the main purpose. Every sentence adds value without repetition.
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 presence of an output schema, the description does not need to detail return values. It covers purpose, parameters, and behavior sufficiently. Could briefly mention that it's for rendering prompts, but not required.
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 baseline is 3. The description adds value by explaining arguments as a 'dict mapping argument names to values,' which is more specific than the schema's 'Optional arguments for the prompt'.
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 prompt by name with optional arguments,' which is a specific verb+resource combination. It distinguishes from sibling tools like list_prompts (which lists all) and get_functions (different resource).
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: use this tool to retrieve a specific prompt by name, while list_prompts lists all. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sectionARead-onlyIdempotentInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by specifying that the tool returns section content from the matched header to the next same-level header, along with file path and line range. It also mentions the data source ('bundled Pine Script v6 documentation'), which provides context 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?
The description is four sentences long, with the key action stated upfront ('USE WHEN reading...'). It is dense but not verbose; each sentence adds value. While it could be slightly more compact, it remains clear 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 3 parameters, no output schema, and presence of sibling tools, the description adequately covers the tool's purpose, usage, return value format, and follow-up steps. It does not detail the exact output structure (e.g., JSON fields), but the mention of 'section content, file path, and line range' provides sufficient context for an agent.
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 description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions (e.g., 'path' and 'header' are already well-described in the schema). The usage hint about 'child header' is a flow suggestion, not semantic enrichment.
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 starts with 'USE WHEN reading a specific named section from a Pine Script v6 documentation file,' which clearly identifies the verb ('reading') and resource (specific named section). It distinguishes from sibling tools like list_sections (which lists all sections) by specifying that this tool retrieves a single 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?
The description explicitly states when to use the tool ('USE WHEN reading a specific named section') and provides follow-up guidance: call list_sections if the header is not found, or call get_section again with a child header. While it doesn't enumerate all sibling alternatives, the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_docsARead-onlyIdempotentInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint; description adds that output is categorised paths with descriptions and notes the data source (bundled docs). No contradictions; behavior is clear.
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—first states purpose, second describes output, third gives actionable follow-up with specific file examples. No extraneous text; highly efficient.
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 no parameters and no output schema, description fully covers purpose, usage context, and post-call guidance. Annotations cover safety; description adds value for effective tool selection.
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 has no parameters (100% coverage), so description doesn't need to add parameter details. It correctly omits param info, which 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?
Description clearly states it returns a categorised list of doc file paths with one-line descriptions for Pine Script v6 documentation, distinguishing it from siblings like get_doc and list_sections which have different purposes.
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 usage condition ('USE WHEN discovering what documentation is available') and provides clear follow-up steps: call get_doc for small files or list_sections then get_section for large files, listing 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_promptsAInspect
List all available prompts.
Returns JSON with prompt metadata including name, description, and optional arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says it returns JSON with metadata. Doesn't disclose any behavioral traits like rate limits, pagination, or safety, so it falls short.
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?
Description is two sentences, efficient and front-loaded. Could be slightly more concise but overall good.
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 (though not shown), the description explains return value. For a parameterless list tool, it is adequately 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?
No parameters in the schema, so baseline score is 4. Description does not need to add parameter info since there are none.
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 prompts, which is specific and distinguishes it from sibling tools like get_prompt (single prompt) and list_docs (lists documents).
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?
No guidance on when to use this tool versus alternatives like get_prompt or search_docs. Agent lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sectionsARead-onlyIdempotentInspect
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'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond the readOnlyHint and idempotentHint annotations: describes the output format (newline-separated), the header level filter (excludes ###), and the data source (bundled Pine Script v6 documentation). No contradictions.
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?
Four sentences, front-loaded with usage context, no unnecessary words or repetition. 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?
Given the tool's simplicity (one parameter, no output schema, rich annotations), the description completely covers purpose, usage, output format, and relation to sibling. 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 already provides a clear description for the single path parameter (including an example). The description does not add further meaning about the parameter beyond the schema, so 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?
Clearly states the tool returns a newline-separated list of # and ## headers from a documentation file, specifies the exclusion of ### headers, and explicitly distinguishes its purpose from the sibling get_section tool by stating to call this before reading a specific 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?
Provides explicit usage context ('USE WHEN navigating a large documentation file before reading a specific section') and a clear follow-up action ('AFTER calling this tool, call get_section...'). Lacks negative guidance, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_topicARead-onlyIdempotentInspect
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'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds data source information (TOPIC_MAP and doc scan) and describes return content (matched keywords, retrieval suggestion). This adds useful context without contradicting 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 and structured: starting with usage condition, then output, then follow-up instructions. Minor redundancy in 'USE WHEN' and 'AFTER calling' could be tighter, but overall efficient.
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 existence of an output schema (not shown), the description covers all needed contextual information: usage, input, output summary, next steps, and data sources. 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 good description for the query parameter. The description does not add additional semantic meaning beyond the schema's, so 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 uses specific verbs (looking up, returns) and identifies the resource (exact Pine Script term or concept keyword). It distinguishes from sibling search_docs by specifying 'exact' vs 'natural language'.
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 WHEN looking up exact term') and when not to ('For natural language questions use search_docs() instead'). It also provides a clear follow-up procedure (call get_doc or list_sections + get_section) based on file size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsARead-onlyIdempotentInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so safety is clear. The description adds behavioral details: returns sections ranked by match count, each with a preview and a get_section() call hint, and specifies data source. Some implicit details (like alphabetical ordering) are missing, but overall good.
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?
Four sentences, front-loaded with the most important usage guidance. No fluff or 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 search tool with 2 parameters and no output schema, the description explains the return format (ranked sections with previews and call hints) and provides post-invocation guidance. Sufficient for an agent to use 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?
Schema has 100% description coverage, so the description adds minimal new info. It reinforces case-insensitive and multi-word matching, which is already in schema. 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 opens with 'USE WHEN finding documentation sections that match specific terms across all Pine Script v6 docs' which is a specific verb+resource combo. It clearly distinguishes from sibling tools like get_section (which retrieves a specific section) by focusing on search across all docs.
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?
Explicit 'USE WHEN' condition is provided, and the description instructs to 'call get_section(file, header) for each result you want to read in full.' This tells the agent when to use this tool vs alternatives and what to do after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_functionARead-onlyIdempotentInspect
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'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds value by detailing what the tool returns (verdict with namespace suggestions or replacement hints) and the data source (bundled pine_v6_functions.json). No contradictions found.
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 with 4 sentences, each earning its place: imperative usage, return behavior, follow-up recommendation, and data source. 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?
Given the single parameter, existing output schema, and the annotations, the description is complete. It covers purpose, usage, return value, and next steps, leaving no significant gaps for the agent.
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 description coverage is 100% with a clear example for fn_name. The tool description does not add additional semantic meaning beyond what the schema already provides. 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 explicitly states 'USE WHEN confirming a Pine Script v6 function name is valid before using it in code.' It identifies the specific verb (validate) and resource (function name), clearly distinguishing it from sibling tools like get_functions which list valid functions.
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 with 'USE WHEN' and specifies a follow-up action: 'AFTER calling this tool, call get_functions(namespace) to list all valid functions in the relevant namespace if the function is invalid.' This clearly tells when to use the tool and what to do next.
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.
Discussions
No comments yet. Be the first to start the discussion!