Skip to main content
Glama
anketpratapsingh

codeforge-mcp

by anketpratapsingh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

generate_test_cases

Generate a complete JUnit 5 and Mockito test class for one Java class, with @DisplayName annotations for readable test reports. Call once per class.

Instructions

Generate a complete JUnit 5 + Mockito test class for one Java class, with @DisplayName annotations on every test class, nested group, and test method for readable test reports. Follows Comviva standards (copyright header, package layout). Call once per class; for 'tests for all classes in the project', the host LLM should glob the sources and invoke this tool per file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
classNameYesFully-qualified or simple class name of the class under test (SUT), e.g. 'MenuService' or 'com.comviva.menuservice.service.MenuService'.
sourceCodeYesFull Java source of the class under test. The generator reads this to derive collaborators, method signatures, branches, and exception paths.
useAssertJNoUse AssertJ (assertThat) for assertions. If false, falls back to JUnit 5 assertions.
coverageTargetsNoOptional list of method names or scenarios that MUST be covered. Use when a specific branch isn't obvious from the source.
packageOverrideNoOverride the test package. Default: same package as SUT under src/test/java.
includeIntegrationTestNoAlso produce a Spring-context integration test (*IT.java suffix) using @SpringBootTest. Off by default — most classes only need unit tests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
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 behavioral burden. It discloses output conventions (@DisplayName on every class, nested group, and method; copyright header; package layout), which is useful, but never says whether the generated test is returned as text or written into the repository, nor whether it overwrites an existing file. For a code-generation tool that ambiguity matters.

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?

Three sentences, front-loaded with what is produced, then conventions, then invocation cadence. Every sentence carries distinct information with no repetition of the name or schema.

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?

There is no output schema, so the description stands in for the return contract, and it does describe the structure of the generated artifact reasonably well. It stops short of stating the delivery mechanism (returned string vs. written file) and any write-side effects, which is the one thing an agent still has to guess.

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 coverage is 100%, so the baseline is 3, and the description adds real value on top: it explains when coverageTargets is needed (when a branch isn't obvious from the source) and confirms the default package/IT behavior. It does not add syntax detail beyond what the schema strings already say.

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?

States a specific verb and resource: generate a JUnit 5 + Mockito test class for one Java class. It also names the framework stack and header conventions, so an agent can distinguish it from generate_code or scaffold_service without reading the schema.

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

Usage Guidelines5/5

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

Explicitly says 'Call once per class' and prescribes the exact alternative workflow for the project-wide case (glob sources, invoke per file). It also flags that integration tests are off by default and most classes only need unit tests, which is real when-to-use guidance.

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

Deploy Server

Other Tools