pluggy-docs

Endpoint

Hosted endpoint · transport streamable-http

Connect

This is a remote MCP server — point an MCP client at the endpoint URL. Clients with native remote support (Claude, Cursor, VS Code, …):

For stdio-only clients (older Claude Desktop, etc.), bridge with mcp-remote:

If the server requires authentication, add the provider's token/header (e.g. an X-API-Key) per its docs. A quick reachability check:

Tool quality observed · not scored

From an anonymous initialize + tools/list capture measured 2026-10-27; tokens are chars/3.6 of each tool definition. Recorded for the Kin Score's agent readiness as an observed signal — it contributes no points yet.

Tools

• query — Ask a natural-language question about the Pluggy API and get a generated answer with citations. Combines docs, changelog, recipes, and API reference. Responds in the user's question language.
• search_docs — Search the Pluggy documentation guides (concepts, quickstart, integration). Returns reranked excerpts with relevance scores.
• search_changelog — Search the Pluggy changelog (release notes, breaking changes, migration notes). Returns reranked excerpts with the entry's publication date, language and the section heading the text came from, so results can be ordered by recency and cited precisely. Entries are published in English and Portuguese.
• list_changelog_changes — Enumerate individual changelog changes — not whole months — filtered by type, breaking status, category or date. Exhaustive and deterministic, so an empty result genuinely means nothing matched. Use this for 'what broke', 'what shipped since X' or 'what changed in payments'; use search_changelog when the question is about wording rather than a filter. Structured months cover February 2026 onwards; older entries are free prose and are not listed.
• search_recipes — Search the Pluggy recipes (cookbook, integration patterns, code examples). Returns reranked excerpts with relevance scores. Recipes are English-only.
• search_qa — Search the curated, human-verified Pluggy support Q&A (real questions answered by the team, mostly in Portuguese). This is the highest-trust source for 'how do I / why does X happen' support questions — prefer it over the docs guides when a question matches. Returns reranked question+answer excerpts with relevance scores.
• get_guide — Retrieve the full content of a single Pluggy documentation guide by its slug and locale.
• list_guides — List all available Pluggy documentation guides (slug, title, description, category) for a given locale. Optionally filter by category.
• get_api_endpoint — Retrieve full details about a specific Pluggy API endpoint by its operationId. Returns method, path, parameters, request body, and responses sourced from the OpenAPI spec. Defaults to the main Pluggy API; pass `spec` for another (e.g. 'enrichment-api').
• list_endpoints — List all available Pluggy API endpoints from an OpenAPI spec. Defaults to the main Pluggy API; pass `spec` to target another (see list_specs — e.g. 'enrichment-api'). Optionally filter by tag (case-insensitive).
• list_specs — List the available Pluggy OpenAPI specs. Use a spec's id with list_endpoints / get_api_endpoint to browse that API. There are two: the main Pluggy API and the Enrichment API (categorize / behavior-analysis / recurring-payments).
• search_endpoints — Deep-search Pluggy API endpoints by keyword across path, operationId, summary, description, tags, and parameter names — to discover the right endpoint when you don't know its operationId. Searches every spec by default; pass `spec` to scope to one (see list_specs).
• submit_feedback — Tell Pluggy what was incorrect, missing, confusing, or broken while using this MCP. Send a concrete observation that a person can review. Do not include credentials, personal data, or customer records. Feedback is saved for review; it does not immediately change the documentation or tools.
• execute_request — Read from the Pluggy API with a live GET call and return the response. Provide either a full `url` or a `path` (+ optional `spec` to resolve the base URL). Safe and side-effect free: this tool cannot POST, PUT, PATCH or DELETE — use create_request, update_request or delete_request for those. Target API: the **Pluggy API** (https://api.pluggy.ai) plus its siblings enrichment-api.pluggy.ai and status.pluggy.ai — no other host can be reached. Reference: https://docs.pluggy.ai/en/reference. Paths are freeform, so discover the right one with list_specs / search_endpoints / get_api_endpoint before calling instead of guessing. Authentication is NOT injected — pass your own credentials in `headers` (e.g. { "X-API-KEY": "…" } for enrichment-api, or { "Authorization": "Bearer " } for the main API).
• create_request — Make a live POST call to the Pluggy API — creating a resource or triggering an action (items, connect tokens, webhooks, enrichment runs). This WRITES to real data, so confirm the endpoint and the body with get_api_endpoint first. Reads go through execute_request; updates through update_request; deletions through delete_request. Target API: the **Pluggy API** (https://api.pluggy.ai) plus its siblings enrichment-api.pluggy.ai and status.pluggy.ai — no other host can be reached. Reference: https://docs.pluggy.ai/en/reference. Paths are freeform, so discover the right one with list_specs / search_endpoints / get_api_endpoint before calling instead of guessing. Authentication is NOT injected — pass your own credentials in `headers` (e.g. { "X-API-KEY": "…" } for enrichment-api, or { "Authorization": "Bearer " } for the main API).
• update_request — Make a live PUT or PATCH call to the Pluggy API to modify an existing resource (e.g. updating an item's credentials or a webhook). PUT replaces, PATCH merges — check get_api_endpoint for which one the endpoint expects. This WRITES to real data. Reads go through execute_request; creation through create_request; deletions through delete_request. Target API: the **Pluggy API** (https://api.pluggy.ai) plus its siblings enrichment-api.pluggy.ai and status.pluggy.ai — no other host can be reached. Reference: https://docs.pluggy.ai/en/reference. Paths are freeform, so discover the right one with list_specs / search_endpoints / get_api_endpoint before calling instead of guessing. Authentication is NOT injected — pass your own credentials in `headers` (e.g. { "X-API-KEY": "…" } for enrichment-api, or { "Authorization": "Bearer " } for the main API).
• delete_request — Make a live DELETE call to the Pluggy API to remove an existing resource (e.g. an item or a webhook). This is IRREVERSIBLE and destroys real customer data — confirm the exact resource id before calling. Reads go through execute_request; creation through create_request; updates through update_request. Target API: the **Pluggy API** (https://api.pluggy.ai) plus its siblings enrichment-api.pluggy.ai and status.pluggy.ai — no other host can be reached. Reference: https://docs.pluggy.ai/en/reference. Paths are freeform, so discover the right one with list_specs / search_endpoints / get_api_endpoint before calling instead of guessing. Authentication is NOT injected — pass your own credentials in `headers` (e.g. { "X-API-KEY": "…" } for enrichment-api, or { "Authorization": "Bearer " } for the main API).
• list_teams — List the teams your Pluggy dashboard account belongs to. Start here: pick a team, then use its id as `teamId` in the other tools. You can switch teams anytime by using a different team's id.
• list_applications — List the applications/environments under a team (from list_teams). Pick one and use its id as `applicationId` in data tools.
• select_application — Validate an application and confirm the team + application to use. Call this after list_applications; then pass the same `teamId` and `applicationId` to the data tools for the rest of the conversation (call it again to switch).
• get_application — Read how one application is configured: its name, environment (sandbox or production), whether it is enabled, its clientId, allowed origins and Connect branding (title, logo, primary color). For webhooks use list_webhooks. Use this to answer questions like 'how is my app configured?' or 'is this app in production?'. Unlike list_applications (which lists a team's apps) and select_application (which only confirms the app to use for the session), this returns the full configuration of one app. The client secret is never included — it is only shown once, when it is generated in the dashboard.
• list_connectors — List the connectors available to a team's application.
• get_stats — The core monitoring tool: the same stats the Pluggy dashboard shows, over any date range and filters, so you can answer 'how are my connections doing', compare periods, and spot anomalies proactively. Kinds: `items` (item counts by execution status), `items-by-connector` (the same split per connector/institution — use it for 'which banks are erroring most'), `syncs` (sync volume/outcomes), `syncs-lag` (how stale connections are), `connectors` (connector availability), `payments` (payment volume and outcomes), `payments-by-connector` (the same per institution). Filters: date range (startDate/endDate, ISO), a connector, error statuses, sandbox, connectors' `fromDay`, and payments' `paymentType`. To compare periods, call twice with different date ranges.
• get_item — Get a single connected item (status + executions) by its id, scoped to a team.
• debug_item — Diagnose why a connected item is failing. Fetches the item's current status and its recent executions (sync attempts, error codes, timestamps) plus any open incident on its institution, so you can explain the root cause and the next step for the end user — e.g. expired credentials → reconnect / update the connection; consent expired or a resource not granted → re-authorize; MFA/user-input needed; or a provider-side/known-incident issue. Read the `status`, the latest execution's error, and the connector, then give a short plain-language diagnosis + suggested fix. When the item looks healthy but a PRODUCT came back empty, this tool cannot tell you whether the institution ever shared it: that lives in `GET /items/{id}/resources` on api.pluggy.ai (Open Finance items only), which you can read with execute_request using the caller's own API key — a resource reported `PENDING_AUTHORISATION` is the end user's to authorise at their bank, `UNAVAILABLE` is the institution's call, and `AVAILABLE` with no data on our side is the only case that is ours. See https://v2.docs.pluggy.ai/en/docs/connections/resources. To see what each recent sync actually brought — products with data or empty, entities returned, transactions created by date — use get_execution_reports. Do NOT expose internal ids or logs to the end customer.
• get_execution_reports — Per-execution breakdown of what a connected item's recent syncs actually brought. Use it when an item looks healthy (debug_item shows no error) but the user says data is missing. For each execution, newest first: its status, and a `report` with the products that came back with data, empty, or failed (`products`), how many entities the institution returned per product (`returned`: accounts by type, credit cards, bills, investments, loans, identity, and transactions per account type), and how many transactions were created, updated and deleted, with the created ones split by transaction date relative to the sync — today, yesterday, two or more days ago, future (`transactions.*.createdByDate`, Brazil time). `report: null` means the execution did not get as far as saving data, or its report is still being processed (it lands shortly after the sync ends). `products: null` or a `null` counter in `returned` means not measured (older executions), never zero. Pass `executionId` (from get_item / debug_item) for one execution; otherwise the `limit` most recent (default 10, max 50). Not the same as get_reports, which is the team's aggregate ingestion over a date range.
• check_incidents — List Pluggy's current (and recently-resolved) Status Page incidents and maintenances — the same source as status.pluggy.ai. Use it to tell a customer whether a problem is a known provider-side outage. Optionally filter by a connector id (the Pluggy institution/connector) to see only incidents affecting that bank, or by infra component (api | webhooks | connect). Pairs with debug_item: if an item is failing and its institution has an open incident, the fix is 'wait for the incident to resolve', not a reconnect.
• get_billing_url — Get a link to the team's usage and billing dashboard, with consumption and cost.
• get_reports — Get the team's transaction-ingestion report over a date range, to understand data volume and ingestion health over time (and compare periods). `daily` = one row per day summed over all connectors, plus the top connectors of the range; pass `connectorIds` (or `byConnector: true`) for one row per connector per day. `summary` = totals per connector for the range, the largest `top` connectors (default 10) with the rest summed in `others`. Without `startDate` the range is the last 30 days. Large answers keep the most recent rows and say so (`truncated`).
• list_webhooks — List the webhooks registered for an application (URLs + the events they fire on).
• list_webhook_events — List recent webhook delivery events for a team/application — useful to debug 'did my webhook fire / did it fail'. Optionally scope by application.
• get_webhook_event — Get the full detail (payload, status, delivery attempts) of a single webhook event.
• dev_portal_tools_introduction — Guidance for these authenticated tools: what they do and the recommended order. Call this when unsure how to answer a question about the user's Pluggy integration.
• create_support_ticket — Open a support ticket for a connector/data problem on one of your teams. Only enabled for teams with the partner ticket integration turned on. Use it for a REPRODUCIBLE problem on a specific item — one ticket per problem, not per affected end user. Always pass externalId (your own issue id) so retries don't create duplicates. Pass dryRun: true first to validate the payload without filing anything.

About MCP

The Model Context Protocol (MCP) is an open protocol Anthropic introduced for connecting LLM-based agents to external tools and data sources. Providers publish MCP servers that expose their API surface as structured, discoverable tools — an MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.) can connect to the server and call its tools without any per-provider integration code.

Browse every MCP server on the APIs.io network or compare with the broader Agent Skill surfaces of the same providers.

Work with this as data

Every MCP server here is available over the APIs.io API and to AI agents over MCP.

curl "https://apis.io/api/v1/mcp/pluggy-docs"

curl "https://apis.io/api/v1/mcp?limit=25"