sops-mcp

Server Quality Checklist

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

Latest release: v0.10.1
Disambiguation5/5
Each tool has a clear, distinct purpose: adding, creating, deleting, listing, renaming, rotating, updating, or adding metadata. No two tools overlap in functionality, and descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent 'sops_verb_noun' pattern in snake_case. The verbs (add, create, delete, list, rename, rotate, update) are descriptive and uniform.
Tool Count5/5
With 9 tools, the server covers the essential operations for managing SOPS-encrypted secrets without being bloated. Each tool serves a necessary and well-scoped function.
Completeness4/5
The tool set covers all major lifecycle operations: create, read (list), update (add, rename, update_external, rotate), and delete. Minor gaps exist (e.g., no explicit metadata removal tool), but the surface is largely complete for secrets management.
Average 4.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the need for the SOPS_AGE_KEY env var and that external secrets are preserved, but it does not detail side effects like overwriting generated secrets or error conditions when the env var is missing. Given no annotations, more transparency would be beneficial.
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, well-structured sentence that conveys essential information without any unnecessary words or redundancy.
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?
While the description covers the core functionality and an important prerequisite, it lacks details about return values, error handling, and potential side effects. This is adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for the only parameter. The description does not add additional meaning beyond what the schema already provides, meeting the baseline.
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's purpose: re-generating 'generated' secrets with new random values while preserving 'external' secrets. It uses a specific verb and resource, and distinguishes from sibling tools like sops_add_secrets.
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?
It mentions the requirement for the SOPS_AGE_KEY environment variable, providing some usage context. However, it does not explicitly state when not to use this tool or mention alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: it decrypts, merges, re-encrypts, preserves existing values and metadata, rejects duplicate keys, and supports multiple source types. This is comprehensive, though it could mention atomicity or error handling for missing keys.
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 well-structured sentences; first sentence immediately states purpose, second explains the process and constraints, third lists support and requirements. No redundant or extraneous information. 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?
Covers workflow, prerequisites, and constraints well. However, it does not describe the return value (likely the updated encrypted content) or specify what happens on failure. Given no output schema, a brief mention of the output would make it more complete. Sibling tools exist but are not referenced for differentiation.
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 the schema already thoroughly describes each parameter. The description adds workflow context (decrypt, merge, re-encrypt) but does not enhance parameter semantics beyond what the schema provides. Baseline of 3 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?
Explicitly states 'Add new secrets to an existing SOPS-encrypted file' with specific verb and resource. Distinguishes from sibling tools like sops_create_secrets (which likely creates a new file) and sops_delete_secrets. The merge-and-preserve behavior further clarifies its unique role.
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?
Provides prerequisite (SOPS_AGE_KEY env var) but offers no explicit guidance on when to use this tool versus alternatives like sops_create_secrets or sops_update_external. The description implies usage by stating it works on existing files, but a direct comparison or when-to-use/when-not-to-use would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains decryption, addition, and re-encryption preserving plaintext, but lacks details on error handling or pre-existing metadata scenarios.
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, front-loaded with purpose, efficient second sentence with process and prerequisite. No unnecessary 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?
Adequate for a modification tool with nested parameters; covers purpose, process, and prerequisite. Lacks output description, but likely trivial for such tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds overall context but no additional parameter-level details beyond 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 the tool adds metadata to SOPS-encrypted files lacking it. Differentiates from sibling tools like sops_add_secrets by focusing on metadata rather than secrets.
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?
Describes when to use (file lacks metadata) and prerequisite (SOPS_AGE_KEY env var). Does not explicitly state when not to use or alternatives, but context with siblings provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 values, source type, and metadata are preserved; that 'from' references in derived secrets are updated; and that the SOPS_AGE_KEY env var is required. It does not mention error handling or idempotency but covers key behavioral traits.
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 concise with three sentences that front-load the main action and cover essential details (preservation, reference updates, env var requirement). No redundant or vague language.
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 annotations or output schema, the description provides sufficient context for the rename operation. It explains side effects (updating derived secrets) and a prerequisite (env var). It could mention what happens on failure or if the key does not exist, but overall it is adequate for an AI agent to understand the tool's behavior.
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 baseline is 3. The description does not add meaning beyond the schema: it mentions 'key' and 'rename' but the parameters (encrypted_content, old_name, new_name) are already described in the schema. No additional constraints or examples are provided.
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 ('rename a key'), the resource ('existing SOPS-encrypted file'), and distinguishes from sibling tools (add, delete, list, etc.) by focusing on renaming. It also details what is preserved and updated.
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 (to rename a key) but provides no explicit guidance on when not to use or alternatives. No mention of prerequisites or comparison with siblings like sops_add_secrets or sops_delete_secrets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns encrypted content and that derived secret plaintexts are returned. It also explains the behavior of different sources (generated uses randomness, external requires value, derived uses transform from another key). Lacks disclosure on authentication or rate limits but is sufficient for basic usage.
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 concise, front-loaded with the main purpose, and uses clear, direct language. Every sentence adds value: first sentence states output and action, second sentence explains derived plaintext behavior, third sentence lists sources. No fluff.
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 appropriately explains the return value (encrypted content for client to write to disk) and derived secret plaintexts. It covers the main aspects of the tool's workflow. Could mention file path handling or error conditions but is fairly complete for a creation tool with complex parameter requirements.
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% with descriptions for all parameters. Description adds value beyond schema by explaining the behavioral implications of source types (e.g., derived secrets return plaintexts, generated uses cryptographic randomness). This contextual information helps agents select and correctly invoke the tool.
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 it generates and encrypts secrets as SOPS YAML, returns encrypted content for client to write to disk. It specifies three distinct sources (generated, external, derived) with examples, distinguishing it from sibling tools like sops_add_secrets or sops_delete_secrets.
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 explains when to use this tool (for creating and encrypting secrets) and provides context about derived secrets returning plaintexts. It implicitly distinguishes from siblings by focusing on creation, but lacks explicit when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: removal of both encrypted value and metadata entry, rejection of dependent keys unless included in the delete list, and the required environment variable. It lacks explicit output details but covers important safety and dependency 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 three sentences with no fluff. It front-loads the main action, then provides specific removal details, and ends with a crucial constraint. Every sentence adds necessary 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 tool with 2 parameters and no output schema, the description covers the deletion process, dependency rule, and env var requirement. It does not describe the return value or error scenarios beyond dependency rejection, but given the context, it is largely 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the effect on parameters: it clarifies that deleting a key removes its encrypted value and meta entry, and that key_names may be rejected if dependencies are not also deleted. This goes beyond the schema descriptions.
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 deletes keys from a SOPS-encrypted file, with specific details about what is removed (encrypted value and _meta_unencrypted entry). It distinguishes itself from sibling tools like sops_add_secrets or sops_list_secrets by specifying deletion behavior and dependency handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (deleting keys) and includes a prerequisite (requires SOPS_AGE_KEY env var). However, it does not explicitly contrast with alternatives or provide when-not-to-use scenarios, though the dependency rejection provides a constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the responsibility. It discloses that it reads key names from encrypted YAML and metadata from the _meta_unencrypted block, and states no decryption is needed. This provides good behavioral insight, though it could be more explicit about being read-only.
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 zero wasted words. The first sentence states the purpose, the second adds the critical behavioral detail. 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?
For a simple input-only tool with no output schema, the description covers the essentials. It could benefit from mentioning what kind of metadata is returned or that the tool is purely read-only, but it is sufficiently complete given the low complexity.
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 single parameter is fully described in the schema ('Contents of a secrets.enc.yaml file'), and the description adds value by explaining how the content is used (reading key names and metadata). This goes beyond the schema's bare description.
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 'key names and metadata from a SOPS-encrypted file.' The verb 'List' and the resource are precise. It distinguishes from sibling tools by highlighting that no decryption is needed, which is unique among the sops_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for read-only inspection without decryption, setting clear context. However, it does not explicitly state when to use it versus alternatives (e.g., sops_add_secrets for modifications). Given many siblings, explicit when/when-not would be ideal, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool generates a 64-char alphanumeric secret and a PBKDF2-SHA512 hash, stores them in a new encrypted file, and returns the hash. However, it does not disclose file naming conventions, overwrite behavior, or authorization requirements, leaving minor gaps.
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 three sentences long, each serving a distinct purpose: stating the tool's purpose, describing the behavior, and relating it to a sibling tool. No unnecessary 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 tool has two parameters, no output schema, and no annotations, the description covers input, output (hash in response), and equivalence to a sibling. It could mention potential side effects like file naming, but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds value by explaining the relationship between 'key_name' and the hash key (KEY_NAME_HASH) and the nature of the generated secret, which goes beyond the schema's type constraints.
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 it is a 'convenience tool' for creating an 'Authelia-compatible OIDC client secret'. It clearly distinguishes itself from the sibling tool 'sops_create_secrets' by specifying it is equivalent to calling it with specific entries.
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 specifies when to use this tool (for OIDC client secrets) and contrasts it with the alternative 'sops_create_secrets' by stating it is a convenience wrapper. It gives clear guidance on 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool recomputes derived secrets referencing the key and rejects non-external secret types. It also states the environment variable requirement.
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 zero waste. The first sentence states the action and use case, the second adds restrictions and side effects. Front-loaded and efficient.
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 has 3 required parameters, no output schema, and no nested objects, the description is complete. It covers purpose, usage, behavioral side effects, and requirements.
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 the descriptions in the schema are clear. The tool description does not add extra meaning beyond the schema for the parameters, so baseline 3 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 tool replaces the value of an external secret, uses a specific verb and resource, and distinguishes itself from siblings by explicitly mentioning that it rejects generated or derived secrets and directs to sops_rotate_generated for those.
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?
It explicitly says when to use (after rotating an upstream API key) and when not to (for generated/derived secrets, with a specific alternative named). It also mentions a prerequisite (SOPS_AGE_KEY env var).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![sops-mcp MCP server](https://glama.ai/mcp/servers/privacyplaybook/sops-mcp/badges/card.svg)](https://glama.ai/mcp/servers/privacyplaybook/sops-mcp)

Score Badge

Copy to your README.md:

[![sops-mcp MCP server](https://glama.ai/mcp/servers/privacyplaybook/sops-mcp/badges/score.svg)](https://glama.ai/mcp/servers/privacyplaybook/sops-mcp)

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/privacyplaybook/sops-mcp'

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