Skip to main content
Glama

get_queries_with_large_result_count

Identify queries returning the most results from Couchbase's completed_requests catalog to optimize performance and resource usage.

Instructions

Get queries with the largest result counts from the system:completed_requests catalog.

Args:
    limit: Number of queries to return (default: 10)

Returns:
    List of queries with their average result count

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function that implements the tool logic. It constructs and executes a SQL++ query on the system:completed_requests catalog to identify queries with the largest average result counts, returning the results or an empty message.
    def get_queries_with_large_result_count(
        ctx: Context, limit: int = 10
    ) -> list[dict[str, Any]]:
        """Get queries with the largest result counts from the system:completed_requests catalog.
    
        Args:
            limit: Number of queries to return (default: 10)
    
        Returns:
            List of queries with their average result count
        """
        query = """
        SELECT statement,
            avgResultCount,
            COUNT(1) AS queries
        FROM system:completed_requests
        WHERE UPPER(statement) NOT LIKE 'INFER %' AND
            UPPER(statement) NOT LIKE 'CREATE INDEX%' AND
            UPPER(statement) NOT LIKE 'CREATE PRIMARY INDEX%' AND
            UPPER(statement) NOT LIKE '% SYSTEM:%'
        GROUP BY statement
        LETTING avgResultCount = AVG(resultCount)
        ORDER BY avgResultCount DESC
        LIMIT $limit
        """
    
        return _run_query_tool_with_empty_message(
            ctx,
            query,
            limit=limit,
            empty_message=(
                "No completed queries were available to calculate result counts."
            ),
        )
  • The tool is registered by being included in the ALL_TOOLS list, which is likely used by the MCP server to register all available tools.
    ALL_TOOLS = [
        get_buckets_in_cluster,
        get_server_configuration_status,
        test_cluster_connection,
        get_scopes_and_collections_in_bucket,
        get_collections_in_scope,
        get_scopes_in_bucket,
        get_document_by_id,
        upsert_document_by_id,
        delete_document_by_id,
        get_schema_for_collection,
        run_sql_plus_plus_query,
        get_index_advisor_recommendations,
        list_indexes,
        get_cluster_health_and_services,
        get_queries_not_selective,
        get_queries_not_using_covering_index,
        get_queries_using_primary_index,
        get_queries_with_large_result_count,
        get_queries_with_largest_response_sizes,
        get_longest_running_queries,
        get_most_frequent_queries,
    ]
  • Supporting helper utility that runs cluster queries and provides a standardized empty result response, used by the handler.
    def _run_query_tool_with_empty_message(
        ctx: Context,
        query: str,
        *,
        limit: int,
        empty_message: str,
        extra_payload: dict[str, Any] | None = None,
        **query_kwargs: Any,
    ) -> list[dict[str, Any]]:
        """Execute a cluster query with a consistent empty-result response."""
        results = run_cluster_query(ctx, query, limit=limit, **query_kwargs)
    
        if results:
            return results
    
        payload: dict[str, Any] = {"message": empty_message, "results": []}
        if extra_payload:
            payload.update(extra_payload)
        return [payload]
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the tool retrieves data from a specific catalog and returns a list, but doesn't disclose behavioral traits like whether it's read-only (implied but not stated), authentication requirements, rate limits, pagination, or what 'largest' means (e.g., top N by average). The description adds minimal context beyond basic functionality.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by clearly labeled 'Args' and 'Returns' sections. Every sentence earns its place with no redundant information, making it easy to scan and understand.

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

Completeness4/5

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

Given the tool's low complexity (one optional parameter) and the presence of an output schema (which covers return values), the description is reasonably complete. It explains what the tool does, the parameter, and the return format. However, for a tool with no annotations, it could better address behavioral aspects like safety or performance implications.

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

Parameters4/5

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

With 0% schema description coverage (schema has no descriptions) and only one parameter, the description compensates well by explaining the 'limit' parameter's purpose ('Number of queries to return') and default value. It adds meaningful semantics beyond the bare schema, though it doesn't specify constraints like minimum/maximum values.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verb ('Get') and resource ('queries with the largest result counts'), and distinguishes it from siblings by specifying the source catalog ('system:completed_requests'). It differentiates from similar tools like 'get_longest_running_queries' or 'get_queries_with_largest_response_sizes' by focusing on result count rather than runtime or response size.

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

Usage Guidelines3/5

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

The description implies usage context by mentioning the 'system:completed_requests catalog', suggesting it operates on historical query data. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_most_frequent_queries' or 'get_queries_not_selective', nor does it provide exclusion criteria or prerequisites.

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/Couchbase-Ecosystem/mcp-server-couchbase'

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