Should AgentKit have a community-providers index, and where should it live?

Hi maintainers — opening this as an Issue since Discussions aren't enabled on this repo. Posting in question/design-shape rather than feature-request shape because the question is upstream of any specific package: does AgentKit want a discoverability surface for **community-maintained `ActionProvider` packages** that ship outside the monorepo? And if yes, where would it live?

I'm asking because I've been building one and ran into the question myself — there's no obvious place to put it, and I want to get the channel right rather than self-list in the wrong surface. Suggested label: `question`. Happy to convert to a PR or close + redirect if a different channel would land better.

---

## The question

The in-tree `typescript/agentkit/src/action-providers/` directory currently holds 40+ first-party providers (across, alchemy, basename, compound, erc20, morpho, x402, ...). External packages built on the same `ActionProvider` base class have no surface in this repo, so:

- developers building on AgentKit can't easily find community-built providers, and
- community builders can't surface their work without forking or proposing in-tree merges that may not fit the strategic roadmap.

A community-providers index would solve discoverability without expanding the maintenance surface for Coinbase. The right shape and home is genuinely a maintainer call.

## Possible surfaces

1. **A `### Community Action Providers` section in the README.** Pro: high visibility. Con: implies Coinbase has vetted entries (the disclaimer doesn't survive screenshot-cropping).
2. **A separate `COMMUNITY.md` in the repo root**, linked from README. Pro: clearer "not in-tree, not vetted" framing.
3. **A sibling `awesome-agentkit` repo** owned by Coinbase but explicitly community-curated. Pro: established pattern, clean separation. Con: more upkeep for someone.
4. **None — community providers don't get a surface here.** Pro: zero distraction from in-tree quality. Con: discoverability gap stays unresolved (likely solved by third-party listings instead).

(Other options like a docs.cdp.coinbase.com section are also fine if you'd prefer — these are just the four I see; happy to take a write-in.)

## Strawman evaluation criteria

A light bar that keeps the surface useful without making maintainers gatekeepers:

- Package is **shipped to npm** (or PyPI) with at least one tagged release.
- Source repo is **public and OSI-licensed**.
- Action surface is **single-domain**, not a generic re-export.
- Not **redundant** with an in-tree provider's primary function.

(I'd note these criteria happen to fit my own package; I don't think any are exclusionary in a way that isn't also intuitive — but tighten if you'd want a higher bar.)

## How a community provider differs from `x402ActionProvider`

The in-tree `x402ActionProvider` handles payment-rail validation — facilitators, USDC, network match, payment cap. What it doesn't provide is **domain-intent-level safety**: a paid call to a specific endpoint that returns a structured semantic verdict the agent can branch on. That's a separate layer.

This is the same shape as `morphoActionProvider` (wraps Morpho's MetaMorpho vault deposit/withdraw, not generic ERC-20 calls): a single domain intent. Community providers at the same level of granularity, for domains Coinbase doesn't directly own, could plug into the same pattern without competing for in-tree merge slots.

## A concrete example (one possible entry)

I'm a one-person operator at PaladinFi (brand of Malcontent Games LLC, MI). The npm scope `@paladinfi/*` was registered 2026-05-02, so this is a brand-new vendor — being upfront that "shipped on npm + working tx" is the entire credibility floor today. Already listed on PulseMCP and the official MCP Registry; awesome-list submissions for x402, Base, and MCP servers are open ([#321](https://github.com/xpaysh/awesome-x402/pull/321), [#48](https://github.com/wbnns/awesome-base/pull/48), [#5740](https://github.com/punkpeye/awesome-mcp-servers/pull/5740)). Not yet merged on those `awesome-mcp-servers` lists; this Issue is not a substitute for those listings, just the AgentKit-specific channel question.

**[`@paladinfi/agentkit-actions@0.1.0`](https://www.npmjs.com/package/@paladinfi/agentkit-actions)** ([source](https://github.com/paladinfi/agentkit-actions), MIT)

Pre-trade composed token-contract risk gate for Base. Adds one action — `paladin_trust_check` — that calls `https://swap.paladinfi.com/v1/trust-check`, composes signals from OFAC SDN (refreshed on a daily best-effort cadence from the Treasury XML feed), GoPlus token security, Etherscan source-code verification, and internal anomaly + lookalike heuristics, and returns a structured `recommendation: "allow" | "warn" | "block"`.

Class shape is `PaladinActionProvider extends ActionProvider` with a `@CreateAction` decorator and `supportsNetwork` gated to Base mainnet. Paid x402 settlement built directly on `walletProvider.toSigner()`. **In this package's bundled action**, a pre-sign hook validates the server's 402 challenge against hard-coded constants (treasury address, USDC contract, $0.01 amount cap as 10× headroom over the $0.001 list price, 10-min validity, EIP-712 domain) before viem signs anything; if any field deviates the call aborts client-side. Users wrapping the endpoint with a different x402 client are responsible for their own pre-sign validation.

**Usage:**

```typescript
import { AgentKit } from "@coinbase/agentkit";
import { paladinActionProvider } from "@paladinfi/agentkit-actions";

const agent = await AgentKit.from({
walletProvider,
actionProviders: [paladinActionProvider({ paidMode: true })],
});

// LLM picks the action; result is a structured verdict the agent can branch on
const result = await agent.run("Is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 safe to swap to?");
```

**Sample preview response** (abridged from a real `POST /v1/trust-check/preview` call). The paid endpoint composes live data — `recommendation` is un-prefixed (`allow`/`warn`/`block`), each factor carries `real: true` and a `details` field, and the number of factors varies by coverage (typically 4–5; see [the trust-check docs page](https://paladinfi.com/trust-check/) for paid-response examples):

```json
{
"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"chainId": 8453,
"trust": {
"risk_score": null,
"risk_score_scale": "0-100 (lower = safer); null on preview because no live evaluation runs",
"recommendation": "sample-allow",
"recommendation_enum": ["allow", "warn", "block"],
"factors": [
{"source": "ofac", "signal": "not_listed", "real": false},
{"source": "etherscan_source", "signal": "verified", "real": false},
{"source": "goplus", "signal": "ok", "real": false},
{"source": "anomaly", "signal": "ok", "real": false}
],
"version": "1.0",
"_preview": true
}
}
```

**Verifiable end-to-end:** [settled paid tx 0xe08f3636…d9db1a1](https://basescan.org/tx/0xe08f3636d2cbbac2eab95cb1685c670369311e4a4e560a743f40719ddd9db1a1) (0.001 USDC, EIP-3009 `transferWithAuthorization`, succeeded).

If you'd accept community providers in some form, this would be a candidate. If you'd accept the surface but want a higher bar than v0.1.0 from a 1-day-old org, that's reasonable feedback.

## What I'm asking for

- Your read on whether a community-providers surface fits AgentKit's direction.
- If yes: which surface (1–4 above, or a write-in).
- If yes: feedback on the strawman bar.
- If no: a redirect.

If the answer is "no surface, but you can submit a separate PR for in-tree consideration," I'll take that as a clear signal and won't conflate the two.

## What I'm not asking for

- Inclusion in the in-tree `action-providers/` directory.
- Endorsement, audit, or sign-off from Coinbase on any specific package.
- A guaranteed merge of any package as the first entry — if the surface exists but a higher bar than v0.1.0 is appropriate, I'll wait.

Thanks for considering. If a maintainer would prefer this lived elsewhere — PR adding a `COMMUNITY.md`, separate `awesome-agentkit` repo proposal, docs.cdp.coinbase.com section, or "we don't surface external integrations" — close + redirect is a clean signal and I'll act on it.