freeplay-mcp

Official

by freeplayai

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.0.7
Disambiguation5/5
Each tool has a clearly distinct purpose: creating prompt versions, analyzing logging issues, retrieving deployment info, fetching specific versions, listing insights, projects, and templates, optimizing prompts, and searching observability data. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., create_prompt_version, list_projects, search). Verbs like 'get', 'list', 'find', 'create', and 'search' are used consistently, and the naming is predictable and readable.
Tool Count5/5
Nine tools is an appropriate scope for a prompt management and observability server. It covers the core workflows without being too sparse or overwhelmingly large.
Completeness4/5
The tool set covers essential CRUD-like operations (create, read) and search/analysis, but lacks delete operations for versions or templates. The missing delete is a minor gap, as most workflows are supported.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on March 5, 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 that the operation is read-only and indicates what it returns (versions deployed to environments like dev, staging, production, custom). However, it does not address behavior for invalid inputs, error cases, or rate limits. Since no annotations are provided, the description carries the full burden, but it provides basic safety information.
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 concise with two short paragraphs. The first paragraph introduces the purpose, and the second provides a parameter list. No redundant information is present. It could be slightly more streamlined, but overall it is well-structured and efficient.
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 required parameters and an output schema exists, the description covers the essential context: purpose, read-only nature, and environments. It does not explain edge cases or output structure, but the output schema compensates for the latter. For a simple tool, the description is adequately 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 parameter schema has 0% description coverage, so the description must compensate. It lists both parameters in an Args section and notes they are required, adding meaning beyond the schema's required specification. However, it does not provide details on valid formats, examples, or additional semantics, so compensation is partial.
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 that the tool retrieves deployment status for a prompt template, indicating which versions are deployed to each environment. It uses specific verbs ('Get') and identifies the resource ('deployed prompt versions'). It distinguishes itself from sibling tools like 'get_prompt_version' (which likely gets a specific version details) by focusing on deployment across environments.
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 for checking deployment status but does not explicitly compare with sibling tools or provide when-not-to-use guidance. It mentions the tool is read-only, which gives some context, but lacks alternative tool references or exclusions.
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?
The description declares the operation as read-only, which is a key behavioral trait. However, it does not disclose error handling, rate limits, authentication requirements, or what happens when the project_id is invalid. Given no annotations, the description carries the full burden but is still somewhat opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long and has some redundancy (e.g., 'List insights' appears twice). It is front-loaded with purpose and structured with a paragraph and Args list, but could be more concise without losing clarity.
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 presence of an output schema, the description appropriately focuses on input semantics and what insights are. It covers pagination and filtering, which are key. Minor omissions like ordering or pagination field details prevent a perfect score.
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?
With 0% schema description coverage, the description compensates well by documenting all five parameters in the Args section, including required/optional status, defaults, and filtering purposes. This adds significant meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'insights' for a Freeplay project, and distinguishes it from sibling tools like 'search' by specifying it returns automatically generated observations. The purpose is unambiguous.
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 explains when to use the tool (to retrieve insights from a project) and mentions filtering by prompt template or agent, but does not provide explicit guidance on when not to use it or compare to alternatives like 'search' for more complex queries.
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 are provided, so the description bears full responsibility. It correctly states 'This is a read-only operation' and indicates the return format (list with IDs and names). However, it could detail pagination, ordering, or authentication requirements, which are absent.
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 earning its place: purpose, return format, usage guidance. Front-loaded with the main function. No filler or repetition.
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 no-parameter tool with an output schema, the description is mostly complete: it covers purpose, read-only nature, output content, and usage context. Missing potential details like pagination, but overall adequate.
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?
With zero parameters, baseline is 4. The description adds value by describing the output (formatted list of projects with IDs and names), which is beyond the empty input schema. This helps the agent understand what to expect.
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 all Freeplay projects accessible to the user, with the verb 'List' and the resource 'projects'. It specifies read-only operation, and the context of siblings shows other list tools for different resources, so this tool is well-distinguished.
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 says 'Start here for most workflows' and 'Use a project ID from this list to scope most other Freeplay operations', providing clear usage context. It does not explicitly exclude scenarios, but the guidance is practical and sufficient for a foundational list tool.
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 are provided, so the description carries the full burden. It declares the operation as read-only and describes the return contents ('messages, model, provider, and LLM parameters'). This discloses the non-destructive nature and output structure, though it omits potential authentication or rate limit details.
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 clear sentences plus a structured Args list. The main purpose is front-loaded, every sentence adds value, and there is no redundancy or 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?
With an output schema present and low complexity (3 required string params), the description adequately covers purpose, parameter semantics, and return content. It does not mention error conditions or prerequisites, but for a simple read operation this is acceptable.
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 has no parameter descriptions (0% coverage). The description compensates by listing Args with meanings: 'The Freeplay project ID', 'The prompt template ID', 'The version ID to retrieve'. This adds essential semantic context beyond the bare 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 starts with 'Get the full contents of a prompt template version', clearly identifying the verb (get) and resource (prompt template version). It distinguishes from siblings like create_prompt_version and get_deployed_prompt_versions by specifying it retrieves a specific version's full contents.
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 states 'Use this to inspect a version before making changes', providing a clear when-to-use context. It does not mention alternatives or when not to use, but for a read-only tool this is sufficient guidance.
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 are provided, so the description fully discloses behavior: it is a write operation requiring user confirmation. It explains the automatic creation behavior when create_if_not_exists is true. It does not detail versioning mechanics (e.g., numbering), but the overall behavior is clear.
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 well-structured: starts with a clear purpose statement, followed by usage guidance, then a parameter block. It is relatively long but every part adds value. Minor redundancy could be trimmed (e.g., the parameter list repeats schema info), but it remains efficient for its complexity.
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 11 parameters (5 required), an output schema exists, and no annotations, the description covers all key aspects: purpose, required confirmation, automatic template creation, deployment limitation, and parameter details. It could mention default values (e.g., create_if_not_exists defaults to true) but these are in the schema. Overall, it is complete for an agent to invoke 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?
Input schema description coverage is 0%, so the description must compensate. It does so by listing all parameters with examples (e.g., prompt_messages JSON format, model examples like 'gpt-4', provider examples like 'openai'). Optional parameters like llm_parameters and tool_schema are explained. Some parameter types (e.g., tool_schema as array of objects) could be more precise, but the examples help.
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 core action: 'Create a new version of a prompt template.' It specifies it is a write operation. None of the sibling tools (e.g., get_prompt_version, list_prompt_templates) perform creation, so it is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to 'Always confirm with the user before calling' and to describe which template, model, provider, and whether a new template will be created. Also warns that 'Deployment is not supported via MCP' and directs to the Freeplay UI, guiding when not to use the tool.
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 explicitly states 'This is a read-only analysis operation,' indicating no destructive side effects. It also explains that it fetches recent completions and returns a list of missing fields with explanations and fixes. Without annotations, the description adequately discloses behavioral traits, though it could mention if any data is modified (but read-only is clear).
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 well-structured with a summary, a read-only clarification, and a bulleted list of arguments. It is slightly repetitive (e.g., first two sentences both describe the core action), but overall efficient and front-loaded with key information.
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 (4 params, no annotations, output schema exists), the description covers the purpose, read-only nature, parameter meanings, and return type. Since an output schema is present, it is not required to detail the return format. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds full meaning to all four parameters. It explains that project_id is required, template_name filters by prompt template (or checks all if not provided), environment filters environment, and limit defaults to 50. This compensates entirely for the lack of 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's purpose: analyzing recent completions for a prompt template and identifying missing logged fields. It specifies the verb (analyze, identify) and the resource (recent completions for a prompt template), and distinguishes from siblings like get_prompt_version or list_insights by focusing on logging gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: 'Use this to identify gaps in your observability instrumentation.' It does not explicitly mention when not to use or list alternatives, but the purpose is distinct enough among siblings to imply appropriate usage.
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 discloses that it is a read-only operation and returns a list with IDs, names, and latest version info. While no annotations are provided, the description adds context about pagination parameters and the nature of the operation.
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 a clear purpose statement, followed by return info and an Args section. Every sentence adds value without unnecessary detail.
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 output schema exists, the description adequately covers the tool's purpose, parameters, and return values. It is complete for a list operation with pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all three parameters: project_id is required, limit defaults to 50, offset defaults to 0, explaining their roles in pagination. This compensates for the 0% schema description coverage.
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 lists all prompt templates in a Freeplay project and specifies it is a read-only operation. This distinguishes it from sibling tools like create_prompt_version and get_prompt_version.
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 the tool (to list templates) and hints at using the results for creating new versions. However, it does not explicitly mention when not to use it or point to alternatives for specific template details.
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?
With no annotations, the description fully discloses behavior: it's a write operation, long-running, creates a new version, incurs LLM costs, and explains the effect of each boolean flag. No contradiction.
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?
Well-structured with key warnings upfront and bullet-like parameter list. Slightly verbose but every sentence adds value; could be tightened slightly without losing clarity.
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 it has an output schema, return values are covered elsewhere. The description fully explains all parameters, behavioral nuances, prerequisites (user confirmation), and cost/performance implications for a complex 8-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists all 8 parameters with clear explanations, e.g., 'user_instructions: Optional specific instructions for the optimization (e.g., focus on reducing hallucinations)', adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Optimize a prompt template version' and specifies it is a write operation that creates a new version. It distinguishes from siblings like 'create_prompt_version' by focusing on AI-powered optimization.
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 instructs to confirm with the user before calling, mentioning cost implications and what to relay. However, no direct exclusions or comparisons to alternatives are provided.
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?
Declares read-only operation, explains result types, and details filter syntax comprehensively. With no annotations provided, the description fully discloses behavior: no side effects, authentication implied but not required beyond tool access, and pagination via limit/offset. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: summary first, then key concepts, followed by filter syntax documentation, and parameter descriptions. Each section earns its place; no fluff. Front-loaded with core purpose and read-only nature.
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 complexity (5 parameters, extensive filter system), the description covers all aspects: result types, filter syntax, all available fields with operators, examples, and parameter details. Output schema exists, so return values are not needed. Complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description compensates fully with an 'Args' section explaining each parameter, plus extensive documentation of the 'filters' parameter including syntax, operators, available fields, and compound filter examples. Adds substantial meaning beyond the bare 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?
States verb 'Search' and resource 'observability data in a Freeplay project', specifies read-only, and lists result types (sessions, traces, completions). Clearly distinguishes from sibling tools which focus on prompts, insights, and projects.
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?
Provides clear context for when to use: searching with filters for sessions, traces, or completions. Includes filter syntax and examples. Does not explicitly state when not to use, but sibling tools are sufficiently distinct so no ambiguity arises.
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:

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

Score Badge

Copy to your README.md:

[![freeplay-mcp MCP server](https://glama.ai/mcp/servers/freeplayai/freeplay-mcp/badges/score.svg)](https://glama.ai/mcp/servers/freeplayai/freeplay-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/freeplayai/freeplay-mcp'

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