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.3/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Each tool targets a distinct action (getting whole files, sections, functions, prompts, or listing/searching) with minimal overlap. Descriptions clearly differentiate granularity and use cases, e.g., get_doc vs get_section vs get_functions.
All tool names follow a consistent verb_noun pattern in snake_case (get_, list_, search_, resolve_, validate_). No mixed conventions or irregular names.
10 tools cover a narrow but deep domain of documentation access. Each tool serves a unique purpose without redundancy, and the count feels well-scoped for the server's purpose.
The tool surface covers listing, searching, reading full files, reading sections, validating functions, and fast term lookup. Minor gap: no tool for fetching function signatures directly, but get_section can handle it if docs are structured.
Available Tools
10 toolsget_docARead-onlyIdempotentInspect
Read a specific Pine Script v6 documentation file.
For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) prefer list_sections() + get_section() to avoid loading 1000-2800 line files into context.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative path to the documentation file (e.g., "reference/functions/ta.md") | |
| limit | No | Maximum characters to return. Use 30000 for large files to avoid token limits. | |
| offset | No | Character offset to start reading from (default: 0) |
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 context about potential large file sizes and suggests limits, which is useful beyond annotations, though it doesn't detail error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second provides critical usage guidance. No wasted words, front-loaded, and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could explain return format, but the action 'Read' implies file content. All parameters are documented, and annotations cover safety. Minor gap on error handling, but sufficient for a simple read operation.
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 value by suggesting a specific limit value (30000) for large files, enhancing parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific Pine Script v6 documentation file. It distinguishes from siblings like list_docs and get_section by specifying the action and 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?
Explicitly advises against using this tool for large files and recommends alternative tools (list_sections + get_section), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_functionsARead-onlyIdempotentInspect
Get valid Pine Script v6 functions, optionally filtered by namespace.
Use before writing Pine Script to see which functions exist. For checking a single function name, use validate_function() instead.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Filter by namespace (e.g., "ta", "strategy", "request"). Empty string returns all functions grouped by namespace. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe, idempotent operation. The description adds no further behavioral details beyond 'valid functions', so it does not significantly enhance transparency beyond 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?
Two concise sentences: first states purpose and optional filter, second gives usage context and sibling alternative. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and strong annotations, the description covers purpose, usage timing, and alternative. No output schema needed; return values are self-evident. Complete for its complexity.
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%, and the description merely restates the schema's info about namespace filtering and empty string behavior. No new parameter semantics are added beyond what the schema already provides.
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 gets 'valid Pine Script v6 functions' with optional namespace filtering. It distinguishes from sibling 'validate_function' by specifying that for a single function name, one should use the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before writing Pine Script to see which functions exist' and gives an alternative for single function name validation, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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
Get a specific section from a documentation file by its header.
Use after list_sections() shows available headers, or after resolve_topic() / search_docs() identifies the relevant file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation file path (e.g., "reference/functions/strategy.md") | |
| header | Yes | Header text to find (e.g., "strategy.exit()" or "## strategy.exit()") | |
| include_children | No | Include nested subsections under the header (default: True) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety. It adds usage pattern context but no additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and immediate usage guidance. No redundant words; every sentence serves a clear function.
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 well-documented schema, the description covers purpose and usage. However, it does not mention what the function returns (e.g., section content), leaving a minor gap in completeness.
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 with clear descriptions for each parameter. The description does not add semantic detail beyond what the schema provides, 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 clearly states the verb ('Get'), resource ('section'), and method ('by its header'). It also distinguishes from siblings like get_doc (whole document) and list_sections (list only).
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 context on when to use this tool: after list_sections() or after resolve_topic()/search_docs(). It suggests alternatives but does not 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.
list_docsARead-onlyIdempotentInspect
List all available Pine Script v6 documentation files with descriptions.
Returns files organised by category with descriptions. For small files use get_doc(path). For large files (ta.md, strategy.md, collections.md, drawing.md, general.md) use list_sections(path) then get_section(path, header).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds that files are returned 'organised by category with descriptions,' which provides additional behavioral context beyond annotations. 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 three sentences, each serving a purpose: primary action, return format, and usage guidelines. It is front-loaded and concise with 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 no parameters, no output schema, and annotations indicating safe operation, the description is complete. It explains the return format (organised by category) and provides guidance on when to use sibling tools for content retrieval.
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?
With 0 parameters and schema coverage 100%, the baseline is 4. The 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 'List all available Pine Script v6 documentation files with descriptions,' specifying a specific verb (list) and resource (documentation files). It distinguishes itself from siblings like get_doc and list_sections by providing guidance on when to use them.
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 provides when to use alternatives: 'For small files use get_doc(path). For large files use list_sections(path) then get_section(path, header).' This gives clear context for usage vs siblings.
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
List all section headers in a doc file. Use before get_section() to find the right header.
Especially useful for large files like ta.md, strategy.md, collections.md, drawing.md, general.md which have 50-115 sections each.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation file path (e.g., "reference/functions/ta.md") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description doesn't need to repeat them. It adds context about large files but no further behavioral details. Adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, followed by usage guidance and examples. 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?
For a simple list tool with one parameter and no output schema, the description covers purpose, usage, and relevant file examples. It does not describe the return format, but the tool name implies it returns section headers, so sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter. The description does not add additional meaning beyond what the schema already provides, 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 clearly states the tool lists section headers in a doc file, with a specific verb and resource. It also distinguishes itself from the sibling tool get_section by indicating its use before retrieving 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?
Explicitly states to use before get_section() to find the right header, and provides context about large files where it is especially useful. No explicit when-not-to-use, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_topicARead-onlyIdempotentInspect
Fast lookup for exact Pine Script API terms and known concepts.
Use for exact function names and Pine Script vocabulary (e.g., "ta.rsi", "strategy.entry", "repainting", "request.security").
For natural language questions, read the docs://manifest resource for routing guidance, then use get_doc() or list_sections() + get_section().
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exact Pine Script term or known concept keyword. |
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 state readOnlyHint=true and idempotentHint=true. Description adds context that it is 'fast lookup', implying quick response, but no behavioral contradictions. Additional detail is helpful but not essential 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?
Three sentences, each purposeful: purpose, examples, alternatives. No fluff, front-loaded, easy to scan.
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?
Complete for a simple tool with one parameter and output schema. Covers what, when, and how to use, plus guidance for alternatives. No missing information.
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% coverage with description 'Exact Pine Script term or known concept keyword.' Description repeats similar phrasing. No additional meaning added beyond schema, baseline 3 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 purpose: fast lookup for exact Pine Script API terms. Uses specific verbs ('lookup') and provides examples like 'ta.rsi' and 'strategy.entry', distinguishing it from sibling tools like get_doc().
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 specifies when to use: 'for exact function names and Pine Script vocabulary'. Also provides when-not-to-use guidance: for natural language questions, consult docs manifest and use get_doc() or list_sections()+get_section().
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsARead-onlyIdempotentInspect
Search Pine Script v6 documentation and return matching sections.
Finds sections containing the query and returns previews with get_section() call hints so you can read the full content.
Multi-word queries use AND logic: all terms must appear in the section (not necessarily on the same line).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms (case-insensitive). Multi-word queries match sections containing ALL terms. | |
| max_results | No | Maximum sections to return (default: 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: multi-word queries use AND logic, results are section previews with get_section() hints, and the search is case-insensitive. This is valuable for an agent to understand exactly how the tool behaves, and it does not contradict any annotation.
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, and every sentence adds value. There is no redundancy or wasted words, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, complete annotations), the description fully explains its functionality: what it searches, how queries work, what results look like (previews with call hints), and how to get full sections. It is a complete and self-contained description 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?
The input schema covers 100% of parameters and already describes query case-insensitivity and AND logic. The description's mention of these features adds little new meaning beyond the schema. It provides context for the overall purpose but not significant parametric detail beyond what is already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Pine Script v6 documentation and returns matching sections. It specifies the verb 'search' and the resource 'documentation', and distinguishes itself from siblings like 'get_section' and 'list_sections' by focusing on query-based retrieval with previews and call hints.
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 clear context for when to use this tool (to find documentation sections via query) and explains query logic (AND for multi-word). However, it does not explicitly state when not to use it or mention alternatives like 'get_section' for known IDs, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_functionARead-onlyIdempotentInspect
Check if a Pine Script v6 function name is valid.
| Name | Required | Description | Default |
|---|---|---|---|
| fn_name | Yes | Function name to validate (e.g., "ta.sma", "strategy.entry", "plot") |
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=true and idempotentHint=true, so description adds minimal behavioral context beyond the action being a check. No mention of return format, but output schema exists.
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?
Single sentence, no fluff, directly delivers the purpose. Front-loaded and 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 tool has one parameter, full annotations, and an output schema, the description completes the picture concisely. No missing information for this straightforward validation.
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% for the single parameter. Description adds examples ('ta.sma', 'strategy.entry', 'plot'), providing practical usage context beyond the schema's parameter 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?
Description clearly specifies the action ('Check') and resource ('Pine Script v6 function name'). It distinguishes from siblings like 'get_functions' which list functions, making validation purpose explicit.
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?
Description implies usage for validating function names before use, but lacks explicit guidance on when to use this tool versus alternatives like 'get_functions' or when not to use.
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!