Skip to main content
Glama
franccesco

Bloomy MCP

by franccesco

get_mutation_details

Retrieve detailed specifications for GraphQL mutations, including argument requirements, return types, descriptions, and usage examples, in YAML format.

Instructions

Get detailed information about specific GraphQL mutations.

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

Args:
    mutation_names: Comma-separated list of mutation names to get details for

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mutation_namesYes

Implementation Reference

  • The handler function that implements the core logic of the 'get_mutation_details' tool by delegating to the shared get_operation_details helper with mutation type.
    def get_mutation_details(mutation_names: str) -> str:
        """Get detailed information about specific GraphQL mutations.
    
        Retrieves argument requirements, return type information, descriptions, and
        example usage for the specified mutations.
    
        Args:
            mutation_names: Comma-separated list of mutation names to get details for
    
        Returns:
            A YAML-formatted string containing detailed information about the requested mutations
        """
        return get_operation_details(mutation_names, "mutation")
  • Core helper function that performs the GraphQL introspection query to fetch operation details, formats arguments and types, generates examples, and returns YAML output. Used by both get_query_details and get_mutation_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)}"
  • MCP tool registration block where get_mutation_details is registered as a tool using the FastMCP mcp.tool() decorator.
    # Register tools
    mcp.tool()(get_query_details)
    mcp.tool()(get_mutation_details)
    mcp.tool()(execute_query)
    mcp.tool()(get_authenticated_user_id)
Behavior3/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. It discloses that the tool retrieves information (implying read-only behavior) and specifies the return format (YAML-formatted string), which adds useful context beyond basic functionality. However, it does not mention potential limitations like rate limits, authentication requirements, or error handling, leaving gaps in behavioral disclosure for a tool with no annotation coverage.

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, with the first sentence stating the core purpose. Additional sentences efficiently elaborate on what is retrieved and provide parameter and return details in a structured format (Args/Returns sections). Every sentence adds value without redundancy, making it highly concise and well-structured.

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 moderate complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage context, parameter semantics, and return format. However, without annotations or an output schema, it could benefit from more behavioral details (e.g., error cases, authentication needs) to be fully comprehensive, though what is provided is sufficient for basic understanding.

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

Parameters5/5

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

The schema description coverage is 0%, so the description must compensate fully. It explicitly defines the single parameter 'mutation_names' as a 'comma-separated list of mutation names to get details for', adding crucial semantic meaning not present in the schema (which only provides a title and type). This fully compensates for the lack of schema descriptions, making the parameter purpose and format clear.

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 verbs ('Get detailed information', 'Retrieves') and resources ('GraphQL mutations'), distinguishing it from sibling tools like execute_query (which executes queries) and get_query_details (which focuses on queries rather than mutations). It explicitly mentions what information is retrieved: argument requirements, return type information, descriptions, and example usage.

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

Usage Guidelines4/5

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 get detailed information about specific GraphQL mutations. It implicitly distinguishes it from get_query_details (for queries) and execute_query (for execution), but does not explicitly state when not to use it or mention alternatives for similar needs. The guidance is sufficient but lacks explicit exclusions or named alternatives.

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