DEV Community: Petter_Strale

Add Counterparty Verification to Your AI Agent in 5 Minutes

Petter_Strale — Sat, 04 Apr 2026 15:29:06 +0000

Your AI agent can browse the web, write code, and manage calendars. Can it answer "is this company real?" before it processes a payment or sends sensitive data?

Counterparty verification is standard practice in financial services. Confirming that the entity you're dealing with is registered, active, and not sanctioned. Every bank does it. Every payment processor does it. AI agents skip it entirely, because the data is scattered across government registries, sanctions lists, and commercial databases that weren't built for programmatic access.

Here's how to fix that in about 5 minutes.

The problem in practice

Say your agent is processing an invoice from a UK supplier. Before authorizing payment, you want to know four things: Is the company actually registered at Companies House? Is it active or dissolved? Who are the directors and persons with significant control? Are any of them on sanctions lists?

Without a verification layer, your agent either skips these checks (risky) or you build custom integrations to Companies House, OFAC, EU sanctions lists, and UN consolidated lists. That's weeks of work and ongoing maintenance for each jurisdiction you add.

MCP: zero code

If your agent supports MCP (Claude Desktop, Cursor, Windsurf, or any MCP-compatible client), connect Strale's MCP server:

{
  "mcpServers": {
    "strale": {
      "type": "streamableHttp",
      "url": "https://api.strale.io/mcp"
    }
  }
}

Your agent now has 271 tools available. Ask it to verify a company and it finds and calls the right capability:

"Verify that Acme Trading Ltd is a real, active UK company and check the directors against sanctions lists."

The agent calls kyb-essentials-uk, gets back registration status, officers, beneficial ownership, and sanctions screening results. Structured JSON with provenance metadata and a quality score.

LangChain / CrewAI: three lines

from langchain_strale import StraleToolkit

toolkit = StraleToolkit(api_key="sk_live_...")
tools = toolkit.get_tools()

That gives your agent access to the full capability set. The toolkit handles discovery, input formatting, and response parsing.

For CrewAI:

from crewai_strale import StraleToolkit

toolkit = StraleToolkit(api_key="sk_live_...")
tools = toolkit.get_tools()

agent = Agent(
    role="Compliance Analyst",
    tools=tools,
    goal="Verify counterparties before transactions"
)

Also available for Semantic Kernel, OpenAI Agents SDK, Google ADK, and Pydantic AI.

Direct API call

curl -X POST https://api.strale.io/v1/execute/kyb-essentials-uk \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"company_name": "Acme Trading Ltd"}'

Response:

{
  "result": {
    "company_name": "ACME TRADING LTD",
    "company_number": "12345678",
    "status": "active",
    "incorporated": "2019-03-15",
    "registered_address": "10 Downing Street, London",
    "officers": [...],
    "persons_with_significant_control": [...],
    "sanctions_check": {
      "is_sanctioned": false,
      "lists_checked": ["OFAC SDN", "EU Consolidated", "UN Security Council"]
    }
  },
  "meta": {
    "quality_score": { "grade": "A", "score": 92 },
    "provenance": {
      "source": "companies-house.gov.uk",
      "fetched_at": "2026-04-04T10:23:15Z"
    },
    "transaction_id": "txn_abc123",
    "verify_url": "https://api.strale.io/v1/verify/txn_abc123"
  }
}

The meta block gives your agent and your compliance team everything needed for an audit trail: where the data came from, when, how reliable it is, and a public URL to verify the result independently.

What's available beyond the UK

271 capabilities across 27 countries. KYB bundles for UK, Norway, Sweden, and Australia that combine company data, sanctions, and beneficial ownership in one call. IBAN validation across 80+ countries. EU VAT validation via VIES. Sanctions screening against OFAC, EU, and UN lists. Domain reputation and WHOIS lookups for verifying a counterparty's web presence. Beneficial ownership via UK Companies House PSC register, with Nordic registries next.

Honest limitation: beneficial ownership is UK-only right now. If your counterparty is registered in Singapore or Delaware, you'll get company data and sanctions screening but not the ownership chain. I'm working on expanding that.

All priced per call, €0.02 to €2.50. No monthly minimums. Charged only on success.

How the scoring works

Every capability is tested by 1,500+ automated test suites. The results are published as a dual-profile quality score. One profile measures the capability itself (correctness, schema compliance, error handling). The other measures the reliability of its upstream data source. A sanctions check scoring 95 is more useful to your agent than one scoring 60, and the score tells you which is which before you pay for the call.

Methodology: strale.dev/trust

We're based in Sweden and bootstrapped. If you're building agents that need to verify counterparties, suppliers, or partners, we'd like to hear what data you need that isn't available yet.

strale.dev. Free capabilities available, €2 trial credit, no card required.

Your DeFi Due Diligence Takes 20 API Calls. It Should Take One.

Petter_Strale — Sat, 04 Apr 2026 14:30:59 +0000

Last week I watched someone investigate a DeFi project using my API platform. They made 23 calls over two days across three different tools. The pattern was always the same:

DNS lookup on the project domain. Does it even exist?
Check domain variants (.com, .io, .finance, .xyz). Squatting or legitimate?
Validate team email addresses. Do the domains resolve?
Scrape the website. Does the content match the whitepaper claims?

They were checking whether a project called OceanSwap was real. Four domain variants, all non-existent. Strong signal. But they had to make four separate calls to learn that.

This is how most DeFi due diligence works today: manual, slow, and fragmented. You piece together free tools, cross-reference results in your head, and hope you didn't miss something.

What the manual approach misses

The DNS + email + website scrape pattern catches the obvious fakes. It won't catch sanctions exposure. Is the team or any associated wallet on OFAC, EU, or UN sanctions lists? You're not checking this manually because the data sources are behind paywalls and the APIs are painful to integrate.

It also won't tell you whether there's an actual registered entity behind the project. A UK company check takes one call if you know the company number, but most DeFi projects don't advertise their Companies House registration. And even if you find the company, you still don't know who actually controls it. Beneficial ownership registries exist in most EU countries. Querying them programmatically is a different kind of painful.

Then there's adverse media. Has the project or its founders appeared in negative news coverage? That requires searching multiple news sources and filtering for relevance. Not something you do with a DNS lookup.

The single-call alternative

The same investigation as a structured verification:

curl -X POST https://api.strale.io/v1/execute/kyb-essentials-uk \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"company_name": "OceanSwap Ltd"}'

One call. You get back company registration status (active, dissolved, or not found), registered address, officer names, beneficial ownership chain, sanctions screening against OFAC/EU/UN lists, adverse media mentions, and a quality score telling you how reliable each data point is.

Cost: €1.50 to €2.50 depending on jurisdiction. Time: under 3 seconds.

For OceanSwap, the response would come back with "company not found" across all registries. Same conclusion the manual researcher reached, but in one call instead of 23.

A limitation worth mentioning: beneficial ownership data is currently UK-only (Companies House PSC register). Nordic registries are next, but if you're investigating a Cayman Islands shell company, you'll hit the same wall everyone else does.

When the manual approach still makes sense

Free tools are fine for a quick sniff test. If you just want to know "does this domain exist?" then dns-lookup is free and instant. If you want to read a project's website without opening a browser, url-to-markdown handles that.

The structured verification becomes worth it when you're evaluating multiple projects and need consistency, when you need sanctions or beneficial ownership data that free tools can't provide, when you're building an agent that does this automatically, or when you need an audit trail of what you checked and when.

For agent builders

If you're building a DeFi research agent, the MCP integration is a few lines of config:

{
  "mcpServers": {
    "strale": {
      "type": "streamableHttp",
      "url": "https://api.strale.io/mcp"
    }
  }
}

Your agent gets access to 271 capabilities. The free ones (DNS, email validation, IBAN, URL scraping) work without signup. Compliance capabilities (sanctions, KYB, beneficial ownership) need an API key and cost €0.02 to €2.50 per call.

Every response includes provenance metadata (where the data came from, when it was fetched) and a quality score so your agent can assess confidence before acting on the result.

I built Strale as a solo founder in Sweden. 271 capabilities, 27 countries, 1,500+ automated test suites. If you're doing DeFi due diligence manually or building agents that need to verify counterparties, I'd like to hear what's missing from your workflow.

strale.dev. Free capabilities available, €2 trial credit on signup, no card required.

One API Call to Know If Your Dependency Is Safe

Petter_Strale — Thu, 02 Apr 2026 10:36:54 +0000

A coding agent just suggested adding a package to your project. You've never heard of it. How do you decide whether to trust it?

Most developers either accept the suggestion blindly or spend fifteen minutes checking GitHub stars, last commit date, the npm advisory database, and whatever license file happens to exist. Agents can't do either — they need a structured signal, fast.

The data exists. It's just scattered.

The information you need to evaluate a dependency already exists across public APIs. OSV.dev maintains a comprehensive vulnerability database covering CVEs and GitHub Security Advisories across npm, PyPI, Go, Rust, and more. Google's deps.dev aggregates dependency graphs, license metadata, and OpenSSF Scorecard results — the 18-check security health assessment that most developers have never heard of despite it covering over a million projects. The npm and PyPI registries themselves tell you when a package was last published, whether it's deprecated, and how many maintainers it has.

The problem isn't data availability. It's that these are five or six separate HTTP calls with different request formats, different response schemas, and different failure modes. An agent checking one dependency has to call OSV.dev with a POST body specifying ecosystem and version, then hit deps.dev's REST API to get the linked GitHub project, then make another call to deps.dev for the OpenSSF Scorecard, then query the registry for freshness signals. Then it has to synthesize all of that into a decision. Multiply that by forty dependencies in a lockfile and you've built an integration project, not a quick check.

What we built

package-security-audit aggregates all of the above into a single API call. You pass a package name and optionally a version and ecosystem. It calls OSV.dev, deps.dev, and the relevant registry in parallel, normalizes everything, and returns a 0–100 risk score with the evidence behind it.

curl -X POST https://api.strale.io/v1/do \
  -H "Authorization: Bearer $STRALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "package-security-audit",
    "inputs": { "name": "express", "version": "4.18.2" }
  }'

Here's what comes back (trimmed to the output fields):

{
  "output": {
    "name": "express",
    "version": "4.18.2",
    "ecosystem": "npm",
    "risk_score": 94,
    "risk_level": "low",
    "vulnerabilities": {
      "total": 2,
      "critical": 0,
      "high": 0,
      "medium": 0,
      "low": 2,
      "details": [
        {
          "id": "GHSA-qw6h-vgh9-j6wx",
          "severity": "low",
          "summary": "express vulnerable to XSS via response.redirect()",
          "fixed_in": "4.20.0"
        },
        {
          "id": "GHSA-rv95-896h-c2vc",
          "severity": "moderate",
          "summary": "Express.js Open Redirect in malformed URLs",
          "fixed_in": "4.19.2"
        }
      ]
    },
    "license": {
      "spdx": "MIT",
      "is_osi_approved": true,
      "is_copyleft": false
    },
    "freshness": {
      "latest_version": "5.2.1",
      "is_latest": false,
      "is_deprecated": false,
      "days_since_last_release": 121
    },
    "maintainers": 5,
    "dependency_count": 0
  },
  "provenance": {
    "source": "osv.dev + deps.dev + registry",
    "fetched_at": "2026-04-02T10:30:33.440Z"
  }
}

Express 4.18.2 scores 94/100 — low risk. Two low-severity vulnerabilities, both with known fix versions. MIT license, five maintainers, not deprecated. The only flag: it's not the latest version (5.2.1 is out). An agent can read that response and make a decision in milliseconds. The whole call took 486ms.

The second capability, license-compatibility-check, handles a different question: given a set of licenses across your dependency tree, are they all compatible with your use case?

curl -X POST https://api.strale.io/v1/do \
  -H "Authorization: Bearer $STRALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "license-compatibility-check",
    "inputs": {
      "licenses": ["MIT", "Apache-2.0", "GPL-3.0-only"],
      "use_case": "commercial"
    }
  }'

{
  "output": {
    "compatible": false,
    "use_case": "commercial",
    "license_count": 3,
    "licenses_analyzed": [
      { "input": "MIT", "type": "permissive", "compatible_with_use_case": true },
      { "input": "Apache-2.0", "type": "permissive", "compatible_with_use_case": true },
      { "input": "GPL-3.0-only", "type": "strong_copyleft", "compatible_with_use_case": false }
    ],
    "conflicts": [
      {
        "licenses": ["GPL-3.0-only"],
        "reason": "GPL-3.0-only is strong copyleft — requires distributing your source code under the same license. Incompatible with proprietary commercial distribution.",
        "severity": "error"
      }
    ],
    "summary": "1 compatibility conflict(s) found for commercial use. Strong copyleft licenses detected."
  }
}

It covers 30+ SPDX licenses and knows the specific compatibility rules that trip people up — GPL-2.0 and GPL-3.0 are mutually incompatible unless "or-later" is used, Apache-2.0 conflicts with GPL-2.0-only, and AGPL in any dependency makes your entire SaaS project AGPL-bound. Purely algorithmic, 8ms response time.

The dependency-risk-check solution chains both: security audit plus license compatibility in a single call for €0.25.

How it works under the hood

The security audit makes four parallel requests. OSV.dev gets queried with the specific package version and ecosystem to find known vulnerabilities. deps.dev provides the license, dependency count, and a link to the source repository. If that repository is on GitHub, a second deps.dev call fetches the OpenSSF Scorecard — an automated assessment of 18 security practices including branch protection, code review, dependency update tooling, and fuzzing coverage. The registry API supplies freshness and deprecation data.

Penalties are applied to a starting score of 100: critical CVEs cost 25 points each, deprecated packages lose 20, packages not updated in over two years lose 20, and missing licenses lose 15. The floor is zero. If any upstream source is temporarily unavailable, the remaining sources still produce a partial score rather than failing the entire call.

Every response includes provenance metadata — which sources were queried and when — so the agent or human reviewing the decision can trace where the data came from.

For agent builders

The practical use case is making npm install or pip install a decision an agent can make autonomously. With Strale's MCP server, a coding agent can check any package before adding it — no configuration, no API keys to manage beyond the Strale key.

npx strale-mcp

Any MCP-compatible client (Claude Code, Cursor, Windsurf, or anything else speaking the protocol) can call package-security-audit directly. The agent gets back structured JSON it can reason over: a numeric risk score, specific vulnerabilities with fix versions, and a clear compatible/incompatible verdict on licensing. That's enough to make an autonomous yes/no decision, or to surface a warning to the developer when the score is marginal.

package-security-audit costs €0.15 per call. license-compatibility-check costs €0.05. That's cheap enough to check every dependency in a typical lockfile for under €10.

Both capabilities are live now. The API docs have the full input/output schemas, or you can browse the capability catalog to see them alongside the 270+ other capabilities available. The source is at github.com/strale-io.

I Scanned 10 Developer Tools for AI Agent-Readiness. Only One Passed.

Petter_Strale — Wed, 01 Apr 2026 19:52:37 +0000

Everyone's building AI agents. Nobody's building for them.

I've been working on agent integrations and kept running into the same problem: when we say "AI agents can use APIs," how many developer tools are actually set up for an agent to discover and interact with autonomously?

So I ran an agent-readiness audit on 10 well-known developer tools. The scanner checks 32 signals across 6 categories:

Discoverability — can agents find you?
Comprehension — can agents understand your API?
Usability — can agents interact with you?
Stability — can agents depend on you?
Agent Experience — what happens when an agent shows up?
Transactability — can agents do business with you?

Each category gets a tier: Ready, Partial, or Not Ready. To "pass," a tool needs at least half its categories at Ready.

One tool passed. Nine didn't.

The Results

Resend — 4/6 Ready ✅

The clear winner, and it wasn't close. Resend has an MCP endpoint at /.well-known/mcp.json, a public OpenAPI spec with 39 fully documented endpoints, Schema.org structured data on the homepage, and returns proper JSON errors with consistent structure.

This is what agent-readiness actually looks like: an agent can discover the API through protocol-based discovery (MCP), understand the full API surface through machine-readable specs (OpenAPI), and verify what the product does through structured data. No human intervention required at any step.

Stripe — 1/6 Ready (Stability)

The most surprising result on the list. Stripe literally invented the Agentic Commerce Protocol. They have a proper llms.txt file. They are, arguably, the most developer-friendly API on the internet.

But: no OpenAPI spec at standard discoverable paths, no MCP endpoint, no /.well-known/agent.json. Agent Experience scored Red. An agent hitting Stripe's /api endpoint gets an HTML page, not a machine-readable spec.

The company building the future of agent payments isn't agent-ready itself.

Vercel — 1/6 Ready (Stability)

Good fundamentals — changelog, status page, proper security headers. But the OpenAPI spec is behind a login wall, and there's no MCP endpoint. An agent would find the documentation but couldn't machine-read the API surface without authenticating first.

Postmark — 1/6 Ready (Discoverability)

Has structured data and llms.txt, which is already more than most. But the scanner got rate-limited (429) on half its checks — the pricing page, signup page, and several API paths all returned "Too Many Requests."

This is actually an interesting finding in itself: aggressive rate limiting without rate-limit headers means agents get blocked with no way to self-throttle. If your rate limiter doesn't include Retry-After or X-RateLimit-* headers, you're not just blocking abuse — you're blocking legitimate agent discovery.

Clerk — 0/6 Ready

Has an impressive 2,395-line llms.txt — more content than most tools' entire documentation. But no OpenAPI spec at discoverable paths, no MCP, and the Terms of Service appear to prohibit automated access.

All that content investment is invisible to protocol-based agent discovery.

Neon — 0/6 Ready

The llms-full.txt is 32,588 lines — by far the largest in the set. But Comprehension scored Red because there's no OpenAPI spec at discoverable paths, and no structured data on the homepage.

This is the clearest example of a pattern I kept seeing: heavy investment in LLM-readable content while missing the machine-readable infrastructure that agents actually use for discovery.

Supabase — 0/6 Ready

This one genuinely surprised me. Supabase has an MCP server — I use it daily. But /.well-known/mcp.json returns 404. No structured data, no OpenAPI spec at standard paths, llms.txt exists but was flagged as basic. Discoverability scored Red.

The tools are there, but the front door isn't wired up for autonomous discovery. An agent using MCP protocol-based discovery would never find Supabase's MCP server.

Plaid — 0/6 Ready

Documentation is good, sandbox is available, but no MCP, no OpenAPI at standard paths. Pricing is behind a table with no structured data. An agent comparing fintech APIs programmatically wouldn't be able to include Plaid in its evaluation.

Twilio — 0/6 Ready

Both Discoverability and Agent Experience scored Red. The llms.txt exists but was too large to parse (body truncated). No MCP, no OpenAPI at discoverable paths. For a company that's been API-first for 15+ years, the agent layer is essentially absent.

SendGrid — 0/6 Ready

Inherits Twilio's infrastructure (it's a Twilio product now), so same limitations. The openapi.json path returns an HTML page instead of JSON — which is a particularly frustrating failure mode for an agent expecting structured data.

What the Data Actually Shows

The gap isn't API quality. Every tool on this list has APIs that developers love. The gap is in the discovery and machine-readability layer — the difference between "a developer can read our docs" and "an agent can programmatically find, evaluate, and start using our API."

Three specific findings stood out:

Almost nobody has `/.well-known/mcp.json`

Only Resend. This is the standard path for MCP protocol-based discovery — how an agent using MCP finds your server endpoint. Without it, your MCP server might exist, but agents following the protocol can't discover it.

`llms.txt` adoption is strong — but insufficient

8 out of 10 tools had an llms.txt file. That's encouraging adoption. But llms.txt solves a different problem than agent discovery. It helps LLMs understand what your product does. It doesn't help an agent using MCP or A2A protocol-based discovery find your API.

An agent browsing /.well-known/mcp.json endpoints won't read your llms.txt. Different protocols, different discovery mechanisms.

Size of `llms.txt` doesn't correlate with readiness

This was the most counterintuitive finding. Neon's 32,588-line file didn't help because the structured infrastructure around it was missing. Resend's much smaller file worked because it had OpenAPI, MCP, and structured data backing it up.

The lesson: llms.txt is valuable when it sits on top of solid machine-readable infrastructure. It's not valuable as a replacement for that infrastructure.

What This Means for Builders

If you're building agents that need to autonomously discover and evaluate APIs, you're going to hit walls everywhere. The infrastructure layer that MCP, A2A, and x402 assume — machine-readable discovery, structured pricing, programmatic auth documentation — barely exists yet.

Build your agents to handle graceful degradation, because most APIs are still built for human developers browsing documentation pages, not autonomous agents making programmatic decisions.

And if you're building an API: the bar for agent-readiness is lower than you think. Resend passed with straightforward infrastructure — a public OpenAPI spec, an MCP endpoint at the standard path, and structured data on the homepage. No exotic technology. Just the basics, done correctly.

The scanner is free at scan.strale.io if you want to check your own stack. Happy to share the full JSON scan reports for any of these tools — just ask in the comments.

Your DeFi Agent Can Read the Blockchain. It Can't Read a Sanctions List.

Petter_Strale — Mon, 30 Mar 2026 10:16:52 +0000

Your DeFi agent reads on-chain data all day. Balances, transactions, contract code, TVL, gas prices — everything the blockchain makes public. It can tell you that wallet 0xd8dA...96045 holds 3,400 ETH, made 1,247 transactions, and first transacted in 2015.

What it can't tell you: whether the entity behind that wallet is sanctioned. Whether they're a politically exposed person. Whether there's fraud coverage in the press. Whether the exchange they're using is actually licensed under EU MiCA.

None of that lives on the blockchain. And as of 2025, regulators expect you to check.

The gap is real

Here's what on-chain data gives you:

Wallet balances and token holdings
Transaction history
Smart contract source code
TVL, liquidity pools, gas prices
Token prices, DEX volumes

And here's what you need for compliance that the blockchain doesn't have:

Sanctions screening — is this entity on OFAC, EU, or UN lists?
Entity identity — who is the person or company behind this wallet?
VASP licensing — is this exchange authorized under MiCA?
PEP screening — is the counterparty politically exposed?
Adverse media — any fraud reports, lawsuits, or investigations?
Domain trust — is the project website legitimate or a phishing clone?

If your agent is making financial decisions — swapping tokens, depositing into protocols, evaluating counterparties — it's operating blind on half the risk picture.

Bridging the gap: wallet to compliance in one call

We built 17 capabilities specifically for this problem. They're all available via x402 (pay per call with USDC on Base) or via standard API key.

Here's the pipeline that chains on-chain identity with off-chain compliance:

# Step 1: Who is behind this wallet?
curl -X POST https://api.strale.io/v1/do \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "ens-reverse-lookup",
    "inputs": {"address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"}
  }'

Response:

{
  "address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  "has_ens": true,
  "ens_name": "vitalik.eth",
  "verified": true
}

Now you have a name. Chain it:

# Step 2: Is this entity sanctioned?
curl -X POST https://api.strale.io/v1/do \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "sanctions-check",
    "inputs": {"name": "Vitalik Buterin"}
  }'

# Step 3: Is this wallet flagged for fraud?
curl -X POST https://api.strale.io/v1/do \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "wallet-risk-score",
    "inputs": {"address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"}
  }'

Response:

{
  "address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  "risk_level": "low",
  "is_malicious": false,
  "risk_labels": []
}

Or skip the individual calls and run the whole pipeline as a single solution:

# Full counterparty due diligence — one call
curl -X POST https://api.strale.io/v1/do \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "web3-counterparty-dd",
    "inputs": {
      "wallet_address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
      "entity_name": "Vitalik Buterin"
    }
  }'

That single call runs: wallet risk score → wallet age check → ENS reverse lookup → sanctions screening → PEP check → adverse media scan. Six capabilities, one response, $0.12.

The 17 capabilities

All quality-scored. All continuously tested.

Wallet security:

wallet-risk-score — fraud labels, phishing, money laundering flags (GoPlus, 30+ chains)
approval-security-check — risky unlimited token approvals
wallet-age-check — first transaction date, age in days
wallet-balance-lookup — native + ERC-20 balances
wallet-transactions-lookup — recent transaction history

Token and contract safety:

token-security-check — honeypot, sell tax, hidden ownership, mint functions (GoPlus)
contract-verify-check — source code verified on Etherscan?
phishing-site-check — known phishing URLs and cloned dApp frontends

DeFi intelligence:

protocol-tvl-lookup — TVL, chains, audits, category (DeFi Llama)
protocol-fees-lookup — 24h/7d/30d fees and revenue
stablecoin-flow-check — stablecoin supply per chain
fear-greed-index — market sentiment 0-100
gas-price-check — safe/proposed/fast gas in Gwei

Identity and compliance:

ens-resolve — ENS name → wallet address
ens-reverse-lookup — wallet address → ENS name (verified)
vasp-verify — check ESMA's MiCA register of authorized CASPs
vasp-non-compliant-check — check ESMA's non-compliant entity list

Pre-built solutions

If you don't want to chain individual capabilities, there are 9 pre-built solutions that bundle them into single calls:

Solution	What it does	Price
`web3-counterparty-dd`	Wallet risk + age + ENS + sanctions + PEP + adverse media	$0.12
`web3-pre-tx-gate`	Go/no-go middleware for DeFi agents	$0.12
`web3-vasp-check`	Is this exchange MiCA-licensed?	$0.08
`web3-pre-trade`	Price + security + TVL + sentiment + gas	$0.08
`web3-wallet-identity`	ENS + risk + age + balance	$0.08
`web3-token-safety`	Honeypot + deployer risk + domain reputation	$0.05
`web3-dapp-trust`	Phishing detection + domain intelligence	$0.05
`web3-protocol-health`	TVL + fees + stablecoins + domain trust	$0.05
`web3-wallet-snapshot`	Balance + transactions + age + ENS + price	$0.05

Why this matters under MiCA

The EU's Markets in Crypto-Assets regulation requires all crypto-asset service providers to be licensed by July 2026. That means compliance checks on counterparties aren't optional for any agent operating in the EU market.

The vasp-verify capability is interesting here — it checks ESMA's official register of authorized CASPs. Nobody else offers this data via API, let alone via x402 micropayments. An agent can verify in one call whether a crypto exchange or custody provider is actually authorized.

Using via x402

All capabilities are available via x402. No signup, no API key — just USDC on Base:

# This returns HTTP 402 with payment requirements
curl https://api.strale.io/x402/wallet-risk-score?address=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

# Agent pays via X-Payment header, gets results

344 x402-enabled endpoints. Discovery at api.strale.io/x402/catalog.

For standard API access, sign up at strale.dev — new accounts get €2 in free credits.

What this isn't

This isn't on-chain analytics. Chainalysis, Nansen, and Glassnode do that well, at enterprise prices ($100K+/yr). This is the off-chain data layer that on-chain agents depend on — the compliance, entity, and trust data that the blockchain can't provide.

Every response comes with a provenance trail and a quality score (SQS), computed from automated testing across correctness, schema compliance, error handling, and edge cases. You're not calling an untested endpoint.

273 capabilities total. 97 solutions. Built in Sweden.

Why Your AI Agent Keeps Failing in Production (And It's Not Your Code)

Petter_Strale — Sat, 28 Mar 2026 12:23:29 +0000

You ship an AI agent to production. It works perfectly in development. Three days later, at 2am, it silently starts returning garbage data. Your users are affected before you even know there's a problem.

This is not a model problem. It's a capability problem — and almost no one is talking about it.

The part of agent development nobody warns you about

When you build an AI agent, you focus on the model — the prompts, the reasoning chain, the output format. This makes sense. The model is where the magic is.

But in production, agents don't just reason. They act. They call tools, fetch data, validate information, and make decisions based on what those tools return. And those tools are connected to external services — APIs, registries, databases — that are entirely outside your control.

Here's the failure taxonomy that will eventually hit every agent in production:

Silent upstream failures. The company registry API your KYB agent depends on starts returning malformed responses. The model doesn't know this. It reasons confidently on bad data.

Schema drift. An external API you depend on changes its response format. Your agent keeps calling it. The data comes back, just different. Depending on how you handle this, you either get silent errors or an agent that produces outputs based on a field that no longer exists.

Latency spikes. The API your agent calls has a bad hour. Calls time out. Your agent either fails hard (if you handle it well) or hangs (if you don't).

Conditional availability. Some data sources work fine in Western Europe but time out consistently from US infrastructure. Your agent worked in testing. It breaks in production for a specific user segment.

The uncomfortable math

If your agent pipeline calls 5 external capabilities, and each has 99% uptime, your composite reliability is 0.99^5 = 95.1%. That's one failure every 20 calls — before you've written a single bug.

At 10 capabilities: 90.4%. One failure every 10 calls.

This is just uptime. It doesn't account for schema drift, latency degradation, or partial failures (the API responds, but with stale or incorrect data).

The multi-step agentic pipelines people are building today compound this problem significantly. Every hop adds a new failure surface.

What actually needs to happen

The model quality problem in AI agents is mostly solved — or at least actively being worked on. The capability quality problem is not.

What "solved" looks like:

Continuous testing against known-answer fixtures. Not just "does the API respond" but "does it return the right answer." A sanctions check that returns 200 OK on a known-flagged entity has a bug. This requires ground truth data and a test suite that runs on a schedule, not just at deploy time.

Separate quality profiles for code and data. A capability can have excellent code — good error handling, correct schema, fast execution — but depend on a data source that's stale, incomplete, or geographically inconsistent. These are different failure modes and need different remediation strategies.

Upstream awareness. When a capability fails, the failure classification matters. "Our code threw an exception" is different from "the upstream service returned 503" is different from "the upstream service returned 200 with an error buried in the response body." An agent that knows the difference can make better recovery decisions.

Execution guidance. Rather than a binary "works / doesn't work" quality signal, what agents actually need is: "here's the confidence level, here's the current reliability profile, here's whether you should proceed or fall back."

The MCP angle

MCP has made capability discovery dramatically easier. Registries like Smithery and mcp.so are indexing thousands of servers. This is genuinely useful.

But discovery and quality are different problems. A registry tells you a server exists and has a description. It doesn't tell you whether it's reliable enough for a production pipeline, what its upstream dependencies are, or how it behaves under the error conditions that matter.

This gap will close — it has to. As agents move from demos to production, the question "can I trust this capability enough to act on its output" becomes the blocking question. Quality signals will become a first-class part of capability metadata, not an afterthought.

What you can do now

If you're shipping agents to production today:

Test your critical capabilities against ground truth. Pick the 5 capabilities your agent depends on most. Find a known-good input/output pair for each. Run that test on a schedule — daily at minimum, hourly if the capability is critical.

Build in upstream failure detection. When a capability returns an unexpected response, classify the failure before retrying. Blind retries on an upstream outage make things worse.

Track capability-specific latency separately from model latency. When something is slow, knowing whether it's the model or the tool call is the difference between a model config change and an API support ticket.

Use capability quality scores where they exist. Some capability platforms now publish quality metadata — test coverage, reliability profiles, historical uptime. Use this signal when choosing which capabilities to route through.

Plan for graceful degradation. For every critical capability in your pipeline: what does the agent do if this call fails? "Return an error" is a valid answer. "Silently continue with missing data" is not.

The longer arc

The agent economy is real and it's moving fast. But the infrastructure assumptions behind it — that capabilities are reliable, that data is accurate, that tools behave consistently — are not yet guaranteed.

The teams that figure out capability quality now will have a significant advantage as pipelines get longer and more autonomous. The failure modes don't get simpler as agents become more capable. They get more consequential.

Strale is a capability marketplace for AI agents — 250+ independently tested capabilities across 27 countries, with Quality and Reliability profiles on every capability. Built to give agents a trust layer, not just a tool layer. strale.dev

Give Your LangChain or CrewAI Agent 250+ Data Capabilities in 3 Lines of Code

Petter_Strale — Thu, 26 Mar 2026 15:06:48 +0000

Building an AI agent is the easy part. Getting it reliable data is the hard part.

Your agent can reason brilliantly, but at some point it needs to validate an IBAN, look up a VAT number, check a company's beneficial ownership, or pull a business registry entry. Every one of those data sources has its own API, its own auth, its own error handling, its own schema. Before you know it you've spent a week plumbing data integrations instead of building the thing you actually set out to build.

langchain-strale and crewai-strale solve this. They give your agent instant access to 250+ tested data capabilities — company registries, compliance checks, financial data, web extraction, and more — with a single import.

Install

# For LangChain agents
pip install langchain-strale

# For CrewAI agents
pip install crewai-strale

The simplest case: call a capability directly

No agent needed. Get the tools, find the one you want, call it.

from langchain_strale import StraleToolkit

toolkit = StraleToolkit(api_key="sk_live_...")
tools = toolkit.get_tools()

# Find the IBAN validator
iban_tool = next(t for t in tools if t.name == "iban-validate")

result = iban_tool._run(iban="GB82WEST12345698765432")
print(result)
# {"valid": true, "country_code": "GB", "bank_code": "WEST", ...}

The same pattern works for any of the 250+ capabilities — VAT validation, sanctions screening, company lookups, web scraping, and more. iban-validate is free tier, so you can run this without spending any credits.

With a LangChain agent

from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate
from langchain_strale import StraleToolkit

llm = ChatOpenAI(model="gpt-4o")
prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a compliance analyst with access to EU business data tools."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

toolkit = StraleToolkit(api_key="sk_live_...")
tools = toolkit.get_tools()  # All 250+ capabilities as LangChain BaseTool instances

agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools)

result = executor.invoke({
    "input": "Validate VAT number SE556703748501 and tell me what you find about the company"
})
print(result["output"])

With a CrewAI agent

from crewai import Agent, Task, Crew
from crewai_strale import StraleToolkit

toolkit = StraleToolkit(api_key="sk_live_...")
tools = toolkit.get_tools()

analyst = Agent(
    role="EU Business Compliance Analyst",
    goal="Validate and research European companies using official data sources",
    backstory="Expert in EU business registries, VAT systems, and compliance data",
    tools=tools,
)

task = Task(
    description="Check if VAT number SE556703748501 is valid and find out what you can about the company",
    agent=analyst,
    expected_output="Validation status and available company information",
)

crew = Crew(agents=[analyst], tasks=[task])
result = crew.kickoff()
print(result)

What's in the toolkit

Every Strale capability becomes a tool with a name, a description (including price), and a typed input schema generated from the capability's own JSON Schema. The agent knows what each tool costs before it calls it.

Some categories worth knowing about:

EU/Nordic business data — Swedish, Norwegian, Danish, Finnish company registries; VAT validation via VIES; IBAN validation; beneficial ownership lookups
KYC & compliance — PEP screening, adverse media checks, sanctions screening across 27 countries
Web extraction — screenshots, structured scraping, metadata extraction, URL-to-markdown
Financial data — crypto prices, stock quotes, currency conversion, economic indicators
Data utilities — JSON repair, CSV cleaning, address parsing, phone normalization

Two meta-tools come included in every toolkit:

strale_search — describe what you need in plain English, get back matching capabilities
strale_balance — check your wallet balance from within the agent

Filter by category

If you don't want to expose all 250+ tools to your agent (reasonable — it can make tool selection noisier), filter by category:

tools = toolkit.get_tools(categories=["compliance", "finance"])

Quality scoring

Every capability on Strale has a Strale Quality Score — a dual-profile score covering quality (correctness, schema compliance, error handling, edge cases) and reliability (availability, success rate, latency, upstream health). You're not calling an untested endpoint. You're calling something that's been continuously tested and scored.

Try it free

Five capabilities are completely free — no API key, no credits, no signup:

curl -X POST https://api.strale.io/v1/do \
  -H "Content-Type: application/json" \
  -d '{"capability_slug": "iban-validate", "inputs": {"iban": "GB82WEST12345698765432"}}'

For all 250+ capabilities, sign up at strale.dev — new accounts get €2 in free trial credits, no card required.

We Scored 2/6 on Our Own Agent-Readiness Scanner. Here's How We Fixed It.

Petter_Strale — Wed, 25 Mar 2026 15:59:33 +0000

We build Strale, an API that gives AI agents access to business data capabilities — company lookups, compliance checks, financial data, that kind of thing. Agents call strale.do() at runtime and get structured, quality-scored results back.

A few weeks ago we asked ourselves a question we probably should have asked sooner: if an agent tried to discover and use our own API, what would it actually experience?

We didn't know. So we built a tool to find out.

The tool we built for ourselves

We started with a simple internal checker — a script that hit our API the way an agent would and reported what it found. Could it find our llms.txt? Could it parse our OpenAPI spec? Did our MCP endpoint actually respond? Were our error messages machine-readable or just HTML 404 pages?

The script grew. We added checks for structured data, robots.txt crawler policies, authentication documentation, rate limit headers, content negotiation, schema drift between our spec and our live responses, machine-readable pricing, and a dozen more signals. By the time we stopped adding checks, we had 32 of them across 6 categories.

Then we ran it against our own API.

The first scan: 2/6

We scored 2 out of 6 categories as "agent-ready." Two. On our own product — a platform specifically built for AI agents.

The llms.txt file was there, and our structured data was fine. But our OpenAPI spec had drifted from our actual responses (11 fields didn't match). Our MCP server was discoverable but the functional verification test couldn't complete a handshake. We had no machine-readable pricing. Our error responses at some paths returned HTML instead of JSON. Authentication was documented in our human-readable docs but not in the OpenAPI spec where agents would look for it.

We were building an agent platform that agents couldn't properly use.

Fixing it

We worked through the failing checks one by one. Some were quick — adding securitySchemes to our OpenAPI spec took ten minutes. Publishing JSON-LD pricing data was another fifteen. Fixing the MCP handshake was a real debugging session.

The hardest part was schema drift. Our spec said one thing; our API returned another. Eleven extra fields that we'd added over time without updating the spec. No human user would notice, but an agent comparing the spec to the response would get confused.

After three rounds of scanning and fixing, we got to 6/6. Every check passing. It took about two days of focused work, spread across a week.

Why we made it free

We figured other teams probably had the same blind spot. You build a great API, you write docs for humans, you set up a marketing site — and you never check what an agent actually sees when it shows up.

So we put a web interface on the scanner and made it free. No signup, no paywall. You type in a URL, it runs the 32 checks, and you get a report showing exactly what passed and what didn't — with the specific HTTP requests that were made and what the responses contained.

We called it Beacon. It lives at scan.strale.io.

What the 6 categories measure

Discoverability — Can agents find you? Checks llms.txt, robots.txt AI crawler policies, structured data, sitemap coverage, MCP/A2A endpoints.

Comprehension — Can agents understand what you do? OpenAPI spec presence and accuracy, documentation accessibility, schema drift between spec and live responses, machine-readable pricing.

Usability — Can agents interact with you? Authentication documentation in machine-readable formats, signup friction, sandbox availability, error response quality.

Stability — Can agents depend on you? API versioning, changelogs, rate limit headers, terms of service compatibility, security headers.

Agent Experience — What happens when an agent arrives? First-contact response quality, documentation navigability from the root, response format consistency.

Transactability — Can agents do business with you? Machine-readable pricing, self-serve provisioning, agent-compatible checkout protocols, usage/billing transparency.

The thing that surprised us

The gap between "works for humans" and "works for agents" was bigger than we expected. Our API documentation was thorough — for a person reading it in a browser. But an agent doesn't read your docs page. It looks for an OpenAPI spec. It checks securitySchemes. It tries to parse your root response for navigation links. It looks for /.well-known/mcp.json.

Most of the fixes were small. The problem wasn't that our API was bad — it was that the machine-readable layer on top was incomplete or inconsistent.

Three output formats

Every scan produces a web report, a downloadable PDF, and a structured JSON report. The JSON one is designed for a specific workflow: paste it into Claude or ChatGPT and say "fix everything." The JSON includes the exact check that failed, what was tested, what was found, and a fix with a verification command.

MCP server

Beacon also ships as an MCP server, which felt appropriate for an agent-readiness tool. Install it in Claude Code:

claude mcp add strale-beacon -- npx strale-beacon-mcp

Three tools: scan, get_report, list_checks. You can scan domains from inside your development workflow without opening a browser.

Try it on your own product

We're curious what other teams find. Our guess, based on the handful of products we've scanned so far, is that most APIs score 1-2 out of 6 — even APIs that are well-built and well-documented for human consumption.

scan.strale.io — takes about 10 seconds.

We're actively improving Beacon and would love feedback — missing checks, confusing results, things that would make the report more useful. Drop a comment here or email hello@strale.io.

Your x402 Agent Just Paid a Sanctioned Wallet. Now What?

Petter_Strale — Tue, 24 Mar 2026 11:23:58 +0000

The x402 ecosystem is growing fast. Agents are paying for web scraping, GPU inference, data feeds — all settled in USDC on Base with a single HTTP round-trip. No accounts, no API keys. It's elegant.

But here's the uncomfortable question nobody in the ecosystem is asking yet:

Who is your agent paying?

The Problem

When your agent hits an x402 endpoint and sends a signed USDC transfer, it trusts the payTo address in the paymentRequirements response. The protocol verifies the payment mechanics — signature valid, amount correct, settlement confirmed. What it doesn't verify is whether that wallet belongs to:

A sanctioned entity on the OFAC SDN list
A business operating without proper licensing
A fraudulent service that will take the USDC and return garbage data
A company that dissolved six months ago

As x402 scales from developer experiments to real agent workflows, compliance isn't optional — it's the thing that determines whether your enterprise clients can actually use agents that pay for services autonomously.

What Agents Need Before They Pay

Think about what a responsible agent workflow looks like for a compliance-conscious organization:

Agent discovers x402 service → COMPLIANCE CHECK → Pay → Get data

That middle step — the compliance check — needs to answer three questions in under a second:

Is this business legitimate? (Company registration, VAT status, active/dissolved)
Is this entity sanctioned? (OFAC, EU, UN sanctions lists)
Is this domain trustworthy? (SSL valid, domain age, reputation signals)

These are exactly the checks that regulated industries already run for traditional vendor onboarding. The difference is that with x402, your agent might encounter 50 new service providers in a single workflow — and it needs to make these decisions programmatically, not through a procurement team.

How We Built This

At Strale, we've been building trust and compliance infrastructure for AI agents. We have 250+ capabilities covering company data across 27 countries, sanctions screening, VAT validation, domain intelligence, and more — all accessible via API, MCP server, and x402 endpoints.

Here's what a pre-payment compliance check looks like using our x402 endpoint:

# Before paying an unfamiliar x402 service, check the domain
curl https://api.strale.io/x402/ssl-check \
  -H "Content-Type: application/json" \
  -H "X-PAYMENT: <signed-usdc-payload>" \
  -d '{"domain": "suspicious-api.xyz"}'

Or run a sanctions screen on the entity behind the wallet:

curl https://api.strale.io/x402/sanctions-check \
  -H "Content-Type: application/json" \
  -H "X-PAYMENT: <signed-usdc-payload>" \
  -d '{"name": "Acme Data Corp", "country": "RU"}'

Both endpoints are x402-native: your agent pays $0.01–$0.02 in USDC on Base per check. No API key, no account, no subscription — the same model the rest of the x402 ecosystem uses.

The Bigger Picture

The x402 ecosystem has web scrapers, GPU providers, data feeds, and analytics APIs. What it's missing is the compliance layer that sits between discovery and payment.

This is especially relevant for:

Fintech agents processing cross-border payments (need sanctions + VAT checks)
KYB workflows where an agent verifies a business counterparty before transacting
Agent-to-agent trust — before Agent A pays Agent B for a service, it should verify Agent B's operator is a real, non-sanctioned entity
EU-regulated businesses that need audit trails for every autonomous transaction their agents make

What's Live

We currently have four x402-gated endpoints on Base mainnet:

Endpoint	What it does	Price
`iban-validate`	Validate IBAN structure + extract bank codes	$0.01
`vat-format-validate`	Verify EU VAT number format	$0.01
`ssl-check`	Check SSL certificate, expiry, chain validity	$0.01
`sanctions-check`	Screen against OFAC, EU, UN sanctions lists	$0.02

These are the first four of our 250+ capabilities exposed via x402. The full catalog — company data for 27 countries, domain reputation, financial validation, regulatory lookups — is available via our MCP server and direct API.

Try It

Hit any endpoint with a GET request to see the payment requirements:

curl https://api.strale.io/x402/iban-validate

You'll get a standard x402 402 Payment Required response with paymentRequirements — scheme, network, amount, payTo address. Standard x402 flow from there.

Full docs: strale.dev
MCP server: npm install strale-mcp
API: api.strale.io

Strale provides trust and quality infrastructure for AI agents. 250+ capabilities, 27 countries, independently tested with the Strale Quality Score (SQS). Learn more at strale.dev.

We Built an x402 Gateway — Here's What We Learned

Petter_Strale — Sat, 21 Mar 2026 14:56:59 +0000

This week, x402 had its biggest week yet. World launched AgentKit to give AI agents human-backed identity via x402. AWS published a full reference architecture for agentic payments on x402. Jensen Huang's GTC remarks sent AI agent tokens surging. And an academic paper (A402) proposed improvements to x402's atomicity model.

Everyone is talking about x402. Very few people have actually built on it.

We have. Here's what we learned.

What we built

Strale is a trust layer for AI agents — 256 independently tested capabilities accessible via MCP and REST API. We exposed five of those capabilities behind x402 routes so that agents with wallets can pay per request using USDC on Base, with no API key, no account, no subscription.

The five capabilities behind x402 today:

iban-validate — validate IBAN structure and extract bank details
vat-format-validate — check EU VAT number formatting
paid-api-preflight — verify a paid endpoint before your agent spends money
ssl-check — certificate chain validation
sanctions-check — screen names against consolidated sanctions lists

The handshake in practice

The x402 flow looks elegant in spec diagrams. In practice, it's three HTTP round trips:

Request 1: The agent tries to access a resource.

GET /x402/iban-validate?iban=DE89370400440532013000

Response: 402 with payment instructions.

HTTP/1.1 402 Payment Required
X-Payment-Required: true
X-Payment-Amount: 0.001
X-Payment-Currency: USDC
X-Payment-Network: base
X-Payment-Recipient: 0x...

The agent reads these headers, evaluates the cost, and decides whether to pay. This is where trust matters — more on that below.

Request 2: The agent pays on-chain and resubmits with proof.

GET /x402/iban-validate?iban=DE89370400440532013000
X-Payment: <signed payment proof>

Response: 200 with the actual data.

{
  "valid": true,
  "country": "DE",
  "bank_code": "37040044",
  "bank_name": "Commerzbank"
}

That's it. No API key exchange. No account creation. No subscription management. The agent discovered a service, paid for it, and got a result — all within standard HTTP.

What surprised us

1. The trust gap is real

The biggest unsolved problem in x402 isn't payments — it's trust. An agent discovers an endpoint that returns 402. How does it know the service is legitimate? That the endpoint will actually return useful data after payment? That the price is fair?

Right now, there's no standard answer. This is exactly why we built paid-api-preflight — a €0.02 check that validates an endpoint before your agent commits funds. It checks reachability, SSL, response time, and whether the payment handshake headers are properly formed. Returns a simple proceed / caution / avoid recommendation.

World's AgentKit announcement this week addresses the identity side of trust: proving there's a real human behind the agent. But there's an equally important question on the provider side: proving the service is worth paying for. Quality scoring, uptime history, independent test results — that's what we're building at Strale.

2. Payment verification is the hard part

Our current implementation uses a stub for payment verification — any X-Payment header returns results. Getting real verification working means funding a Base wallet, integrating the @x402/hono middleware, and handling on-chain settlement. The protocol spec is clean, but the operational overhead of running an on-chain payment verifier is nontrivial for a small team.

We're being transparent about this because we think the ecosystem benefits from honest status reports, not just launch announcements.

3. Header parsing needs to be defensive

Different x402 implementations format the PAYMENT-REQUIRED headers slightly differently. Some use the X-Payment-* prefix pattern. Others embed a JSON blob in a single WWW-Authenticate header. Our gateway handles both, but if you're building a client, don't assume consistency across providers yet — the spec is still solidifying.

4. MCP and x402 are complementary, not competing

MCP (Model Context Protocol) gives agents a way to discover and call tools. x402 gives agents a way to pay for tools. We run both: our MCP server at api.strale.io/mcp lets agents browse 256 capabilities, and our x402 routes let agents pay for a subset of them without any credentials.

The developer experience we're aiming for: an agent discovers a capability via MCP, checks its quality score, runs a pre-flight check, and if everything looks good, pays via x402 and gets the result. Discovery → trust → payment → execution, all automated.

What's still missing in the ecosystem

Standardized quality signals. Before an agent pays, it should be able to check an endpoint's reliability score, recent uptime, and test results. We publish this data through our Trust API, but there's no ecosystem-wide standard for it yet.

Provider discovery. x402scan.com is emerging as a directory, but agents need machine-readable discovery — not a website to browse. MCP catalogs are one piece. A402's proposed service channels could be another.

Dispute resolution. What happens when an agent pays and the service returns garbage? x402 v2 doesn't address this. A402's paper proposes atomic service channels with TEE-assisted verification, which is interesting but adds significant complexity.

Cross-protocol interop. L402 (Lightning), x402 (Base/Solana), and MPP (Stripe/Tempo) all use HTTP 402 but with different header formats and payment flows. Our paid-api-preflight capability normalizes across all three, but the ecosystem would benefit from a shared discovery format.

Getting started

If you want to try Strale's x402 endpoints:

# This will return 402 with payment headers
curl -i https://api.strale.io/x402/iban-validate?iban=DE89370400440532013000

For MCP access (no wallet needed, uses API key billing):

{
  "mcpServers": {
    "strale": {
      "type": "streamableHttp",
      "url": "https://api.strale.io/mcp"
    }
  }
}

Search and browse are free. Execution requires an API key from strale.dev — new accounts get €2.00 in trial credits.

What's next

We're watching the x402 ecosystem closely. Our open PRs on awesome-x402 and x402.org are awaiting review. Once real Base wallet settlement is live, we'll have one of the first independently quality-scored x402 service providers.

The agentic economy needs more than payment rails. It needs trust infrastructure. Payments solve how agents pay. Trust solves whether they should.

Strale provides 256 independently tested data capabilities across 27 countries, each with a published quality score. Accessible via MCP and REST API.

How to Verify Paid APIs Before Your AI Agent Spends Money

Petter_Strale — Thu, 19 Mar 2026 20:26:36 +0000

AI agents are starting to pay for API calls autonomously. Protocols like L402 (Lightning Network), x402 (Coinbase/Base), and MPP (Stripe/Tempo) let APIs charge per request using HTTP 402 — the "Payment Required" status code that's been reserved since the 1990s.

But here's the problem: how does your agent know the endpoint is actually worth paying for?

An endpoint might be listed in a directory. It might have been healthy yesterday. But right now, at the moment your agent is about to commit funds — is it live? Is the SSL valid? Is the payment handshake properly configured? Or is your agent about to send money into a broken endpoint?

The pre-flight check pattern

Before any paid API call, run a pre-flight check. Think of it like a pilot checking instruments before takeoff — you don't skip it just because the plane flew fine yesterday.

We built paid-api-preflight as a Strale capability that does exactly this. Pass it any URL, and it returns:

Whether the endpoint is reachable
Response time
SSL validity
Which payment protocol it uses (L402, x402, MPP, or unknown)
Whether the payment handshake is properly formed
For x402: whether the facilitator is reachable
A simple recommendation: proceed, caution, or avoid

Using it via MCP

If your agent is connected to Strale's MCP server, the tool is already available:

{
  "tool": "paid-api-preflight",
  "arguments": {
    "url": "https://some-paid-api.com/data"
  }
}

Response:

{
  "output": {
    "url": "https://some-paid-api.com/data",
    "is_reachable": true,
    "response_time_ms": 180,
    "status_code": 402,
    "ssl_valid": true,
    "payment_protocol": "x402",
    "payment_handshake_valid": true,
    "facilitator_reachable": true,
    "recommendation": "proceed",
    "issues": []
  }
}

Your agent reads "proceed" and goes ahead with the payment. If it had returned "avoid", the agent skips that endpoint and saves the money.

Using it via the REST API

curl -X POST https://api.strale.io/v1/do \
  -H "Authorization: Bearer sk_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "capability_slug": "paid-api-preflight",
    "inputs": { "url": "https://some-paid-api.com/data" },
    "max_price_cents": 10
  }'

Costs €0.02 per check. New accounts get €2.00 in trial credits — that's 100 pre-flight checks for free.

What it checks per protocol

L402 (Lightning): Validates the WWW-Authenticate: L402 header, checks for a valid macaroon and BOLT11 invoice.

x402 (Base/Solana): Decodes the PAYMENT-REQUIRED header, checks for an accepts[] array, a payTo address, and tests whether the facilitator URL is reachable.

MPP (Stripe/Tempo): Parses the WWW-Authenticate: Payment header for required fields — id, realm, method, and payment intent.

If the endpoint doesn't return 402 at all, the tool reports protocol: "unknown" — it might not be a paid API, or it might need specific request parameters to trigger the paywall.

The agent workflow

The pattern we recommend for any agent making paid API calls:

Discover an endpoint (from a directory, browsing, or a tool suggestion)
Call paid-api-preflight with the URL
If recommendation is "proceed" → make the paid call
If "caution" → check the issues array and decide
If "avoid" → skip it, find an alternative

This adds ~200ms and €0.02 to each new endpoint your agent encounters. After the first check, your agent can cache the result and skip the pre-flight for repeat calls.

Getting started

Connect to Strale's MCP server — no installation needed:

{
  "mcpServers": {
    "strale": {
      "type": "streamableHttp",
      "url": "https://api.strale.io/mcp"
    }
  }
}

The strale_search tool works without an API key, so your agent can browse the full catalog of 225+ capabilities. For executing tools including paid-api-preflight, sign up at strale.dev for an API key and €2.00 in trial credits.

Full trust methodology: strale.dev/trust

Strale gives AI agents access to 225+ quality-scored capabilities via MCP, REST API, or SDK. Every capability is independently tested and scored. Get started free — €2 credit, no card required.

Your AI Agent Doesn't Care Which AI Act Passes

Petter_Strale — Thu, 19 Mar 2026 13:52:53 +0000

On March 18, a US senator released a discussion draft for federal AI legislation — the TRUMP AMERICA AI Act. It proposes mandatory duty-of-care obligations, bias audits for high-risk systems, and training data transparency requirements. Three days earlier, the EU Council agreed to delay its own AI Act's high-risk rules by over a year.

Two continents. Two frameworks. Neither is finalized.

If you're building AI agents right now, this might feel like a reason to wait. Don't know which rules will apply? Don't build governance yet.

That instinct is wrong. Here's why.

What's actually happening

In the US, there is no federal AI law. What exists is a discussion draft — a proposal from Senator Blackburn that hasn't been formally introduced, needs bipartisan support, and faces opposition from both tech companies (too much regulation) and consumer groups (too much preemption of state laws). It's ambitious: mandatory risk assessments, FTC enforcement authority, expanded liability for AI developers, required bias audits for systems affecting health, safety, employment, education, law enforcement, or critical infrastructure.

But the bill provides almost no guidance on how to classify a system as "high-risk." That determination is left to organizations themselves, with significant liability if they get it wrong.

What IS already operational: a December 2025 executive order establishing a DOJ task force to challenge state AI laws in court, and an FTC directive on state bias-mitigation requirements. The federal government is actively trying to preempt state-level AI regulation, even without a federal replacement in place.

Meanwhile, 38 states enacted AI-related laws in 2025. Colorado's AI Act is live. Illinois amended its Human Rights Act to cover AI discrimination. California has transparency requirements for frontier models.

The practical result: if you deploy agents in the US today, you face a patchwork of state laws, an executive branch actively challenging those laws, and a proposed federal framework that may or may not replace them.

In the EU, the AI Act is enacted law — but the rules that matter most aren't enforceable yet. The Commission missed its own deadline for high-risk classification guidance. Two standardization bodies missed their deadline for technical standards. The "Digital Omnibus" package pushes high-risk system deadlines from August 2026 to December 2027 (standalone systems) or August 2028 (product-embedded systems).

But here's the catch: the Omnibus hasn't passed yet. If Parliament and Council don't agree before August 2026, the original deadlines technically apply — even though nobody has the guidance or standards to comply with them. The EU could enter a period where obligations are legally active but practically impossible to meet.

Prohibited AI practices (social scoring, subliminal manipulation) have been enforced since February 2025. Transparency obligations for AI-generated content take effect August 2026 regardless of the Omnibus. GPAI model rules are already in force.

What's converging

The regulatory text is diverging — the US and EU disagree on approach, scope, enforcement mechanisms, and timeline. But read past the policy language and look at what both frameworks actually require organizations to produce. The infrastructure requirements are remarkably similar:

Logging. The EU AI Act (Article 12) requires automatic logging of AI system operations. The US bill requires risk assessments and documentation of algorithmic systems. Both want a record of what your system did and why.

Transparency. The EU (Article 13, Article 50) requires disclosure of AI involvement and labeling of AI-generated content. The US bill requires training data use records and inference data use records. Both want visibility into how AI systems process data.

Data provenance. The EU requires operators to document data sources, processing locations, and jurisdictional context. The US bill creates liability for using copyrighted or personal data without consent in AI training. Both want you to know — and prove — where your data came from.

Quality assurance. The EU requires conformity assessments, accuracy standards, and human oversight protocols for high-risk systems. The US bill requires bias audits and participation in evaluation programs. Both want evidence that your system produces reliable outputs.

Audit trails. Both frameworks assume that organizations can produce, on demand, documentation showing what their AI system did, what data it used, whether it was reliable, and whether appropriate oversight was in place.

This convergence isn't coincidental. These are the basic requirements of accountable software. Logging, transparency, provenance, and quality assurance aren't regulatory inventions — they're engineering practices that regulated industries have used for decades. The AI frameworks are adapting them for a new context, but the underlying infrastructure is the same.

What this means if you're building agents

AI agents have a specific version of this problem. An agent that calls external tools at runtime — looking up company data, validating tax numbers, screening sanctions lists, checking compliance — creates a chain of data dependencies that neither framework can ignore.

Every external data call your agent makes is potentially auditable: What data source did it use? Was the source reliable at the time of the call? Was AI involved in processing the response? What jurisdiction was the data processed in? How long is the data retained?

If your agent stack doesn't capture this information today, adding it later is expensive. You'd need to instrument every integration point, build a logging layer, create provenance metadata, design quality monitoring — and do it retroactively across an architecture that wasn't designed for it.

The practical argument isn't "comply with regulation X by date Y." It's that the infrastructure for accountable agent operations — logging, provenance, quality signals, audit trails — is the same regardless of which regulatory text ends up applying. Building it now costs less than retrofitting it later, and it works no matter what happens in Washington or Brussels.

The quality signal gap

There's one dimension where agent infrastructure is further behind than most teams realize: quality signals for external tools.

When a developer hardcodes an API integration, they test it. They know when it breaks. An agent discovering and calling tools at runtime has no equivalent — it trusts whatever comes back. If the API returns stale data, the agent doesn't know. If the response schema changed, the agent's output degrades silently.

Regulators in both jurisdictions are starting to notice this gap. The EU AI Act's accuracy and robustness requirements (Article 15) apply to the entire system, including external data dependencies. The US bill's duty-of-care obligation covers "algorithmic systems and data practices." Neither framework will accept "we called an API and it returned JSON" as evidence of quality assurance.

Agent builders who treat external tool quality as someone else's problem are accumulating regulatory risk on both sides of the Atlantic — even before anyone agrees on which specific rules apply.

What to build now

If you're deploying agents that interact with external data, here's what both regulatory trajectories suggest you should have in place regardless of jurisdiction:

Per-call audit records. Every external data call should produce a structured log: what was called, what data source was used, what was returned, how long it took. Not for compliance theater — for debugging and accountability when something goes wrong.

Provenance metadata. Each data source should have a documented chain: where the data comes from, how fresh it is, whether AI was involved in processing it, what jurisdiction it was processed in. This is the information that both the EU and US frameworks will eventually require, and it's useful for debugging long before any regulator asks for it.

Quality monitoring. External tools should have measurable quality signals — success rates, schema stability, data freshness. Your agents should be able to check these signals before trusting a response, not after.

Transparency markers. If AI was involved in generating or processing a response, that should be visible in the output. Both frameworks require this. It's also just good practice — downstream consumers of your agent's output deserve to know what was AI-generated.

None of this requires you to pick a regulatory jurisdiction. It's infrastructure that works everywhere because it's based on engineering principles, not legal text.

How we think about this at Strale

Strale is a capability marketplace for AI agents — 225+ data capabilities accessible via a single API call. But the part that's relevant to this discussion is what happens underneath: every call through the platform automatically generates a structured audit record with data provenance, quality scores, transparency markers, and regulatory cross-references.

We didn't build that layer because of the EU AI Act or the US bill. We built it because agents calling external data sources without quality signals and audit trails is an engineering problem, and engineering problems get worse when you ignore them.

The regulatory frameworks are catching up to what good agent infrastructure already requires. The developers who build governance into their stack now — whether through Strale or through their own instrumentation — won't need to scramble when the rules finally land.

Full methodology: strale.dev/trust
Try five capabilities free, no signup: strale.dev

Strale gives AI agents access to 225+ quality-scored capabilities via MCP, REST API, or SDK. Every capability is independently tested and scored. Get started free — €2 credit, no card required.

DEV Community: Petter_Strale

Add Counterparty Verification to Your AI Agent in 5 Minutes

The problem in practice

MCP: zero code

LangChain / CrewAI: three lines

Direct API call

What's available beyond the UK

How the scoring works

Your DeFi Due Diligence Takes 20 API Calls. It Should Take One.

What the manual approach misses

The single-call alternative

When the manual approach still makes sense

For agent builders

One API Call to Know If Your Dependency Is Safe

The data exists. It's just scattered.

What we built

How it works under the hood

For agent builders

I Scanned 10 Developer Tools for AI Agent-Readiness. Only One Passed.

The Results

Resend — 4/6 Ready ✅

Stripe — 1/6 Ready (Stability)

Vercel — 1/6 Ready (Stability)

Postmark — 1/6 Ready (Discoverability)

Clerk — 0/6 Ready

Neon — 0/6 Ready

Supabase — 0/6 Ready

Plaid — 0/6 Ready

Twilio — 0/6 Ready

SendGrid — 0/6 Ready

What the Data Actually Shows

Almost nobody has /.well-known/mcp.json

llms.txt adoption is strong — but insufficient

Size of llms.txt doesn't correlate with readiness

What This Means for Builders

Your DeFi Agent Can Read the Blockchain. It Can't Read a Sanctions List.

The gap is real

Bridging the gap: wallet to compliance in one call

The 17 capabilities

Pre-built solutions

Why this matters under MiCA

Using via x402

What this isn't

Why Your AI Agent Keeps Failing in Production (And It's Not Your Code)

The part of agent development nobody warns you about

The uncomfortable math

What actually needs to happen

The MCP angle

What you can do now

The longer arc

Give Your LangChain or CrewAI Agent 250+ Data Capabilities in 3 Lines of Code

Install

The simplest case: call a capability directly

With a LangChain agent

With a CrewAI agent

What's in the toolkit

Filter by category

Quality scoring

Try it free

Links

We Scored 2/6 on Our Own Agent-Readiness Scanner. Here's How We Fixed It.

The tool we built for ourselves

The first scan: 2/6

Fixing it

Why we made it free

What the 6 categories measure

The thing that surprised us

Three output formats

MCP server

Try it on your own product

Your x402 Agent Just Paid a Sanctioned Wallet. Now What?

The Problem

What Agents Need Before They Pay

How We Built This

The Bigger Picture

What's Live

Try It

We Built an x402 Gateway — Here's What We Learned

What we built

The handshake in practice

Almost nobody has `/.well-known/mcp.json`

`llms.txt` adoption is strong — but insufficient

Size of `llms.txt` doesn't correlate with readiness