DEV Community: michielinksee

5 ways SaaS products lock out AI agents — data from probing 11,000+ services

michielinksee — Wed, 15 Jul 2026 05:33:47 +0000

Your AI agent isn't dumb. The SaaS it's calling is hostile.

We run a database that catalogs 11,000+ MCP servers and SaaS APIs, and we probe them — real JSON-RPC handshakes, real liveness checks, real robots.txt reads. 1 in 10 cataloged endpoints was simply dead. 1 in 5 live MCP endpoints failed a basic handshake. And that's before your agent even gets to read the docs.

Here's what the data says about why agents fail — and it's mostly not the agent's fault.

TL;DR

1,154 of 11,151 cataloged MCP/API endpoints were dead (removed after our liveness sweep)
892 of 4,367 live JSON-RPC initialize probes failed the handshake (20.4%)
In a deep-dive of 31 major Japanese SaaS products: only 10 ship an official MCP server, and 5 have no publicly reachable developer docs at all — a human can email sales for the PDF; an agent can't
One vendor ships an official MCP server while its API documentation site blocks every bot via robots.txt. The front door is open; the information desk is locked
Auth is a dialect zoo: custom token headers, non-standard Authorization: Token schemes, client-ID-to-Bearer exchanges — each one burns tokens on trial-and-error

1. One in ten endpoints is just... dead

Registries and awesome-lists keep growing, but nobody prunes them. When we swept our full catalog of 11,151 MCP/API endpoints with liveness checks, 1,154 (10.4%) were dead — servers gone, repos abandoned, URLs 404ing.

For a human developer this is a mild annoyance. For an agent it's worse: it confidently selects a tool from a registry, tries to connect, fails, retries, and burns your tokens doing it. Dead endpoints don't look dead in a catalog.

2. One in five live MCP endpoints fails the handshake

We send real JSON-RPC initialize requests to hosted MCP endpoints — the most basic "hello, are you an MCP server?" check.

Out of 4,367 probe attempts: 3,475 succeeded, 892 failed (20.4%). These aren't dead servers — they respond over HTTP. They just don't complete the protocol handshake: wrong content types, auth walls with no discoverable flow, half-implemented spec versions.

If a fifth of "live" agent entrances can't say hello, your agent's retry loop isn't a bug. It's the environment.

3. The docs are locked to humans-only

This one surprised us most. We took 31 major Japanese SaaS products (accounting, HR, e-signature, payments, CRM — the software that runs actual businesses) and verified every fact against vendor primary sources.

5 of the 31 had no publicly reachable developer reference at all. The API exists — but the spec is behind a sales contact, a partner program, or a paid contract. A human developer emails sales and gets the PDF. An agent hits a marketing page and gives up.

And the sharpest case: one major vendor ships an official MCP server while its API documentation site returns 403 to every bot and disallows all crawlers in robots.txt. The agent is invited in and then locked out of the manual. (Full teardown coming in our next report.)

If your docs aren't reachable by an agent, then as far as agents are concerned, your product doesn't exist.

4. Official agent entrances are still rare

Of those 31 major SaaS products:

10 ship an official MCP server (accounting leads: freee and Money Forward both AAA in our index)
10 serve an llms.txt on their product or developer domain
The rest offer "an API" — which in agent terms means: figure out auth, pagination, and error semantics yourself, one failed call at a time

We rated all 26 rateable products AAA–D and published the full table, the scoring formula, and the facts behind every grade. It's here: Agent Readiness Index 2026 Summer.

5. Auth is a dialect zoo

Among just these 31 products we found:

OAuth 2.0 (fine!)
API keys in custom headers
A proprietary Kaonavi-Token header you get via a client-credentials exchange
Authorization: Token {token} — not Bearer, Token — after a Basic-auth token issuance
A client-ID→access-token exchange with 1-hour expiry
An API key and an API token required simultaneously in different headers

None of these are wrong individually. But every non-standard dialect is another way for an agent to fail silently, retry, and burn tokens. Standardization is a feature; every deviation is a tax on every agent that ever connects.

How we measured (and what we don't publish)

Liveness + handshake data: our own automated probes (JSON-RPC initialize against hosted MCP endpoints), continuously since 2026. Counts above are as of 2026-07.
The 31-product deep-dive: every fact (official MCP, public docs, auth method) verified against vendor primary sources — developer docs, press releases, official help — on 2026-07-13. Corrections welcome; we publish a correction log.
What we don't publish: per-vendor success-rate numbers. Our third-party telemetry isn't at a scale where those numbers would be fair yet, so they stay unpublished until it is. Methodology and independence policy are public: kansei-link.com/independence.

The dataset behind this is what our MCP server serves to agents (connection guides, auth pitfalls, failure workarounds for 11,000+ services): npx @kansei-link/mcp-server — free, and every failure report makes the data better.

Your turn

What's the worst API your agent has ever fought with? Dead endpoint, undocumented auth dialect, docs behind a sales call — war stories welcome. We're collecting failure patterns for the next report.

Written with AI assistance; all measurements, verification, and analysis are our own. Data: KanseiLink, measured 2026-07.

Stop letting Claude guess your SaaS API auth flow

michielinksee — Wed, 01 Jul 2026 13:37:29 +0000

The problem

Claude Code is great at writing integration code.

But when I ask it to connect to a SaaS API, the same annoying pattern keeps showing up:

Write auth code
↓
Call the API
↓
Auth error
↓
Fix the scope
↓
Missing required parameter
↓
Fix again
↓
Wrong endpoint version
↓
Try again

By the time it works, I have burned thousands of tokens.

This happens a lot with SaaS APIs like Salesforce, HubSpot, Stripe, Slack, freee, SmartHR, kintone, and others.

The issue is not that Claude cannot write code.

The issue is that Claude often starts with stale assumptions.

SaaS APIs change all the time:

OAuth flows get updated
PKCE becomes required
API versions change
required parameters get added
rate limits change
official docs get reorganized
MCP servers behave differently from direct API calls

If the agent starts with the wrong connection assumptions, everything after that becomes a retry loop.

So I tried a simple fix:

Before letting Claude write API integration code, give it a connection guide.

The idea

Instead of asking Claude to connect directly to a SaaS API, I added an MCP server that tells Claude how to connect first.

claude mcp add kansei-link -- npx @kansei-link/mcp-server

No API key.

No auth.

No setup beyond that.

Now the flow looks like this:

Before:
User → Claude → SaaS API
              ↑
        guessing from stale knowledge

After:
User → Claude → KanseiLINK MCP → connection guide
              ↓
           SaaS API

The goal is not to make Claude “smarter”.

The goal is to stop Claude from guessing.

Example: Salesforce

Before writing code, Claude can ask KanseiLINK what it should know about the service.

search_services({ query: "salesforce crm" })

Example response:

Salesforce
- Grade: BB
- Agent connection success rate: 43%
- Connection type: third-party MCP / API
- Auth: OAuth 2.0
- Known issues:
  - complex scope configuration
  - instance URL varies by org
  - API version must be specified

Then it can ask for the actual connection details.

lookup({ service_id: "salesforce-crm", detail: true })

Example response:

Auth:
  OAuth 2.0

Common pitfalls:
  - instance URL varies per org
  - API version must be specified
  - third-party MCP servers may not support all write operations
  - Bulk API has different requirements

That context is small, but it changes the output a lot.

Claude starts from the right assumptions instead of writing a plausible but outdated integration.

Example: freee accounting

Another example:

lookup({ service_id: "freee-accounting", detail: true })

Example response:

Auth:
  OAuth 2.0 + PKCE

Required:
  company_id

Common pitfalls:
  - PKCE is required
  - company_id must be fetched before posting transactions
  - endpoint versions are easy to confuse
  - missing scopes cause auth failures

This is exactly the kind of information that prevents a 3-turn debugging loop.

Before vs after

I tested this on a few common SaaS integration tasks.

This is not a formal benchmark, but I tracked token usage and retries in my own Claude Code workflow.

Task	Before	After	Reduction
Salesforce opportunity update	~5,500 tokens	~1,800 tokens	67%
HubSpot contact creation	~3,400 tokens	~1,200 tokens	65%
Stripe invoice generation	~2,800 tokens	~1,100 tokens	61%
Slack webhook setup	~2,100 tokens	~900 tokens	57%

On average, this reduced token usage by around 60–70%.

The savings mostly came from removing failed retries.

The lookup itself is cheap.

A failed retry is expensive.

The MCP tools

KanseiLINK MCP currently exposes three simple tools.

1. search_services

Use this to find the right service.

search_services({ query: "accounting invoice" })

Example response:

freee: AAA grade, high success rate, API/MCP support
QuickBooks: A grade, API-first
Xero: BBB grade, community MCP available

The useful part is that services are ranked by how easy they are for agents to actually connect to.

Not by marketing claims.

Not by popularity.

By agent connection signals.

2. lookup

Use this before writing code.

lookup({ service_id: "freee-accounting", detail: true })

Example response:

Auth:
  OAuth 2.0 + PKCE

Rate limit:
  300 requests / 5 min

Required:
  company_id

Gotchas:
  - PKCE is mandatory
  - company_id must be fetched first
  - some endpoint versions are easy to confuse

This is the main value.

Claude gets the connection map before it starts coding.

3. report

Optional, but useful.

report({
  service_id: "freee-accounting",
  success: true
})

Or:

report({
  service_id: "freee-accounting",
  success: false,
  reason: "OAuth scope mismatch"
})

This helps improve the connection data over time.

Why not just read the docs?

You should read the docs.

But when working with coding agents, there are three practical problems.

1. Model knowledge is stale

Claude or GPT may know an older version of an API.

That is enough to cause a bad first implementation.

2. Docs are long

The answer might be in the docs, but buried across multiple pages:

auth
scopes
rate limits
object IDs
endpoint versions
sandbox behavior
write permissions

If you make the agent read everything from scratch, you may burn tokens before writing any useful code.

3. MCP-specific issues are not in vendor docs

This is the biggest one.

A direct API call may work, but an MCP server may fail because:

the MCP server is outdated
only read operations are supported
write operations have lower success rates
OAuth scopes are handled differently
the server wraps the API in a non-obvious way

Vendor docs usually do not cover that.

Agent connection data does.

What it covers

KanseiLINK currently includes connection data for 11,000+ SaaS and API services.

Some examples:

Accounting:
  freee
  QuickBooks
  Xero
  MYOB

CRM:
  Salesforce
  HubSpot
  Sansan

HR:
  BambooHR
  SmartHR
  Gusto

Dev tools:
  GitHub
  GitLab
  Jira
  Linear

Other:
  Slack
  Notion
  Stripe
  Twilio

Each service has a grade from AAA to C.

AAA: likely to work smoothly
A: usable with minor care
BBB: some friction expected
BB: expect issues
C: difficult to connect

This is not a rating of the product.

It is a rating of how easy it is for an AI agent to discover, understand, connect, and execute against that service.

Setup

Claude Code:

claude mcp add kansei-link -- npx @kansei-link/mcp-server

Claude Desktop:

{
  "mcpServers": {
    "kansei-link": {
      "command": "npx",
      "args": ["@kansei-link/mcp-server"]
    }
  }
}

GitHub:

https://github.com/kansei-link/kansei-mcp-server

Takeaway

When Claude Code struggles with SaaS API integration, the problem is often not code generation.

It is the starting context.

If the agent starts with stale API assumptions, you pay for retries.

If the agent starts with a current connection guide, it writes better code sooner.

That is the whole trick:

Give the agent the map before asking it to drive.

If you are using Claude Code, Cursor, or any AI coding agent for SaaS API integration, this can save real tokens and real time.

I let AI build my products for months — then I couldn't tell what any of them were anymore

michielinksee — Tue, 16 Jun 2026 08:11:45 +0000

Claude Code and Cursor make you ship fast.

But once I was running several products in parallel — and across several different LLMs (Claude Code, Cursor, ChatGPT) — a different problem showed up:

I'd forget what I'd decided (the human)
A design I locked in via Claude Code, the Cursor session didn't know about (the LLM)
The README and the code drifted apart
The CLI changed, but npm and the docs stayed old
Neither I nor the AI could say which part of the product we were even touching

Every single change was correct. But the product as a whole kept sliding away from what it was supposed to be.

That's rough.

Building just one product? CLAUDE.md is probably enough. This is for people juggling several.

There's a name for this now: intent drift — the product slowly diverging from what you meant to build.

The exact moment it bites

You ask Claude Code:

fix the CLI setup flow

It does. Perfectly.

But to actually match that change, you probably also needed to touch:

README
the npm description
the GitHub install steps
docs
the landing page
the demo screenshot

The AI fixes the spot you asked about. That's it.

So you get:

The engine is fine. The install steps are stale. Users get stuck.

That's scarier than a bug. The code runs — the story around it is wrong.

Here's the tool catching exactly that — the README promises a --export flag the code doesn't have, and it shows the blast radius too:

A product has a map

A product grows along a path:

discovered → understood → tried → installed → kept → paid → expanded

And under each step sits a stack of surfaces:

LP / README / npm / GitHub / CLI / MCP / dashboard / docs / Stripe / support

While coding, you want to know: "where on this map am I, and if I change this, what else moves?" But running several products across several LLMs, that map falls out of your head — and nobody is tracking it. That's the drift.

So I'm building Linksee Memory

A local-first tool that records the decisions, the implementation, and the drift as you build with AI — so you can see them later.

It started as a memory tool. Now I think of it differently:

A shared map of the project — for the human and the multiple AIs.

Three commands.

1. What's drifting?

npx linksee-memory map status

Lists what's out of sync:

README says it, code doesn't
CLI changed, docs are old
LP and README disagree
a flow you planned, then abandoned

2. What do I fix next?

npx linksee-memory map next

3. Show me the whole map

npx linksee-memory map blueprint

Bonus: npx linksee-memory map where README.md tells you where a file sits, and what changing it would touch.

It all lives in a local SQLite file — so Claude Code, Cursor, ChatGPT, Codex and Gemini share the same map. No cloud, no API key, MIT.

Why it helps

The scariest thing in AI development isn't the code breaking.

It's the code working while the product's story — install, docs, promises — quietly drifts.

Try it

npx linksee-memory init

Everything stays local. Nothing leaves your machine.

repo: https://github.com/michielinksee/linksee-memory
landing: https://linksee-site.vercel.app

A GitHub star genuinely makes my day 🙏

I'd love your take

If you run multiple products / multiple LLMs — have you hit the "wait, what was this even for?" moment?

Was it a memory problem, or a map problem?
Of "what's drifting," "what's next," and "the whole map" — which would you actually use?

Drop a comment, or find me on X (@michielinksee).

Solo founder in Singapore, building in public.

I Built an MCP Server to Stop Claude Code from Forgetting Everything Between Sessions

michielinksee — Fri, 29 May 2026 10:30:27 +0000

TL;DR

Problem: Claude Code starts every session cold. It re-suggests libraries I already rejected, asks "should we use X?" about decisions made weeks ago, and re-reads unchanged files from scratch (paying full tokens each time).
Solution: I built linksee-memory — an MCP server with 6 structured memory layers and chunk-level file diff caching. Local SQLite, MIT, no cloud. Works across Claude Code / Cursor / Codex / Gemini CLI from the same database.
The feature that actually changed my workflow: the caveat layer — forget-protected entries for "never do this again". Cut repeat-suggestions of bad patterns to zero.
Install: npm install -g linksee-memory

The problem: my agent kept making the same mistake

Three Mondays in a row last month, I explained the same deploy failure to Claude Code. The root cause was identical each time: our production Cloudflare Workers had a memory-cache incoherence issue between distributed instances. Each session, I walked through the same investigation — same files, same logs, same 30-minute trail to the same conclusion.

Claude Code doesn't remember previous sessions. So every Monday morning, I was re-discovering the same bug with my agent from scratch.

I tried the available solutions; none fit:

Tool	What's good	Where it fell short for me
`CLAUDE.md`	Zero setup, official	Flat structure, model ignores parts of it
Mem0	Hosted, easy install	Cloud-only, no "pain memory" concept
Letta	Built into an agent framework	Can't share memory across MCP clients
Zep	Graph-based, strong relationships	Single-client; I also use Cursor and Codex

All good products optimizing for different things. But the one feature I wanted most — a guarantee that I'll never repeat the same mistake — wasn't in any of them.

So I built linksee-memory.

The design: 6 layers, with `caveat` as the hero

linksee-memory organizes memory into 6 explicit layers:

+-- goal           Why are we doing this?
+-- context        Current situation & constraints
+-- emotion        User's mood, tone of the relationship
+-- implementation How we built it (success or failure)
+-- caveat         Pain lessons (forget-protected)
+-- learning       Growth log & realizations

The key design principle is WHY-first. Other tools store facts ("we use PostgreSQL"). linksee-memory separates the WHY ("we chose PostgreSQL because the workload is OLTP with strict consistency needs") from the WHAT ("connection pool: 20, timeout: 30s").

The caveat layer is special. Entries there are permanently protected from auto-forgetting — even when old memories decay and get consolidated, caveats stay forever. This is how I enforce "never make this mistake again" as a structural property, not prompt discipline.

3 tools, not 8

Early versions had 8 separate tools (remember, update_memory, forget, recall, recall_file, list_entities, consolidate, read_smart). This worked fine in Claude Code where I could teach tool selection via SKILL.md.

But Cursor couldn't tell recall from recall_file. Codex mixed up remember and update_memory. Too many tools = LLM tool selection breaks down.

v0.7 unified everything into 3 tools:

Tool	What it does
`remember`	Create, update, or delete a memory. Mode auto-detected from params.
`recall`	Search memories, get file history, or list entities. Mode auto-detected from params.
`read_smart`	Read a file with chunk-level diff caching.

// Create
remember({ entity_name: "MyProject", layer: "caveat", content: "..." })

// Update (was: update_memory)
remember({ memory_id: 42, content: "updated content" })

// Delete (was: forget)
remember({ forget: true, memory_id: 42 })

// Search (was: recall)
recall({ query: "RLS policy", layer: "caveat" })

// File history (was: recall_file)
recall({ path: "server.ts" })

// Entity overview (was: list_entities)
recall({})

One tool name per intent. Every LLM client handles it correctly now.

The part that surprised me: `read_smart()`

Structured memory is half the tool. The other half is file-diff caching.

Think about what your agent does at the start of every session:

Re-reads package.json
Re-reads your main entry file
Re-reads the config
Re-reads the tests

Each file is maybe 500-2000 lines. Each session, you pay full tokens to re-read all of them. But in most sessions, most of these files haven't changed.

read_smart() fixes this with chunk-level caching:

// First read: full file, chunked and cached
const r1 = read_smart({ path: "src/http-server.ts" });
// -> full content, ~3400 tokens

// Same session, no change: cache hit
const r2 = read_smart({ path: "src/http-server.ts" });
// -> { status: "unchanged", tokens_used: ~50 }

// After editing 2 functions: only changed chunks returned
const r3 = read_smart({ path: "src/http-server.ts" });
// -> only the 2 changed function chunks, ~340 tokens

Chunk boundaries are language-aware:

Code (TS / JS / Python / etc.): AST-based, one chunk per function or class
Markdown: one chunk per h2 / h3 section
JSON / YAML: one chunk per top-level key

Cache keys are sha256(chunk_content). In practice, I see ~86% token reduction on file re-reads.

Concrete example: the caveat that stopped Claude from repeating

Here's a real example of caveat working.

A few weeks ago, for a one-off data migration task, Claude suggested "let's set up a cron job". One-off tasks shouldn't use cron (auth rotation overhead, monitoring cost, retry logic that doesn't match one-off semantics).

I stored one caveat entry:

Don't propose cron for one-off tasks. Alternatives: GitHub Actions workflow_dispatch, or a manual script with a completion notification.

In the 4 sessions before I added that caveat, Claude suggested cron 4 times for one-off tasks.

In the 3 weeks since? Zero.

And because all my LLM clients share the same SQLite file, the caveat also works in Cursor, Codex, and Gemini CLI — not just Claude Code.

Install (2 minutes)

Claude Code

npm install -g linksee-memory
claude mcp add -s user linksee -- npx -y linksee-memory

Cursor

Settings -> Features -> "Model Context Protocol" -> Edit:

"linksee": {
  "command": "npx",
  "args": ["-y", "linksee-memory"]
}

OpenAI Codex

codex mcp add linksee-memory -- npx -y linksee-memory

Gemini CLI

~/.gemini/settings.json:

{
  "mcpServers": {
    "linksee": {
      "command": "npx",
      "args": ["-y", "linksee-memory"]
    }
  }
}

Everything runs locally. SQLite file at ~/.linksee-memory/memory.db. No cloud, no API key, no telemetry. MIT licensed.

Because memory lives in a single SQLite file, it's shared across all MCP clients on your machine. My Claude Code sessions and my Cursor sessions see the same memory.

I'd genuinely love feedback

I've been using this daily for 3+ months, and my results are biased by the fact that I designed it for my own workflow. I'd like to know:

Does the caveat layer actually prevent your agent from repeating mistakes, or am I pattern-matching on one dataset (me)?
How does the chunk cache behave on your codebase? Monorepos, generated code, notebooks — I'd love bug reports.
Is 6 layers too many? Too few? Are there memory types you want that none of these cover?

Open an issue on GitHub, or ping me on X at @ELLECraftsinga1. I respond to everything.

GitHub: https://github.com/michielinksee/linksee-memory
Docs: https://docs.linksee.app

I built an MCP server that helps agents find and orchestrate other MCP servers

michielinksee — Thu, 02 Apr 2026 13:19:35 +0000

The Problem
MCP servers are multiplying fast. There are now MCP servers for accounting (freee), HR (SmartHR), project management (Backlog), messaging (Chatwork, LINE WORKS, Slack), and more — just for Japanese SaaS alone.

But when you tell an agent "create and send an invoice," it has to figure out:

Which MCP handles invoices?
How to combine multiple MCPs for a complete workflow?
Has anything changed since last time?
There's no discovery layer. Every agent starts from zero.

What I Built
An MCP server that searches, combines, and tracks other MCP servers.

npx @kansei-link/mcp-server

DEV Community: michielinksee

5 ways SaaS products lock out AI agents — data from probing 11,000+ services

TL;DR

1. One in ten endpoints is just... dead

2. One in five live MCP endpoints fails the handshake

3. The docs are locked to humans-only

4. Official agent entrances are still rare

5. Auth is a dialect zoo

How we measured (and what we don't publish)

Your turn

Stop letting Claude guess your SaaS API auth flow

The problem

The idea

Example: Salesforce

Example: freee accounting

Before vs after

The MCP tools

1. search_services

2. lookup

3. report

Why not just read the docs?

1. Model knowledge is stale

2. Docs are long

3. MCP-specific issues are not in vendor docs

What it covers

Setup

Takeaway

I let AI build my products for months — then I couldn't tell what any of them were anymore

The exact moment it bites

A product has a map

So I'm building Linksee Memory

1. What's drifting?

2. What do I fix next?

3. Show me the whole map

Why it helps

Try it

I'd love your take

I Built an MCP Server to Stop Claude Code from Forgetting Everything Between Sessions

TL;DR

The problem: my agent kept making the same mistake

The design: 6 layers, with caveat as the hero

3 tools, not 8

The part that surprised me: read_smart()

Concrete example: the caveat that stopped Claude from repeating

Install (2 minutes)

Claude Code

Cursor

OpenAI Codex

Gemini CLI

I'd genuinely love feedback

I built an MCP server that helps agents find and orchestrate other MCP servers

The design: 6 layers, with `caveat` as the hero

The part that surprised me: `read_smart()`