Skip to main content
Glama
seohyunjun

OpenSearch MCP Server

by seohyunjun

generate_discover_url

Create OpenSearch Dashboards Discover URLs to visualize and analyze indexed data based on specific queries, time ranges, and index patterns.

Instructions

Generate OpenSearch Dashboards Discover view URL

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
index_pattern_idYes
from_timeYes
to_timeYes

Implementation Reference

  • The handler function for the 'generate_discover_url' tool. It constructs an OpenSearch Dashboards Discover URL using the provided query, index_pattern_id, from_time, and to_time parameters, encoding them into rison format query params.
    @mcp.tool(description="Generate OpenSearch Dashboards Discover view URL")
    async def generate_discover_url(query: str, index_pattern_id: str, from_time: str, to_time: str) -> list[TextContent]:
        """
        Generate a URL for the OpenSearch Dashboards Discover view that will display the results of a query.
        The argument values must be compatible with the rison data format used by OpenSearch Dashboards.
        Use the list index patterns tool to determine the available index pattern IDs. 
        Index_pattern_id argument must be the ID of the index pattern to be used.
        The query arguement must be a valid OpenSearch lucene format.
        Refrain from using querying the timestamp or @timestamp fields in the query. Use from_time and to_time parameters instead
        The function constructs a URL that includes the query and index pattern as parameters.
    
        Args:
        query str: The query to apply in the Discover view in lucene format.
        index_pattern_id str: The index pattern ID to use in the Discover view URL.
        from_time str: The starting time for the query in the format like `now-15m`.
        to_time str: The ending time for the query in the format like `now`.
    
        Returns:
        list[TextContent]: A list containing the generated URL or an error message.
        """
        self.logger.info("Generating Discover view URL")
        config = self._get_es_config()
        try:
            base_url = config["dashboards_host"] + "/app/data-explorer/discover#?" #"http[s]://host[:port]/app/data-explorer/discover#? + query_params"
            query_params = {
                "_g": "(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:'"+from_time+"',to:'"+to_time+"'))",
                "_q": "(filters:!(),query:(language:lucene,query:\'"+query+"\'))",
                "_a": "(discover:(columns:!(_source),isDirty:!f,sort:!()),metadata:(indexPattern:\'"+index_pattern_id+"\',view:discover))"   
            }
            url = base_url + urlencode(query_params, safe="(),:")
            return [TextContent(type="text", text=url)]
            
        except Exception as e:
            self.logger.error(f"Error generating Discover view URL: {e}")
            return [TextContent(type="text", text=f"Error: {str(e)}")]
  • Registers the DashboardTools instance by calling its register_tools method on the MCP server instance. This indirectly registers the 'generate_discover_url' tool along with other dashboard tools.
    index_tools = IndexTools(self.logger)
    document_tools = DocumentTools(self.logger)
    cluster_tools = ClusterTools(self.logger)
    dashboard_tools = DashboardTools(self.logger)
    admin_index_tools = AdminIndexTools(self.logger)
    admin_cluster_tools = AdminClusterTools(self.logger)
    
    # Register tools from each module
    index_tools.register_tools(self.mcp)
    document_tools.register_tools(self.mcp)
    cluster_tools.register_tools(self.mcp)
    dashboard_tools.register_tools(self.mcp)
    admin_index_tools.register_tools(self.mcp)
    admin_cluster_tools.register_tools(self.mcp)
  • Imports the DashboardTools class which contains the generate_discover_url tool implementation.
    from .tools.dashboards import DashboardTools
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does (generates a URL) without revealing any behavioral traits: it doesn't mention whether this requires authentication, has rate limits, returns a permanent or temporary URL, or what format the URL follows. This is inadequate for a tool with 4 required parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool that generates URLs, though the brevity comes at the cost of missing important contextual information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 required parameters, no annotations, no output schema), the description is severely incomplete. It doesn't explain what the tool returns (just a URL string? with what properties?), how parameters interact, or any error conditions. For a URL generation tool with multiple time and query parameters, this leaves too many questions unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description provides absolutely no information about what the parameters mean, their expected formats, or how they influence the generated URL. For example, it doesn't explain what 'query' should contain or how 'from_time' and 'to_time' should be formatted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Generate' and the resource 'OpenSearch Dashboards Discover view URL', making the purpose specific and understandable. However, it doesn't distinguish this tool from its siblings (which are primarily query/retrieval tools), missing the opportunity to clarify that this generates URLs rather than performing data operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include 'search_documents' and 'list_indices', there's no indication whether this URL generation is for visualization purposes, sharing links, or integration with other systems. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seohyunjun/opensearch-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server