Zerion MCP Server

A production-ready Model Context Protocol (MCP) server that provides AI assistants with access to the Zerion API for cryptocurrency portfolio management, DeFi positions, NFTs, and market data.

Features

• 🔌 Auto-generated Tools: Automatically exposes Zerion API endpoints as MCP tools via OpenAPI specification

• ⚙️ Flexible Configuration: YAML config files with environment variable overrides

• 📝 Structured Logging: JSON and text formats with sensitive data redaction

• 🛡️ Robust Error Handling: Custom exceptions with detailed context and troubleshooting hints

• 🔁 Automatic Retry Logic: Exponential backoff for rate limits (429) and wallet indexing (202)

• 📄 Pagination Support: Manual and automatic pagination for large result sets (5000+ items)

• 🚦 Rate Limit Management: Transparent retry handling with configurable backoff strategies

• 🔍 Advanced Filtering: Chain filtering, DeFi positions, spam filtering, transaction types, and more

• 🧪 Testnet Support: Test applications on testnets (Sepolia, Monad, etc.) via X-Env header

• 💱 Multi-Currency: Portfolio values in USD, ETH, EUR, or BTC denomination

• ✅ Comprehensive Tests: Unit and integration tests with pytest

• 🚀 Async HTTP: Non-blocking API calls with httpx

Operational Capabilities

The Zerion API provides three powerful operational capabilities that make it stand out from traditional blockchain data providers:

1. Multi-Chain Aggregation

100+ blockchains in one API call - Zerion automatically aggregates data across all supported blockchain networks without requiring multiple API requests.

How it works:

• No special parameters needed - multi-chain aggregation is automatic

• Single call to getWalletPortfolio returns balances across Ethereum, Base, Polygon, Arbitrum, Optimism, Solana, and 100+ other chains

• Eliminates the need for per-chain API providers (Alchemy, Infura, Moralis)

Supported chains include:

• EVM chains: Ethereum, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche, Fantom, Gnosis, zkSync, StarkNet

• L2s: Optimism, Arbitrum, Base, zkSync Era, Polygon zkEVM, Linea, Scroll

• Non-EVM: Solana

• 100+ total chains (see listChains for complete list)

Examples:

Result: Portfolio data aggregated from all 100+ supported chains in a single response.

Result: DeFi positions from Ethereum, Base, Arbitrum, and all other chains in one call.

Benefits vs. per-chain APIs:

• Zerion: 1 API call for cross-chain portfolio

• Per-chain APIs: 10+ separate API calls needed (one per chain)

• Quota savings: 90% reduction in API requests

• Simplified logic: No manual chain aggregation required

Use cases:

• Cross-chain portfolio dashboards

• DeFi aggregators (track positions across all chains)

• Multi-chain wallet analytics

• Cross-chain transaction history

2. DeFi Protocol Coverage

8,000+ DeFi protocols tracked - Zerion provides comprehensive protocol metadata for lending, staking, LP, and yield farming positions.

Available protocol metadata:

• relationships.dapp.data.id - Protocol identifier (e.g., "uniswap-v3", "aave-v3")

• attributes.position_type - Position category (staked, deposit, loan, reward, etc.)

• DApp data following JSON:API relationship format

Protocol categories covered:

• DEX: Uniswap, Curve, Balancer, SushiSwap, PancakeSwap

• Lending: Aave, Compound, MakerDAO, Euler

• Staking: Lido, Rocket Pool, StakeWise

• Yield aggregators: Yearn, Beefy, Convex

Examples:

Result: Returns positions with relationships.dapp containing protocol metadata (Uniswap, Aave, Curve, etc.).

Result: Only Aave V3 and Compound V2 positions.

Use cases:

• DeFi protocol analytics dashboards

• Position aggregation by protocol

• Protocol yield tracking

• Risk management (track exposure by protocol)

3. NFT Metadata Completeness

Comprehensive NFT metadata - Zerion provides rich metadata for ERC-721 and ERC-1155 tokens, enabling full-featured NFT displays.

Available metadata fields:

• metadata.name - NFT name

• metadata.description - NFT description

• metadata.content.preview - Thumbnail/preview image URL

• metadata.content.detail - High-resolution image URL

• market_data.prices.floor - Collection floor price (where available)

• metadata.attributes - NFT traits and properties

• relationships.nft_collection - Collection relationship data

Image URLs:

• Preview URLs for thumbnails/gallery views

• Detail URLs for full-size displays

• URLs may be IPFS gateways

Floor price availability:

• Available for most established collections

• New/small collections may lack floor data

• Measured in requested currency (USD, ETH, EUR, BTC)

Examples:

Result: Complete NFT metadata including name, description, images, floor price, traits, and collection data.

Result: NFT positions with metadata for rich NFT gallery displays.

Use cases:

• NFT gallery applications

• NFT marketplace displays

• Collection analytics (floor price tracking)

• Trait-based filtering and rarity analysis

Available Functions

Wallet & Portfolio

• getWalletPortfolio: Returns the portfolio overview of a web3 wallet.

• listWalletPositions: Returns a list of wallet positions (supports filter[positions]=only_complex for DeFi).

• getWalletChart: Returns a portfolio balance chart for a wallet.

• getWalletPNL: Returns the Profit and Loss (PnL) details of a web3 wallet.

• listWalletTransactions: Returns a list of transactions associated with the wallet (supports advanced filters).

NFTs

• getWalletNftPortfolio: Returns the NFT portfolio overview of a web3 wallet.

• listWalletNFTCollections: Returns a list of the NFT collections held by a specific wallet.

• listWalletNFTPositions: Returns a list of the NFT positions held by a specific wallet.

• getNFTById: Returns a single NFT by its unique identifier.

• listNFTs: Returns a list of NFTs by using different parameters.

Webhooks & Real-Time Notifications (NEW!)

• createTxSubscription: Create webhook subscription for real-time transaction notifications.

• listTxSubscriptions: List all active transaction subscriptions.

• getTxSubscription: Get subscription details by ID.

• updateTxSubscription: Update subscription addresses, callback URL, or chain filters.

• deleteTxSubscription: Delete a transaction subscription.

Market Data

• getFungibleById: Returns a fungible asset by its unique identifier.

• getFungibleChart: Returns the chart for a fungible asset for a selected period.

• listFungibles: Returns a paginated list of fungible assets supported by Zerion.

• listGasPrices: Provides real-time information on the current gas prices across all supported blockchain networks.

• listChains: Returns a list of all chains supported by Zerion.

• getChainById: Returns a chain by its unique chain identifier.

Swaps & Bridges

• swapFungibles: Provides a list of fungibles available for bridge exchange.

• swapOffers: Provides a comprehensive overview of relevant trades and bridge exchanges.

Requirements

For Docker (Recommended)

• Docker 20.10 or higher

• Docker Compose V2

• Zerion API key (Get one here)

For Native Python Installation

• Python 3.11 or higher

• Zerion API key (Get one here)

Installation

Using Docker (Recommended)

See DOCKER.md for detailed Docker deployment guide.

From Source

From PyPI (when published)

Quick Start

1. Set up your API key

2. Run the server

3. Connect with an MCP client

The server will start and listen for MCP protocol connections. You can connect it to AI assistants like Claude Desktop.

Claude Desktop Configuration

Add to your claude_desktop_config.json:

Configuration

Configuration File

Create a config.yaml file in your working directory:

See config.example.yaml for a complete example.

Environment Variables

Environment variables override config file values:

Usage Examples

Once connected to an MCP client (like Claude), you can query Zerion data:

Portfolio Balance

The server exposes tools like getWalletChart, getWalletPositions, etc.

DeFi Positions

NFT Collections

All Zerion API endpoints are automatically available as MCP tools. See the Zerion API documentation for available operations.

Webhooks - Real-Time Transaction Notifications

The Zerion MCP Server now supports transaction subscription webhooks for real-time wallet activity monitoring. This is critical for production applications because webhooks eliminate inefficient polling, conserve API quotas, and enable sub-second notification latency.

Why Use Webhooks?

• Rate Limit Conservation: Polling wastes API quota (~5K requests/day on free tier). Webhooks push updates only when transactions occur.

• Real-Time: Sub-second notifications when monitored wallets transact

• Scalability: Monitor hundreds of wallets without quota waste

• Cost Efficiency: On paid tiers ($149/mo Builder), webhooks eliminate redundant polling requests

Architecture Overview

Important: The MCP server manages webhook subscriptions but does NOT receive webhook payloads. You must deploy a separate HTTP service to receive webhook POST requests from Zerion.

Available Tools

• createTxSubscription - Create new webhook subscription

• listTxSubscriptions - List all active subscriptions

• getTxSubscription - Get subscription details by ID

• updateTxSubscription - Update addresses, callback URL, or chain filters

• deleteTxSubscription - Delete subscription

Example: Create Subscription for Ethereum Address

This creates a subscription that sends webhook notifications to your callback URL whenever the specified address has transactions on Ethereum or Base.

Example: Create Subscription for Solana Address

Webhook Payload Structure

When a monitored address has a new transaction, Zerion sends a POST request to your callback URL with this structure:

The included array contains full transaction details using the same schema as the listWalletTransactions endpoint.

Setting Up a Webhook Receiver

Option 1: Testing with webhook.site (Recommended for Development)

1. Visit https://webhook.site

2. Copy your unique URL (e.g., https://webhook.site/abc-123-def)

3. Use that URL as callback_url when creating subscriptions

4. View incoming webhooks in real-time on the webhook.site page

Option 2: Python Flask Receiver (Production)

Deploy this to a public server (Heroku, Vercel, AWS Lambda, etc.) and use the public HTTPS URL as your callback.

Option 3: Node.js Express Receiver

Webhook Best Practices

1. Respond Quickly: Zerion expects < 5 second response time. Do heavy processing asynchronously.

2. Idempotency: Webhooks may be delivered multiple times. Check for duplicate transaction IDs.

3. Retry Policy: Zerion retries delivery up to 3 times on failure.

4. HTTPS Required: Callback URLs must use HTTPS (not HTTP).

5. No Guaranteed Order: Don't assume webhook delivery order matches blockchain order.

Security Considerations

• Signature Verification: Future enhancement - webhook payload signing (check Zerion docs)

• IP Whitelisting: Consider restricting webhook receiver to Zerion's IP ranges

• HTTPS Only: Never use HTTP callback URLs in production

Troubleshooting Webhooks

Webhooks Not Arriving

1. Check callback URL is publicly accessible: Test with curl -X POST https://your-url.com

2. Verify subscription is active: Use listTxSubscriptions to confirm subscription exists

3. Check Zerion dashboard: Verify API key has webhook permissions

4. Test with webhook.site first: Confirm Zerion can reach your infrastructure

Rate Limits on Subscription Management

• Developer keys: Limited subscriptions (1-5)

• Contact api@zerion.io for enterprise webhook quotas

Advanced Filtering - Query Optimization

The Zerion API supports powerful filter parameters that are already available in the MCP server but often underutilized. Using filters reduces API quota usage, improves response times, and enables precise data queries.

Filter Applicability Matrix

DeFi Position Filtering (only_complex)

Problem: By default, listWalletPositions returns simple token balances. DeFi protocols (staking, LPs, lending) are excluded.

Solution: Use filter[positions]=only_complex to get only DeFi positions.

Example: Get DeFi Positions Only

Result: Returns staking positions (e.g., staked ETH), liquidity pool tokens (Uniswap, Curve), lending positions (Aave, Compound), and yield farming positions. Excludes simple ERC-20 balances.

Use Cases:

• DeFi analytics dashboards

• Institutional risk management (track complex positions separately)

• Yield farming trackers

• Portfolio categorization for tax reporting

Filter Options

• only_simple (default): Only wallet-type positions (basic token balances)

• only_complex: Only DeFi protocol positions (staking, LP, lending)

• no_filter: Both simple and complex positions

Chain Filtering (filter[chain_ids])

Problem: Fetching positions across all 50+ chains wastes quota and returns irrelevant data.

Solution: Use filter[chain_ids] to query specific blockchains.

Example: Ethereum + Base Only

Result: Only transactions on Ethereum and Base. Ignores activity on Polygon, Arbitrum, Optimism, etc.

Example: Single Chain (Optimism)

Use Cases:

• L2-focused analytics (Base, Optimism, Arbitrum)

• Cross-chain comparison (Ethereum vs. L2s)

• Mainnet-only queries

Valid Chain IDs: ethereum, base, optimism, arbitrum, polygon, solana, binance-smart-chain, avalanche, fantom, gnosis, etc. Use listChains to see all supported chains.

Spam Filtering (filter[trash])

Problem: Wallet transaction history polluted with spam tokens, dust, and airdrop scams.

Solution: Use filter[trash]=only_non_trash to hide spam.

Example: Clean Transaction History

Result: Clean transaction history without spam tokens or dust transfers.

Filter Options

• only_non_trash: Hide spam/dust (recommended for user-facing apps)

• only_trash: Show only spam/dust (for security monitoring)

• no_filter (default): Show all transactions

Use Cases:

• User-facing wallets (clean UI)

• Portfolio analytics (exclude noise)

• Tax reporting (ignore spam airdrops)

Transaction Type Filtering (filter[operation_types])

Problem: Need to analyze specific transaction types (e.g., only swaps, only transfers).

Solution: Use filter[operation_types] to isolate transaction categories.

Example: Trades Only

Result: Only DEX swaps and trades. Excludes transfers, approvals, contract executions.

Available Operation Types

• trade: Token swaps (Uniswap, 1inch, etc.)

• transfer: Simple token transfers

• execute: Smart contract interactions

• approve: Token approvals

• deposit: Protocol deposits

• withdraw: Protocol withdrawals

Use Cases:

• Trading analytics (volume, frequency)

• Transfer tracking (payroll, payments)

• Smart contract interaction audits

Position Type Filtering (filter[position_types])

Problem: DeFi positions span many categories (staking, lending, rewards). Need to isolate specific types.

Solution: Use filter[position_types] for granular DeFi categorization.

Example: Staking + Rewards Only

Result: Only staked assets and claimable rewards. Excludes LP positions, loans, deposits.

Available Position Types

• wallet: Simple balance

• deposit: Lending protocol deposits (Aave, Compound)

• loan: Borrowed assets

• staked: Staked tokens (ETH staking, governance staking)

• reward: Claimable rewards

• locked: Vested/locked tokens

• margin: Margin trading positions

• airdrop: Airdrop eligibility

Use Cases:

• Staking dashboards

• Yield optimization

• Loan/collateralization tracking

• Rewards harvesting

Query Optimization Best Practices

1. Use Filters to Reduce Quota Usage

Bad (fetches all data, filters client-side):

Cost: ~1000 positions returned, large response

Good (filter at API level):

Cost: ~50 positions returned, 20x smaller response

2. Combine Filters for Precision

Example: DeFi-Only, Ethereum, No Spam

Result: High-value Ethereum DeFi positions only. Perfect for risk dashboards.

3. Page Size Control

Smaller pages = faster responses, less quota per request.

Common Filter Combinations

Pagination - Fetching Large Result Sets

The Zerion API uses cursor-based pagination for endpoints that return lists (transactions, positions, NFTs). The MCP server provides both manual and automatic pagination support.

Why Pagination Matters

Active wallets can have thousands of transactions. Without pagination:

• API quota exhausted quickly (Developer tier: ~5K requests/day)

• Incomplete data (default page size: 100 items)

• Slow responses (large payloads)

Manual Pagination

All list endpoints support page[size] and page[after] parameters:

The response includes a links.next URL for fetching the next page:

To fetch the next page, extract the cursor from links.next and use it as page[after]:

Continue until links.next is absent (last page reached).

Automatic Pagination (Python SDK)

For programmatic access, use the auto-pagination helper to fetch all pages automatically:

Pagination Configuration

Control pagination behavior in config.yaml:

Example calculations:

• 50 pages × 100 items = 5,000 results (covers 99% of wallets)

• 50 API requests consumed (watch your quota!)

Pagination Best Practices

1. Use Filters to Reduce Results

Bad (fetches everything):

Result: 2,000 transactions (20 pages)

Good (filter first):

Result: 300 transactions (3 pages) - 85% quota savings!

2. Choose Appropriate Page Sizes

• Small pages (25-50): Faster individual requests, more total requests

• Large pages (100): Fewer requests, larger payloads (recommended)

• Default: 100 items per page

3. Monitor Auto-Pagination Limits

The auto-pagination helper logs warnings at key thresholds:

If you see "results may be incomplete", increase max_auto_pages or use manual pagination.

Quota Impact Example

Scenario: Fetch all transactions for an active wallet (5,000 transactions)

Takeaway: Use filters + reasonable max_pages limits to avoid quota exhaustion.

Rate Limiting - Automatic Retry with Backoff

The Zerion API enforces rate limits based on your subscription tier:

When you exceed your quota, the API returns 429 Too Many Requests with a Retry-After header.

Automatic Retry Behavior

The MCP server automatically retries rate-limited requests using exponential backoff with jitter:

You don't need to handle retries manually - the server handles them transparently.

Retry Configuration

Customize retry behavior in config.yaml:

Delay sequence (with exponential_base=2):

• Retry 1: 1 second

• Retry 2: 2 seconds

• Retry 3: 4 seconds

• Retry 4: 8 seconds

• Retry 5: 16 seconds

Total maximum wait: ~31 seconds (if all retries needed).

Rate Limit Error Messages

If retries are exhausted, you'll see an actionable error:

Next steps:

1. Wait for the retry_after duration (from error message)

2. Reduce request frequency in your app

3. Upgrade to a higher tier if needed

Rate Limiting Best Practices

1. Use Webhooks Instead of Polling

Bad (polling):

Cost: 8,640 requests/day (exceeds Developer tier quota!)

Good (webhooks):

Cost: 1 request total 🎯

2. Implement Client-Side Caching

3. Use Filters to Reduce Data Volume

Smaller responses = faster processing = fewer timeout retries:

Monitoring Rate Limit Status

The server logs rate limit events:

Enable DEBUG logging to see detailed retry information:

Disabling Automatic Retry

To disable automatic retry (e.g., for testing):

Now 429 responses will immediately raise RateLimitError.

Error Handling - 202 Accepted (Wallet Indexing)

When you query a newly created wallet (first request for that address), Zerion may return 202 Accepted instead of 200 OK. This means:

"Wallet is being indexed. Data will be ready in 2-10 seconds."

Automatic 202 Retry

The MCP server automatically retries 202 responses with a fixed delay:

You don't see - the server handles them transparently.

When Does 202 Occur?

• First request to a new wallet address: Zerion hasn't indexed it yet

• Recently created on-chain wallet: Blockchain confirmed, Zerion indexing in progress

• Rare edge case: Heavy load on Zerion's indexing service

Typical indexing time: 2-10 seconds (usually 3-5 seconds).

202 Configuration

Customize retry behavior in config.yaml:

Total wait time: retry_delay × max_retries (e.g., 3s × 3 = 9 seconds).

202 Error Messages

If indexing times out after max retries:

Next steps:

1. Wait 30-60 seconds for Zerion to complete indexing

2. Retry your request

3. If issue persists, contact api@zerion.io

Disabling 202 Auto-Retry

To disable automatic retry (e.g., for instant feedback):

Now 202 responses will immediately raise:

202 Logging

The server logs indexing events:

Or if timeout:

Troubleshooting 202 Errors

"Indexing timeout after 3 retries"

Cause: Wallet indexing taking longer than expected (>9 seconds).

Solution:

1. Increase max_retries or retry_delay:

   wallet_indexing: retry_delay: 5 max_retries: 5

   New total wait: 5s × 5 = 25 seconds

2. Wait 1-2 minutes and retry manually

"This is a new wallet address"

Cause: Normal behavior for first request to a wallet.

Solution: No action needed if auto_retry: true (default). The server will retry automatically.

Testnet Support

Certain Zerion API endpoints support testnet data through the X-Env header parameter. This allows developers to test applications on testnets before deploying to mainnet.

Supported Testnet Endpoints

The following endpoints accept the X-Env header:

• listWalletPositions - Get wallet positions on testnets

• getWalletPortfolio - Get portfolio data for testnet wallets

• listWalletTransactions - Fetch testnet transaction history

• listWalletNFTPositions - Get NFT positions on testnets

• listWalletNFTCollections - List NFT collections on testnets

• getWalletNftPortfolio - Get NFT portfolio for testnets

• listFungibles - List fungible assets on testnets

• getFungibleById - Get specific fungible on testnets

• listChains - List chains (including testnets)

Using Testnet Data

To query testnet data, include X-Env: testnet when calling supported endpoints:

This will return positions for the specified address on testnet chains (e.g., Ethereum Sepolia, Monad Testnet).

Testnet API Access

Important: Testnet access may require special API credentials or specific tier access. Check your API key capabilities:

• Contact api@zerion.io for testnet API access

• Verify your tier includes testnet support

• Some testnets may have limited data availability

Testnet Development Workflow

Recommended workflow for testnet-first development:

1. Create Test Wallet on Testnet (e.g., Sepolia)

2. Fund with Testnet Tokens (use faucets)

3. Test MCP Tools with X-Env: testnet

4. Verify Data Accuracy on testnet

5. Deploy to Mainnet after validation

Example - Testing Portfolio Fetch:

Supported Testnet Chains

Use listChains with X-Env: testnet to see all available testnet chains. Common testnets include:

• Ethereum Sepolia (sepolia)

• Monad Testnet (monad-testnet)

• Base Sepolia (base-sepolia)

• Optimism Sepolia (optimism-sepolia)

• Arbitrum Sepolia (arbitrum-sepolia)

Note: Testnet chain availability may vary. Use the listChains endpoint to get the current list.

Testnet Limitations

• Data Freshness: Testnet indexing may be slower than mainnet

• Historical Data: Some testnets have limited historical data

• Protocol Coverage: Not all DeFi protocols deployed on testnets

• Price Data: Testnet tokens typically have no market price

Multi-Currency Support

The Zerion API supports multiple currencies for price denomination. You can request portfolio values, position prices, and charts in USD, ETH, EUR, or BTC.

Supported Currencies

Currency-Compatible Endpoints

The currency parameter is supported on these endpoints:

• getWalletPortfolio - Portfolio total value in specified currency

• listWalletPositions - Position values in specified currency

• getWalletChart - Historical balance chart in specified currency

• getWalletPNL - Profit/Loss calculations in specified currency

• getFungibleChart - Asset price charts in specified currency

Using Different Currencies

USD (Default):

ETH Denomination:

This returns portfolio value in ETH. For example, if a wallet is worth $10,000 and ETH is $2,000, the value would be shown as 5 ETH.

EUR Denomination:

All position values will be shown in EUR instead of USD.

BTC Denomination:

Historical portfolio values will be shown in BTC equivalent.

Currency Parameter Behavior

Default Behavior: If currency parameter is omitted, USD is used by default.

Price Fields Affected: The currency parameter affects:

• attributes.value - Total value

• attributes.price - Individual asset prices

• attributes.changes - Value changes over time

• attributes.floor_price - NFT floor prices (where applicable)

Exchange Rates: Zerion uses real-time exchange rates for currency conversion. Rates are updated continuously.

Multi-Currency Examples

Example 1: DeFi Portfolio in ETH

Result: All DeFi position values shown in ETH denomination.

Example 2: European User Portfolio

Result: Portfolio value and all asset prices in EUR.

Example 3: Historical Performance in BTC

Result: Year-long portfolio performance chart denominated in BTC.

Currency Best Practices

1. Use USD for General Applications - Most users expect USD pricing

2. Use ETH for DeFi Dashboards - DeFi users often think in ETH terms

3. Use EUR for EU Compliance - Required for some European regulatory reporting

4. Use BTC for Bitcoin Communities - Aligns with Bitcoin-centric worldview

Development

Setup Development Environment

Running Tests

Code Quality

Troubleshooting

Common Issues

"Configuration error: Missing required configuration: api_key"

Solution: Set the ZERION_API_KEY environment variable:

"Timeout loading OpenAPI specification"

Solution: Check your internet connection. The server needs to download the OpenAPI spec from GitHub.

"Unauthorized: Invalid or missing API key"

Solution: Verify your API key is correct and includes the "Bearer " prefix:

"Rate limit exceeded"

Solution: Wait for the rate limit window to reset. Check the error message for retry_after_sec value.

Debug Mode

Enable debug logging for detailed information:

Or in config.yaml:

Log Interpretation

• INFO: Normal operation (startup, requests)

• WARN: Potential issues (slow operations)

• ERROR: Failures (API errors, network issues)

• DEBUG: Detailed traces (request/response bodies)

Architecture

Tech Stack

• Python 3.11+: Core language

• FastMCP: MCP server framework with OpenAPI integration

• httpx: Async HTTP client

• PyYAML: Configuration parsing

• pytest: Testing framework

Contributing

Contributions are welcome! Please follow these guidelines:

1. Fork the repository

2. Create a feature branch: git checkout -b feature/your-feature

3. Write tests for your changes

4. Ensure tests pass: pytest

5. Submit a pull request

Development Workflow

• Follow PEP 8 style guidelines

• Add type hints to function signatures

• Write docstrings for modules and functions

• Update tests for any code changes

• Keep commits focused and atomic

License

MIT License - see LICENSE file for details

Support

• Issues: GitHub Issues

• Zerion API Docs: developers.zerion.io

• MCP Specification: modelcontextprotocol.io

Changelog

See CHANGELOG.md for version history and changes