Generates a request form from a provided library schema so clients can collect and submit valid form data.
Generate request form for a given library schema. POST /form-service/api/forms/renderer/request
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request body Also accepts: $ref, $data, $dynamicDefault. | |
| formType | No | The form type | |
| sourceId | No | The request source id | |
| sourceType | No | The request source type |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds only the endpoint path and does not explain what 'generate' actually does—whether it creates a persisted form, renders a transient payload, or has side effects. With annotations covering the safety profile, the description contributes little behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded: the first sentence states the purpose and the second gives the endpoint. No sentence is wasted, though the endpoint line is of limited use to an agent and the definition is slightly under-specified rather than over-long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested JSON-schema body, four parameters, no output schema, and many close form-related siblings. The description does not clarify return behavior, the meaning of 'library schema,' or how this differs from form_generate, so it is not complete enough for an agent to call it confidently in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description says nothing about the four parameters. The schema itself documents formType, sourceId, sourceType, and the recursive body, but the description does not add any meaning beyond those structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a general verb and resource ("Generate request form for a given library schema"), but it is vague about what a 'request form' or 'library schema' is in this platform. It also does not distinguish this tool from nearby siblings like form_generate, form_fetch_model, or form_get_action_form, and the name form_fetch_form suggests a fetch operation while the description says generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of form_generate, form_fetch_model, form_fetch_customized_form, or form_get_action_form. The only implied usage is that a caller has a library schema and wants a request form, which is too thin for an agent to route correctly among the many form siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.