foxform_get_responseFetch one response by its ID (from foxform_list_responses).
Args:
response_id (string)
response_format ('markdown' | 'json')
Returns the full response object (id, form_id, answers, submitted_at, metadata).
| Name | Required | Description | Default |
|---|---|---|---|
| response_id | Yes | Response ID | |
| response_format | No | Output format: 'markdown' (human-readable) or 'json' (machine-readable) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds the return shape ('full response object' with key fields) and the ID source, which is useful behavioral context beyond the annotations.
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?
The description is compact and well-organized into a one-line summary, an Args list, and a Returns section. There is no filler or redundancy; every line adds either scope, parameter semantics, or return information.
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?
For a simple read-by-ID operation with two parameters, rich annotations, and a fully documented schema, the description provides enough context to invoke the tool correctly. It also supplies the return object's key fields, compensating for the absence of an output schema.
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 coverage is 100%, with both parameters fully described including the enum values and default for response_format. The description mostly restates the schema, though it does add the useful hint that response_id comes from foxform_list_responses.
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?
Description states a specific verb ('Fetch') and resource ('one response by its ID'), making the tool's scope immediately clear. Referring to foxform_list_responses as the source of the ID helps differentiate it from the list and export siblings.
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?
The phrase 'one response by its ID (from foxform_list_responses)' implies the intended workflow: first list responses to obtain an ID, then fetch a single one. It does not explicitly enumerate alternatives such as export_responses for bulk retrieval, but the single-response framing provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool pairs a unique action with a unique resource: forms have create/get/update/list/publish/unpublish, responses have list/get/export, and analytics is separate. The only near-overlap (export vs list responses) is explicitly differentiated by truncation and pagination.
All tool names share the foxform_ prefix and follow a strict verb_noun pattern (create_form, list_responses, publish_form). No mixed casing or synonym verbs create ambiguities.
Ten tools is a well-scoped surface for a form management API: form lifecycle, response access, and analytics each have dedicated operations. None feel redundant, and the count stays comfortably within the ideal range.
The core form lifecycle is covered: create, read, update, publish, unpublish, and list. The only notable gap is delete_form (and no response deletion/update), which agents can work around but is still a real missing lifecycle op.