DEV Community: Dany

What building an MCP form server taught me about designing tools for AI agents

Dany — Thu, 02 Jul 2026 15:32:19 +0000

I've spent the last few months building a form builder with an unusual bet: the Model Context Protocol server is the product. There's a web dashboard, but you never have to open it. You describe a form to Claude, ChatGPT or Cursor (say, "a client intake form with budget and timeline fields") and the AI creates it, publishes a live URL, and reads the responses back, all in the same chat.

Most form tools that ship an MCP server bolt it onto a dashboard-first product. Building MCP-first flipped how I think about tools. You're not designing a UI for a human who clicks. You're designing an API for a caller that reads your docs, guesses, and acts. Here's what actually mattered.

1. One tool, one job

My instinct from REST was to build a few flexible endpoints. That's wrong for agents. A model reasons better about a set of small, unambiguous tools than about one big tool with a mode flag.

The server ended up with 12 narrow tools: list_forms, get_form, create_form, update_form, duplicate_form, publish_form, unpublish_form, set_form_theme, get_responses, get_form_analytics, get_form_share_assets, delete_form. Each does exactly one thing. When the model wants to change a theme, there's a tool literally called set_form_theme, so it doesn't have to infer that from an update_form payload shape.

Rule of thumb: if you can't describe the tool in one sentence without the word "and", split it.

2. Names and descriptions are the UX

The model never sees your code. It sees the tool name, the description, and the parameter schema, and it picks tools the way a person picks a button by its label. Those strings are your interface.

I rewrote every description to be about when to use this, not what it does internally:

get_responses: "Return submissions for a form. Use when the user asks 'how many responses', 'who filled it out', or wants to analyze answers."

Putting concrete trigger phrases in the description made the model pick the right tool far more often. Treat description-writing as prompt engineering, because it is.

3. Annotate read-only vs destructive tools

MCP lets you annotate each tool with hints like readOnlyHint and destructiveHint. It's tempting to skip them. Don't.

Clients use them: some gate destructive calls behind a confirmation, and agents plan more cautiously around tools flagged as mutating. Getting them right is also a hard requirement to pass directory reviews (Anthropic's Connectors Directory rejects incorrect annotations).

// read-only tool
{ "name": "list_forms",  "annotations": { "readOnlyHint": true } }

// the one genuinely dangerous tool
{ "name": "delete_form", "annotations": { "readOnlyHint": false, "destructiveHint": true } }

Of my tools, the five get_*/list_* ones are read-only, most writes are non-destructive state changes, and exactly one, delete_form, is destructive. Being honest about that one is what lets a client protect the user.

4. Return results the model can chain

A tool's return value is an input to the model's next step. Return structured, self-describing data: IDs, and above all URLs.

Every mutation returns a preview_url. That one field means the AI can create a form and immediately hand the user a link to verify it, without a second call. Anything you'd want the model to reference next, put it in the response.

5. Safe defaults for actions you can't undo

Guessing plus irreversible actions is a bad mix. So create_form returns a draft. Publishing to a public URL is a separate, explicit publish_form call. The model has to decide to go public. It can't do it by accident while building.

The general principle: make the reversible thing the default, and require an explicit step for anything you can't take back.

6. Design for chaining across servers

The most freeing realization: I don't need native integrations. My server has no built-in Notion or Slack connector, and doesn't want one. If the user has a Notion MCP connected to the same assistant, they just say "save the qualified leads to my Notion" and the AI chains get_responses into Notion. My job is to expose clean tools and get out of the way. The composition happens in the model's context, not in my backend.

Testing without a human in the loop

Two things that helped:

Inspectors. The Glama inspector and Smithery let you call every tool with real auth and eyeball the responses before any model touches them.
Real clients. Behavior differs between Claude, Cursor and others. Test in the clients your users actually run. Descriptions that work in one sometimes need tightening for another.

What it comes down to

Building for a model caller is API design, except your reader guesses instead of reading exactly. Small tools, trigger-oriented descriptions, honest annotations, chainable outputs, safe defaults. None of it is exotic. It's just good interface design, aimed at a new kind of user that reads your labels literally and then acts on them.

If you're building an MCP server, I'd love to compare notes. And if you want to see these ideas in a shipped product, I'm building Brieform: forms your AI builds, publishes and reads, from inside the chat.

Last week, I made my very first sale as an indiehacker

Dany — Mon, 24 Jun 2024 12:25:22 +0000

Last week, I made my very first sale as an #indiehackers 🥳

"cool story bro"

But what's important here isn't the sale, it's how I got it 👉 Fighting my imposter syndrome.

I got a response on a marketing post here asking for a DM before buying.
My 2023 me would have avoided it: "What if I can't respond positively? What if they thought it was bad? What if...".
1 year xp Indie me: "Nothing happens out of nothing, let's go".
The potential customer just wants to know if DirectoryFast can do a "classic" directory layout?
I spent 5 minutes creating it and sent a screenshot.
Deal done, money and access sent in less than an hour.

Sound trivial? It's absolutely not the case for a savage like me, I really don't like talking to people, my impostor syndrome is on another level.

But I've been fighting it all my life, I chose a previous difficult career to prove myself and I choose another career in hardmode as an indie now.

I just need challenges 💪

I made a whooping 1.60$ from my books-for-indies app and... it's totally fine.

Dany — Fri, 03 May 2024 21:33:05 +0000

The Intro

First, a little look back at 4 months ago.

I just shipped my first-ever product, a fantastic AI app that gives you everything you need to fill your e-commerce product page with enhanced images and automatic descriptions!

Woohoo what a banger... No. 🙃

Second to last on the ProductHunt launch, no users, no feedback, no nothing. And DDoS attacks. Noice!

Disappointing right? But anyway I was starting to get annoyed by this messy codebase and product.

Time to move on.

The building process

I needed to improve ALOT of skills, so naturally I searched for cool books on Amazon.

Did you ever try to find business or even niche books blindly on Amazon?
It's a mess.
Like really, wtf? 🥴

So I decided to make that app, "scratch your own itch" as they say.

And that's what I made, I applied everything I learned from my previous failure, and I decided to build a simple, clean, and useful app.

I even made terrible wireframes and hasardous database tables and relations on a little notebook like a grown man!

Motivated like I was I made a blog series about it!

The money

Cool story bro, how about money now? 💰
Don't worry I'm smart. It will be Amazon Affiliate links. My idea is so nice that the entire indie community will use it and I will be rich!

Lol.

I made 1.20$ on the ProductHunt launch and... that's all folks.
(no, actually, a lost one bought 1 another book for a massive 0.40$ this month!)

And you know what? I don't even give a fck!

The learning

I made a product that I'm proud of, that I use myself, that I know is useful for others, and that I can improve. I learned a lot, I improved a lot, and I'm happy with that.

While building this very product I had at least 3 app ideas, with the one I'll start working on very soon.
I gained confidence in crucial aspects (marketing, communication, SEO...) and technologies (LemonSqueezy, Loops, SSR/SSG...) so I'm no more scared of the next project.

And most importantly, I met so many cool people from the indie community, and I'm so grateful for that. Thank you guys. 🤜🤛

The conclusion

So, if you're like me, a little indie dev with a lot of ideas and a lot of motivation, don't be scared of failure. It's not the end of the world, it's the beginning of the next project and the next success. 💪

And if you need good books to achieve your goals like your favorite #indiehackers, just go check what they read: IndiesRead.it

I made a free tool to help online sellers obtain product details automatically.

Dany — Thu, 30 Nov 2023 12:58:29 +0000

Hi everyone,

Watching my wife build prestashop and wooCommerce sites for small local artisans, I realized that most of them were struggling to fill out their product details page and thus missing out on SEO and sales opportunities.

So I decided to create a practical tool for online store owners and managers. It uses AI to create product details from a brief description.

How does it work?

Describe your product
It generates product details (title, desc, keywords, meta desc and more)

Objective

Simplify the product listing process and improve the efficiency of the online store for people that don't know how to do it properly or even experts that want to save time or get a quick template to iterate on.

Here is the link to the tool

What should I add to improve it?
Already had a feed that someone would love to have tabs with sorted details

And here is my dev stack:

depikt stack

I'd be happy to share with you my struggles, victories and discoveries in the course of this project, so don't hesitate to ask!

Thanks for reading this and trying the tool, or even better, sharing it!