# Era Context MCP

```json
{
  "name": "Era Context MCP",
  "slug": "era_context_mcp",
  "url": "https://composio.dev/toolkits/era_context_mcp",
  "markdown_url": "https://composio.dev/toolkits/era_context_mcp.md",
  "logo_url": "https://logos.composio.dev/api/era_context_mcp",
  "categories": [
    "finance & accounting"
  ],
  "is_composio_managed": false,
  "updated_at": "2026-09-03T05:39:36.471Z"
}
```

![Era Context MCP logo](https://logos.composio.dev/api/era_context_mcp)

## Description

Securely connect your AI agents and chatbots (Claude, ChatGPT, Cursor, etc) with Era Context MCP or direct API to retrieve account balances, list transactions, initiate transfers, and generate billing statements through natural language.

## Summary

Era Context MCP provides authorized financial context and action APIs across banking, brokerage, billing, and social resources.
Use it to give agents secure, contextual access to accounts, transactions, portfolios, and billing workflows.

## Categories

- finance & accounting

## Toolkit Details

- Tools: 51

## Images

- Logo: https://logos.composio.dev/api/era_context_mcp

## Authentication

- **Dcr Oauth**
  - Type: `custom`
  - Description: Dcr Oauth authentication for Era Context MCP.
  - Setup:
    - Configure Dcr Oauth credentials for Era Context MCP.
    - Use the credentials when creating an auth config in Composio.

## Suggested Prompts

- List recent transactions from checking account
- Get portfolio holdings and current market values
- Transfer funds from checking to savings

## Supported Tools

| Tool slug | Name | Description |
|---|---|---|
| `ERA_CONTEXT_MCP_ACCOUNTS__CHECK_ACCOUNT_BALANCE` | Accounts check account balance | Get the current and available balance for a specific account, including credit limit if applicable. Requires an account_group_key from accounts__list_financial_accounts. Use when the user asks about a specific account's balance rather than all accounts. |
| `ERA_CONTEXT_MCP_ACCOUNTS__LIST_FINANCIAL_ACCOUNTS` | Accounts list financial accounts | List all linked bank accounts, credit cards, and investment accounts with current and available balances. Use this when the user asks about their accounts, which banks they use, or when you need an account_group_key to pass to other tools like accounts__check_account_balance or transactions__list_transactions. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. |
| `ERA_CONTEXT_MCP_ACCOUNTS__MANAGE_ACCOUNT` | Accounts manage account | Manage financial accounts in the user's universe — both manually tracked accounts and accounts synced from a connected banking provider. Actions: 'create' a new manual account (manual only), 'update' to change account properties (account_name is account-type-agnostic; account_type/institution_name/account_number_mask are manual-only), 'delete' to soft-delete a manual account (manual only), 'set_balance' to record a balance snapshot (manual only). On update, supplying 'account_name' writes a user-supplied display-name override that applies on top of any institution-supplied name and works for any account type — manual or connected. Supplying 'clear_account_name=true' removes the override, reverting to the institution-supplied name. The two are mutually exclusive. The account_type enum in the schema lists all valid types. Use accounts__list_financial_accounts to obtain the account_group_key for existing accounts. |
| `ERA_CONTEXT_MCP_ACCOUNTS__SET_ACCOUNT_VISIBILITY` | Accounts set account visibility | Set the visibility of a single financial account. Pass visible=true to show an account or visible=false to hide it. Hidden accounts are excluded from analytics and summaries. Use accounts__list_financial_accounts (with include_hidden=true) to get the account_group_key. Accounts excluded by tier enforcement (tier_excluded) cannot be toggled — the user must use the swap operation or upgrade their plan via billing__list_plans. Showing an account when the user is at their tier limit is also blocked — use swap instead. |
| `ERA_CONTEXT_MCP_ACCOUNTS__TOGGLE_BALANCE_BACKFILL` | Accounts toggle balance backfill | Toggle balance backfill for an account group. When enabled, balances are derived from cumulative transaction history rather than relying solely on explicit balance snapshots. This is useful for accounts that have transaction data but lack balance snapshots (e.g., CSV-imported accounts). This feature is only supported for manual accounts. Use accounts__list_financial_accounts to obtain the account_group_key. |
| `ERA_CONTEXT_MCP_BILLING__CANCEL_SUBSCRIPTION` | Billing cancel subscription | Initiate subscription cancellation. This is a three-path retention gate. Step 1: Call WITHOUT a confirmation_key — the tool returns a retention offer with a 50% discount coupon for the next billing cycle and a confirmation key. Present this offer to the user. Step 2a: If the user accepts the discount, call AGAIN WITH the confirmation_key AND accept_offer=true — the tool applies the coupon to their subscription and returns the outcome. Step 2b: If the user declines, call AGAIN WITH the confirmation_key AND accept_offer=false (or omit accept_offer) — the tool returns the billing page URL where the user can complete cancellation manually. This tool does NOT cancel the subscription directly. Requires billing-write permission. |
| `ERA_CONTEXT_MCP_BILLING__GET_CURRENT_PLAN` | Billing get current plan | Get the user's current subscription plan, tier, usage against meter limits, and what the next tier up would unlock. Use for questions like 'what plan am I on?', 'how many API calls do I have left?', or 'what am I paying for?'. Call billing__list_plans if the user wants to compare all available tiers. The response distinguishes a scheduled full cancellation from a genuine tier downgrade via is_cancellation_pending — a downgrade also sets a pending tier but is not a cancellation. When is_cancellation_pending is true, call billing__uncancel_subscription to offer the user the winback path and keep their subscription active. |
| `ERA_CONTEXT_MCP_BILLING__LIST_PAYMENTS` | Billing list payments | List the user's past invoices — what they were charged, when, for which service period, and whether each was paid. Use for 'what have I been charged?', 'when was I last billed?', or 'show me my receipts'. Amounts are in minor currency units (cents for USD). Pagination is forward-only and cursor-based, not page-numbered: pass the previous response's next_cursor back as cursor to get the next page, and stop when next_cursor is null (has_more is false). There is no total count and no way to jump to a page or go backwards — never invent a cursor value. This tool returns no invoice PDF or hosted invoice link, by design. If the user wants the actual document, send them to the billing portal, which authenticates them first. |
| `ERA_CONTEXT_MCP_BILLING__LIST_PLANS` | Billing list plans | List all available subscription plans with pricing, billing periods, feature comparisons relative to the user's current tier, and free trial eligibility. Use for questions like 'what plans are available?', 'how much does the automate plan cost?', or 'can I get a free trial?'. Returns each tier marked as upgrade, current, or downgrade. After the user picks a plan, call billing__upgrade to subscribe or change tiers directly. billing__preview_subscription_change and billing__confirm_subscription_change require an organize-tier-or-above subscription and preview then confirm the exact prorated cost of a change for an existing subscriber — call billing__upgrade instead if the user has no active subscription yet. |
| `ERA_CONTEXT_MCP_BILLING__LIST_SUBSCRIPTIONS` | Billing list subscriptions | List what the user is actually being charged for right now, read live from Stripe, broken down by individual line item. Use for 'what am I paying for?', 'when does my subscription renew?', 'how much is my add-on?', or 'am I being charged twice?'. Each subscription carries one or more items, and price, billing period and renewal date are per ITEM, not per subscription: a plan item and an add-on item on the same subscription can bill on different cadences and renew on different dates, so answer renewal questions from the specific item's current_period_end and never from another item's. A user may also hold more than one subscription; when the list has more than one entry, say so plainly rather than describing only the first. An item with kind 'legacy' is on a price predating the current catalog: report its name and amount as given and do not offer to change its billing period. Call billing__list_payments for past invoices rather than inferring them from this response. |
| `ERA_CONTEXT_MCP_BILLING__UNCANCEL_SUBSCRIPTION` | Billing uncancel subscription | Un-cancel a subscription that Stripe holds a scheduled cancellation for, in either of the two mutually exclusive expressions Stripe stores one in: the cancel_at_period_end flag, or a concrete cancel_at instant with that flag false. Clears the scheduled cancellation and optionally applies a 50% off winback coupon for the next billing cycle. The user must have an active subscription that is currently scheduled to stop renewing. Returns the current tier and whether the coupon was applied. Requires billing-write permission. |
| `ERA_CONTEXT_MCP_BILLING__UPGRADE` | Billing upgrade | Start a subscription upgrade or plan change. Returns either a confirmation that the change was applied immediately (for existing subscribers changing tiers) or a secure checkout URL the user must visit to complete payment. Use when the user says 'I want to upgrade to automate', 'switch me to the yearly plan', or 'subscribe to organize'. Call billing__upgrade directly to subscribe for the first time or change tiers immediately; existing subscribers who already have an organize-tier-or-above subscription can instead call billing__preview_subscription_change first to show the prorated price before confirming with billing__confirm_subscription_change. Requires billing-write permission. After presenting a checkout URL to the user, consider polling billing__get_current_plan after 1-2 minutes to verify the upgrade completed. |
| `ERA_CONTEXT_MCP_CONNECTIONS__CONNECT_BANK_ACCOUNT` | Connections connect bank account | Initiate a bank account connection flow. Opens a secure connection page that the user interacts with to link their bank account. Optionally accepts a connection_id to reconnect an existing connection that has become stale or requires re-authentication. Also accepts an assistant_name (your name, e.g. 'Claude') to personalize the experience. Use this when the user wants to connect a new bank account or fix a broken connection. |
| `ERA_CONTEXT_MCP_CONNECTIONS__DISCONNECT_INSTITUTION` | Connections disconnect institution | Permanently disconnect a bank institution. This is a DESTRUCTIVE, IRREVERSIBLE operation that severs the link to the financial institution and stops all future data syncs. All accounts associated with this connection will be soft-deleted and excluded from analytics. Use connections__list_connections to identify the connection_id for the institution. After disconnecting, use connections__connect_bank_account to reconnect where the provider supports reconnecting (some connection types can't be reconnected on demand — the disconnect response says which). |
| `ERA_CONTEXT_MCP_CONNECTIONS__LIST_CONNECTIONS` | Connections list connections | List every one of the user's bank connections with an honest, provider-agnostic status for each: whether it is healthy, syncing with no data yet, needs reconnecting, is currently disconnected, or one of several other narrower states — see each row's state for the exact one. This is the discover hop of the connection recovery loop — call this first to get each connection's connection_id, then act on a specific connection with connections__trigger_connection_resync, connections__connect_bank_account, or connections__disconnect_institution. Unlike accounts__list_financial_accounts, this tool's subject is the connection roster itself, not the accounts beneath it — use it to answer "what banks are connected and are any of them broken?" rather than "what accounts do I have?" |
| `ERA_CONTEXT_MCP_CONNECTIONS__SET_PROACTIVE_SYNC_MODE` | Connections set proactive sync mode | Record whether Era may proactively ask a bank connection's provider for fresh data on its own schedule. Set mode='disabled' when the user wants Era to stop reaching out to that bank between their own requests; set mode='enabled' to allow it again. This does NOT stop the connection: webhook updates, reconciliation and reads of data the provider already holds continue either way, and an on-demand refresh the user asks for is always honoured. The instruction is recorded for any connection the user owns — including one whose provider is never proactively contacted, and one whose plan does not include the proactive lane — so it survives a plan change and takes effect if the situation changes. Use connections__list_connections to obtain the connection_id. The response reports what was recorded AND whether it changes anything today, so say that back to the user rather than implying an effect that will not occur. |
| `ERA_CONTEXT_MCP_CONNECTIONS__TRIGGER_CONNECTION_RESYNC` | Connections trigger connection resync | Trigger an on-demand data resync for a bank connection. This fetches the latest transaction and balance data from supported banks — most major institutions support on-demand refresh, though it may take a few minutes for data to arrive. Possible outcomes: (1) resync queued successfully — check back shortly for updated data, (2) the bank requires the user to re-authenticate first — a widget link is returned that the user must open in the app to authenticate before the latest data can be fetched, (3) user's plan does not include on-demand resync (available on Automate tier or with Fast-Lane Data Sync add-on; use billing__list_plans to explore upgrade options), (4) data was already refreshed recently — next refresh available after the indicated time, (5) connection not found or not owned by the user. Use connections__list_connections to obtain the connection_id. |
| `ERA_CONTEXT_MCP_HELP__GET_HELP` | Help get help | Get contextual help and onboarding guidance for Era Context. Use when the user asks how to use the platform, what capabilities are available, how to get started, how to connect accounts, what they can ask, or questions about privacy or troubleshooting. Returns authoritative help content — prefer this over generating answers from memory. |
| `ERA_CONTEXT_MCP_INSIGHTS__ANALYZE_SPENDING` | Insights analyze spending | Break down spending by category, merchant, account, week, or month. Each group carries amount, percent of total, and transaction count. group_by 'category', 'merchant' or 'account' returns the top_n highest-spending groups, highest first. 'week' and 'month' ignore top_n and return one group per period that has spending, oldest first, never truncated. A gap in the series means no spending in that period, not an omitted group. A wide range returns many groups; narrow the period to bound the response. Week and month groups carry period_start and period_end: the dates covered, clamped to the requested range. Read those dates, not the label, when the span matters. The first and last group are commonly partial. A week label is a 7-day block counted from January 1, not an ISO week. period.start is the first date the response covers: the requested start date whenever the request names one, and — for 'all_time', or a custom range starting 0001-01-01, which name none — the date of the earliest transaction matching this call. It is omitted whenever no such date is available: beside empty groups the empty_state envelope explains why; beside non-empty groups the bound was unavailable, never that nothing matched. Divide total_spending by the span from period.start to period.end only for 'week' or 'month', where every matching transaction is in some group. With 'category', 'merchant' or 'account', total_spending sums only the groups RETURNED, not everything matched. Dividing it understates the rate; use group_by='month' or 'week' instead. Drill from a category into its merchants with category_key. Use it for questions like 'where is my money going?'. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_INSIGHTS__COMPARE_SPENDING_PERIODS` | Insights compare spending periods | Compare spending between any two time periods side-by-side with pre-computed deltas and percentage changes. Group comparisons by category, merchant, or total. Use for questions like 'am I spending more this month than last?', 'how do my grocery costs compare to last year?', or 'which categories increased the most?'. Automatically warns about partial periods to prevent misleading comparisons. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_INSIGHTS__FORECAST_SPENDING` | Insights forecast spending | Estimate how much the user will spend by the end of the current period based on their spending pace so far. Returns: projected end-of-period total, daily spending rate, category-level breakdown with projections, and expected upcoming recurring charges (subscriptions, bills). Use for questions like 'how much will I spend this month?', 'am I on track with my budget?', or 'what recurring charges are coming up?'. The projection is based on current spending patterns and known recurring items — it is an estimate, not a guarantee. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_INSIGHTS__GET_CASH_FLOW` | Insights get cash flow | Analyze income, spending, and net cash flow over multiple weeks or months (up to 12 periods) with computed averages. Use for trend questions like 'am I saving more than last quarter?', 'how has my spending changed?', or 'what's my average monthly income?'. Returns pre-computed averages so you can narrate trends directly without doing math. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_INSIGHTS__GET_DAILY_CATEGORY_SPENDING` | Insights get daily category spending | Get a per-day, per-category spending breakdown for a calendar month. Returns one row per day-and-category combination with the spending amount, transaction count, and the user's category display name, plus month totals. Use for spending-calendar drill-downs and questions like 'which categories did I spend on each day this month?' or 'break down my daily spending by category'. For per-day totals of spending, income, and bills use insights__get_daily_financial_summary; for ranked category totals over a period use insights__analyze_spending. For the current month, totals apply a same-day rolling cutoff: rows dated after today are still returned but excluded from total_amount and transaction_count. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_INSIGHTS__GET_DAILY_FINANCIAL_SUMMARY` | Insights get daily financial summary | Get daily financial calendar for a month. Returns spending, income, bills/recurrences, and net per day, plus month totals and prior-month comparisons. Totals are broken down per currency (keyed by ISO-4217 code in totals_by_currency and each day's by_currency): a user's accounts may span several currencies, which are reported separately and never summed together. Use for calendar heatmaps, daily budgets, cash flow analysis, or questions like 'what did I earn and spend each day this month?'. These are aggregate daily totals, not a row-level transaction list, so they are not subject to the free-plan history window that limits transactions__list_transactions/transactions__search_transactions — a queried month's totals reflect all of that month's activity regardless of plan. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__CONFIRM_OR_REJECT_INFERENCE` | Knowledge confirm or reject inference | Confirm or reject a fact that was inferred by the system. Use 'confirm' when the user agrees with an inferred assertion (upgrades confidence to 'confirmed'). Use 'reject' when the user disagrees -- optionally provide a corrected_value with the user's actual answer. Call knowledge__get_financial_context_and_overview first to see inferred assertions that need confirmation. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__DEFER_QUESTION` | Knowledge defer question | Skip or snooze an onboarding question. Use 'skip' when the user declines to answer a question (it may be re-surfaced later by the flow engine). Use 'snooze' when the user wants to defer the question for a specific number of days. Call knowledge__get_pending_questions first to discover available question slugs. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__FORGET` | Knowledge forget | Retract or delete a previously recorded fact about the user. Use this when the user asks to forget or remove a specific piece of information. The assertion is marked as retracted (not physically deleted) so it appears in the audit history. Call knowledge__get_financial_context_and_overview first to find the slug of the fact to retract. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__GET_FINANCIAL_CONTEXT_AND_OVERVIEW` | Knowledge get financial context and overview | Load the user's profile, complete financial snapshot (all account balances, net worth, this month vs. last month income/spending/net, top 5 spending categories), known facts, goals, preferences, and personalization state — all in one call. Typically the first tool called in a session to establish user context. Returns a personalization.guidance_quality field: when not 'ready', personalization.questions_to_unlock_better_guidance contains onboarding questions that improve guidance quality. For additional questions, call knowledge__get_pending_questions. Facts whose structured value carries "$type": "lookup", "lookupTarget": "connected-accounts" record the user's intent to source that value from their connected accounts; resolve the current amount against the accounts and totals_by_type arrays in this same response rather than surfacing the raw directive string. Related tools: insights__analyze_spending, transactions__search_transactions, insights__compare_spending_periods for deeper financial analysis. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__GET_PENDING_QUESTIONS` | Knowledge get pending questions | Get the next onboarding questions to ask the user. Returns an ordered list of pending questions with each question's slug, display text, answer type, category, constraints, and a suggested_presentation field. Inspect suggested_presentation to decide how to present each question: when 'conversational', ask in natural language -- for single-select and country types, consider using your client's native question/picker tool (e.g., AskUserQuestion) for a better user experience. When 'embedded_ui', call knowledge__show_question_ui to present a visual input control (best for numeric, date, money, multi-select, compound, and scale types). After the user answers, record it via knowledge__remember. Tip: you can offer to extract answers from documents or images the user shares (pay stubs, tax forms, statements), or from facts you already know — not every question needs to be asked directly. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__RECALL_HISTORY` | Knowledge recall history | Get the version history of a specific fact about the user. Returns all versions of the assertion including supersessions, retractions, and confirmations. Use this when the user asks how a fact has changed over time or to audit the history of a specific piece of information. Call knowledge__get_financial_context_and_overview first to find assertion slugs. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__REMEMBER` | Knowledge remember | Record a fact, preference, goal, or observation about the user. Persistent across sessions and shared with all connected agents. Two modes: (1) prompted -- supply the slug and answer from knowledge__get_pending_questions; category is auto-derived. (2) Ambient -- supply a descriptive slug and category for facts discovered in conversation. Populate exactly one typed value field matching the answer_type, or set use_connected_accounts to source the value from the user's connected financial data. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__RESET_PACK_QUESTIONS` | Knowledge reset pack questions | Warning: this cannot be undone — only call when you have high confidence the user wants to reset and re-surface all previously skipped or snoozed questions. This operation reverts all Skipped and Snoozed question states back to Pending so they will be re-surfaced by the flow engine. It does not delete any stored facts or assertions — only the skip/snooze state is reset. Call knowledge__get_pending_questions after a successful reset to obtain the newly re-surfaced questions. |
| `ERA_CONTEXT_MCP_KNOWLEDGE__SHOW_QUESTION_UI` | Knowledge show question ui | Present an onboarding question using a visual input control (slider, date picker, multi-select checklist, etc.). Best for answer types that benefit from structured widgets: numeric, date, money, multi-select, compound, and scale. Requires a client that supports MCP Apps embedded UI rendering. If your client is a CLI or terminal without embedded UI support, present the question conversationally or use your client's native question/picker tool instead. Call knowledge__get_pending_questions first to discover available question slugs and check each question's suggested_presentation field. Use this tool when suggested_presentation is 'embedded_ui'. For simple answer types (text, boolean, single-select, country, region), record the answer directly via knowledge__remember. |
| `ERA_CONTEXT_MCP_NURTURE__GET_MY_STATUS` | Nurture get my status | Get the caller's own nurture (lifecycle email) campaign enrollment status — which campaigns they are currently enrolled in, their progress through each, and whether they have unsubscribed. Use for questions like 'what emails am I signed up for?' or 'am I subscribed to X?'. Call nurture__set_subscription to change the subscription state for a specific campaign. |
| `ERA_CONTEXT_MCP_NURTURE__SET_SUBSCRIPTION` | Nurture set subscription | Subscribe the caller to, or unsubscribe them from, a nurture (lifecycle email) campaign. Takes effect immediately — no confirmation step, and always reversible by calling this tool again with the opposite value. Unsubscribing from a campaign the caller was never enrolled in is a safe no-op. Call nurture__get_my_status first to see the caller's current campaigns and subscription state. |
| `ERA_CONTEXT_MCP_REFERRAL__GET_DASHBOARD_SSO` | Referral get dashboard sso | Get a single-use SSO magic link to open the user's Rewardful affiliate dashboard. The link expires after approximately 1 minute and can only be used once. Use when the user wants to view detailed referral reporting, commission history, or manage their affiliate settings. |
| `ERA_CONTEXT_MCP_REFERRAL__GET_REFERRAL_LINK` | Referral get referral link | Get the user's referral link if they are enrolled in the referral program. Returns the shareable referral URL and affiliate ID for enrolled users, or indicates the user is not yet enrolled. Users must join the referral program before a link is available. |
| `ERA_CONTEXT_MCP_REFERRAL__GET_REFERRAL_STATS` | Referral get referral stats | Get the user's referral performance statistics: visitors, conversions, earned commissions, and pending commissions. Use when the user asks about referral earnings, conversion rates, or how their referrals are performing. |
| `ERA_CONTEXT_MCP_REFERRAL__JOIN_REFERRAL_PROGRAM` | Referral join referral program | Join the referral program by creating a Rewardful affiliate for the authenticated user. Returns the shareable referral URL and affiliate ID on success. Use when the user wants to start referring others and earning commissions. |
| `ERA_CONTEXT_MCP_REFERRAL__SWITCH_REFERRAL_CAMPAIGN` | Referral switch referral campaign | Move the user's referral programme onto a different track. Rewardful allows one affiliate per email, so this reassigns their existing affiliate rather than creating a second one — the user must already have joined (referral__join_referral_program) or this returns an error. Two destinations accept members: 'friends-family-usd' pays a fixed reward for each friend who subscribes, in the currency that user is billed in, and 'creator' pays 30% recurring commission for 12 months on each referred subscription. Naming 'friends-family-usd' selects the track only — the server assigns the campaign paying the user's own settled currency and the response reports the slug actually assigned, so read the currency off the result rather than off the request. Any other slug, including a campaign the deployment has retired, is refused with the list of destinations that would have worked. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__IMPORT_CSV_TRANSACTIONS` | Transactions import csv transactions | Import transactions from inline CSV text into a manual account. Supports auto-detection of common formats or explicit format hints. Partial-success semantics: rows that fail validation are reported individually. Set preview_only=true to validate without importing. PROTOCOL — before calling, do the categorisation work up front so the CSV you submit is already aligned with the user's category landscape: (1) call accounts__list_financial_accounts to obtain the account_group_key for the target manual account; (2) call transactions__list_spending_categories to enumerate the user's effective categories — both system and custom (Origin="user"); (3) inspect the source CSV header to see whether it carries a category column; (4) when you write the CSV content into csv_content, set the Category column on each row to text that maps cleanly onto the categories surfaced in step 2. Composing the CSV deliberately at submission time keeps the import deterministic and avoids a follow-up cleanup pass. A plan may limit reads to a rolling recent window of history. When that limit applies to this caller, a transaction dated before the window is still stored and syncs normally — the write is never blocked, delayed, or rejected by the window. It simply will not appear in transactions__list_transactions/transactions__search_transactions results until the plan is upgraded or the date rolls back into the window. The response signals when this applies to a specific transaction and, whenever the window could be confirmed, leads that signal with the date visible history starts — relay that date rather than only the fact of exclusion. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__LIST_RECURRING_CHARGES` | Transactions list recurring charges | List detected recurring transactions — subscriptions (Netflix, Spotify), bills (rent, utilities), and regular income (salary, freelance) — with estimated monthly amounts, frequency, and last-seen date. Includes monthly totals by type. Use for questions like 'what subscriptions am I paying for?', 'how much are my fixed monthly expenses?', or 'what’s my regular income?'. This is detected pattern metadata (the FirstSeen/LastSeen dates that identify a recurrence), not a row-level transaction list, so it is not subject to the free-plan history window that limits transactions__list_transactions/transactions__search_transactions. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__LIST_SPENDING_CATEGORIES` | Transactions list spending categories | List all available spending categories organized in a parent/child hierarchy (e.g., 'Daily living' contains 'Groceries', 'Dining out', etc.). Each category has a unique key (the key field) that you MUST use when assigning categories via transactions__update_transactions or transactions__manage_automation_rules. Call this tool first whenever you need to categorize a transaction or create a rule with a set_category action — do not guess category keys. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__LIST_TRANSACTIONS` | Transactions list transactions | List recent transactions with pagination, optionally filtered by account and date range. Returns merchant name, amount, category, and pending status for each transaction. Best for browsing recent activity or getting a chronological view. For targeted lookups (e.g. 'find my Amazon charges'), prefer transactions__search_transactions instead. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. A plan may limit reads to a rolling recent window of history; when that limit applies to this caller, older transactions outside the window are not returned even when explicitly requested by date. The response signals whenever the window clamped the results (history_window_applied) and then carries the date visible history starts (history_window_floor_date), how far back matching activity actually exists (history_window_earliest_date), and how many older transactions were withheld (history_window_hidden_count) — lead with the dates when relaying this, so the user learns how far their history really goes rather than only that some rows are missing. The earliest date and the count are each omitted when unknown (absent is NOT zero), and both are scoped to THIS request's own filters (account, category, search, date range), i.e. what was withheld from THIS query, not an account-wide total. So an empty or shortened result set does not necessarily mean no matching transactions ever existed — upgrading the plan reveals full history immediately. When the window clamped results AND the caller's plan was confirmed, the response also carries a structured upgrade affordance (history_window_upsell) naming the plan that unlocks the hidden history and the tool to call to upgrade — relay it to offer the user a concrete next step. If the plan could not be confirmed at read time (a transient fail-closed clamp that may have affected a paid caller), history_window_upsell is omitted; the response instead carries a warning that the history window could not be confirmed and to retry shortly — relay that caveat and do NOT attribute the clamp to the caller's plan. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__MANAGE_AUTOMATION_RULES` | Transactions manage automation rules | Create and manage automation rules that automatically organize the user's transactions. Transaction-scope rules evaluate filters against each individual transaction as it arrives. Pattern-scope rules evaluate a pattern specification against a time-windowed batch of transactions to detect cross-transaction patterns such as transfers, recurring charges, spending anomalies, and frequency thresholds. Transaction-scope rules watch for transactions matching conditions you define (by merchant name, amount, category, tags, transaction type, date, or combinations using and/or/not logic) and then perform actions like assigning a category, adding/removing tags, renaming the merchant, hiding the transaction, flagging for review, updating the description, or marking as a transfer. Pattern-scope rules require a pattern_spec object and window_days parameter. Library pattern rules (like Transfer Detection, Recurring Detection, and Anomaly Detection) are created automatically and cannot be deleted, but you can enable, disable, or tune their behavior via user_overrides on update. Use the preview action to test filters or pattern specs against historical data before committing. BEFORE creating rules: call transactions__list_spending_categories to get category keys for set_category actions, and call transactions__manage_transaction_tags with list_tags to get tag keys for tag-related actions or filters. AFTER creating rules: the user's existing transactions are updated immediately by default (apply_retroactively defaults to true), and all future matching transactions will be processed automatically. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__MANAGE_CATEGORIES` | Transactions manage categories | Create, rename, hide, unhide, delete, or merge spending categories. Display mutations (rename, emoji, description, spending type) of system categories are free on all plans. Custom category limits per plan — Context Basic (free): 2, Context Organize: 10, Context Automate: 50, Context Optimize: 100, Context Operate: 300. Use transactions__list_spending_categories first to get current category keys. When creating a category, provide a URL-safe slug (lowercase, hyphens allowed, 2-50 chars) and a parent category key under which to place it. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__MANAGE_MANUAL_TRANSACTION` | Transactions manage manual transaction | Batch-manage transactions on a manually tracked account. Send an array of operations (create, update, delete) in a single call — ideal for bulk imports. All operations share one account_group_key and are processed sequentially with partial-success semantics. Set preview_only=true to validate without writing. Use accounts__list_financial_accounts to obtain the account_group_key, and transactions__list_transactions to obtain the transaction_group_key. Before creating transactions, call transactions__list_spending_categories to obtain a valid category_key (fcat_xxx format). A plan may limit reads to a rolling recent window of history. When that limit applies to this caller, a transaction dated before the window is still stored and syncs normally — the write is never blocked, delayed, or rejected by the window. It simply will not appear in transactions__list_transactions/transactions__search_transactions results until the plan is upgraded or the date rolls back into the window. The response signals when this applies to a specific transaction and, whenever the window could be confirmed, leads that signal with the date visible history starts — relay that date rather than only the fact of exclusion. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__MANAGE_TRANSACTION_TAGS` | Transactions manage transaction tags | Create, list, update, or delete tags, and attach or detach them from transactions. Tags are custom labels the user attaches to transactions for organizing expenses by project, trip, goal, or any personal grouping (e.g., 'Vacation 2026', 'Tax Deductible', 'Side Project'). Use this tool when the user wants to create a new tag, see existing tags, or tag specific transactions. After creating a tag, attach it to specific transactions with the 'assign_tags' action (and detach with 'remove_tags'), or set up a rule to auto-tag matching transactions using transactions__manage_automation_rules. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__MANAGE_TRANSFER_LINKS` | Transactions manage transfer links | List, confirm, or reject detected transfer links between the user's accounts. Transfer links are automatically detected when matching debit/credit transactions appear across different accounts (exact or near-match amounts within 3%). Use 'list' to see all detected transfers. Use 'confirm' when the user verifies a detected transfer is correct (upgrades confidence to 100%). Use 'reject' when a detected transfer is a false positive (removes the link and prevents re-detection). Transfer-tagged transactions are automatically excluded from spending and income analytics to prevent double-counting. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__SEARCH_TRANSACTIONS` | Transactions search transactions | Search and filter transactions by merchant name, description, amount range, date range, and direction (debit/credit). Returns matching transactions with total count and sum — no arithmetic needed. Use for targeted questions like 'how much did I spend at Starbucks?', 'what was that $50 charge?', or 'show me all refunds this month'. Supports free-text search so exact merchant names are not required — but free-text does NOT match category names. To filter by category, first call transactions__list_spending_categories to resolve the category to its fcat_* key, then pass that key as category_key (set include_children=true to also include its subcategories). For browsing recent activity chronologically, prefer transactions__list_transactions instead. Results include only posted/settled transactions; pending (authorization-hold) transactions are excluded. A plan may limit reads to a rolling recent window of history; when that limit applies to this caller, older transactions outside the window are not returned even when explicitly requested by date. The response signals whenever the window clamped the results (history_window_applied) and then carries the date visible history starts (history_window_floor_date), how far back matching activity actually exists (history_window_earliest_date), and how many older transactions were withheld (history_window_hidden_count) — lead with the dates when relaying this, so the user learns how far their history really goes rather than only that some rows are missing. The earliest date and the count are each omitted when unknown (absent is NOT zero), and both are scoped to THIS request's own filters (account, category, search, date range), i.e. what was withheld from THIS query, not an account-wide total. So an empty or shortened result set does not necessarily mean no matching transactions ever existed — upgrading the plan reveals full history immediately. When the window clamped results AND the caller's plan was confirmed, the response also carries a structured upgrade affordance (history_window_upsell) naming the plan that unlocks the hidden history and the tool to call to upgrade — relay it to offer the user a concrete next step. If the plan could not be confirmed at read time (a transient fail-closed clamp that may have affected a paid caller), history_window_upsell is omitted; the response instead carries a warning that the history window could not be confirmed and to retry shortly — relay that caveat and do NOT attribute the clamp to the caller's plan. When a result — or a section of it — is empty, the response carries an empty_state envelope (kind, reason, next_step; multi-section responses instead use section-scoped variants such as accounts_empty_state) giving the authoritative reason it is empty and the recovery action. Read that envelope for the reason rather than inferring one — do not assume data is still syncing or settling. The response may also carry a top-level warnings array flagging data-health caveats (e.g. a connection to reconnect, or an unconfirmed check to retry); relay those caveats too. Session context from knowledge__get_financial_context_and_overview enriches these results with the user's profile, goals, and preferences. |
| `ERA_CONTEXT_MCP_TRANSACTIONS__UPDATE_TRANSACTIONS` | Transactions update transactions | Update the category, merchant name, description, or review status on one or more transactions. The user's changes take priority over automatically detected values. BEFORE calling: use transactions__list_transactions or transactions__search_transactions to get transaction IDs, and call transactions__list_spending_categories to get valid category keys if changing the category. Use the clear_ options to undo a previous manual change and revert to the original value. For bulk automatic updates based on conditions, use transactions__manage_automation_rules instead. |

## Supported Triggers

None listed.

## Installation and MCP Setup

### Path 1: SDK Installation

#### Path 1, Step 1: Install Composio

Install the Composio SDK
```python
pip install composio_openai
```

```typescript
npm install @composio/openai
```

#### Path 1, Step 2: Initialize Composio and Create Tool Router Session

Import and initialize Composio client, then create a Tool Router session
```python
from openai import OpenAI
from composio import Composio
from composio_openai import OpenAIResponsesProvider

composio = Composio(provider=OpenAIResponsesProvider())
openai = OpenAI()
session = composio.create(user_id='your-user-id')
```

```typescript
import OpenAI from 'openai';
import { Composio } from '@composio/core';
import { OpenAIResponsesProvider } from '@composio/openai';

const composio = new Composio({
  provider: new OpenAIResponsesProvider(),
});
const openai = new OpenAI({});
const session = await composio.create('your-user-id');
```

#### Path 1, Step 3: Execute Era Context MCP Tools via Tool Router with Your Agent

Get tools from Tool Router session and execute Era Context MCP actions with your Agent
```python
tools = session.tools
response = openai.responses.create(
  model='gpt-4.1',
  tools=tools,
  input=[{
    'role': 'user',
    'content': 'YOUR_SPECIFIC_PROMPT_HERE'
  }]
)
result = composio.provider.handle_tool_calls(
  response=response,
  user_id='your-user-id'
)
print(result)
```

```typescript
const tools = session.tools;
const response = await openai.responses.create({
  model: 'gpt-4.1',
  tools: tools,
  input: [{
    role: 'user',
    content: 'YOUR_SPECIFIC_PROMPT_HERE'
  }],
});
const result = await composio.provider.handleToolCalls(
  'your-user-id',
  response.output
);
console.log(result);
```

### Path 2: MCP Server Setup

#### Path 2, Step 1: Install Composio

Install the Composio SDK for Python or TypeScript
```python
pip install composio claude-agent-sdk
```

```typescript
npm install @composio/core ai @ai-sdk/openai @ai-sdk/mcp
```

#### Path 2, Step 2: Initialize Client and Create Tool Router Session

Import and initialize the Composio client, then create a Tool Router session for Era Context MCP
```python
from composio import Composio
from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

composio = Composio(api_key='your-composio-api-key')
session = composio.create(user_id='your-user-id')
url = session.mcp.url
```

```typescript
import { Composio } from '@composio/core';

const composio = new Composio({ apiKey: 'your-api-key' });
const session = await composio.create('your-user-id');
console.log(`Tool Router session created: ${session.mcp.url}`);
```

#### Path 2, Step 3: Connect to AI Agent

Use the MCP server with your AI agent (Anthropic Claude or Mastra)
```python
import asyncio

options = ClaudeAgentOptions(
    permission_mode='bypassPermissions',
    mcp_servers={
        'tool_router': {
            'type': 'http',
            'url': url,
            'headers': {
                'x-api-key': 'your-composio-api-key'
            }
        }
    },
    system_prompt='You are a helpful assistant with access to Era Context MCP tools.',
    max_turns=10
)

async def main():
    async with ClaudeSDKClient(options=options) as client:
        await client.query('YOUR_SPECIFIC_PROMPT_HERE')
        async for message in client.receive_response():
            if hasattr(message, 'content'):
                for block in message.content:
                    if hasattr(block, 'text'):
                        print(block.text)

asyncio.run(main())
```

```typescript
import { openai } from '@ai-sdk/openai';
import { experimental_createMCPClient as createMCPClient } from '@ai-sdk/mcp';
import { generateText } from 'ai';

const client = await createMCPClient({
  transport: {
    type: 'http',
    url: session.mcp.url,
    headers: {
      'x-api-key': 'your-composio-api-key',
    },
  },
});

const tools = await client.tools();
const { text } = await generateText({
  model: openai('gpt-4o'),
  tools,
  messages: [{
    role: 'user',
    content: 'YOUR_SPECIFIC_PROMPT_HERE'
  }],
  maxSteps: 5,
});

console.log(`Agent: ${text}`);
```

## Why Use Composio?

### 1. AI Native Era Context MCP Integration

- Supports both Era Context MCP and direct API based integrations
- Structured, LLM-friendly schemas for reliable tool execution
- Rich coverage for reading, writing, and querying your Era Context MCP data

### 2. Managed Auth

- Built-in OAuth handling with automatic token refresh and rotation
- Central place to manage, scope, and revoke Era Context MCP access
- Per user and per environment credentials instead of hard-coded keys

### 3. Agent Optimized Design

- Tools are tuned using real error and success rates to improve reliability over time
- Comprehensive execution logs so you always know what ran, when, and on whose behalf

### 4. Enterprise Grade Security

- Fine-grained RBAC so you control which agents and users can access Era Context MCP
- Scoped, least privilege access to Era Context MCP resources
- Full audit trail of agent actions to support review and compliance

## Use Era Context MCP with any AI Agent Framework

Choose a framework you want to connect Era Context MCP with:

- [ChatGPT Work](https://composio.dev/toolkits/era_context_mcp/framework/chatgpt)
- [Claude Cowork](https://composio.dev/toolkits/era_context_mcp/framework/claude-cowork)
- [Hermes](https://composio.dev/toolkits/era_context_mcp/framework/hermes-agent)

## Related Toolkits

- [Stripe](https://composio.dev/toolkits/stripe) - Stripe is a global online payments platform offering APIs for managing payments, customers, and subscriptions. Trusted by businesses for secure, efficient, and scalable payment processing worldwide.
- [44API](https://composio.dev/toolkits/44api) - 44API is an API service for validating VAT and tax identifiers and returning company details. Use it to verify business tax data and manage account IP whitelists quickly.
- [Aiwyn Tax MCP](https://composio.dev/toolkits/aiwyn_tax_mcp) - Aiwyn Tax MCP is a tax estimation service powered by Aiwyn's federal and state tax engine. It helps teams estimate tax outcomes without building tax calculation logic from scratch.
- [Alpaca](https://composio.dev/toolkits/alpaca) - Alpaca is a stock and crypto trading platform for commission-free trading, real-time market data, and algorithmic strategies. Use it to build brokerage apps, trading bots, and portfolio workflows with market connectivity.
- [Alpha vantage](https://composio.dev/toolkits/alpha_vantage) - Alpha Vantage is a financial data platform offering real-time and historical stock market APIs. Get instant, reliable access to equities, forex, and technical analysis data for smarter trading decisions.
- [Altoviz](https://composio.dev/toolkits/altoviz) - Altoviz is a cloud-based billing and invoicing platform for businesses. It streamlines online payments, expense tracking, and customizable invoice management.
- [Benzinga](https://composio.dev/toolkits/benzinga) - Benzinga provides real-time financial news and data APIs for market coverage. It helps you track breaking news and actionable market insights instantly.
- [Bigdata.com MCP](https://composio.dev/toolkits/bigdata_com_mcp) - Bigdata.com MCP provides grounded access to financial news, transcripts, filings, and entity intelligence. Ideal for building research workflows and generating timely market insights.
- [Billsby](https://composio.dev/toolkits/billsby) - Billsby is a subscription billing platform for managing customers, subscriptions, invoices, products, plans, usage counters, add-ons, and allowances. It helps SaaS and subscription teams automate billing operations without building complex billing logic from scratch.
- [Brex](https://composio.dev/toolkits/brex) - Brex provides corporate credit cards and spend management tailored for startups and tech businesses. It helps optimize company cash flow, streamline accounting, and accelerate business growth.
- [Cashfree Payments MCP](https://composio.dev/toolkits/cashfree_payments_mcp) - Cashfree Payments MCP is a merchant payments platform that handles collection, payouts, subscriptions, settlements, refunds, and identity verification. Simplifies merchant money lifecycle management with unified, API-driven workflows.
- [Chaser](https://composio.dev/toolkits/chaser) - Chaser is accounts receivable automation software that sends invoice reminders and helps businesses get paid faster. It streamlines the collections process to save time and improve cash flow.
- [Clarity AI MCP](https://composio.dev/toolkits/clarity_ai_mcp) - Clarity AI MCP is an MCP toolkit for simulating SFDR 2.0 fund classifications from a fund name, ISIN, or CUSIP. Use it to tap Clarity AI disclosure data and modeling without building custom sustainability-data workflows.
- [Clientary](https://composio.dev/toolkits/clientary) - Clientary is a platform for managing clients, invoices, projects, proposals, and more. It streamlines client work and saves you serious admin time.
- [Coinbase](https://composio.dev/toolkits/coinbase) - Coinbase is a platform for buying, selling, and storing cryptocurrency. It makes exchanging and managing crypto simple and secure for everyone.
- [Coinranking](https://composio.dev/toolkits/coinranking) - Coinranking is a comprehensive cryptocurrency market data platform offering access to real-time coin prices, market caps, and historical data. Get accurate, up-to-date stats for thousands of digital assets in one place.
- [Coupa](https://composio.dev/toolkits/coupa) - Coupa is a business spend management platform for procurement, invoicing, and expenses. It helps organizations streamline purchasing, control costs, and gain complete visibility over financial operations.
- [CurrencyScoop](https://composio.dev/toolkits/currencyscoop) - CurrencyScoop is a developer-friendly API for real-time and historical currency exchange rates. Easily access fiat and crypto data for smart, up-to-date financial applications.
- [Daffy](https://composio.dev/toolkits/daffy) - Daffy is a modern charitable giving platform with a donor-advised fund. Easily set aside funds, grow them tax-free, and donate to over 1.7 million U.S. charities.
- [Debitura](https://composio.dev/toolkits/debitura) - Debitura is a debt collection platform for managing creditor cases, payments, tasks, coverage, divisions, and webhooks. It helps teams organize collection operations and track debtor activity through a Customer API.

## Frequently Asked Questions

### Do I need my own developer credentials to use Era Context MCP with Composio?

Yes, Era Context MCP requires you to configure your own Dcr Oauth credentials. Once set up, Composio handles secure credential storage and management for you.

### Can I use multiple toolkits together?

Yes! Composio's Tool Router enables agents to use multiple toolkits. [Learn more](https://docs.composio.dev/tool-router/overview).

### Is Composio secure?

Composio is SOC 2 and ISO 27001 compliant with all data encrypted in transit and at rest. [Learn more](https://trust.composio.dev).

### What if the API changes?

Composio maintains and updates all toolkit integrations automatically, so your agents always work with the latest API versions.

---
[See all toolkits](https://composio.dev/toolkits) · [Composio docs](https://docs.composio.dev/llms.txt)