DBJavaGenix

codegen_render_controller

Renders a Spring REST Controller with @RestController and Bean Validation. Requires a template context from codegen_build_context.

Instructions

渲染 REST Controller(@RestController + Bean Validation)。需要先调用 codegen_build_context 获取 context。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "context": "<context>"
    },
    "name": "codegen_render_controller"
  }
}

Input Schema

Name	Required	Description	Default
`context`	Yes	从 codegen_build_context 返回的完整模板上下文 dict。包含 className/columns/primaryKeyType/templateCategory 等字段。LLM 应原样传递,可在传入前修改字段以重新渲染。

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1May 26, 2026

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It reveals the dependency on a prior context-building step, which is useful. However, it does not mention whether the tool generates files, overwrites existing code, requires specific permissions, or what the output is. The description is minimal, but the dependency is a key behavioral point.

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: two sentences, each serving a distinct purpose. The first sentence states the action and the result, the second provides the essential prerequisite. No filler or redundant information. It is front-loaded and efficient.

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?

Given the low complexity (1 parameter, no output schema), the description is nearly complete. However, the tool's output is not described at all; an agent might need to know whether the output is code, a file path, or something else. The description covers the prerequisite but lacks information about the result format. With no output schema, the description should at least hint at what the tool produces.

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?

The input schema provides 100% coverage with a description for the 'context' parameter, stating it comes from codegen_build_context. The tool description adds no extra semantic meaning beyond what the schema already says. With high schema coverage, baseline is 3, and the description repeats the prerequisite without adding new details.

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 specifies the tool's function: rendering a REST Controller with @RestController and Bean Validation annotations. The verb 'render' combined with the resource 'REST Controller' makes the purpose unambiguous, and it distinguishes from sibling tools that render other artifacts like entities, mappers, services, or DAOs.

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 explicitly states the prerequisite: '需要先调用 codegen_build_context 获取 context' (need to call codegen_build_context first). This gives clear usage context. However, it does not discuss when to use this tool versus alternatives (e.g., when do you need a controller vs. a service), nor does it mention any exclusions or when not to use it.

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