foxform_unpublish_formUnpublish a form (takes it offline; stops accepting responses). Requires a WRITE-scoped API key.
Args:
form_id (string)
Returns: a confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | Form ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details beyond the annotations: the operation requires a WRITE-scoped API key and the effect of taking the form offline. This aligns with readOnlyHint=false and adds practical context that annotations alone do not provide.
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 short, front-loaded with the action and effect, and includes only essential supporting information: auth requirement, argument list, and return type. Every sentence earns its place.
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 tool with a single required parameter, clear annotations, and no nested schema complexity, the description fully covers what an agent needs: the action, effect, auth requirement, parameter, and return value. Nothing critical is missing.
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%, and the only parameter, form_id, is already documented in the schema as 'Form ID'. The description merely restates the parameter name without adding extra meaning, so the baseline score of 3 applies.
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 clearly states the action (unpublish), the resource (form), and the intended effect (takes it offline; stops accepting responses). This meaningfully differentiates it from sibling tools like foxform_publish_form, though it does not explicitly name the alternative.
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 description gives clear context for when to use the tool: when a form should stop accepting responses. It also notes the WRITE-scoped key requirement, which helps the agent determine prerequisites, but it does not explicitly contrast with publish/update or mention 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.
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.