If you already keep project briefs in Claude Code, you can use that context to draft a client questionnaire in Dashform. The useful result is an editable form whose questions match the brief, with a clear point at which you decide to publish it.
This guide was revised September 8, 2026 against the current MCP tool definitions and Claude Code documentation. Tool arguments can evolve, so ask the connected assistant to inspect the available tools rather than copying an old form payload blindly.
A skill and an MCP connection do different jobs
The public Dashform Agent Skills repository contains reusable instructions and examples for an assistant. MCP is the connection through which the assistant can operate on your Dashform account.
A skill file by itself does not sign you in or grant access. Conversely, you can give a clear task to a connected assistant without installing an additional skill. Our recommendation is to establish the connection first, then add reusable instructions if you build the same kind of form repeatedly.
Connect Claude Code to Dashform
With Claude Code installed, add the remote HTTP server from your project directory:
claude mcp add --transport http dashform https://getaiform.com/api/mcpIn Claude Code, use /mcp to check the connection and complete the offered authentication flow. This follows the command format and remote authentication workflow in Claude Code's official MCP documentation.
Then ask:
Check the Dashform connection. List the organizations I can access
and tell me which organization is active. Do not create or change
anything yet.Choose the correct organization before creating a client form. If you can list organizations but cannot create a draft, check your role and the tool's requirements. The current create and update tools require an Owner or Admin role.
Use the normal authorization flow. Do not copy session cookies, passwords, or access tokens into a project brief or a form question.
Create a draft with a bounded brief
Use a specific task instead of “make me a high-converting funnel”:
In the organization we just selected, create an unpublished structured
client inquiry form for a website design agency.
Ask for desired outcome, requested service, current website, budget
range, preferred start date, approval process, name, and email.
Include "Not sure yet" for budget and timing.
Don't invent prices, availability, or a booking guarantee.
Use a neutral confirmation that the team will review the inquiry.
Inspect the current Dashform tool schema before creating it.
After creation, read the saved form back and show me its identifier,
questions, required fields, and publication status.The current create_form tool creates a private draft. It accepts a parent organization path and a form definition. Structured forms use explicit steps; dynamic forms support an adaptive conversation. Use a structured form when you need to check the same questions consistently.
Avoid copying an old example that treats creation as immediate publication. Publication is a separate action.
Review the saved form, then make a targeted edit
Ask the assistant to use the current read tool to retrieve the draft. Compare the stored questions with the brief. Check that optional fields stayed optional and that no invented price or delivery promise slipped into a description.
For example:
Make the current website optional and add "Not sure yet" to the budget
options. Preserve the other questions and keep the form unpublished.
Read it back after saving and summarize the changes.The current update_form tool updates selected fields, but supplying steps replaces the full step list. An assistant should therefore read the current draft and preserve the other steps when editing a question. A successful tool response is not a substitute for inspecting the saved result.
For a complete worked brief, use project brief to client intake.
Keep publishing explicit
When you have reviewed the draft, instruct the assistant to publish that specific form. The current publish_form tool makes the draft a live version that can receive replies. Check the returned form identifier and open the public URL supplied by the service.
Preview the public page, then submit a clearly labeled test when you are ready to exercise the response workflow. Inspect the saved reply and any connected destination. A working share link proves that the page is reachable; it does not prove every answer, scoring rule, or integration is correct.
If you change the draft after publication, publish again when you intend those changes to go live. Keep draft review and public verification as separate steps.
Handle lead scoring as its own configuration
Dashform's current lead scoring uses written descriptions for hot, warm, and cold inquiries. Describe your service and constraints, then review the classifications it produces. Do not present those judgments as an exact numeric quiz score or assume that a generated questionnaire configured scoring automatically.
The agency qualification scorecard provides example criteria and explains where a deterministic calculation is needed instead.
If the connection or task fails
| Symptom | Check |
|---|---|
| Dashform tools are not available | Open /mcp and inspect server status and authentication. |
| The organization is wrong | List organizations again and select the intended workspace. |
| Creation or editing is denied | Verify the signed-in account and organization role. |
| An old payload is rejected | Inspect the live tool schema and rebuild the request from it. |
| A draft change does not appear publicly | Check whether that draft version was published. |
| A submission is missing downstream | Inspect the saved reply, integration configuration, and destination separately. |
The skill repository and MCP connection do not make usage unlimited. Check Dashform's plan allowances and your Claude Code usage separately. Start with the project-brief example, inspect the draft, and publish only the version you have reviewed.
