Which integrations are available for this server?

Allows searching for artworks and their metadata through Wikidata, especially useful for regions without dedicated museum APIs. Provides access to artwork images hosted on Wikimedia Commons, serving as the image source for Wikidata results.

How do I use art-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., "@art-mcp Show me impressionist paintings from the Art Institute of Chicago" 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.

art-mcp

by puf3zin

Overview Schema Related Servers Score Discussions

TypeScript

Remote

art-mcp

npm Nightly smoke test

An MCP server for searching museum collections and viewing artwork images and metadata — right inside Claude (or any MCP client).

It works out of the box with seven sources that need no API key, and can pull in three more if you provide free keys.

Sources

Source	`source` id	Strongest in	API key
The Metropolitan Museum of Art	`met`	Encyclopaedic	none
Art Institute of Chicago	`artic`	European & American	none
Cleveland Museum of Art	`cleveland`	European & American	none
Rijksmuseum	`rijksmuseum`	Dutch Golden Age	none
Victoria and Albert Museum	`vam`	Chinese, Japanese, Korean, South & SE Asian, Islamic, African	none
Japan Search	`japansearch`	Japanese art, prints, manuscripts	none
Wikidata / Wikimedia Commons	`wikidata`	Latin America and anywhere without a museum API	none
Harvard Art Museums	`harvard`	Encyclopaedic	free (request one)
Smithsonian Open Access	`smithsonian`	African, Asian, Indigenous American	free (sign up)
Museum of New Zealand Te Papa Tongarewa	`tepapa`	Taonga Māori, Pacific Cultures	free (register)

Looking beyond Europe and the United States

The first four sources are all Western institutions, which meant non-Western art was only visible through a collecting museum's Asian or African department. The six added since address that directly, but the coverage is uneven in ways worth knowing up front:

Asia is well served. vam and japansearch are both keyless, and smithsonian adds the National Museum of Asian Art.
Africa runs mainly through smithsonian (unit_code:NMAfA) and vam. There is no Africa-based institutional API to point at — Digital Benin is the most significant African digital archive but publishes no public API, and the British Museum's SPARQL endpoint no longer resolves.
South America has no museum API at all. Not one Latin American institution publishes a usable collections API. Brazil's federal museums run Tainacan as one WordPress site per museum with no central index and patchy images; Mexico's Mediateca INAH now redirects to a bare repository. So the region is covered by smithsonian (unit_code:NMAI, for Andean and Amazonian material) and by wikidata, which reaches Brazilian and Latin American painting through Wikimedia Commons. This is a real gap, not an oversight — worth revisiting as digitisation programmes there mature.

Why there is no Google Arts & Culture source

It has no public read API. The only developer-facing programme, Large Scale Data, is a pipeline for institutions to publish into the platform, and artsandculture.google.com/robots.txt explicitly disallows /api/*, so the internal endpoint is off-limits on both robots and terms-of-service grounds. Going direct to the institutions that publish their own open data — which is what most of the sources above are — gets the same collections without the problem.

A note on Smithsonian

One adapter covers 21 museums, so narrowing helps. The API accepts Solr-style field filters straight in the query string: unit_code:NMAfA (African Art), unit_code:FSG (Freer and Sackler, Asian art), unit_code:NMAI (American Indian).

Write the filter as a plain AND term — Nasca AND unit_code:NMAI. Wrapping free text and a field filter in parentheses makes EDAN drop the filter and match most of the institution.

DEMO_KEY works for a first try but is capped at 10 requests/hour.

NMAI is metadata-only in practice. Its records are flagged as having images, but the API returns no media for them — not in search results and not on the detail endpoint — which is consistent with the museum's cultural protocols around Indigenous material. So unit_code:NMAI is genuinely useful for finding and reading about Andean and Amazonian works, and get_artwork_image will almost always come up empty for them. NMAfA and FSG both serve images normally.

A note on Japan Search

Japan Search is the National Diet Library's cross-sector aggregator — national museums, university archives and prefectural collections behind one index. It catalogs in Japanese and has no English titles, so query it in Japanese (北斎, 浮世絵) for decent recall. Results come back with language: "ja" and the native title in titleOriginal; that is correct output, not a failure. It is also the only source that reports a real per-object licence, which lands in license.

A note on Wikidata

This is a fallback for regions no museum API reaches, not a curated catalogue. Metadata quality varies far more per item than a museum's own records, and a search resolves the keyword to an entity and then returns works by it — so it answers "Tarsila do Amaral" well and a subject phrase badly. Images come from Wikimedia Commons.

A note on Rijksmuseum

This uses Rijksmuseum Data Services, which needs no key — the older www.rijksmuseum.nl/api endpoint was retired and now answers 410 Gone.

The new API serves Linked Art and has no free-text search parameter, so search_artworks fans the keyword across title, creator, and description and interleaves the hits. Search also returns bare identifiers, so each result costs a follow-up lookup (plus two more to resolve its image) — expect Rijksmuseum to be the slowest source in an all-museum search.

A note on Art Institute of Chicago

Search and metadata work, but the IIIF image host sits behind a Cloudflare bot challenge, so get_artwork_image will usually fail for artic with a 403.

Related MCP server: artic-mcp

Tools

list_sources — which museums are queryable right now.
search_artworks { query, source?, limit? } — search one source or all of them; returns compact results with a source + id for each.
get_artwork { source, id } — full metadata for one artwork.
get_artwork_image { source, id } — downloads the image and returns it so the model can actually see it.

Connect to Claude

No install step — npx fetches the package on demand.

Claude Code

claude mcp add art-mcp -- npx -y art-mcp

Claude Desktop

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "art-mcp": {
      "command": "npx",
      "args": ["-y", "art-mcp"]
    }
  }
}

Restart the client, then try: "Search the Met for Van Gogh and show me an image."

Adding API keys

All optional — seven sources work without any key. The server reads keys from the process environment, so pass them through your MCP client's env block; a bare .env file is not loaded automatically.

{
  "mcpServers": {
    "art-mcp": {
      "command": "npx",
      "args": ["-y", "art-mcp"],
      "env": {
        "HARVARD_API_KEY": "your-key-here",
        "SMITHSONIAN_API_KEY": "your-key-here",
        "TEPAPA_API_KEY": "your-key-here"
      }
    }
  }
}

SMITHSONIAN_API_KEY is the one most worth setting: it is instant and self-service from api.data.gov, and it is what unlocks the African, Asian and Indigenous American collections.

Reliability

Museum APIs rot quietly. The Rijksmuseum endpoint this server was originally built on was retired and started answering 410 Gone with no announcement — the kind of break that only surfaces when a user hits it.

So a nightly workflow runs the full search → detail → image path against every live API and opens an issue when a source that used to work stops working. Run it yourself with:

npm run smoke

Known-broken checks (currently the Art Institute's Cloudflare-blocked images) are reported but don't fail the run, so a red badge always means something new actually broke.

Development

npm install
npm run build     # compile to dist/
npm run dev       # run from source with tsx
npm run inspect   # build + open the MCP Inspector
npm run smoke     # exercise every provider against the live APIs

License

MIT

Available Tools

4 tools

get_artworkGet artwork detailsA

Fetch full catalog details for a single artwork by its source and id (as returned by search_artworks) — medium, dimensions, department, culture, where it was made, credit line, and rights where the museum publishes them. Use this to confirm attribution or rights before relying on a work, since search results carry only a summary.

Rights come back in two fields: isPublicDomain is a boolean and is only set when the source states it outright, while license carries the source's own wording (e.g. 'CC0', 'CC BY-NC-SA', 'In copyright'). Prefer license when advising on reuse — an absent isPublicDomain means unknown, not free.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The provider-native artwork id from search results.
`source`	Yes	The museum source the artwork belongs to.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that rights come back in two fields (isPublicDomain and license) with caveats about when isPublicDomain is set, and notes that fields are only present where the museum publishes them. This goes beyond basic functionality, though it could mention potential missing fields or error behavior.

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 well-organized paragraphs. The first states the main purpose and fields, the second explains rights fields in detail. Every sentence adds value, with no waste. Front-loaded with purpose.

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 only two simple parameters and no output schema, the description provides good context about return fields and their semantics. It mentions limitations ('where the museum publishes them'). Could be improved by noting possible null fields or error cases, but overall 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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds that the id is 'as returned by search_artworks' and lists the sources in the enum context. This adds minor value but does not significantly enhance understanding 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?

The description clearly states the tool fetches full catalog details for a single artwork by source and id, listing specific fields like medium, dimensions, department, culture, credit line, and rights. This distinguishes it from sibling tools such as search_artworks (summary) and get_artwork_image (image).

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 explicitly says to use this tool to confirm attribution or rights before relying on a work, and notes that search results carry only a summary. This provides clear when-to-use guidance, though it does not explicitly list when not to use or name alternative tools.

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

get_artwork_imageGet artwork imageA

Download the image for a single artwork (by source and id) and return it so it can actually be viewed, plus a short caption. Use this whenever the user wants to see a work, or when you need to judge what a work actually depicts rather than trusting its title.

Not every record has an image, and the Art Institute ('artic') serves images from a host behind a bot challenge, so those usually fail with a 403 — prefer another source when you need to display something, and fall back to the museumUrl from search results if an image cannot be fetched.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The provider-native artwork id from search results.
`source`	Yes	The museum source the artwork belongs to.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that not every record has an image and that artic requests usually fail with 403. However, it does not specify the returned image format (e.g., binary, base64) or any size limits. The mention of 'short caption' is vague. More details on what exactly 'return it' means would improve transparency.

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 front-loaded with the primary use case and includes essential behavioral notes in a second paragraph. It is concise enough, but could be slightly shorter by combining sentences. Overall, every sentence serves a purpose, and the structure is logical.

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's simplicity (2 params, no output schema), the description covers key aspects: when to use, failure modes, fallback strategy, and return of caption. It does not detail the caption format or the exact image return mechanism, but these are minor omissions. The description is largely complete for an AI agent to decide correctly.

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 100% and descriptions exist for both parameters. The description adds extra context: it explains that the 'source' parameter is the museum and that artic has issues, and that 'id' is from search results. This provides real-world semantic value beyond the schema definitions, earning a score above baseline.

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 ('download the image for a single artwork') and the result ('return it so it can actually be viewed, plus a short caption'). It distinguishes from sibling tools by specifying that it retrieves the image data, not just metadata, and mentions fallback behavior. However, it does not explicitly state the return format (e.g., base64 or URL), which could be clearer.

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?

The description provides excellent guidance: 'Use this whenever the user wants to see a work, or when you need to judge what a work actually depicts rather than trusting its title.' It also explicitly warns against using for Art Institute ('artic') due to bot challenges, and suggests preferring other sources and falling back to the museumUrl. This clearly tells when to use the tool and when to avoid it.

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

list_sourcesList museum sourcesA

List the museum data sources this server can query and whether each is currently available. Sources needing an API key are unavailable until the key is configured.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that sources requiring an API key will be marked unavailable until configured, adding important behavioral context about conditional availability.

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 extremely concise with two sentences, no redundancy, and front-loads the primary action. Every word adds value.

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, no output schema), the description fully covers its behavior: listing sources and indicating availability. No additional information is necessary for proper use.

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 score is 4. The description does not need to add parameter info, and it correctly avoids extraneous details.

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 lists museum data sources and their availability. It uses specific verbs and resources ('list', 'museum data sources'), and distinctly separates this tool from sibling tools that deal with artworks.

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 provide explicit guidance on when to use this tool versus alternatives or any prerequisites. While the purpose is clear, it fails to set usage context or mention when this tool is needed (e.g., before querying other tools).

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

search_artworksSearch artworksA

Search museum collections for artworks. Returns compact results including a source and id used with get_artwork or get_artwork_image.

IMPORTANT — this matches keywords against catalog metadata; it is not semantic search. Artist names, titles, cultures, and periods work well. Descriptions of subject matter work badly: a query like 'man crossing a bridge' matches any record containing 'man', 'bridge', or names like 'Bridges' and 'Cross', and buries the relevant results.

So translate the user's intent into catalog vocabulary before calling. If you can name a likely artist, school, or title from your own knowledge, search for that instead — e.g. prefer 'Hokusai' or 'Hiroshige Tokaido' over 'japanese painting of a bridge'. Searching a subject phrase directly is a last resort; if you must, use one or two distinctive nouns rather than a sentence.

Results are ordered by each museum's own relevance ranking, which is often weak — scan the whole list rather than assuming the first hit is best.

CHOOSING A SOURCE. 'all' is a fine default, but naming a source is much better when the work has an obvious home. Five of the ten sources hold mostly Western art (met, artic, cleveland, harvard, rijksmuseum); for anything else, reach for these first:

Japanese art and objects → 'japansearch' (Japan's national aggregator), then 'vam', 'met'
Chinese, Korean, South and Southeast Asian, Islamic → 'vam', then 'smithsonian'
African art → 'smithsonian' with unit_code:NMAfA in the query, then 'vam'
Indigenous Americas and pre-Columbian → 'smithsonian' with unit_code:NMAI
Māori and Pacific → 'tepapa'
Latin American art, and anywhere else with no museum API → 'wikidata'

Source-specific quirks worth knowing:

'smithsonian' accepts field filters in the query, so unit_code:NMAfA or unit_code:FSG (Asian art) narrows 21 museums to one. Write it as a plain AND term — 'Nasca AND unit_code:NMAI' — and do not parenthesise it, which makes the filter silently drop. Note that unit_code:NMAI returns metadata but essentially never images, so use it to find and read about Indigenous American works, not to display them.
'japansearch' catalogs in Japanese and has no English titles — query it in Japanese ('北斎', '浮世絵') for good recall, and expect titles to come back in Japanese with a language field marking them; that is correct output, not a failure.
'tepapa' images are mostly 'All Rights Reserved' under Te Papa's cultural protocols for taonga Māori. They can still be fetched and viewed, but check license from get_artwork before suggesting a work can be reused.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results per source (default 10).
`query`	Yes	Catalog keywords — ideally an artist name, title, culture, or period, e.g. 'Katsushika Hokusai' or 'Edo period landscape'. Avoid full sentences and subject descriptions.
`source`	No	A specific museum source, or 'all' (default) to search every available source. An all-source search costs several seconds — 'rijksmuseum' has no free-text search, and 'wikidata' runs a SPARQL query — so name a source when you know which one holds the work.

TDQS

A4.8/5.0

Behavior5/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 of behavioral disclosure. It explicitly states the search is not semantic, warns about weak relevance ranking, details source-specific quirks (e.g., smithsonian field filters dropping silently, japansearch returning Japanese-only titles, tepapa image licensing restrictions), and explains the time cost of an 'all' search.

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 long but well-organized with sections (IMPORTANT, CHOOSING A SOURCE, Source-specific quirks). Every sentence adds necessary context; however, the length could slightly tax LLM context windows. It is front-loaded with the core purpose and key warnings, earning a high score but not perfect conciseness.

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 complexity (multiple sources, non-semantic search, weak ranking, field filters, language differences), the description is remarkably thorough. It covers return format, behavioral quirks, and actionable guidelines for all major scenarios. The lack of output schema is compensated by explaining what results contain ('source' and 'id').

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 100%, providing baseline meaning for each parameter. The description adds significant value by elaborating on the 'query' parameter (preferred format, translation advice), the 'source' parameter (detailed guidance on choosing sources with cultural/regional recommendations and quirks), and the 'limit' parameter (default behavior and implications).

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 begins with a clear verb-resource pair ('Search museum collections for artworks') and immediately distinguishes the tool's output from siblings by noting it returns 'source and id used with get_artwork or get_artwork_image'. It provides specific enough detail to differentiate from list_sources, get_artwork, and get_artwork_image.

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?

The description gives extensive when-to-use guidance: it explains that keyword search is not semantic, instructs translating user intent into catalog vocabulary, recommends preferring known artist/title over subject descriptions, and provides a last-resort strategy. It also advises scanning the entire result list rather than assuming the first hit.

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.

4 tool updatesv0.2.1Jul 28, 2026
- First observedget_artwork
- First observedget_artwork_image
- First observedlist_sources
- First observedsearch_artworks

Install Server

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

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: listing sources, searching for artworks, fetching full details, and retrieving images. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_sources, search_artworks, get_artwork, get_artwork_image) in snake_case.

Tool Count5/5

Four tools is well-scoped for a museum art server that needs to discover sources, search, retrieve metadata, and get images.

Completeness5/5

The tool surface covers the full workflow: source discovery, search, detail retrieval, and image access. No obvious gaps for the intended use case.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

Resources

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

Met Museum Mcp
io.github.varvararatta
Unlock a world of art with the Met Museum MCP! Use the 'search_artworks' API to find stunning
Art & Culture Search
2
art A
io.github.pipeworx-io
Art MCP — Metropolitan Museum of Art Collection API (free, no auth)
Art & Culture Search Open Data
342
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
met-museum-mcp-server A
io.github.cyanheads
MET Museum collection via MCP — 500K+ artworks, metadata, provenance, open-access images.
Art & Culture Open Data
324

Related MCP Servers

Met Museum MCP Server
Art & Culture Search
mikechao
A
license
A
quality
C
maintenance
A MCP Server that lets user ask AI models to discover the collection of the Metropolitan Museum of Art. Adds the discovered art works as Resources on the server.
Updated 4 months ago (2026-04-27 22:07 UTC)
4
266
34
MIT
artic-mcp
Art & Culture Search Content Management Systems
mikechao
A
license
B
quality
C
maintenance
A server that provides access to the Art Institute of Chicago Collection through natural language interactions. This server allows AI models to search the Art Institute of Chicago Collection and have art works available as a Resource.
Updated a year ago (2025-07-21 17:26 UTC)
6
14
5
MIT
confd-mcp
Art & Culture Databases Content Management Systems
mytours
A
license
Not graded
quality
D
maintenance
An MCP server for the ConFd API that enables comprehensive management of museum and organization data. It allows users to search, create, update, and retrieve records, as well as manage logos through natural language commands.
Updated 6 months ago (2026-03-18 03:28 UTC)
19
MIT
MusicBrainz MCP Server
Search Entertainment & Media Open Data
usercourses63
A
license
Not graded
quality
C
maintenance
A comprehensive MCP server for querying the MusicBrainz database, providing tools to search for artists, releases, recordings, and browse music metadata.
Updated a year ago (2025-09-15 08:44 UTC)
4
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/puf3zin/art-mcp'

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