gamebook

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to distinct actions: starting, choosing, examining, looking, using, taking, dropping, hinting, and checking status. Minor overlap exists between look_around and examine since both inspect the current environment, but their intended purposes remain distinguishable.
Naming Consistency4/5
The naming pattern is mostly verb_noun with clear action-oriented names like begin_adventure, take_item, and drop_item. The bare verbs 'use' and 'examine' deviate slightly from the pattern, but they are still intuitive and readable.
Tool Count5/5
Nine tools is well-scoped for a gamebook server, covering the core interaction loop without unnecessary bloat. Each tool serves a clear gameplay purpose, and the count feels appropriate for the domain.
Completeness4/5
The tool set covers the core interactive fiction lifecycle: starting, choosing, looking, examining, using, taking, dropping, hinting, and status tracking. A minor gap is the lack of a dedicated way to refetch the current scene's available actions without beginning or choosing, which could leave agents stuck if context is lost.
Average 3.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action and fails to mention side effects such as removing the item from the player's inventory, whether the action is reversible, what happens to the item in the place, or whether any validation occurs.
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 one short, well-structured sentence with no redundant wording. The verb and object are front-loaded, making the core purpose immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has an output schema, the description leaves key operational details unaddressed: how the item is identified, what session context is required, what side effects occur, and when this action is permissible. The absence of annotations makes this a notable gap for an agent invoking a mutating action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It gives minimal context for item_name and none for adventure_session_id beyond its name; the meaning of the session identifier and its relationship to the current place is left entirely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Drop'), a resource ('an inventory item'), and a location ('in the player's current place'), making the action clear. It distinguishes itself from siblings like take_item and use by naming the drop operation explicitly, though it does not directly reference any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as take_item, use, or examine. The wording implies it should be used to discard a held item, but no explicit context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior, but it only states that a choice is made. It does not disclose whether the choice advances the scene, whether it is reversible, whether the session state changes, or what response shape to expect beyond the existence of an output schema.
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 a single concise sentence with no filler. It front-loads the core action, though it could benefit from a short second sentence clarifying the source of action IDs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is fairly simple and an output schema exists, but the description leaves important operational gaps: where action IDs come from, whether adventure_session_id is required from context, and what selecting an action triggers. Given two required parameters and zero schema coverage, this is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only lightly hints at choice_id through 'action IDs', which helps slightly, but it completely fails to explain adventure_session_id, its format, or how it relates to the current scene.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Choose') and resource ('action IDs offered by the current scene'), so an agent can infer this selects from available scene actions. It does not explicitly contrast with sibling tools like use or examine, but the wording is specific enough to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool should be used when the current scene offers action IDs and the agent must pick one. However, there is no explicit guidance on when not to use it or how it relates to siblings, such as whether use is for applying items versus selecting a narrative action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'review', which implies a read-only observation, but does not explicitly state that it has no side effects, whether hidden items are revealed, or whether a turn is consumed.
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?
One concise sentence with no redundant phrasing. The key action and scope are front-loaded, and 'including any items present there' adds useful specificity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple exploration tool with an output schema, the description gives a usable baseline. However, the lack of any relation to sibling tools such as examine, and the absence of behavioral caveats, leaves some context 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% and the description does not mention adventure_session_id or its role. While the parameter name is self-explanatory, the description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Review') and resource ('current place') and adds that items present are included. This clearly distinguishes it from tools like take_item or use, but does not explicitly contrast it with the similar examine sibling.
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 phrase 'current place' implies it is for when the agent wants an overview of the current surroundings, but it provides no explicit guidance about when to prefer look_around over examine or other siblings. Usage context is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful behavioral trait: failures list available item names. But it does not disclose the core side effect of taking an item, whether the action is reversible, what prerequisites exist, or what happens on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence delivers the core action and a useful failure behavior. No extra words or repeated schema information; the structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is thin for a state-changing game action. It does not clarify what taking an item accomplishes, when the action is valid, how the available names are returned, or how it relates to sibling actions like use and drop_item. An agent needs more context to call this reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that item_name must be the exact name, but it says nothing about adventure_session_id, which is also required. The failure behavior partially informs item_name usage but leaves the session parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Take an item using its exact name'. It is distinguishable from siblings like use, examine, and drop_item by the semantics of taking, though it does not explicitly name or contrast them.
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 the player wants to take an item, and it emphasizes using the exact name. However, it does not explicitly say when not to use it or how it differs from use, examine, or drop_item, leaving routing partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects and call semantics. 'Check' suggests a read-only operation, but the description does not explicitly state that calling it has no game state impact, does not consume a turn, or can be safely invoked at any time. This is a meaningful gap for an adventure-game context.
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 succinct sentence that immediately conveys the tool's core purpose. There is no filler, and the most important information ('current health and inventory') is front-loaded. For a simple tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to document return values, but the description still lacks crucial contextual details: it does not explain the adventure_session_id parameter, whether the tool is a free action or costs a turn, or how this status check fits into the broader adventure flow. For a tool with no annotations and low schema coverage, this leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention adventure_session_id at all. The parameter name is somewhat self-explanatory, but the description provides no guidance on how to obtain a valid session ID, what format it should be in, or why it is needed. Since coverage is low, the description should compensate, but it does not.
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 ('Check') and a clear resource ('the player's current health and inventory'). This distinguishes it from siblings like take_item, drop_item, and look_around, which operate on the environment or inventory items rather than the player's internal state.
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 this tool: whenever the agent needs the player's health or inventory state. However, it does not explicitly state when not to use it or mention alternatives, such as using 'examine' for inspecting objects or 'look_around' for the environment. Usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions receiving opening context and choices but does not say whether beginning a new adventure creates or overwrites a session, or what happens if an existing adventure_session_id is supplied. This is a material gap for a state-changing, session-based tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler. The core action and expected outcome are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter whose semantics are unexplained, and the absence of annotations leaves side effects and prerequisites unclear. While an output schema exists, the description alone does not tell an agent whether to start fresh, carry over a session, or expect destructive behavior.
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% and the description never mentions adventure_session_id. The parameter name hints at session identity, but the description does not clarify whether null starts a fresh adventure or an ID resumes/restarts one, leaving the sole parameter ambiguous.
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 ('Begin') with a clear resource ('a new adventure') and states the expected output ('opening context and choices'). It is immediately distinguishable from sibling action tools like choose_action, examine, and look_around.
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 that this tool is the entry point before the action-oriented sibling tools, but it never explicitly states when to use it or how to choose between passing null and an adventure_session_id. No alternatives or exclusions are mentioned, so usage guidance relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether examining is read-only, whether it changes game state, what happens when the item is absent, or whether scene vs. inventory items behave differently.
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, and the verb-object structure front-loads the core purpose. Every word earns its place.
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?
The description covers the core purpose and item scope well, and an output schema exists to handle return-value documentation. However, missing parameter explanation and absent usage guidance leave meaningful gaps, particularly around the required adventure_session_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that item_name can refer to either an inventory item or a current scene item, but it says nothing about adventure_session_id, expected formats, or how the two parameters relate.
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 pairs the verb "Examine" with specific resource types: "an inventory item or an item present in the current scene." This clearly distinguishes the tool from scene-level look_around and mutating actions like take_item, drop_item, or use.
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 that examine should be used when an agent wants details about a specific item, but it gives no explicit when-to-use or when-not-to-use guidance relative to siblings like look_around or use. The boundary is inferable from sibling names, but the description does not state it directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It reveals an item constraint (inventory or statefil in scene) but does not state what 'using' does—whether the item is consumed, whether the scene changes, or what side effects occur. An agent cannot predict the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler; the core constraint is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with two required parameters, the description leaves out usage selection and parameter semantics, and it does not illuminate behavioral outcomes. However, the presence of an output schema mitigates the need to document return values, so the description is minimally viable but not complete.
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% and the description never mentions item_name or adventure_session_id. item_name is weakly inferable from 'inventory item,' but adventure_session_id is entirely unexplained, forcing the agent to guess its purpose.
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 names a specific action ('use') and a precise scope ('an inventory item or a stateful item present in the current scene'), which clearly distinguishes it from siblings like take_item, drop_item, and examine. The verb-plus-resource pattern makes the tool's purpose immediately intelligible.
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 that 'use' is appropriate when an item should be consumed or activated, but it never explicitly states when to prefer this tool over examine, take_item, or drop_item. No when/when-not guidance is provided, only the inherent meaning of the verb.
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?
With no annotations, the description carries the full behavioral burden. It discloses that 'direct' produces a stronger clue, which is useful, but it does not state side effects, limits on hint requests, or whether the hint is read-only. It is minimally transparent but has 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?
A single, front-loaded sentence conveys the core action and parameter effect without filler. Every word contributes to understanding the tool.
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?
The tool is simple and has an output schema, so return values need not be spelled out. However, the description omits the session context and any constraints around hint availability, leaving context to be inferred from the required 'adventure_session_id' and the adventure-themed siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the non-obvious 'direct' boolean ('stronger clue') but does not explain 'adventure_session_id', though that parameter's title is reasonably self-explanatory. The required parameter is not described 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 uses a specific verb and resource ('Request a subtle hint') and clearly distinguishes the two modes via the 'direct' flag. It also stands apart from all sibling action tools, none of which are hint-related.
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 the tool is for obtaining hints during an adventure, but it never states when to prefer it, when not to use it, or how it relates to sibling tools. No explicit usage conditions are given; the use case is inferred from the name and wording.
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:

[![gamebook MCP server](https://glama.ai/mcp/servers/bruceweir/gamebook/badges/card.svg)](https://glama.ai/mcp/servers/bruceweir/gamebook)

Score Badge

Copy to your README.md:

[![gamebook MCP server](https://glama.ai/mcp/servers/bruceweir/gamebook/badges/score.svg)](https://glama.ai/mcp/servers/bruceweir/gamebook)

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/bruceweir/gamebook'

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