I gave 360 browser tools an MCP server. Here is what broke.

Toine — Mon, 05 Oct 2026 14:34:27 +0000

I run ToolForte. It is a site with 360 small tools: merge a PDF, validate an IBAN, parse a cron line, diff two texts. Most of them run in the browser, so the file never leaves your machine. I built it for people who do not want an account for a five second job.

Then I started using Claude and Cursor for real work and noticed I was copying results out of my own site into a chat. That is silly. The tools are deterministic. An agent should be able to call them.

So I gave the site an MCP server. This is what I learned, including the parts that went wrong.

The first version was too big to be useful

The obvious move is to expose everything. I did. The server listed 111 tools, later 180. It worked, technically. In practice a list that size eats a large slice of the context window before the agent has done anything. And the agent picks the wrong tool more often, because twelve of them sound alike.

The fix was progressive disclosure. The server now shows 14 tools by default. Those cover most jobs. A search tool finds the other 166 by name or by what you need. A registry or a power user can ask for the full list with ?tools=all on the endpoint. Same server, two views.

Registries score you on metadata, not on what the tools do

I listed the server on Smithery and got a quality score of 43 out of 100. The tools worked. The score was about what the listing said about them. No titles. Thin parameter descriptions. No output schema. No annotations saying which tools are read only.

I went through all of them. Every tool got a title, a description per parameter, an output schema with structured content, and annotations. The score went to 96. Nothing about the tools changed. If you publish an MCP server, do this first. It is what an agent reads to decide whether to call you.

Version numbers drift when nothing ties them together

My registry manifest said 1.10.0. The server told every client it was 1.8.0. The number was typed by hand in the handler and nothing checked it against the manifest that gets published. Two releases went out like that.

Now the handler reads its version from the manifest file. The publish script asks the live server for its version and refuses to publish while the two differ. Boring, but it is the kind of thing a registry scan flags and you do not notice yourself.

What is in it now

150 deterministic utilities. IBAN and VAT validation, cron parsing, regex testing, date maths, unit conversion, hashing, JSON and text tools.
14 render tools. HTML or a URL in, a hosted PDF or screenshot out, as a signed link that lives for 24 hours.
Workflows. Chain tools into one job, save it, and let an agent run it by id.
Memory that survives between sessions.
6 AI tools for the jobs that are not deterministic.

Free to try without a key: 3 renders a day. Pro is 19 euro a month. That buys a monthly balance of credits, and the API, the MCP server and the AI tools all draw from the same one.

Adding it takes about thirty seconds

Remote server, streamable HTTP:

https://toolforte.com/api/mcp

Claude Desktop, Cursor, ChatGPT and the others each have a config screen for this; the exact steps per client are on toolforte.com/mcp. If you prefer stdio, npx toolforte-mcp wraps the same endpoint. The server is in the official registry as io.github.Toinedotcom/toolforte.

The same 150 tools are also a plain REST API, documented at toolforte.com/developers. Everything is searchable in one box at toolforte.com/everything.

What I want to know from you

Which tool is missing? I add deterministic ones quickly. If your agent calls the server and something comes back wrong, tell me the tool and the input. I will look at it the same day.

Dutch test data that passes validation: BSN, IBAN, UPA

Toine — Mon, 05 Oct 2026 14:31:05 +0000

I work as a test manager on pension projects in the Netherlands. Each one of them needs test data that looks Dutch and passes the checks the system runs, without being a real person. Each of them started with someone typing numbers by hand until the validator stopped complaining.

I got tired of that and built the generators I kept needing. They are free, they run in the browser, and this is what is in them and what I learned making them.

BSN: the check is the elfproef

A BSN is nine digits. The check is the elfproef. Multiply the digits by 9, 8, 7, 6, 5, 4, 3, 2, and the last one by minus 1. Add them up. The total has to divide by 11. Most made up numbers fail. A generator that only knows "nine digits" produces test data that gets rejected at the first form.

Test BSN generator gives you numbers that pass the elfproef. They are valid by checksum, not registered to anyone I know of, and meant for test environments only. Do not put them in production and do not use them to impersonate anyone.

IBAN: do not run the elfproef on it

This one cost me time. The old Dutch bank account numbers had an elfproef of their own. The IBAN does not. NL IBANs use the standard mod 97 check and nothing else. Since 1 July 2020 banks issue account numbers that do not pass the old elfproef, and some validators still reject them. If your test IBAN validator fails on a real ING account, this is why.

Test IBAN generator makes IBANs that pass mod 97 for NL and other countries, with a real bank code in the right position. The IBAN validator is the one I use to check what a supplier sends me. It knows that the bank code sits at a different position per country: Italy starts at position 5, Germany has eight digits. The naive substring(4, 8) everyone writes first is wrong for a third of Europe.

UPA and BRP: whole files, not single values

Pension administration in the Netherlands runs on UPA deliveries from employers. Testing that chain means you need an UPA file with a plausible mix of employments, salaries and dates. And you need twenty of them, not one. Typing those in XML by hand is how a week disappears.

The UPA file generator builds a complete file from a few settings. The BRP test data generator does the same for person records: names, birth dates, addresses that fit together, BSNs that pass. Both run locally in the browser. Nothing you generate is sent anywhere, which matters when the test environment is under an NDA.

The rest of the Dutch set

Everything Dutch is grouped on toolforte.com/netherlands. A VAT number checker. Working days between two dates with Dutch public holidays. Holiday allowance, notice periods, severance. The test data tools by themselves are on toolforte.com/test-data.

If you write test automation, the same generators are callable from an API and from an MCP server. A test can ask for a fresh valid BSN instead of reading one from a fixture file. Fixture files are what someone eventually copies into production.

What I still want

I keep a list of checks that Dutch systems run on incoming data and I add generators when I hit a new one. If your project validates something I do not cover yet, tell me which field and which rule.

DEV Community: Toine