formhaus-mcp

Formhaus capabilities

capabilities

Read-only

Call this first, before writing or editing a definition, for the full reference of what a definition supports; example_definitions gives whole working forms to copy instead.

Instructions

Call this first, before writing or editing a definition, for the full reference of what a definition supports; example_definitions gives whole working forms to copy instead. Lists what a Formhaus definition supports: field types (including scale, rating and picture options), sections (including matrix), repeatable groups, field props, validation rules, condition operators, step and route semantics, actions, translation (lang, messages, labels, i18n keys, overlay addresses) and adapters. To check a finished definition, call validate_definition instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "capabilities"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`i18n`	No
`steps`	Yes
`groups`	Yes
`recall`	Yes
`actions`	Yes
`adapters`	Yes
`sections`	Yes
`conditions`	Yes
`definition`	Yes
`fieldProps`	Yes
`fieldTypes`	Yes
`containerTypes`	Yes
`fieldTypeNotes`	Yes
`validationRules`	Yes
`customFieldTypes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.13.4Oct 22, 2026

addedOutput schema / properties / recall

Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "definition",
-  "fieldTypes",
-  "customFieldTypes",
-  "containerTypes",
-  "sections",
-  "groups",
-  "fieldTypeNotes",
-  "fieldProps",
-  "validationRules",
-  "conditions",
-  "steps",
-  "actions",
-  "adapters"
-]New value: +[
+  "definition",
+  "fieldTypes",
+  "customFieldTypes",
+  "containerTypes",
+  "sections",
+  "groups",
+  "fieldTypeNotes",
+  "fieldProps",
+  "validationRules",
+  "conditions",
+  "recall",
+  "steps",
+  "actions",
+  "adapters"
+]

Changed5 schema fields changedv0.13.3Oct 15, 2026

addedOutput schema / properties / containerTypes

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / fieldTypeNotes

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedOutput schema / properties / groups

Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedOutput schema / properties / sections

Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "definition",
-  "fieldTypes",
-  "customFieldTypes",
-  "fieldProps",
-  "validationRules",
-  "conditions",
-  "steps",
-  "actions",
-  "adapters"
-]New value: +[
+  "definition",
+  "fieldTypes",
+  "customFieldTypes",
+  "containerTypes",
+  "sections",
+  "groups",
+  "fieldTypeNotes",
+  "fieldProps",
+  "validationRules",
+  "conditions",
+  "steps",
+  "actions",
+  "adapters"
+]

First observedv0.13.1Oct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

readOnlyHint=true already tells the agent this is a safe read. The description adds genuinely useful behavioral context beyond annotations: it is a reference lookup rather than an action, and it enumerates the breadth of what the returned reference includes (including less obvious topics like step/route semantics, overlay addresses, adapters), which sets expectations for the payload. It doesn't describe output structure, but an output schema exists to carry that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The imperative to call it first is front-loaded, and the alternatives are stated before the long feature enumeration. The second sentence is a dense list, but each item names a distinct capability domain an agent would otherwise have to discover by trial, so the length is largely earned; it is slightly list-heavy for a two-sentence description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-arg read-only reference tool with an output schema, the description covers what it returns, when to call it, and what to use instead for the two adjacent tasks. Nothing an agent needs in order to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so per the baseline this scores high; the description correctly spends no words on argument syntax. Its enumeration maps to the content the call returns rather than to inputs, which is the right use of description space for a no-arg tool.

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 names a specific verb and resource ('Lists what a Formhaus definition supports') and enumerates the reference domains covered (field types, sections, groups, validation rules, actions, translation, adapters). It also distinguishes itself from two siblings by name, so an agent can tell it apart from example_definitions and validate_definition without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the trigger ('Call this first, before writing or editing a definition') and routes to the two alternatives with their selecting conditions: example_definitions for whole working forms to copy, validate_definition for checking a finished definition. No inference is required.

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

Deploy Server