Loading ToolBench
Exposes Plaidify as tools for AI agent frameworks. Provides tools for connecting to utility/energy/bank portals, authenticating users through a hosted link flow, and extracting structured financial data.
Plaidify MCP Server exhibits significant gaps in definition quality. While tool naming is mostly clear and descriptions exist, they lack the specificity and actionability required for production LLM agents. Parameter schemas are present but minimally documented, and critical missing pieces include: no input validation guidance, no documented output schemas, no error recovery instructions, no pagination or result limits, and no explicit security parameter handling for sensitive credentials. The descriptions read like feature summaries rather than LLM-optimized decision guides. Tools like connect_site and submit_mfa accept credentials and sensitive tokens as parameters, a critical security anti-pattern. No tool provides recovery guidance or categorizes errors as retryable vs. fatal. Average tool description length is ~120 chars (below the 194-char production baseline), and parameter descriptions are sparse or absent for most tools.
Check the current status of a link session. Use this after asking the user to open the link URL, to see if they've completed the authentication flow.
Connect to a site and extract data directly with credentials. This is the simplest integration — provide credentials and get data back. If MFA is required, you'll receive a session_id to use with submit_mfa().
Create a hosted link session for a user to authenticate securely. This generates a URL the user opens in their browser to enter credentials. The agent never sees raw credentials — they stay in the hosted page. Use check_connection_status() to monitor when the user completes.
Retrieve extracted data for a completed connection. Use this after check_connection_status() shows status == 'connected'.
List all available site blueprints that can be connected. Returns a formatted list of sites with names, domains, and supported features. Each site has: - site: identifier used for connect_site() or connect_utility_account() - name: human-readable name - domain: target website - has_mfa: whether MFA may be required
Credentials exposed as tool parameters (username/password in connect_site; MFA codes in submit_mfa; access_token/link_token in multiple tools). This violates critical security pattern, secrets in parameters enter agent logs and traces.
No output schemas documented. Tools return data but LLMs cannot predict field names, types, or pagination structure. fetch_data and list_connections responses are undefined, agents must guess what fields exist.
No error recovery guidance. Descriptions do not explain what to do on failure. No indication which errors are retryable vs. fatal, or what the LLM should do next (e.g., 'If connection fails, try connect_utility_account() instead').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
List all active connections and their current status. Returns a table of connections with site, status, and last sync time.
Request scoped data access from the user. Before calling fetch_data(), you may need to request permission for specific scopes.
Submit MFA verification code for a pending session. Use this when connect_site() or a previous submit_mfa() returns status == 'mfa_required'.
Parameter descriptions are minimal or missing. 'site' is described as 'Site identifier' but never explains format, valid values, or how to discover them (must call list_available_sites first). 'code' in submit_mfa is vague, does it accept OTP, security question answers, or both?
No pagination documented. list_available_sites and list_connections do not specify limits, offsets, or whether results are paginated. If an agent calls list_connections and 10,000 connections exist, the response could exhaust context.
Tool dependencies undocumented. Workflow is connect_site → check_connection_status → fetch_data, but descriptions do not guide this sequence or explain prerequisite states (e.g., 'fetch_data requires access_token from completed check_connection_status').
Access tokens and session IDs passed as parameters. Even if the server does not log them, returning tokens in responses (from check_connection_status) enters LLM context and risks exposure. Should use opaque server-side session management or return short-lived, narrowly-scoped tokens.
No idempotency guarantees. If connect_site or submit_mfa fails and the agent retries, it is unclear whether the operation is idempotent (safe to retry) or could create duplicate connections/MFA attempts.
Scopes parameter in request_consent is undocumented. Description says 'List of scopes to request (e.g. ["account_numbers", "transaction_history"])' but does not specify complete enum, format, or consequences of requesting vs. not requesting each scope.
No permission gating or audit trail documented. Tools expose sensitive financial data access (fetch_data returns account numbers, transactions) but descriptions do not indicate what permissions are required or how calls are logged.