Skip to main content
Glama
franccesco

Bloomy MCP

by franccesco

get_query_details

Retrieve comprehensive details about specific GraphQL queries, including argument requirements, return types, descriptions, and example usage. Outputs results in YAML format for clarity and integration.

Instructions

Get detailed information about specific GraphQL queries.

Retrieves argument requirements, return type information, descriptions, and
example usage for the specified queries.

Args:
    query_names: Comma-separated list of query names to get details for

Returns:
    A YAML-formatted string containing detailed information about the requested queries

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
query_namesYes

Implementation Reference

  • The handler function implementing the 'get_query_details' tool logic. It wraps get_operation_details to fetch query-specific schema details.
    def get_query_details(query_names: str) -> str:
        """Get detailed information about specific GraphQL queries.
    
        Retrieves argument requirements, return type information, descriptions, and
        example usage for the specified queries.
    
        Args:
            query_names: Comma-separated list of query names to get details for
    
        Returns:
            A YAML-formatted string containing detailed information about the requested queries
        """
        return get_operation_details(query_names, "query")
  • Registration of the get_query_details tool using the FastMCP tool decorator.
    mcp.tool()(get_query_details)
  • Core helper function that performs GraphQL schema introspection to gather operation details, formats them, and returns YAML. Called by get_query_details.
    def get_operation_details(operation_names: str, operation_type: str) -> str:
        """Get detailed information about specific GraphQL operations.
    
        Retrieves and formats detailed information about GraphQL queries or mutations,
        including arguments, return types, and example usage.
    
        Args:
            operation_names: Comma-separated list of operation names to get details for
            operation_type: Either "query" or "mutation"
    
        Returns:
            A YAML-formatted string containing detailed information about the requested operations
    
        Raises:
            Exception: If there's an error retrieving the operation details
        """
        type_name = "QueryType" if operation_type == "query" else "MutationType"
    
        details_query = gql(
            f"""
        {{
          __type(name: "{type_name}") {{
            fields(includeDeprecated: false) {{
              name
              description
              args {{
                name
                description
                type {{
                  kind
                  name
                  ofType {{
                    kind
                    name
                    ofType {{
                      kind
                      name
                      ofType {{
                        kind
                        name
                      }}
                    }}
                  }}
                }}
                defaultValue
              }}
              type {{
                kind
                name
                ofType {{
                  kind
                  name
                }}
              }}
            }}
          }}
        }}
        """
        )
    
        try:
            result = default_client.execute(details_query)
    
            # Parse the list of operation names
            operation_name_list = [name.strip() for name in operation_names.split(",")]
    
            # Collect all requested operations
            all_details = {}
    
            for operation_name in operation_name_list:
                # Find the specific operation
                operation_info = None
                for field in result["__type"]["fields"]:
                    if field["name"] == operation_name:
                        operation_info = field
                        break
    
                if not operation_info:
                    all_details[operation_name] = f"{operation_type.capitalize()} '{operation_name}' not found"
                    continue
    
                # Format arguments
                args = []
                for arg in operation_info["args"]:
                    type_info = format_type_info(arg["type"])
                    args.append(
                        {
                            "name": arg["name"],
                            "description": arg["description"] or "No description",
                            "type": type_info,
                            "required": type_info.endswith("!"),
                            "defaultValue": arg["defaultValue"],
                        }
                    )
    
                # Format return type
                return_type = format_type_info(operation_info["type"])
    
                # Create result structure
                details = {
                    "name": operation_name,
                    "description": operation_info["description"] or "No description",
                    "arguments": args,
                    "returnType": return_type,
                    "example": generate_operation_example(operation_name, args, operation_type),
                }
    
                all_details[operation_name] = details
    
            return yaml.dump(all_details, sort_keys=False)
    
        except Exception as e:
            return f"Error getting {operation_type} details: {str(e)}"
Behavior3/5

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

With no annotations provided, the description carries the full burden. It describes what the tool retrieves (argument requirements, return types, descriptions, examples) and the return format (YAML-formatted string), which is helpful behavioral context. However, it doesn't mention potential limitations like rate limits, authentication requirements, error conditions, or whether it's read-only (though 'get' implies safe read).

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 well-structured and front-loaded with the core purpose, followed by specific details, then clearly labeled 'Args' and 'Returns' sections. Every sentence adds value: the first states the purpose, the second elaborates on what's retrieved, and the parameter/return sections provide essential usage information with zero waste.

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

Completeness3/5

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

For a 1-parameter tool with no annotations and no output schema, the description is reasonably complete: it explains the purpose, parameter semantics, and return format. However, it lacks details about behavioral aspects like error handling, authentication needs, or rate limits, which would be helpful given the absence of annotations. The return format description is adequate but could benefit from more specificity about the YAML structure.

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?

Schema description coverage is 0%, so the description must compensate. It adds crucial semantic context: 'query_names' is a 'comma-separated list of query names to get details for', which explains the parameter's purpose and format beyond the schema's basic string type. This significantly enhances understanding, though it doesn't specify format details like case sensitivity or valid query name patterns.

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 tool's purpose: 'Get detailed information about specific GraphQL queries' with specific details about what information is retrieved (argument requirements, return type information, descriptions, example usage). It distinguishes from sibling 'execute_query' (which executes queries) and 'get_mutation_details' (which focuses on mutations), though it doesn't explicitly contrast with 'get_authenticated_user_id'.

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 (when you need detailed information about GraphQL queries rather than executing them), but doesn't explicitly state when to use this tool versus alternatives like 'get_mutation_details' for mutations or 'execute_query' for execution. No explicit 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

Related 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/franccesco/bloomy-mcp'

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