What can you do with this server?

This server provides read-only access to the current and historical cinema program of Movieplexx Buchholz, allowing you to browse films, showtimes, and scrape history. * List Showtimes (list_showtimes): Retrieve performances with optional filters by date (YYYY-MM-DD), film slug, and whether only upcoming shows should be returned. * Get Film Details (get_film): Fetch the full record for a specific film by its slug, including metadata such as formats and booking links. * List Films (list_films): Get all known films in the database, optionally restricted to those with upcoming performances (defaults to true). * Search Films (search_films): Perform a case-insensitive substring search across film title, genre, director, or distributor. * Film History (film_history): Access the append-only scrape history of a film's performances, useful for tracking changes like sold-out status over time.

How do I use movieplexx-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., "@movieplexx-mcp showtimes for Dune 2 today" 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.

movieplexx-mcp

by zahlenhelfer

Overview Schema Related Servers Score Discussions

Python

Hybrid

movieplexx-mcp

MCP server that mirrors and historically archives the current cinema program of Movieplexx Buchholz.

It polls the cinema's internal JSON endpoint (https://movieplexx.de/programm/api/filtered-films) — which returns every current film with all showtimes, booking links, formats and metadata in a single response — normalizes it into SQLite, keeps an append-only history log, and exposes the data read-only to an MCP client.

Architecture

One image, two roles selected by command:

scraper (CLI)  ── hourly ──▶  SQLite (volume)  ── read-only ──▶  mcp-server (stdio) ──▶ Claude

scrape — fetch, upsert current performances, append a history snapshot
serve — run the MCP server (stdio), reading the same DB read-only

Related MCP server: moviefinder-mcp

Layout

src/movieplexx/scrape.py — HTTP fetch + normalization of the API response
src/movieplexx/store.py — SQLite schema, upsert, append-only history
src/movieplexx/cli.py — scrape [--loop], serve
src/movieplexx/server.py — FastMCP tools

Local usage

uv sync
DB_PATH=./movieplexx.db uv run movieplexx scrape      # one fetch + store
DB_PATH=./movieplexx.db uv run movieplexx serve       # MCP server over stdio

Configuration (environment)

Variable	Default	Purpose
`DB_PATH`	`/data/movieplexx.db`	SQLite file location
`TARGET_URL`	`.../programm/api/filtered-films`	Source endpoint
`USER_AGENT`	`MovieplexxProgrammMirror/0.1 (+kontakt@zahlenhelfer.de)`	Self-identifying UA
`POLL_INTERVAL_SECONDS`	`3600`	Loop interval for `scrape --loop`
`METRICS_PORT`	`9000`	Prometheus endpoint port in loop mode (`<=0` disables)
`MCP_TRANSPORT`	`stdio`	`serve` transport: `stdio` (local) or `http` (remote)
`MCP_HOST`	`0.0.0.0`	HTTP bind address (`http` transport)
`MCP_PORT`	`8000`	HTTP port (`http` transport)
`MCP_PATH`	`/mcp`	HTTP endpoint path (`http` transport)
`MCP_ALLOWED_HOSTS`	—	Comma-separated `host:port` values to accept in the `Host` header, in addition to `localhost`/`127.0.0.1`/`::1` (`http` transport)
`MCP_AUTH_TOKEN`	—	Bearer token; required for `http` transport (fail-closed)
`MCP_TLS_CERTFILE`	—	Path to a TLS certificate; terminates HTTPS directly in the server. Must be set together with `MCP_TLS_KEYFILE` (`http` transport)
`MCP_TLS_KEYFILE`	—	Path to the matching TLS private key (`http` transport)
`LOG_LEVEL`	`INFO`	Logging level

MCP tools

list_showtimes(date?, film_slug?, only_upcoming?) — performances, filterable
get_film(film_slug) — full film record
list_films(only_current?) — all known films
search_films(query) — substring search over title/genre/director/distributor
film_history(film_slug) — append-only scrape history (sold-out / status drift)

Registering with an MCP client

The server speaks stdio. Add it to your client's server config (e.g. Claude Desktop's claude_desktop_config.json). It only reads the DB, so populate it first with at least one scrape.

Local (via uv):

{
  "mcpServers": {
    "movieplexx": {
      "command": "uv",
      "args": ["run", "movieplexx", "serve"],
      "cwd": "/absolute/path/to/movieplexx-mcp",
      "env": { "DB_PATH": "/absolute/path/to/movieplexx-mcp/movieplexx.db" }
    }
  }
}

Docker (reads the shared moviedata volume the scraper writes):

{
  "mcpServers": {
    "movieplexx": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "moviedata:/data:ro", "movieplexx-mcp", "serve"]
    }
  }
}

Docker

docker compose up -d          # runs scraper (hourly loop) + shared volume

The MCP server is typically launched on demand by the client, e.g.:

docker run -i --rm -v moviedata:/data:ro movieplexx-mcp serve

Remote serving on a NAS (HTTP transport)

By default serve speaks stdio and is spawned locally by the client. To run the server long-lived on a NAS and reach it from your local Claude over the LAN, set MCP_TRANSPORT=http. The endpoint is protected by a static bearer token and refuses to start without MCP_AUTH_TOKEN.

Generate a token and start the networked mcp service (see docker-compose.yml, which binds the port to the NAS LAN IP — adjust 192.168.1.50):

echo "MCP_AUTH_TOKEN=$(openssl rand -hex 32)" >> .env   # .env is gitignored
echo "MCP_ALLOWED_HOSTS=192.168.1.50:8000" >> .env      # the LAN address clients connect to
docker compose up -d mcp

The server validates the incoming Host header (DNS-rebinding protection) and otherwise only trusts localhost/127.0.0.1/::1. Without MCP_ALLOWED_HOSTS set to the address in the URL above, remote requests fail with 421 Invalid Host header even though the bearer token is correct.

Claude Code (CLI) — native HTTP transport:

claude mcp add --transport http movieplexx http://192.168.1.50:8000/mcp \
  --header "Authorization: Bearer <TOKEN>"

Claude Desktop — no native remote-HTTP client, so use the mcp-remote stdio↔HTTP bridge instead. Pass the full header through env to avoid whitespace-splitting in --header:

{
  "mcpServers": {
    "movieplexx": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://192.168.1.50:8000/mcp",
               "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer <TOKEN>" }
    }
  }
}

Quick smoke test (no token → 401):

curl -s -o /dev/null -w '%{http_code}\n' http://192.168.1.50:8000/mcp   # 401

Without TLS, the bearer token travels in cleartext on the wire — anyone who can observe the LAN segment can read it. To terminate HTTPS directly in the server, set MCP_TLS_CERTFILE/MCP_TLS_KEYFILE (both required together) and use https:// in the client config and smoke test above. A self-signed cert is enough for LAN use:

openssl req -x509 -newkey rsa:2048 -nodes -days 825 \
  -keyout mcp-key.pem -out mcp-cert.pem -subj "/CN=192.168.1.50"
echo "MCP_TLS_CERTFILE=/data/mcp-cert.pem" >> .env
echo "MCP_TLS_KEYFILE=/data/mcp-key.pem" >> .env

This is intended for a trusted LAN. For off-LAN access put Tailscale/WireGuard in front; for public exposure add a TLS reverse proxy. See spec.md §10.

Container image (GHCR)

Multiarch images (linux/amd64, linux/arm64) are published to the GitHub Container Registry by .github/workflows/docker-publish.yml:

ghcr.io/zahlenhelfer/movieplexx-mcp

Tag	Published on	Meaning
`dev`	every push to `main`	latest development build
`X.Y.Z`, `X.Y`, `X`	a published GitHub release `vX.Y.Z`	semver-pinned build
`latest`	a published GitHub release	newest release (never `dev`)

Pull and run the published image instead of building locally:

docker pull ghcr.io/zahlenhelfer/movieplexx-mcp:latest

# scraper (hourly loop)
docker run -d --rm -v moviedata:/data ghcr.io/zahlenhelfer/movieplexx-mcp:latest scrape --loop

# MCP server (launched on demand by the client)
docker run -i --rm -v moviedata:/data:ro ghcr.io/zahlenhelfer/movieplexx-mcp:latest serve

The image is public — no docker login needed to pull. To cut a release image, tag a commit and publish a GitHub release (vX.Y.Z); the workflow builds the semver and latest tags.

Metrics

In loop mode the scraper serves Prometheus metrics on :${METRICS_PORT}/metrics:

movieplexx_scrape_success_total / movieplexx_scrape_failure_total
movieplexx_scrape_duration_seconds (histogram)
movieplexx_films_seen / movieplexx_performances_seen (last cycle)
movieplexx_parse_errors_total — increments on a film that fails to normalize; alert on > 0 to catch upstream schema drift.

Tests

uv run pytest

tests/test_contract.py parses a checked-in golden snapshot (tests/fixtures/filtered-films.golden.json) and asserts the exact field shape the normalizer relies on. A failure means the upstream JSON drifted — regenerate the snapshot (command in the test's docstring) once the change is understood.

Etiquette

Honors robots.txt (/programm/* is allowed), uses a self-identifying User-Agent with a contact address, and defaults to one request per hour.

Available Tools

5 tools

film_historyA

Return the append-only scrape history for a film's performances (sold-out / status drift).

ParametersJSON Schema

Name	Required	Description	Default
`film_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It mentions 'append-only', implying read-only behavior, but lacks details on authentication, rate limits, or error handling. The term 'scrape history' provides some context but 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 sentence with no unnecessary words. It is front-loaded with the main verb and resource, making it easy to digest.

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 low complexity (1 required param, no enums, output schema exists), the description adequately conveys the purpose. However, it could specify that it returns a list of historical entries and that the operation is safe.

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?

Schema description coverage is 0%, so the description must compensate. While 'film_slug' is self-explanatory, the description adds no extra meaning or examples. It does not clarify how to obtain the slug or its expected format.

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 action ('Return'), the resource ('append-only scrape history for a film's performances'), and provides specific context ('sold-out / status drift'). This distinguishes it from sibling tools like 'get_film' or 'list_showtimes'.

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 does not explicitly state when to use this tool versus alternatives. It implies it is for historical data, but no direct guidance is given, such as 'Use list_showtimes for current showtimes'.

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

get_filmA

Return the full film record for one slug, or null if unknown.

ParametersJSON Schema

Name	Required	Description	Default
`film_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description discloses the expected behavior: returns a full record or null if unknown. This is sufficient for a simple read operation, though it does not cover edge cases or auth requirements.

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 with no wasted words. It front-loads the verb and quickly conveys the essential purpose and return behavior.

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?

For a simple tool with one parameter and an output schema, the description sufficiently covers the action, input, and output (full record or null). The presence of an output schema further clarifies the return structure.

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?

The description mentions 'slug' but does not explain what a film slug is or provide examples. With 0% schema description coverage, this adds minimal meaning beyond the parameter name and type.

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 explicitly states the action ('Return'), the resource ('full film record'), and the input ('one slug'), and implies it is for a single film, distinguishing it from sibling tools like list_films or search_films.

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 usage when you have a specific slug and want a single record, but does not provide explicit guidance on when not to use it or compare with alternatives like search_films for fuzzy lookups.

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

list_filmsB

List all known films. With only_current, restrict to films with an upcoming performance.

ParametersJSON Schema

Name	Required	Description	Default
`only_current`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states it lists films (read-only), but lacks important details such as whether pagination is used, ordering, or any side effects. This is minimal for a listing 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 two sentences, front-loaded with the main purpose, and contains no extraneous information. Every word adds value.

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 simple tool with one parameter and an output schema, the description is adequate but misses contextual details such as the default value of 'only_current' (true) and whether the list is paginated or sorted. The output schema may fill some gaps, but the description could be more 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 schema has 0% description coverage for the only parameter. The description adds clear meaning: 'With only_current, restrict to films with an upcoming performance,' which explains the boolean parameter's effect.

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 'List all known films' which is a specific verb and resource. It distinguishes from sibling tools like 'search_films' by indicating it's a full listing, but does not explicitly differentiate from 'list_showtimes' or 'get_film'.

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 usage by describing the 'only_current' parameter for filtering to upcoming performances, but it does not provide explicit guidance on when to use this tool vs. alternatives like 'search_films' or when not to use it.

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

list_showtimesB

List performances, optionally filtered by ISO date (YYYY-MM-DD) or film slug.

Set only_upcoming to hide performances whose date lies in the past.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`film_slug`	No
`only_upcoming`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

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 mentions filtering and the only_upcoming flag. It does not disclose important behavioral traits like pagination, default ordering, result limits, or what happens when no filters are applied (e.g., does it return all future showtimes?). For a list tool, this is insufficient.

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 very concise, with two clear sentences that front-load the main action and immediately follow with the optional filters. No wasted words or redundant information.

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's simplicity (3 optional params) and the presence of an output schema, the description is adequate but lacks details about default behavior, pagination, and order. An agent could use it correctly but might have questions about edge cases.

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 0%, so the description must clarify parameter meanings. It explains 'date' as ISO date and 'only_upcoming' to hide past performances. However, 'film_slug' is not defined; the agent might not know what a slug is. Partial compensation for missing schema 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 lists performances with optional filters. It distinguishes from sibling tools like film_history and search_films by focusing on showtimes, though 'performances' could be more specific (e.g., film showtimes).

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?

Usage is implied: use to list showtimes filtered by date or film slug, with an option to hide past performances. However, there is no explicit guidance on when to use this tool vs alternatives, or when not to use it. Siblings are different enough that context provides clarity, but the description does not directly address selection criteria.

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

search_filmsA

Search films by title, genre, director or distributor (case-insensitive substring).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states case-insensitive substring matching but omits details like result limits, pagination, ordering, or whether the search returns full film objects or summaries.

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?

A single concise sentence that efficiently conveys the tool's purpose and search capabilities with no extraneous words.

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 simple nature of the tool (one parameter, no nested objects) and the existence of an output schema, the description provides essential information. However, it could be slightly more complete by noting that the search is across multiple fields, which it does.

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?

Schema coverage is 0%, but the description explains that the 'query' parameter is searched across title, genre, director, and distributor. This adds significant meaning beyond the bare parameter name in the schema, though it does not mention that the parameter is required (already in 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?

The description clearly states the tool searches films by multiple criteria (title, genre, director, distributor) with case-insensitive substring matching. It distinguishes from sibling tools like get_film (specific film), list_films (listing all), and film_history (history) by indicating it's a search across multiple fields.

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?

There is no guidance on when to use this tool versus alternatives like list_films or get_film. The description does not mention any prerequisites, limitations, or scenarios where this tool is preferred.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation4/5

Tools are mostly distinct: film_history covers performance history, get_film and list_films cover films, list_showtimes covers performances, and search_films covers search. However, list_films with upcoming filter and search_films could be confused for similar film queries.

Naming Consistency4/5

Four tools follow verb_noun pattern (get_film, list_films, list_showtimes, search_films), but film_history is a noun_noun exception, causing minor inconsistency.

Tool Count5/5

With 5 tools, the set is well-scoped for a movie information server, fitting the ideal range of 3-15 tools for focused functionality.

Completeness4/5

The server covers key read operations: listing, searching, detail, showtimes, and history. Minor gaps include lacking a dedicated performance detail tool, but the set is largely complete for its domain.

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

thoughts
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247

Related MCP Servers

Movie Search MCP Server
tonderflash
A
license
D
quality
D
maintenance
An MCP server that allows users to search for movies, get detailed information, receive genre-based recommendations, and discover popular/trending films using OMDb and TMDb APIs.
Updated a year ago (2025-07-20 23:12 UTC)
5
25
MIT
moviefinder-mcp
Entertainment & Media Search
AmeliaMiddleton
F
license
A
quality
D
maintenance
An MCP server that wraps The Movie Database (TMDB) API, enabling search for movies and TV shows, retrieval of movie details, recommendations, similar movies, trending content, streaming providers, and movie discovery.
Updated 4 months ago (2026-05-05 01:50 UTC)
8
Fandango MCP
Entertainment & Media Web Scraping
atfinke
A
license
A
quality
C
maintenance
Unofficial, read-only MCP server for Fandango showtimes and seat availability, reverse-engineered from observed web traffic.
Updated 2 months ago (2026-07-04 18:27 UTC)
2
6
MIT
moviecom-mcp
Entertainment & Media Web Scraping
Santosl2
F
license
Not graded
quality
C
maintenance
MCP server for querying movie schedules and seat availability from Moviecom.
Updated a month ago (2026-07-30 17:16 UTC)

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/zahlenhelfer/movieplexx-mcp'

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