Skip to main content
Glama
jiseong-choi

Commit Conventional Message Court (CCMCP)

by jiseong-choi
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Server Quality Checklist

50%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v0.1.0

  • Disambiguation3/5

    While each tool has a distinct function, the relationship between prosecute_commit and render_verdict is unclear—agents may not know if they need to call both in sequence or if prosecute_commit alone suffices. require_better_subject also feels like it could be a sub-operation of the prosecution rather than a standalone tool.

    Naming Consistency4/5

    All tools follow a consistent court.<verb>_<object> pattern using lowercase snake_case. The 'court.' prefix acts as a namespace, and the verb choices (prosecute, render, require) are thematically appropriate, though 'require' breaks the pure verb_noun pattern slightly with the 'better' modifier.

    Tool Count3/5

    Three tools is at the lower bound of acceptable for this domain. While the core analysis and suggestion functions are present, the set feels thin—missing configuration, batch processing, or actual commit amendment capabilities that would make this a complete solution.

    Completeness3/5

    The set covers analysis (prosecute), presentation (render), and suggestion (require), but lacks obvious lifecycle operations like applying fixes, configuring rules/standards, or handling commit metadata beyond the subject line. The separation between rendering and prosecution creates a potential gap if agents expect a single 'check and report' operation.

  • Average 2.9/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.

    If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.

    MCP servers without a LICENSE cannot be installed.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior2/5

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

    No annotations provided, but description fails to disclose the courtroom metaphor/personality evident in the 'style' parameter (judge/prosecutor/defense), does not clarify what 'Force' means behaviorally, and omits return format details.

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

    Conciseness3/5

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

    Single sentence is front-loaded but extremely terse. Given 6 parameters, no annotations, and no output schema, the brevity undermines completeness rather than demonstrating efficient communication.

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

    Completeness2/5

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

    With no output schema and no annotations, description should explain return values (suggestions format) and theatrical courtroom behavior. Six parameters with thematic complexity require more contextual framing than provided.

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

    Parameters3/5

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

    Schema description coverage is 100%, establishing baseline 3. Description mentions 'commit subject' aligning with the subject parameter but adds no semantic depth beyond well-documented 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?

    Clear verb 'provide' and resource 'commit subject' with specific focus on rewrite suggestions. However, does not explicitly differentiate from sibling tools like 'prosecute_commit' or explain the 'court' theme.

    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?

    No guidance on when to use this versus 'court.prosecute_commit' or other siblings. No mention of prerequisites (e.g., when diff is required vs optional).

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

  • Behavior2/5

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

    No annotations provided, so description carries full disclosure burden. It fails to indicate what the tool returns (presumably a string containing the verdict text), whether it has side effects, or if it calls external services. 'Render' implies generation but lacks specifics on output format.

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

    Conciseness4/5

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

    Single sentence of 9 words is efficiently structured and front-loaded. However, extreme brevity is detrimental given the 6-parameter complexity and lack of output schema—every word earns its place, but there aren't enough of them.

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

    Completeness2/5

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

    Incomplete for a 6-parameter tool with no output schema. The description omits return value specification, courtroom metaphor explanation, and workflow context with siblings. Relies entirely on schema for parameter understanding.

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

    Parameters3/5

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

    With 100% schema description coverage, the schema adequately documents all 6 parameters. The description adds minimal semantic context beyond the schema, though 'courtroom opinion' loosely hints at the 'style' enum purpose. Baseline score appropriate given schema quality.

    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 uses specific verb 'Render' and resource 'courtroom opinion' within the commit message domain. It hints at the courtroom metaphor aligning with sibling tools, though it could more explicitly differentiate from 'prosecute_commit' (arguments) vs this tool (final judgment).

    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?

    No guidance provided on when to use this versus 'court.prosecute_commit' or 'court.require_better_subject'. The workflow relationship between these three tools is unclear from the description alone.

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

  • Behavior2/5

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

    With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions returning a 'structured verdict,' it fails to disclose whether the operation is destructive, if it persists data, rate limits, underlying LLM usage, or what the verdict actually contains (criticisms, scores, etc.).

    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?

    Single sentence with zero filler. The core action and return value are front-loaded. No redundant words or tautology.

    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 6-parameter tool with enum constraints and sibling relationships, the description is minimally viable. It states the core function and hints at output structure ('structured verdict'), but lacks workflow context and behavioral details that would be necessary given the absence of output schema or annotations.

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

    Parameters3/5

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

    Schema description coverage is 100%, so baseline expectations are met by the schema itself. The description mentions 'commit subject and diff' which reinforces the two required parameters, but adds no syntactic details, format constraints, or semantic relationships between parameters (e.g., how style affects the verdict).

    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 core action ('Put on trial') and inputs ('commit subject and diff'), distinguishing it from sibling tools like 'require_better_subject' (which focuses only on subjects) and 'render_verdict' (which likely displays rather than prosecutes). The courtroom metaphor is consistent with the tool name, though 'put on trial' requires slight interpretation.

    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 its siblings (court.render_verdict, court.require_better_subject) or whether this is the first step in a multi-tool workflow. No prerequisites or exclusion criteria are mentioned.

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

CCMCP MCP server

Copy to your README.md:

Score Badge

CCMCP MCP server

Copy to your README.md:

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/jiseong-choi/CCMCP'

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