Retrieves the form definition for a specified resource action by ID, enabling clients to render or inspect the action's input fields.
Get resource action's form GET /form-service/api/custom/resource-actions/{id}/form
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | (path) |
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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes nothing beyond restating the endpoint path — it does not say what the returned form represents, whether the id refers to an action definition vs. an action execution, or any auth/visibility constraints.
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?
Very short and front-loaded, which is good, but the second line is just a URL path that largely duplicates the tool name and the annotation title. Every sentence should earn its place; the path line adds minimal decision value while the space that could have held usage or return-value context is unused.
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?
There is no output schema, so the description should describe what the returned 'form' looks like (form definition, layout, JSON schema payload) or how it is consumed. With an ambiguous resource and many sibling form tools, the definition leaves the agent guessing about semantics and return shape.
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?
Single required path parameter with 100% schema description coverage, so the baseline is 3. The description only echoes '{id}' from the URL template without clarifying what entity the id identifies (a resource action definition, a resource-action instance, etc.), adding little meaning.
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 verb (Get) and a resource (resource action's form), which is clearer than the bare tool name. However, it does nothing to distinguish it from the many near-identical siblings such as form_get_resource_action, form_get_resource_action_form_data, form_get_action_runnable_item, or form_get_form, all of which sound like they return forms for similar entities.
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?
No guidance on when to call this instead of the closely related form/resource-action tools. The only added text is the raw HTTP path, which gives no selection criteria for an agent choosing among dozens of form_* alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.