Skip to content
IsoKron
Menu

MCP server development

MCP servers built to the rules our audits enforce

The rules come out of our audits of other people’s MCP servers. Where a public finding motivated a rule, it links to it. IsoKron designs and builds MCP servers that follow all ten from the first commit.

Talk about a buildStart with a fixed-price audit

The ten rules

Each rule links the finding that motivated it, where one is public.

  1. Rule 1

    Per-field writes with preconditions

    An update changes only the fields it names, and fails if the object changed since it was read. Two agents cannot silently undo each other.

    Motivated by github-mcp-server #3751 and PostHog #131620 (merged): concurrent updates that silently revert.

  2. Rule 2

    Fail-closed safety switches

    A read-only or safety setting the server does not understand stops the server. It never falls back to “writes on”.

    Motivated by github-mcp-server #3747: a read-only setting that silently stays off.

  3. Rule 3

    No credentials in model context

    Tool results never carry tokens, signed URLs or secrets. If the agent needs a file, the server fetches it.

    Motivated by github-mcp-server #3748, a hardening issue: short-lived tokenised URLs for private files in directory listings.

  4. Rule 4

    Strict schemas, no silent coercion

    A value of the wrong type is rejected with a clear error, not quietly turned into something else.

    Motivated by PostHog #131514: “false” stored as true, null stored as 0.

  5. Rule 5

    Batch operations

    Reading N things takes one call, not N. Fewer round trips means fewer tokens and fewer chances to fail halfway.

    Motivated by our GitHub MCP server audit. Submitting a pull-request review with inline comments took 5 MCP calls; GitHub’s REST API accepts the same review, comments included, in one request.

  6. Rule 6

    Atomic multi-resource writes

    Multi-resource writes use transactions where the backend supports them, otherwise explicit staging and rollback; partial outcomes are reported exactly, never as success.

    Working example: sea-lite, our open-source work queue, lays down a batch of tickets and links in one all-or-nothing write.

  7. Rule 7

    Idempotency keys

    A write retried after a timeout is recognised and applied once, not twice.

  8. Rule 8

    Writes that return usable IDs

    Every create returns the ID of what it made, so the next call can use it without a search.

  9. Rule 9

    Honest annotations

    readOnlyHint, destructiveHint and idempotentHint describe what each tool actually does. They are not authorization controls: permissions are enforced by the server, not by hints.

  10. Rule 10

    Lean tool catalogs

    Few tools, short descriptions, no duplicates. Tool definitions cost context whenever a client loads them; we measure the real overhead in your client and cut what isn’t needed.

    The catalog is pinned with mcp-catalog-snap, so any change to it shows up in CI.

We don’t audit our own work as if it were independent

We don’t present an audit of code we built for you as independent work. We test everything we build and you get that evidence, but we call it what it is: our own testing. If you want an independent audit of a server we built, hire another auditor and we’ll give them what they need.

What a build includes

  • The server in your repository, under your account
  • Tests for each of the ten rules, run in your CI
  • A pinned tools/list snapshot made with mcp-catalog-snap, so catalog changes show up in review
  • A short note on deployment and auth options: stdio for one machine, or remote HTTP with OAuth when other people need to call it (what that involves)
  • A handover call with whoever will maintain it

Fixed quote after a scoping call

Builds typically start from $4,500, as a fixed quote after a scoping call. Most builds start after an audit. The audit report says what to fix and what to build, which is most of the scope.

  1. Step 1

    Scope

    A call about what the server must do and the systems it connects to. If you already have an audit report, we start from that.

  2. Step 2

    Fixed quote

    A fixed price and a delivery date in writing. If the work turns out bigger, we tell you before doing more, and you decide.

  3. Step 3

    Build and hand over

    Everything above, delivered by the date in the quote, then a handover call.

MCP server development FAQ

How much does an MCP server build cost?

Builds typically start from $4,500, as a fixed quote after a scoping call. Most builds start after an audit, because the audit report is most of the scope.

Can you fix the findings from an audit?

Yes. Fixes are quoted from the report after you have read it, so the audit has no incentive to inflate findings. The retest runs on the same frozen harness and you get the raw evidence.

Will you audit the server you build for us?

Not as independent work. We test everything we build, and you get that evidence, but we do not call it an independent audit. If you want one, hire another auditor and we will give them what they need.

Talk about a build

Tell us what the server needs to do and what it connects to. We reply to set up the scoping call.

Talk about a buildhello@isokron.ai

Already have a server? Start with an audit

Find out what it gets wrong first. Audits are fixed price, from a narrow Snapshot to a full audit with a cost-per-task benchmark.

Request an auditSee audit packages