What can you do with this server?

The ASF Policy MCP server lets you query, search, and manage Apache Software Foundation (ASF) policy documents via an MCP interface. * list_policies: Get an overview of all available ASF policy documents organized by section (e.g., Releases, Licensing, Branding, Security, Incubator, Infrastructure, Privacy, etc.), along with their cache status. * get_policy: Fetch the complete text of any specific policy document by its key (e.g., release_policy, branding, incubator). Supports a force_refresh option to bypass the 30-day local cache and fetch the latest version from the ASF website. * search_policies: Perform keyword searches across all locally cached policy documents, returning ranked excerpts with surrounding context. Supports configuring the maximum number of results returned. * refresh_cache: Force re-fetching of one or more (or all) policy documents from the ASF website in parallel, bypassing the 30-day cache to ensure up-to-date content.

Which integrations are available for this server?

Provides tools for retrieving, searching, and managing Apache Software Foundation policy documents, enabling AI agents to answer questions about releases, licensing, branding, security, incubator, and other ASF policies.

How do I use ASF Policy 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., "@ASF Policy MCP Is the MIT license compatible with Apache 2.0?" 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.

de en es ja ko ru zh

ASF Policy MCP

by justinmclean

Overview Schema Related Servers Score Discussions

Python

Remote

ASF Policy MCP

MCP server for answering questions about Apache Software Foundation policies.

Covers the full set of policies listed at https://www.apache.org/board/policies — releases, licensing, branding, security, infrastructure, incubator, and more.

Also includes the Delaware General Corporation Law (Title 8, Chapter 1 of the Delaware Code), under which the ASF is incorporated. Delaware sources are only included in search when the query mentions Delaware; they can always be retrieved directly by key with get_policy.

Policy pages are cached locally for 30 days. Use force_refresh=true on read tools to bypass the cache for a single call.

Install

python3 -m venv .venv
. .venv/bin/activate
pip install -e .

Related MCP server: Open Policy Agent (OPA) REST API MCP Server

Run

asf-policy-mcp

For local development:

python -m asf_policy_mcp.server

Test

pip install -e ".[dev]"
make check

Configure with Claude Desktop or Codex

{
  "mcpServers": {
    "asf-policy": {
      "command": "<path to PolicyMCP>/.venv/bin/python",
      "args": ["-m", "asf_policy_mcp.server"]
    }
  }
}

Tools

list_policies — list all available policy documents organised by section, with cache status.
get_policy — retrieve the full text of a policy document by key (e.g. release_policy, branding, incubator).
search_policies — keyword search across all policy documents, returning ranked excerpts with context. Delaware law sources are only searched when the query mentions Delaware.
refresh_cache — force re-fetch of one or all policy documents from the ASF website.

Example questions

Releases

What files must be included in a release artifact for it to be valid?
Can we ship a release with only one +1 vote from the PMC?
Where must release artifacts be published — can we use GitHub Releases as the primary download?

Incubator

What does a podling need to do before it can graduate?
Can a podling cut a release before graduating, and what extra requirements apply?
Who can vote on a podling release, and whose votes are binding?

Licensing

Is the MIT licence compatible with Apache 2.0 for bundling in a release?
Can we include a library licensed under LGPL 2.1?
What is a Category X licence and why does it matter?
Do we need a CLA from every contributor, or only committers?
What licence headers are required in source files?

Security

If someone reports a vulnerability privately, how long before we must disclose?
Should security issues be discussed on the public dev list?

Branding

Can a company call its commercial product "Apache Foo Enterprise Edition"?
Can a third party use "Apache Foo" in the name of their commercial product?
What must appear on a project website for trademark compliance?

Infrastructure, press, privacy, and reporting

Can a project use an external Git host like GitLab as its primary code repository?
Can a project host its website on GitHub Pages?
Can a company issue a press release announcing new features they've added support for in an Apache project?
Are Apache mailing list archives public, and what does that mean for personal data posted to them?
If a PMC discovers a company misusing their project's trademark, who handles it and what should they do first?
Can a project list corporate affiliations next to committer names on a "Who We Are" page?
What fields are required in every PMC board report?

Apache Foo scenarios

Apache Foo wants to publish container images, nightly builds, and release candidates from the same Docker Hub namespace. Which parts are allowed, and what labels or warnings are needed?
ExampleCo donated most of Apache Foo's original code and still employs most committers. What website, branding, and project independence issues should the PMC watch for?
A security researcher privately reports a vulnerability in Apache Foo, but a downstream vendor wants to publish a fix immediately. How should the PMC coordinate disclosure, release voting, and public communication?
Apache Foo wants to accept a large generated code contribution produced with AI tooling and containing third-party snippets. Which licensing, provenance, and source-header checks apply?
The Apache Foo PMC wants to run an in-person "FooCon" with paid sponsors, project swag, and talks by vendors. Which event branding, merchandise, press, and conduct policies apply?
A former Apache Foo committer asks for their name and email to be removed from old mailing list archives and Git commits. What do the privacy, public archive, and repository policies imply?
Apache Foo has not released in two years, has no recent PMC additions, and depends on infrastructure that Infra wants to retire. What should the next board report include?

Policy documents

Key	Title	Section
`pmc`	PMC Guide	Community And Project Oversight
`code_of_conduct`	Code of Conduct	Community And Project Oversight
`anti_harassment`	Anti-Harassment Policy	Community And Project Oversight
`public_archives`	Public Forum Archive Policy	Community And Project Oversight
`bylaws`	Bylaws of The Apache Software Foundation	Governance
`certificate_of_incorporation`	Certificate of Incorporation of The Apache Software Foundation	Governance
`project_independence`	Project Independence	Independence
`board_reporting`	Board Reporting Requirements	Reporting
`release_policy`	Release Policy	Release
`voting`	Apache Voting Process	Release
`release_distribution`	Release Distribution Policy	Release
`docker_hub`	Docker Hub Policy	Release
`release_download_pages`	Release Download Pages Policy	Release
`nightlies`	Project Use of nightlies.apache.org	Release
`security`	Security Team Guidance	Security
`security_committers`	Vulnerability Handling for Committers	Security
`licenses`	Contributor License Agreements	Licensing
`apply_license`	Applying the Apache License, Version 2.0	Licensing
`cla_faq`	CLA FAQ	Licensing
`source_headers`	Apache Source Headers	Licensing
`resolved_licenses`	Approved/Resolved Third-Party Licenses	Licensing
`crypto_policy`	Handling Cryptography within an ASF Release	Licensing
`generative_tooling`	Generative Tooling Guidance	Licensing
`branding`	Project Branding Requirements	Branding
`trademark_maintenance`	Trademark Maintenance Responsibilities	Branding
`website_linking`	Website Linking Policy	Branding
`event_branding`	Third-Party Event Branding Policy	Branding
`merchandise_branding`	Non-Software Merchandise Branding Policy	Branding
`domain_name_branding`	Domain Name Branding Policy	Branding
`downstream_distribution`	Apache Software Downstream Distribution Policy	Branding
`podling_branding`	Incubator Podling Branding Guide	Branding
`event_code_of_conduct`	Event Code of Conduct	Events
`trademark_policy`	ASF Trademark Policy	Branding
`repo_policy`	Repository Policy	Infrastructure
`infra_site_ban`	Site-Wide Ban	Infrastructure
`committer_outreach`	Outreach to Committers	Infrastructure
`content_moderation`	Content Moderation	Infrastructure
`mail_rejection`	Mail Rejection Policy	Infrastructure
`spam_reporting`	Dealing with Spam in Your ASF Email Account	Infrastructure
`password_policy`	Password Requirements	Infrastructure
`third_party_services`	Policy on Issues in Third-Party Services	Infrastructure
`slack_policy`	Policy for Using ASF Slack	Infrastructure
`sensitive_information`	Policy on Sharing Sensitive Information with Infra	Infrastructure
`github_actions`	GitHub Actions	Infrastructure
`website_policy`	Website Policy	Infrastructure
`content_security_policy`	Content Security Policy	Infrastructure
`app_upgrade_policy`	Application Upgrades	Infrastructure
`backup_policy`	Backups	Infrastructure
`os_upgrade_policy`	Operating System Upgrades	Infrastructure
`vm_policy`	Virtual Machines for Projects	Infrastructure
`jira_account_approval`	Approving Jira Account Requests	Infrastructure
`jira_account_retention`	Jira Account Retention Policy	Infrastructure
`press`	Press & Marketing Policy	Press
`sponsorship`	Sponsorship Requirements	Fundraising
`targeted_sponsorship`	Targeted Sponsorship Policy	Fundraising
`privacy`	Privacy Policy	Privacy
`privacy_contributors`	Privacy Policy for Contributors	Privacy
`privacy_committers`	Privacy Policy for Committers	Privacy
`privacy_project_websites`	Privacy Policy for Project Websites	Privacy
`privacy_downloadable_products_high`	Privacy Policy for ASF Downloadable Applications (High Privacy Standards)	Privacy
`privacy_downloadable_products_medium`	Privacy Policy for Products with Medium Privacy Standards	Privacy
`privacy_mailing_lists`	Mailing List Policy	Privacy
`incubator`	Incubator Podling Policies	Incubator
`incubator_ip_clearance`	Incubator IP Clearance	Incubator
`delaware_gcl_formation`	Delaware GCL — Subchapter I. Formation	Delaware Law
`delaware_gcl_powers`	Delaware GCL — Subchapter II. Powers	Delaware Law
`delaware_gcl_registered_office`	Delaware GCL — Subchapter III. Registered Office and Registered Agent	Delaware Law
`delaware_gcl_directors_officers`	Delaware GCL — Subchapter IV. Directors and Officers	Delaware Law
`delaware_gcl_stock_dividends`	Delaware GCL — Subchapter V. Stock and Dividends	Delaware Law
`delaware_gcl_stock_transfers`	Delaware GCL — Subchapter VI. Stock Transfers	Delaware Law
`delaware_gcl_meetings_voting`	Delaware GCL — Subchapter VII. Meetings, Elections, Voting and Notice	Delaware Law
`delaware_gcl_amendments`	Delaware GCL — Subchapter VIII. Amendment of Certificate of Incorporation	Delaware Law
`delaware_gcl_merger_conversion`	Delaware GCL — Subchapter IX. Merger, Consolidation or Conversion	Delaware Law
`delaware_gcl_dissolution`	Delaware GCL — Subchapter X. Sale of Assets, Dissolution and Winding Up	Delaware Law
`delaware_gcl_insolvency`	Delaware GCL — Subchapter XI. Insolvency; Receivers and Trustees	Delaware Law
`delaware_gcl_renewal_revival`	Delaware GCL — Subchapter XII. Renewal, Revival, Extension and Restoration	Delaware Law
`delaware_gcl_suits`	Delaware GCL — Subchapter XIII. Suits Against Corporations, Directors, Officers or Stockholders	Delaware Law
`delaware_gcl_close_corporations`	Delaware GCL — Subchapter XIV. Close Corporations; Special Provisions	Delaware Law
`delaware_gcl_public_benefit`	Delaware GCL — Subchapter XV. Public Benefit Corporations	Delaware Law
`delaware_gcl_foreign_corporations`	Delaware GCL — Subchapter XVI. Foreign Corporations	Delaware Law
`delaware_gcl_domestication_transfer`	Delaware GCL — Subchapter XVII. Domestication and Transfer	Delaware Law
`delaware_gcl_miscellaneous`	Delaware GCL — Subchapter XVIII. Miscellaneous Provisions	Delaware Law

Delaware Law sources (from https://delcode.delaware.gov/title8/c001/) are searched only when the query mentions Delaware, e.g. "Under Delaware law, can members vote by proxy?"

PolicyMCP is an independent tool and is not a project of the Apache Software Foundation. Apache and related marks are trademarks of The Apache Software Foundation.

Available Tools

4 tools

get_policyA

Retrieve the full text of a specific ASF policy document.

Use list_policies to discover valid policy keys such as 'release_policy', 'branding', 'resolved_licenses', 'incubator', etc.

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes
`force_refresh`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/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 implies a read-only operation but does not explain the force_refresh parameter or any caching behavior. Side effects are not mentioned, but the tool is likely safe.

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 with no wasted words. The key point is front-loaded, and the guidance is immediately after.

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 retrieval tool, the description covers the main purpose and provides a prerequisite. However, it lacks details on the force_refresh parameter and potential errors. The output schema may compensate, but the description alone is slightly incomplete.

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%. The description does not explain the 'key' parameter's format or valid values beyond the example keys, and 'force_refresh' is not described. This is insufficient for parameter understanding.

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 retrieves the full text of a specific ASF policy document. It distinguishes from siblings by referencing list_policies for discovering valid keys.

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 directs users to use list_policies to find valid policy keys, providing a clear prerequisite and alternative. However, it does not mention when to use search_policies or refresh_cache instead.

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

list_policiesA

List all available ASF policy documents organised by section.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/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 states the tool lists all policies organized by section, which is transparent enough for a simple read operation. However, it does not disclose potential pagination, rate limits, or data volume, which could be relevant for an agent.

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 filler. Every word adds value: 'list all available' sets scope, 'ASF policy documents' identifies the resource, 'organised by section' provides structure. It is optimally concise.

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 zero parameters and the presence of an output schema, the description is complete. It tells the agent what the tool does (list all policies by section) and nothing more is needed for correct invocation. Sibling tools provide additional context for differentiation.

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, and the input schema coverage is 100% (empty). According to guidelines, the baseline score is 4 when no parameters exist. The description adds no param info because none are needed.

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 'List' and clearly identifies the resource as 'all available ASF policy documents'. It also adds organization detail 'by section', which differentiates it from siblings like 'get_policy' (single document) and 'search_policies' (filtered search).

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 when to use the tool (when you need all policies organized by section) but provides no explicit guidance on when not to use it or alternatives. Given sibling names, context is inferred but not stated, so the score is neutral.

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

refresh_cacheA

Re-fetch policy documents from the ASF website in parallel, bypassing the 30-day cache.

Omit keys to refresh all policies.

ParametersJSON Schema

Name	Required	Description	Default
`keys`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

The description mentions parallel fetching and cache bypass, which are key traits. But without annotations, it should disclose potential costs (external fetches) and safety (non-destructive but mutates cache). Currently lacks these.

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 sentences with no redundancy. The first sentence states the main action, the second explains the parameter behavior. Efficient and well-structured.

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?

With an output schema and a single optional parameter, the description covers the essential information for invocation. Minor gap: doesn't mention the effect on other tools' data (e.g., get_policy will now show fresh data).

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 only parameter 'keys' has no schema description, but the description clarifies its meaning: omit to refresh all, provide to refresh specific. This adds value 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 action (re-fetch policy documents via parallel) and resource (ASF website), and it distinguishes from sibling tools that read the cached policies.

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?

It explains when to use the tool (to bypass cache and force refresh) and how to scope the refresh (omit keys for all, provide keys for specific). However, no explicit 'when not to use' or alternatives.

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

search_policiesA

Search across cached ASF policy documents for a query term or phrase.

Returns ranked excerpts with surrounding context. Only searches policies already in the local cache — run refresh_cache first to ensure all policies are available.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Describes return format (ranked excerpts with context) and cache dependency. Does not disclose read-only nature or other behavioral details like rate limits or error conditions.

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?

Three sentences, each adding value: first states purpose, second specifies return format, third gives prerequisite. No filler. Information is front-loaded and 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?

Output schema exists, so return details are covered. Description gives a high-level sense of output (ranked excerpts). However, missing parameter details and lack of behavioral nuance about caching status make it slightly less complete than ideal for a search tool.

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 coverage is 0%, meaning no descriptions in schema. Description only mentions 'query term or phrase' for the query parameter, but does not explain the max_results parameter or provide any additional semantics beyond the parameter names.

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 verb 'search' and resource 'cached ASF policy documents', distinguishing it from siblings get_policy (retrieve specific), list_policies (list all), and refresh_cache (update). It specifies ranking and excerpts.

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?

Explicitly states prerequisite 'run refresh_cache first', advising when the tool is usable. Does not explicitly state when not to use or directly contrast with siblings, but the context is clear enough.

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.1.0May 6, 2026
- First observedget_policy
- First observedlist_policies
- First observedrefresh_cache
- First observedsearch_policies

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: listing, retrieving, searching, and caching. No overlap or confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_policy, list_policies, refresh_cache, search_policies.

Tool Count5/5

Four tools are perfectly scoped for managing policy documents: list, get, search, and cache refresh.

Completeness5/5

The set covers all necessary operations for a read-only policy server: discovery, retrieval, search, and cache management.

Maintenance

ActivityMaintained

ResponsivenessNo issues

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

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
opencode
io.github.doc2mcp
MCP server for opencode documentation, generated by doc2mcp.
Documentation Access Developer Tools
24
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
111
agentverse
io.github.doc2mcp
MCP server for agentverse documentation, generated by doc2mcp.
Agent Orchestration Documentation Access
24

Related MCP Servers

Policy Analyzer API MCP Server
Autonomous Agents Legal & Compliance Documentation Access
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
This MCP Server provides a natural language interface to interact with Google's Policy Analyzer API, allowing users to analyze policies and evaluate compliance through conversations.
Updated a year ago (2025-07-16 14:02 UTC)
-
Open Policy Agent (OPA) REST
Shell Access Command Line Code Execution
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP Server that enables natural language interaction with the Open Policy Agent REST API, allowing users to manage policies, decisions, and data through conversational interfaces.
Updated a year ago (2025-07-16 14:21 UTC)
1
-
AsyncAPI-MCP
Documentation Access Developer Tools
Souvikns
A
license
A
quality
B
maintenance
An MCP server that gives AI assistants access to the AsyncAPI specification - search, explore and retrieve any version of the spec directly from your coding tool.
Updated 6 days ago (2026-08-31 07:07 UTC)
5
Apache 2.0
Whoosh RAG MCP
RAG Systems Search Documentation Access
jianlins
A
license
Not graded
quality
C
maintenance
An MCP server that provides full-text search over documentation using Whoosh, enabling AI assistants to find up-to-date, authoritative answers.
Updated 9 months ago (2025-11-22 01:16 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/justinmclean/PolicyMCP'

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