DEV Community: Zonaib Bokhari

I built a form builder that lives inside your AI chat

Zonaib Bokhari — Tue, 05 May 2026 10:06:20 +0000

Context switching is the thing that kills me.

I'm mid-conversation with Claude, figuring something out, and then I need to collect responses from a few people. So I open Typeform in another tab, build the form, copy the link, come back. By which point I've completely lost the thread of what I was thinking.

So one weekend I just decided to fix it for myself. The result is MCP Forms — you describe a form to Claude, it builds it and hands you a live link, and you can read the responses back later. All in the same chat window.

Here's what it actually looks like

You just talk to it:

Create a job application form. Ask for full name, email, and experience level 
(Junior / Mid / Senior). If they select Senior, show a field asking about 
their leadership experience.

Claude calls the tool, the form gets generated, and you get a shareable link back — or an inline preview card if you're in a supported client:

The form itself is clean, works on mobile, has a light/dark toggle. The conditional logic works exactly as you'd expect — select Senior, the leadership field appears:

When you want to see who filled it out:

Show me submissions for the job application form
Export as CSV

What it supports

Field types: text, email, number, textarea, dropdown (select), radio buttons, checkboxes, and date. Claude picks the right type from your description — ask for an email field and it generates type: email with validation, ask for a yes/no question and it generates a radio group.

Conditional logic: any field can have a showIf rule that makes it appear only when another field has a specific value. Works across field types — radio, dropdown, whatever.

Dark theme: forms default to light, but every form has a built-in theme toggle that respondents can use themselves. You can also set the default at creation time:

Create a feedback form using the dark theme

Updating forms: this one I use a lot. You don't have to rebuild from scratch if something's wrong — just tell Claude what to change:

Add a phone number field to the job application form
Change the experience level options to Junior, Mid, Senior, Lead
Remove the cover letter field

The form updates in place. Same URL, same submissions, just a different shape.

Draft / Publish workflow: forms start as drafts so you can preview before anyone fills them out. You publish explicitly when you're ready to share the link.

Email notifications: get an email on every new submission:

Create a contact form and notify me at you@example.com on each submission

Redirect after submit: send respondents somewhere specific after they hit submit — a thank-you page, back to your site, anywhere:

Create an application form and redirect to https://example.com/thanks after submission

The bit I find genuinely cool about this

Most MCP tools are wrappers around read operations. Search this, summarize that, fetch the other thing. What I liked about building this one is that the AI is actually creating something that persists — a real form at a real URL that other people can fill out, that collects real data.

It sounds small but it's a different kind of thing. The AI isn't just helping you think, it's helping you build.

How I built it

Stack is pretty simple:

Claude Desktop / Claude.ai / Cursor / any MCP client
        │
        │  MCP (stdio or streamable-http)
        ▼
Python MCP Server
        │
        │  HTTP
        ▼
ASP.NET 9 API (on Railway)
        │
        ├── Claude API → JSON form schema
        ├── SQLite for storage
        └── Scriban templates → HTML

The flow that makes it work: when you describe a form, the API calls Claude with a prompt that returns a JSON schema — field types, labels, options, conditional rules. The form renderer takes that schema and generates HTML server-side using Scriban templates. Claude runs exactly once per form, at creation time. Loading the form page doesn't touch the AI API at all.

Conditional logic lives in the schema as showIf rules:

{
  "id": "leadership_experience",
  "type": "textarea",
  "label": "Describe your leadership experience",
  "showIf": { "field": "experience_level", "value": "Senior" }
}

There's a bit of vanilla JS on the form that watches trigger fields and shows/hides dependents. One thing I got wrong the first time — I was using getElementById to find radio button groups, which doesn't work because radio inputs use name not id. Had to fall back to querySelectorAll('[name="..."]'). Classic.

On the security side: MCP endpoints are behind an API key, form view and submit are public (obviously — people need to fill out your forms), server-side validation mirrors the schema rules, rate limiting on submit, XSS handled by Scriban's auto-encoding. Nothing exotic, just the basics done properly.

No install needed if you just want to try it

The MCP server is hosted on Railway with streamable-http transport. Add it as a custom connector in Claude.ai:

https://mcp-forms-production-cdf7.up.railway.app/mcp

Settings → Connectors → Add custom connector. Works the same way in ChatGPT, Cursor, Windsurf.

The webhook thing

Every form can have a webhook URL. On submission, the payload gets POSTed there. If it's a Slack incoming webhook URL, MCP Forms formats the payload as a proper Slack message automatically. Anything else gets raw JSON.

I'm pretty happy with this design decision — one feature, zero native integrations, but it unlocks Slack, Zapier, Make, n8n, and Google Sheets at once. You just tell Claude:

Create a contact form and send submissions to my Slack at 
https://hooks.slack.com/services/...

Submissions land in Slack like:

New submission: Contact Form
• name: Jane Smith
• email: jane@example.com
• message: Interested in your services!
Submitted at 2026-01-15T10:32:00Z

Try it / grab the code

github.com/xonaib/mcp-forms — MIT licensed

You'll need .NET 9, Python, uv, and an Anthropic API key. Self-hosting takes maybe 10 minutes following the README.

A few things still on the list: Notion integration, file upload fields, and proper multi-tenant auth (right now it's single-tenant — one database, one API key). Happy to take PRs or ideas.

Built this mostly on weekends and evening sessions between putting the kids to bed and falling asleep on the couch. If you try it and something's broken, open an issue — I'm actively working on it.

I got tired of copy-pasting the same table code, so I built a library

Zonaib Bokhari — Mon, 20 Apr 2026 08:56:21 +0000

Every Angular project I've worked on has a table. Usually more than one. And every single time I end up writing the same setup — wire up MatSort, wire up MatPaginator, build a SelectionModel for checkboxes, manage filter state somewhere, figure out export again from scratch.
It's not hard, it's just tedious. And when you do it enough times across enough projects, slightly differently each time, you start to wonder why you haven't just extracted it.
So I did. ngx-mat-simple-table — an Angular Material table component that takes a column config and data, and handles the rest.

The core idea

I wanted to go from this (the usual boilerplate situation) to this:

<simple-table
  [tableColumns]="columns"
  [dataSource]="rows"
  [tableConfig]="config"
  (sortChange)="onSort($event)"
  (filterChange)="onFilter($event)"
  (selectionChange)="onSelect($event)"
>
  <st-export filename="tasks" format="xlsx" [allDataProvider]="getAllForExport" />
</simple-table>

Column config is a plain array:

readonly columns: ColumnDef[] = [
  { key: 'select' },
  { key: 'title',    label: 'Title',    hasColumnFilters: true },
  { key: 'assignee', label: 'Assignee', hasColumnFilters: true, filterType: FilterType.DropDown },
  { key: 'status',   label: 'Status',   hasColumnFilters: true, filterType: FilterType.DropDown,
    displayValue: v => String(v).replace(/-/g, ' ').toUpperCase() },
  { key: 'dueDate',  label: 'Due Date' },
];

Fully paginated, sortable, filterable, exportable table. That's the whole host component.

Signals from the start

I built this after Angular 17 shipped, so I went all-in on the signals API. No @Input(), no EventEmitter, no ChangeDetectorRef. Everything is input(), output(), computed(), effect().

I wasn't sure how it would feel at first but honestly it's made the component much easier to reason about. I've never once had to think about change detection. Would not go back.

The Windows `file:` reference trap

This one annoyed me more than it should have.

When developing a library locally you need the demo app to consume the built output. I used "ngx-mat-simple-table": "file:./dist/ngx-mat-simple-table" in the root package.json. On macOS this works fine. On Windows, npm install with a file: reference copies the files at install time — so running build:lib:watch updates dist/ but node_modules/ stays completely stale. I kept seeing old code after rebuilds and couldn't figure out why for longer than I'd like to admit.

The fix is tsconfig.json paths instead:

"paths": {
  "ngx-mat-simple-table": ["./dist/ngx-mat-simple-table"]
}

Angular's build system watches files resolved through paths, so incremental rebuilds are picked up immediately. Should have just done this from the start.

CDK drag-reorder was a puzzle

Column drag-reorder uses Angular CDK. My first attempt put cdkDropList and cdkDrag on the same <th> element. CDK silently reported previousContainer === container on every drop, so the column order never actually changed. Body cells stayed out of sync with headers. No error, just nothing happening.

The fix: <th> is the CdkDropList, a wrapper <div> inside it carries CdkDrag. Separate elements. Also — and this surprised me — Angular's @for block doesn't work here. CDK needs to traverse the view tree to find connected drop lists, and @for uses a different internal structure than *ngFor. Switching to *ngFor on the column blocks fixed it.

Don't install SheetJS without checking if it actually does what you need

I needed styled Excel headers. I installed SheetJS (xlsx), the most popular option. Spent a while getting it set up, wrote the header styling code, tested it — headers were completely plain. No error, styling just silently had no effect.

Turns out cell styles in SheetJS community edition are a Pro-only feature. It's in the docs if you look for it, but it's not exactly front and centre.

Switched to ExcelJS (MIT, actually free) and it worked immediately. The API is clean and it supports full cell styling. To match the exported header to the rendered grid I just read styles from the DOM at export time:

const el = hostEl.querySelector('th.mat-mdc-header-cell') as HTMLElement;
const cs = window.getComputedStyle(el);
const bg = this._cssColorToArgb(cs.backgroundColor); // → ARGB hex for ExcelJS
const bold = parseInt(cs.fontWeight) >= 600;

Whatever theme or custom CSS the host applies, the Excel header automatically matches it.

Export should export everything, not just what's on screen

The first version of export grabbed whatever rows were rendered — so if you were on page 3 of 10, you'd export 10 rows. Obviously wrong in hindsight.

Client-side mode was easy to fix: export MatTableDataSource.filteredData, which has all filtered rows regardless of page.

Server-side mode needed a different approach. The <st-export> directive accepts an allDataProvider callback — the host provides a function that fetches everything from the API without pagination params:

readonly getAllForExport = (): Promise<Task[]> => {
  return firstValueFrom(
    this._http.get<TasksResponse>('/api/tasks', { params: this.activeFilterParams() })
      .pipe(map(r => r.data))
  );
};

<st-export filename="tasks" [allDataProvider]="getAllForExport" />

Active filters are forwarded so the export reflects exactly what the user sees — just without the page limit.

Vercel 404 after deploy

After one release the demo started returning 404 on every route. Angular 17+'s esbuild builder outputs to dist/<project>/browser/ — Vercel was pointed at dist/<project>/ and finding no index.html.

Fixed with a vercel.json:

{
  "buildCommand": "npm run build:lib && npm install && npm run build",
  "outputDirectory": "dist/Demo-table/browser",
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

The rewrites rule matters too. Without it, refreshing any route other than / returns 404 because Vercel looks for a file at that path instead of letting Angular's router handle it.

Where it is now

npm: ngx-mat-simple-table
Demo: ng-simple-table.vercel.app
GitHub: github.com/xonaib/ng-simple-table

It has pagination, sorting, multi-select, dropdown filters, column chooser, drag-reorder, column resize, sticky columns, Excel export with full header styling, user settings persistence, and virtual scroll. Client-side and server-side data modes.

If you're building data-heavy Angular apps, hopefully it saves you some of the boilerplate.

What's new in v1.2

Since the original post the library has grown quite a bit. Here's what landed in v1.2:

Sticky columns — ColumnDef.sticky: 'left' | 'right' pins columns to either edge during horizontal scroll. Drag-reorder is automatically disabled for sticky columns so users can't accidentally break the layout.
Dark mode — all colour tokens alias Angular Material 3 system tokens, so flipping body { color-scheme: dark } adapts the entire table with zero extra CSS. Use the CSS light-dark() function for any custom cell colours and they adapt too.
cellClass callback — return a CSS class from (value, row) for conditional cell styling — colour-coded status badges, priority indicators — without needing a full custom template.
fillContainer mode — set TableConfig.fillContainer: true and the table stretches to fill its parent height. Toolbar and paginator stay pinned; only the rows scroll.
22 CSS custom properties — every visual surface now has a --st-* token covering header, borders, row backgrounds, hover, sticky cells, cell text, scrollbar, filter popup, and column chooser. Override any of them on the element or any ancestor.
State persistence fix — new columns added after a saved state are now correctly appended rather than silently dropped.

What's new in v1.3

v1.3 ships virtual scroll.

Pagination works, but some UIs just want to scroll. Flip one flag and the paginator disappears and CDK virtual scroll takes over — only the rows in the viewport are in the DOM.

Client-side is a one-liner config change:

<simple-table
  [dataSource]="allRows"
  [columns]="columns"
  [config]="{ virtual: true, virtualRowHeight: 48 }"
/>

Pass your full array. The component handles everything internally.

Server-side is where it gets more interesting. Instead of fetching everything upfront, the table emits a virtualRangeChange event as the user scrolls, telling you which rows are in view. You fetch just that window:

<simple-table
  [dataSource]="currentWindow"
  [columns]="columns"
  [config]="{ virtual: true, virtualRowHeight: 48 }"
  [virtualOffset]="windowStart"
  [totalLength]="totalRecords"
  (virtualRangeChange)="onRangeChange($event)"
/>

onRangeChange({ start, end }: VirtualRange) {
  this.windowStart = start;
  this.http.get(`/api/items?offset=${start}&limit=${end - start}`)
    .subscribe(data => this.currentWindow = data);
}

virtualOffset tells the table where in the full dataset your loaded window starts. totalLength sizes the scroll track correctly so the scrollbar reflects the real dataset. You never load more than what's on screen.

One thing that took longer than expected: CDK virtual scroll normally positions loaded content by applying transform: translateY() to the content wrapper. That creates a CSS stacking context, which breaks position: sticky on the table header — the header scrolls away with the content instead of staying fixed. The fix is to no-op that transform entirely and use margin-top instead. Same visual positioning, no stacking context, sticky headers stay sticky. Not obvious until you hit it.