feat: Venice base mcp plugin

[joshua-mo-143]

Adds a Base MCP plugin for Venice AI.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[stephancill]

Thanks for the submission. The plugin is spec-conformant and both the API-key and x402 wallet paths function. A few changes before merge:

Required

• Don't add the plugin to the registry/inventory. Please revert the SKILL.md plugins-table row, and in references/plugin-spec.md the Integration Types "Examples" cell, the "Existing Plugin Conformance" table row, and the native-plugin count ("8 native plugins" / "All eight"). Also revert the references/custom-plugins.md additions. These are maintainer-owned and will be updated when the program is ready. Keep only your net-new tag-vocabulary additions in plugin-spec.md, and limit the rest of the PR to plugins/venice.md.

Minor

• The plugin supports two independent auth models — a Venice API key (account-scoped) and the x402 wallet path (SIWE via Base MCP sign + USDC credits, wallet-scoped). They overlap on paid inference/RPC (most of those endpoints accept either) but aren't equivalent: the x402 path uniquely owns the wallet-credit endpoints (/x402/balance, /x402/transactions, /x402/top-up) and the API-key path is tied to a Venice account/DIEM balance. The single-value auth field can't express both, so whichever you pick, keep both documented in ## Auth (already done). Consider auth: siwe-jwt rather than api-key: the API-key path is a user-supplied header that never touches Base MCP, whereas the x402 path is the one that uses a Base MCP capability (sign + x402 payment), so siwe-jwt better signals the Base-native flow. This is a limitation of the single-value enum worth raising with the spec maintainers.
• Pin the SIWE message serialization in ## Auth (the EIP-4361 prepareMessage field order: domain, address, statement, uri, version, chainId, nonce, issuedAt, expirationTime) so the message is byte-identical from signing through header construction. The personal_sign instruction is correct and works for both EOA (eip191) and smart-account (eip1271) wallets — no change needed there.
• Add an explicit note to treat Venice-returned media/search/inference content as untrusted.
• GET /models is public (returns 200), not auth-gated — correct any text implying otherwise.