How do I use Edenred Plus MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Edenred Plus MCP What are my current benefit balances?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Edenred Plus MCP

by B-Mahdj

Overview Schema Related Servers Score Discussions

TypeScript

Local

Edenred Plus MCP

Read-only local MCP server for Edenred Plus balances, transactions, and deals.

WARNING

This is an unofficial, single-user research preview. It is not affiliated with or endorsed by Edenred. Use it only with an account and API access you are authorized to use, and check Edenred's terms before making live requests.

Visual Demo :

https://github.com/user-attachments/assets/8ad0c635-af52-42cf-8ea6-093a02bc78fd

Tools

Tool	Purpose
`edenred_start_login`	Opens the Windows default browser in an isolated profile and starts local Edenred login.
`edenred_auth_status`	Reports whether login is required, pending, authenticated, expired, or failed without returning secrets.
`edenred_get_balances`	Lists every issuer account, benefit wallet, currency balance, spending limit, and associated masked card. Cards do not receive invented balances.
`edenred_list_transactions`	Lists transactions whose timestamps fall in an inclusive date range and signs amounts from Edenred's `CREDIT`/`DEBIT` movement.
`edenred_find_deals`	Finds active discounts by product, need, brand, or exact category across the deal widgets available to the web account.

Related MCP server: workday-mcp

Install and test

Requirements: Windows, a Chromium-based default browser, Node.js 22.21 or newer, and npm. Node.js 24 is recommended.

git clone https://github.com/B-Mahdj/edenred-plus-mcp.git
cd edenred-plus-mcp
npm.cmd ci
npm.cmd test

Print the absolute server path needed in desktop-client configuration:

(Resolve-Path .\build\index.js).Path.Replace('\', '/')

The server uses stdio. Do not print application logs to stdout; stdout is reserved for MCP JSON-RPC.

Local browser authentication

Call edenred_start_login when a data tool reports AUTH_REQUIRED or AUTH_EXPIRED. The server resolves the browser registered as the Windows HTTPS default, opens a temporary isolated profile, and lets Edenred's own website handle the username, password, and OTP. It captures only the successful Edenred token response through a private debugging pipe, keeps the access token in memory, closes the temporary browser, and deletes the profile.

Automatic capture currently supports Chromium-based default browsers such as Edge, Chrome, Brave, Vivaldi, and Chromium. It never silently substitutes a different browser. Tokens captured from the current web flow last about one hour and have no refresh token, so repeat browser login after expiry. Use edenred_auth_status to check progress.

The isolated profile does not reuse normal browser cookies, so you must sign in again. If Edenred temporarily blocks login after repeated attempts, stop retrying and wait or use Edenred's official account-recovery flow; this MCP cannot bypass Edenred security controls.

EDENRED_ACCESS_TOKEN remains an optional manual fallback. The server reads it at startup but can replace it in memory after browser login.

Obtain a current bearer token only through Edenred access you are authorized to use. For personal research, this can be the token visible on your own authenticated prd.smarter.edenred.io/bff-user-api/v1/home browser request. Never paste a token into source code, .env files, chat, issues, or logs.

Set it without placing the value in PowerShell history:

$env:EDENRED_ACCESS_TOKEN = Read-Host "Temporary Edenred bearer token"

Close that shell when finished. Never export or share a HAR with sensitive data: it can contain the submitted password and token response.

Codex desktop

Build first:

npm.cmd run build

Add this to ~/.codex/config.toml (or a trusted project's .codex/config.toml):

[mcp_servers.edenred_plus]
command = "node"
args = ["C:/absolute/path/to/edenred-plus-mcp/build/index.js"]

Restart the desktop app after changing the MCP configuration, then use /mcp to verify the server. For the optional manual-token fallback, add env_vars = ["EDENRED_ACCESS_TOKEN"]; Codex forwards the named variable without putting its value in config.toml. See the official MCP configuration reference.

Claude Desktop

Add this server to %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "edenred-plus": {
      "command": "node",
      "args": ["C:/absolute/path/to/edenred-plus-mcp/build/index.js"]
    }
  }
}

Fully quit and reopen Claude Desktop after changing its configuration. Browser login needs no token in this JSON file. If using the manual fallback, Claude Desktop inherits only a limited set of environment variables; do not add the token under the JSON env key unless you explicitly accept storing it locally. See the MCP debugging guidance.

Inspector

Neither mode requires an Edenred token merely to discover tools:

npm.cmd run inspect       # CLI tool discovery
npm.cmd run inspect:ui    # browser interface

The browser interface prints a local URL containing an Inspector proxy token. Treat that URL as temporary and do not share it.

Example prompts

"Show each of my Edenred benefit balances and daily limits."
"Log me in to Edenred using my default browser."
"List my Edenred transactions created between 2026-07-01 and 2026-07-22."
"I want to buy a coffee machine. Check my Edenred deals before recommending one."
"Are there active travel discounts in my Edenred account?"

Troubleshooting

Tools missing: run npm.cmd test, verify the absolute build/index.js path, then fully restart the desktop client.
AUTH_REQUIRED / AUTH_EXPIRED: ask the client to call edenred_start_login.
LOGIN_PENDING: finish login in the isolated browser, then call edenred_auth_status.
LOGIN_FAILED: close the temporary browser and retry only after normal Edenred login works again.
BROWSER_UNAVAILABLE: make a supported Chromium browser the Windows HTTPS default, or use the temporary-token fallback.
No deals returned: the unofficial web endpoint may expose fewer offers than Edenred's mobile app.

`UPSTREAM_UNAVAILABLE`

This means the MCP started, but its Node.js process could not complete a request to the Edenred API. The error message now distinguishes an Edenred HTTP response from timeout, DNS, refused/reset connection, TLS trust, and unknown network failures.

First, test the same HTTPS route from Node without sending a token or reading the response body:

node --version
node -e "fetch('https://prd.smarter.edenred.io/bff-user-api/v1/home',{redirect:'error',signal:AbortSignal.timeout(15000)}).then(r=>console.log('Reachable: HTTP '+r.status)).catch(e=>{console.error(e.cause?.code??e.name);process.exitCode=1})"

Any Reachable: HTTP ... result proves that Node can resolve, trust, and connect to the API; the unauthenticated status itself is expected. If the browser works but Node reports a timeout, ENOTFOUND, a certificate error, or another network code:

Compare node --version with the working computer and install a supported current Node release. Node 22.21 or newer can use standard proxy environment variables with NODE_USE_ENV_PROXY=1; Node 22.19 or newer can use the operating-system CA store with NODE_USE_SYSTEM_CA=1.
On an organization-managed network, ask the administrator for the correct proxy and CA settings. Set NODE_USE_ENV_PROXY=1 when HTTPS_PROXY/HTTP_PROXY/NO_PROXY are already configured, and set NODE_USE_SYSTEM_CA=1. If the administrator supplies a PEM certificate bundle, NODE_EXTRA_CA_CERTS can point to it.
Restart the desktop client after changing environment variables. Codex users can add env_vars = ["NODE_USE_ENV_PROXY", "NODE_USE_SYSTEM_CA", "HTTPS_PROXY", "HTTP_PROXY", "NO_PROXY", "NODE_EXTRA_CA_CERTS"] to the existing [mcp_servers.edenred_plus] entry so those named values are forwarded.
Check whether a VPN, endpoint-security product, DNS filter, or firewall treats node.exe differently from the browser.

Do not set NODE_TLS_REJECT_UNAUTHORIZED=0; disabling certificate verification would expose the access token and account data.

Security and limitations

Requests are restricted to https://prd.smarter.edenred.io; redirects are refused.
Browser login uses the configured Windows default browser, a unique temporary profile, and a private debugging pipe. The MCP never receives the password or OTP.
The server does not log tokens, response bodies, addresses, or raw traffic; .gitignore excludes common capture, token, environment, log, and raw-response files.
Card PANs are masked, transaction addresses are omitted, and monetary values are returned as decimal strings.
Deal matching is deterministic text/category matching, not semantic search.
The captured web home endpoint may expose fewer deals than the mobile app.
The server does not retry requests or cache personal data.
The current captured BFF contract targets the French tenant and web application version 19.3.0; Edenred can change this unofficial contract without notice.

This browser-assisted login is an unofficial local convenience, not an OAuth client issued to this project. Remote HTTPS transport, mobile clients, and marketplace publication still require an Edenred-approved OAuth client and API agreement. The required access is listed in docs/edenred-partner-access.md.

License

MIT applies only to this source code and grants no rights to Edenred services, data, APIs, or trademarks.

Available Tools

5 tools

edenred_auth_statusA

Read-onlyIdempotent

Check whether local Edenred browser login is required, pending, authenticated, expired, or failed. Never returns credentials or tokens.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds that it never returns credentials/tokens and lists possible statuses, providing extra context beyond annotations.

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?

Single, well-structured sentence with no fluff. Includes key states and a safety note.

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?

Covers purpose and behavior well. Lacks mention of return format (e.g., string or object), but listing possible statuses provides enough context for interpretation.

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?

No parameters, so schema coverage is 100%. Description adds no parameter info but none is needed. Baseline 4 is appropriate.

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 'Check' and specific resource 'local Edenred browser login status', listing possible states. It distinguishes from siblings like edenred_start_login, which initiates login.

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?

Purpose is clear but no explicit when/when-not guidance. However, the mention of 'never returns credentials or tokens' provides safety context, and sibling tools imply usage before other actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edenred_find_dealsA

Read-onlyIdempotent

Find active Edenred Plus discounts for shopping, brands, products, services, and savings questions. Call this before recommending a purchase. The catalogue is French: translate broad search terms to French, or omit query to browse when unsure.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`query`	No	Product, service, need, or brand to match.
`category`	No	Exact opaque category ID returned by a previous Edenred deal result.
`active_on`	No	Validity date; defaults to today, YYYY-MM-DD.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds behavioral context: the catalogue is French, implying search terms need translation, and suggests omitting query to browse. It also implies only active discounts are returned, going beyond annotations.

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 two sentences, front-loaded with the core purpose, followed by a usage instruction. No redundant text; every sentence earns its place.

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 no output schema, the description adequately explains purpose and usage. Annotations cover safety traits. The description misses mentioning pagination or result limits, but the schema defines limit. It is sufficient for an AI agent to understand when and how to invoke the tool.

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 coverage is 75% (3 of 4 params have descriptions). The description adds guidance on the query parameter (translate to French or omit), but does not elaborate on limit, category, or active_on beyond what the schema provides. Baseline 3 is appropriate with minor added value.

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 tool finds active Edenred Plus discounts for shopping, brands, products, etc., and advises calling it before recommending a purchase. It distinguishes from sibling tools (login, auth, balances, transactions) which handle different actions. The verb 'find' and resource 'discounts' are specific.

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 provides explicit usage context: 'Call this before recommending a purchase.' It advises translating broad search terms to French or omitting query to browse, aiding when to use. While it doesn't explicitly list alternatives, siblings are distinct enough that no confusion arises.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edenred_get_balancesA

Read-onlyIdempotent

Get all Edenred Plus account and benefit-wallet balances, limits, and associated cards. Balances belong to wallets/accounts, not individual cards.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description need not restate that. The description adds behavioral context (balances belong to wallets/accounts, not cards), which clarifies the tool's scope beyond annotations. No contradictions.

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?

Two concise sentences. The verb and resource are front-loaded. Every word adds value with no redundancy.

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 no input schema and no output schema, the description adequately explains what the tool returns (balances, limits, cards). It could benefit from mentioning if results are paginated or how to interpret limits, but is sufficient for a simple getter.

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?

No parameters exist, so schema coverage is 100%. The description adds no param info because none is needed; this aligns with the baseline for zero-parameter tools.

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?

Description clearly states the verb 'Get' and specific resources ('Edenred Plus account and benefit-wallet balances, limits, and associated cards'). It provides a key distinction (balances belong to wallets/accounts, not cards), but does not explicitly differentiate from sibling tools like edenred_list_transactions.

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 on when to use this tool versus siblings (e.g., when to check balances vs. list transactions or find deals). No context about prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edenred_list_transactionsA

Read-onlyIdempotent

List Edenred Plus transactions whose timestamp falls in an inclusive date range.

ParametersJSON Schema

Name	Required	Description	Default
`to_date`	Yes	End of the transaction date range, YYYY-MM-DD.
`from_date`	Yes	Start of the transaction date range, YYYY-MM-DD.

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, destructiveHint, etc. Description adds 'inclusive date range' but lacks details on pagination, result limits, or any behavioral quirks.

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?

Single sentence, front-loaded with key info. No unnecessary words.

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?

Adequate for a simple list tool with good annotations and schema coverage, but missing description of return format or available fields, which is needed since there is no output schema.

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 coverage is 100% and both parameters are well-described in the schema. Description adds no extra meaning beyond the schema.

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?

Description clearly states action (list), resource (Edenred Plus transactions), and criteria (inclusive date range). It distinguishes from siblings like edenred_get_balances and edenred_find_deals.

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 on when to use this tool vs alternatives. No mention of prerequisites or context for selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edenred_start_loginA

Open the Windows default browser for local Edenred Plus login. Call this when Edenred tools report AUTH_REQUIRED or AUTH_EXPIRED. The token stays in MCP memory and is never returned.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-readonly (readOnlyHint=false) and external interaction (openWorldHint=true). The description adds key behavioral detail: 'The token stays in MCP memory and is never returned.' This clarifies token handling and emphasizes that the tool does not expose the token, which is important for security. No contradictions.

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?

Two concise sentences that each add value. First sentence specifies the action; second provides usage trigger and token behavior. No extraneous information.

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?

For a simple authentication tool with no parameters and no output schema, the description covers the essential points: action, trigger condition, and token lifecycle. It could mention return behavior (e.g., success/failure), but given that it opens an external browser, the return may be minimal. The description is adequate for an AI agent to understand when and how to use it.

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 coverage is 100%. The description does not need to elaborate on parameters. Baseline of 4 is appropriate as the description focuses on the action and usage context.

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?

Clearly states verb 'Open' and resource 'browser for local Edenred Plus login'. Specifically distinguishes from sibling tools which handle different operations (status, balances, transactions, deals) by being the authentication initiation tool. Provides explicit condition for use (AUTH_REQUIRED or AUTH_EXPIRED).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call: 'Call this when Edenred tools report AUTH_REQUIRED or AUTH_EXPIRED.' This provides clear usage context. No alternative tools are suggested because the login is a prerequisite for others; thus the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 29, 2026
- First observededenred_auth_status
- First observededenred_find_deals
- First observededenred_get_balances
- First observededenred_list_transactions
- First observededenred_start_login

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: login, auth status, balances, transactions, and deals. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'edenred_verb_noun' pattern in snake_case, making the set predictable and easy to understand.

Tool Count5/5

5 tools is a well-scoped set for an Edenred benefit platform, covering authentication and core data retrieval without being overwhelming.

Completeness4/5

The tool set covers essential read operations (balances, transactions, deals) and authentication. A minor gap is the lack of write operations like redeeming a deal or managing cards, but the set is functional for its likely informational purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Stellaroid Earn A
io.github.Iron-Mark
Read-only MCP server: verify credentials and browse escrows on the Stellar testnet contract.
Blockchain Cryptocurrency
626
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

readonly-mcp-akamai
Networking & Infrastructure Cloud Platforms
desty2k
A
license
A
quality
D
maintenance
Read-only MCP server for Akamai CDN that enables searching properties, browsing EdgeWorker code, querying DNS zones, inspecting network lists, and translating error codes via natural language.
Updated 4 months ago (2026-04-28 20:26 UTC)
16
1
MIT
workday-mcp
ERP Systems Finance
chrischall
A
license
A
quality
A
maintenance
Read-only MCP server for Workday that fetches your tasks and data cards (pay, benefits, compensation) via your existing browser session, returning structured JSON.
Updated 2 days ago (2026-09-05 00:50 UTC)
10
398
1
MIT
FinTS-Finanzen
Finance Security
NG-Bullseye
A
license
Not graded
quality
C
maintenance
Read-only MCP server for FinTS/HBCI banking; enables account information retrieval such as balances and transactions via PIN-TAN.
Updated a month ago (2026-08-05 12:54 UTC)
MIT
Getnet
Finance Payments & Billing
mcp-dir
A
license
Not graded
quality
D
maintenance
Read-only MCP server for Getnet (Santander) enabling query of transactions, tokenized cards, and customers via the Digital Platform API.
Updated 7 days ago (2026-08-30 19:39 UTC)
MIT

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/B-Mahdj/edenred-plus-mcp'

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