Skip to main content
Glama
jolfr

Commit Helper MCP

by jolfr

get_commit_types

Retrieve available commit types and their descriptions from the Commit Helper MCP server to structure conventional commit messages effectively.

Instructions

Get list of available commit types from the current plugin.

Returns: Dict containing available commit types and their descriptions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler for get_commit_types. Decorated with @mcp.tool() for automatic registration. Retrieves commit types via service facade and formats response.
    @mcp.tool()
    @handle_errors(log_errors=True)
    def get_commit_types() -> Dict[str, Any]:
        """
        Get list of available commit types from the current plugin.
    
        Returns:
            Dict containing available commit types and their descriptions
        """
        commit_types = service.get_commit_types()
    
        result = {
            "commit_types": commit_types,
            "count": len(commit_types),
            "plugin": service.get_info().get("plugin_name"),
        }
    
        return create_success_response(result)
  • Service facade method that delegates get_commit_types to the CommitzenCore service.
    def get_commit_types(self) -> List[Dict[str, str]]:
        """Extract available commit types from questions."""
        return self.commitizen_core.get_commit_types()
  • Core implementation that extracts commit types from the plugin's questions, handling various choice formats and returning list of dicts with name/value.
    def get_commit_types(self) -> List[Dict[str, str]]:
        """Extract available commit types from questions."""
        try:
            questions = self.get_questions()
            commit_types = []
    
            for question in questions:
                if question.get("name") == "prefix" and "choices" in question:
                    # Handle different choice formats
                    choices = question["choices"]
                    for choice in choices:
                        if isinstance(choice, dict):
                            # Choice is a dict with 'name' and 'value'
                            commit_types.append(
                                {
                                    "name": choice.get(
                                        "name", choice.get("value", str(choice))
                                    ),
                                    "value": choice.get(
                                        "value", choice.get("name", str(choice))
                                    ),
                                }
                            )
                        elif isinstance(choice, str):
                            # Choice is a simple string
                            commit_types.append({"name": choice, "value": choice})
                        else:
                            # Fallback for other formats
                            commit_types.append(
                                {"name": str(choice), "value": str(choice)}
                            )
                    break
    
            logger.debug(f"Extracted {len(commit_types)} commit types")
            return commit_types
        except CommitizenException as e:
            logger.error(f"Failed to get commit types: {e}")
            raise PluginError(
                f"Failed to extract commit types: {e}",
                plugin_name=self.committer.__class__.__name__,
                cause=e,
            )
        except Exception as e:
            if not isinstance(e, (PluginError, ValidationError)):
                logger.error(f"Failed to get commit types: {e}")
                raise PluginError(
                    f"Failed to extract commit types: {e}",
                    plugin_name=self.committer.__class__.__name__,
                    cause=e,
                )
            raise
  • Imports the get_commit_types tool function from message_tools, ensuring it's available and registered when the server module is imported.
    from .server.message_tools import (
        generate_commit_message,
        create_commit_message,
        validate_commit_message,
        get_commit_types,
    )
Behavior2/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. It states the tool returns a dict with commit types and descriptions, which is helpful, but doesn't cover other aspects like whether it's a read-only operation (implied by 'Get'), potential errors (e.g., if no plugin is active), performance characteristics, or side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 extremely concise and front-loaded: the first sentence states the purpose, and the second clarifies the return format. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly. The structure is clear and efficient.

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 simplicity (0 parameters, output schema exists), the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for a basic read operation. However, with no annotations and many sibling tools, it could benefit from more context about when to use it or error conditions, but the output schema likely covers return values, reducing the burden on the description.

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?

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the return value. This meets the baseline of 4 for zero-parameter tools, as there's no parameter information to add beyond the schema.

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 list of available commit types from the current plugin.' This specifies the verb ('Get'), resource ('list of available commit types'), and source ('from the current plugin'). However, it doesn't explicitly differentiate from sibling tools like 'get_commit_questions' or 'get_git_implementation_info' that also retrieve information but about different resources.

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. It doesn't mention prerequisites (e.g., whether a plugin must be loaded), context for usage (e.g., before generating commit messages), or exclusions. With many sibling tools for commit-related operations, this lack of differentiation leaves the agent to infer usage from the tool name alone.

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/jolfr/commit-helper-mcp'

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