Open Banking MCP Server

by tkom04

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
exchange_code and complete_code_exchange overlap almost entirely (one is a legacy alias), and get_accounts/list_accounts plus get_transactions/list_transactions have similar names but differ in real vs. dummy behavior, creating confusion. An agent could easily select the wrong tool without careful description inspection.
Naming Consistency3/5
The pattern is mostly verb_noun, but the use of both get_ and list_ prefixes for closely related actions, along with exchange_code versus complete_code_exchange, shows inconsistent verb choice. The 'legacy alias' note further muddies the name convention.
Tool Count5/5
With 9 tools, the server is well-scoped for Open Banking operations covering auth, accounts, transactions, consents, and export. Each tool has a place, and the count is neither too small nor excessive.
Completeness4/5
The surface covers the core lifecycle: OAuth authorization, code exchange, account listing, transaction retrieval, CSV export, and consent listing. Notable gaps include consent revocation and token refresh, which are minor but would round out the workflow.
Average 3.2/5 across 9 of 9 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits fully. Instead, it introduces an incongruent behavior ('Read sample CSV') and fails to mention side effects, data source, or handling of validation failures. The description actively misleads about what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is not appropriately concise because it omits essential information and substitutes misleading details. It is under-specified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is completely inadequate. It fails to explain the actual operation, prerequisites, or relation to the input parameters, leaving the tool's behavior entirely ambiguous and inconsistent with its name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema descriptions cover 100% of parameters, the tool description adds no value and actually contradicts the parameters by referencing CSV instead of account_id and date ranges. The agent cannot infer how parameters relate to the described CSV processing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read sample CSV, normalize rows → Transaction[] with schema validation' does not match the tool name 'list_transactions' or its parameters (account_id, start_date, end_date). It describes a CSV processing operation instead of listing transactions, making it misleading about the tool's actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_transactions. It does not mention the intended use case (e.g., fetching transactions for an account within a date range), leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List all user bank accounts' without disclosing any behavioral details such as authentication requirements, consent dependencies, pagination, or error behavior. This is a significant gap for a tool that likely requires an authorized connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, making it extremely succinct and front-loaded. It earns its place by stating the core function, though it lacks additional structure (e.g., usage examples) that could be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is mostly complete, but it fails to differentiate from the sibling tool 'list_accounts'. There are no annotations to compensate for the missing usage context, and the tool appears to be one of two similar listing tools, so the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% vacuously. Per the rubric, a 0-parameter tool gets a baseline of 4, and the description appropriately confirms the tool takes no filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all user bank accounts, using a specific verb and resource. However, it does not distinguish between this tool and the sibling tool 'list_accounts', which appears to have the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative tools. The description is a single statement with no context, exclusions, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It fails to mention pagination behavior, default redaction of transaction data, or any other operational details beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately sized. It front-loads the primary action and scoping without wasting words, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema fully documents all parameters, the description is adequate for a simple retrieval tool. However, it lacks context about pagination or how this tool differs from siblings, making it slightly incomplete for a tool in a family of similar operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive text for all six parameters. The description adds minimal value beyond the schema, only reinforcing the date-range concept already captured in the start_date and end_date parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves transactions for a specific account within a date range, using a specific verb and resource. It does not explicitly differentiate from the sibling 'list_transactions', which may perform a similar function, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_transactions or get_accounts. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses that state validation occurs, which is a useful trait, but it does not mention side effects (e.g., token storage), security considerations, potential errors (e.g., state mismatch), or whether the operation is reversible. This is a notable gap for an OAuth exchange tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that wastes no words. It front-loads the main verb and resource, and includes the crucial qualifier 'with state validation.' It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple two-parameter tool, and the presence of an output schema reduces the need to explain return values. However, given it is part of an OAuth flow with sibling tools like 'exchange_code' and 'create_data_auth_link', the description lacks context about where this step fits in the overall process. No annotations further limit its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, providing the baseline of 3. The description adds value by specifying that the state parameter is validated, which goes beyond the schema's simple 'The state parameter from OAuth callback.' It also frames the code within the PKCE context, enriching the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Complete PKCE OAuth authorization code exchange with state validation.' It specifies the resource (authorization code exchange) and adds the key qualifier of state validation, making the purpose specific. However, it does not differentiate from the sibling tool 'exchange_code', which could lead to ambiguity about which tool to invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing a previously created data auth link, or exclusions for when not to use it. The description implies it is used after an OAuth callback, but it does not explicitly state this or distinguish it from 'exchange_code'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool creates a URL, but doesn't disclose side effects, prerequisites (e.g., client credentials), whether the operation is safe/read-only, or any other behavioral traits. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. It contains no unnecessary words and fully communicates the core operation in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description doesn't need to explain return values. However, it lacks context about the OAuth flow, relationship to sibling tools (e.g., exchange_code), and when this should be invoked. This leaves it adequate but with clear gaps for understanding the full usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage by virtue of no params). Per instructions, the baseline is 4 for 0 params. The description adds no parameter-specific details because none exist, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (TrueLayer OAuth authorization URL) with context of data access. It distinguishes from sibling tools like exchange_code and complete_code_exchange by focusing on URL creation, though it doesn't explicitly place it in the OAuth flow order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is the first step in the OAuth flow or that exchange_code should be used after obtaining the URL. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It clarifies that the output is a CSV and mentions categorization/summary, but it does not disclose whether the operation is read-only, how the file is delivered (e.g., direct download or URL), or any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action ('Export transactions') and includes key qualifiers. There is no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks crucial operational details such as the delivery mechanism of the CSV (e.g., file content vs. download URL), authentication requirements, or whether the export is scoped to the authenticated user. While an output schema exists (per context signals), its absence in the provided data means the agent cannot rely on it. Still, for a straightforward export tool, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage, with descriptions for account_id, start_date, end_date, and filename. The tool description adds no additional parameter semantics beyond referencing the CSV export, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('transactions') with a clear output format ('HMRC-ready CSV'). It also mentions 'categorization and summary,' which adds specificity and distinguishes it from sibling tools like get_transactions/list_transactions that likely return JSON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'HMRC-ready CSV' implies the tool is for generating tax-compliant exports, giving some context on when to use it. However, it does not explicitly compare against alternatives like get_transactions/list_transactions or state any exclusions, leaving the decision to the agent based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the accounts are dummy (fake) and that responses undergo schema validation. With no annotations, it partially carries the transparency burden, but it doesn't clarify side effects, authentication, or rate limits; however, for a zero-parameter read-like operation, this is somewhat adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It front-loads the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential purpose. It could benefit from stating the intended use case (e.g., testing/validation), but the term 'dummy' implies it adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers parameter semantics. The baseline for zero parameters is 4, and the description need not provide additional parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 1-2 dummy accounts, using a specific verb and resource. It distinguishes itself from get_accounts by noting these are dummy accounts, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus get_accounts or other siblings, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the core exchange behavior and the legacy alias status, which adds some transparency. However, it does not disclose potential side effects, error conditions, or deprecation details beyond the term 'legacy'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is mostly sufficient. However, the 'legacy alias' is vague—it does not reference the canonical tool (likely 'complete_code_exchange' from the sibling list), leaving the broader context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'OAuth authorization code' aligns with the 'code' parameter but adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('exchange') with a clear resource ('OAuth authorization code') and outcome ('for access and refresh tokens'). The phrase 'legacy alias' distinguishes it from likely non-legacy alternatives, making the tool's role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is a legacy alias, suggesting there is a preferred alternative, but it does not explicitly name the alternative or state when to use this tool vs. another. This is implied usage guidance, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds value by specifying 'active' (filtering behavior) and the included fields, but it does not explicitly state read-only nature, authentication requirements, or any potential side effects. The verb 'list' implies safety, but the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is complete. It clearly states what is listed and the included fields. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning about the returned data, though it does not need to explain parameters. The schema already has full coverage (no parameters to document).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('all active user consents'), and the return fields ('purposes and expiration dates'). It is specific and easily distinguishable from sibling tools, which focus on accounts, transactions, or data links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need a list of active consents. It doesn't explicitly mention alternatives or exclusions, but the sibling tools are for different resources, making the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openbankingMCP MCP server](https://glama.ai/mcp/servers/tkom04/openbankingMCP/badges/card.svg)](https://glama.ai/mcp/servers/tkom04/openbankingMCP)

Score Badge

Copy to your README.md:

[![openbankingMCP MCP server](https://glama.ai/mcp/servers/tkom04/openbankingMCP/badges/score.svg)](https://glama.ai/mcp/servers/tkom04/openbankingMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tkom04/openbankingMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server