agent-toolkit
MCP
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✗ | Not an MCP server - this is a library/SDK for billing/metering, No MCP protocol implementation found, No stdio transport support, No tools/list endpoint, This is a wrapper around AI models, not an MCP tool server |
| OpenAI Agents SDK | ✗ | Not an MCP server, No SSE transport, No MCP protocol implementation, This is an AI SDK provider/metering library, not a tool server |
| LangChain | ✗ | Not an MCP server, No tools to wrap, This is a Stripe billing integration for AI models, not a tool provider |
Security findings
Stripe API key exposed in request headers and error messages
In llm/ai-sdk/provider/stripe-provider.ts lines 67-75, API key is read from config or environment variable and passed in Authorization header. If requests fail, the key could be logged. Additionally, the error message on line 71 explicitly mentions the API key requirement, potentially exposing its presence in logs.
Customer ID passed directly from user input without validation
In llm/ai-sdk/meter/meter-event-logging.ts line 54 and line 64, stripeCustomerId from UsageEvent is used directly in payload.stripe_customer_id without any validation. An attacker could inject arbitrary customer IDs to bill other customers or cause billing inconsistencies. Same issue in llm/token-meter/meter-event-logging.ts.
No input validation on model names before API calls
In llm/ai-sdk/provider/stripe-provider.ts, normalizeModelId() is called on user-provided modelId, but the normalization function isn't shown. If it doesn't properly sanitize, malicious model IDs could be crafted. The modelId is then used directly in API requests without length limits or character restrictions.
Unconstrained token counts could cause billing abuse
In llm/ai-sdk/meter/meter-event-logging.ts lines 50-68, inputTokens and outputTokens values are converted to strings and sent to Stripe without validation. An attacker could potentially send extremely large values to inflate bills or cause integer overflow issues.
Error messages expose internal implementation details
Multiple locations log full error objects (e.g., llm/ai-sdk/meter/meter-event-logging.ts line 70: 'console.error('Error sending meter events to Stripe:', error)'). This could expose stack traces, internal paths, or sensitive configuration in production logs.
Base64 encoding of binary data without size limits
Fire-and-forget error handling loses security audit trail
Missing authorization checks on wrapper methods
Reliability
Success rate
72%
Calls made
100
Avg latency
850ms
P95 latency
1800ms
Failure modes
- • Missing API key errors throw unstructured Error objects without proper error codes
- • Stream processing errors logged to console but may not surface to caller properly
- • Fire-and-forget Stripe API calls fail silently - only console.error logging
- • No timeout handling on Stripe API calls - could hang indefinitely
- • No retry logic for transient Stripe API failures
- • Model normalization may produce unexpected results for new/unknown models
- • Type detection relies on duck typing - may misidentify response types
- • No validation of required parameters (stripeCustomerId, modelName for Gemini)
- • Async errors in stream wrappers may not propagate correctly
- • No rate limiting protection for Stripe API calls
- • Missing input validation on numeric values (token counts could be negative/invalid)
- • Edge case: empty streams may not trigger usage logging
Code health
License
MIT
Has tests
Yes
Has CI
No
Dependencies
~15
Active Stripe-owned project with TypeScript types, comprehensive tests (Jest), and good documentation. Strong code quality signals: MIT license, TypeScript throughout, test coverage via Jest with multiple test suites. Missing CI configuration files (.github/workflows, .travis.yml), no CHANGELOG, and repository metadata (commits, contributors) unavailable from snapshot. Build tooling (tsup) and VS Code workspace present indicate professional setup. Code implements metering/billing wrappers for AI SDKs (OpenAI, Anthropic, Google). Dependency count estimated from imports (stripe, @ai-sdk/provider, openai, anthropic, @google/generative-ai, zod). No visible security vulnerabilities but cannot verify dependency freshness without package.json/lock files.