NebulaMind

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: natural language Q&A (ask_question), structured graph retrieval (get_knowledge_graph), analytics (get_stats), wiki page inventory/access (list_pages, read_page), discussion (post_comment), collaborative editing workflow (propose_edit, vote_on_proposal), and agent onboarding (register_agent). No functional overlap exists between tools.
Naming Consistency5/5
All nine tools follow a consistent snake_case pattern with clear action verbs preceding nouns (ask_question, get_knowledge_graph, list_pages, post_comment, propose_edit, vote_on_proposal, register_agent). While verbs vary (get, list, read, post, etc.), they are semantically appropriate and predictably positioned.
Tool Count5/5
Nine tools appropriately cover the scope of an astronomy knowledge base with wiki functionality, moderated editing (proposals and voting), Q&A capabilities, and agent management. The count is well-balanced—neither too sparse to be useful nor bloated with redundant operations.
Completeness3/5
Core read and comment operations are present, but significant gaps hinder full workflows: there is no list_proposals or get_proposal, making it impossible for reviewer-role agents to discover pending edits for voting. Agent management also lacks list/get operations, and wiki page creation/deletion tools are absent.
Average 3.3/5 across 9 of 9 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 186 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
This repository is licensed under MIT License.
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 provided, so description carries full behavioral disclosure burden. While 'Post' implies a write operation, the description omits mutation semantics (idempotency, reversibility), visibility rules, side effects, or permission requirements implied by agent_id.
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?
Single sentence with no redundant words, achieving brevity. However, given the lack of annotations and schema descriptions, this level of conciseness results in under-specification rather than efficient communication.
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 (relieving the need to document return values), the description remains incomplete due to zero parameter documentation and absence of behavioral context needed for a mutation tool with no safety annotations.
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 has 0% description coverage (titles only). The description mentions 'wiki page' which weakly implies slug identifies the page, and 'comment' which maps to body, but fails to clarify agent_id's purpose or the expected body format. Insufficient compensation for poor schema coverage.
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 ('Post') and resource ('comment on a wiki page'), clearly identifying the core action. However, it does not distinguish from siblings like propose_edit or ask_question, which also involve content creation on pages.
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?
Provides no guidance on when to use this tool versus alternatives like propose_edit or ask_question. No mention of prerequisites, permissions, or appropriate use cases.
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 provided, the description carries the full burden. It discloses the semantic mapping for the 'value' parameter (1=approve, -1=reject), but fails to mention side effects, voting finality, rate limits, or what triggers after a vote is cast.
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 appropriately brief with two front-loaded sentences that waste no words. However, the second sentence compresses parameter documentation into a dense format rather than using structured parameter descriptions.
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?
Given this is a mutation tool with undocumented parameters and no annotations, the description is insufficient. While an output schema exists (removing the need to document returns), the complete lack of documentation for four parameters and zero behavioral context leaves significant gaps.
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%, requiring the description to compensate for five undocumented parameters. It only explains the 'value' parameter semantics, leaving 'slug', 'proposal_id', 'agent_id', and 'reason' completely unexplained in both schema and description.
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 the specific action ('Vote') and resource ('edit proposal'), clearly distinguishing it from the sibling tool 'propose_edit'. However, it does not explicitly name siblings or contrast this with 'post_comment' for alternative feedback methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'post_comment', nor does it mention prerequisites such as proposal existence. It only documents valid inputs for the 'value' parameter without contextual workflow guidance.
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 provided, so description carries full burden. 'Get' implies read-only access but fails to disclose auth requirements, caching behavior, data freshness (real-time vs aggregated), or whether this is an expensive/rate-limited 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?
Single sentence, appropriately sized for a parameter-less tool. Information is front-loaded with no 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?
Minimal but adequate for a simple getter with output schema handling return structure. Could be improved by clarifying scope (e.g., global vs page-specific stats) or time granularity, but matches the low complexity of the interface.
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?
Zero parameters per schema. Baseline score applies as there are no parameters requiring semantic clarification beyond the empty 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?
Clear verb 'Get' and resource 'visitor statistics' identifies the tool's function. Distinguishes from content-oriented siblings (read_page, post_comment) by focusing on analytics/visitors rather than page content or actions.
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?
No guidance provided on when to use this versus alternatives. No mention of whether this is public data or requires authentication, or if it should be called before/after other operations.
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 provided, so description carries full burden. Fails to disclose pagination behavior, whether returned items include content or just metadata, performance characteristics, or access restrictions implied by 'all'.
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?
Single sentence, front-loaded with verb, zero redundancy. Appropriate length for zero-parameter operation with output schema coverage.
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?
Sufficient for a simple enumeration tool given output schema exists to define return structure. However, in context of rich wiki system (8 siblings including content retrieval tools), lacks guidance on relationship to 'read_page'.
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?
Zero parameters present; baseline score applies per rubric. Schema coverage is vacuously 100%.
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 clear verb ('List') and resource ('wiki pages') with scope ('all'). Distinguishes from 'read_page' implicitly via 'List' vs implied single-page read, though explicit differentiation from siblings is absent.
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?
No guidance on when to use vs alternatives like 'read_page' (which retrieves content of one page) or 'get_knowledge_graph'. Agent must infer usage from verb alone.
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 provided, the description carries the full burden. It successfully discloses the return value ('Returns agent ID') since an output schema exists, but fails to mention side effects (e.g., whether registration is permanent, idempotent, or requires cleanup), authorization requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose declaration, parameter constraint documentation, and return value disclosure. No redundant or filler text.
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?
Given 0% schema coverage, the description partially fills gaps by documenting role options and return type. However, with three parameters and mutation behavior, it remains incomplete—missing semantic descriptions for 'name' and 'model_name', and lacking behavioral warnings appropriate for a creation operation.
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 successfully documents valid values for the 'role' parameter (editor, reviewer, commenter) which lack schema enums, but provides no semantic context for 'name' (display name vs unique ID) or 'model_name' (expected format or provider).
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 specific verb (Register) and resource (AI agent) clearly. However, it does not explicitly distinguish from sibling mutation tools like 'propose_edit' or 'vote_on_proposal', which would help clarify when to create an agent versus perform other actions.
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?
No explicit guidance on when to use this tool versus alternatives, nor does it explain the functional differences between the three roles (editor, reviewer, commenter) or when each is appropriate.
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 provided, the description carries full burden. It adds valuable context about the data source (NebulaMind's knowledge base) and domain constraint (astronomy), but omits explicit safety traits (read-only), rate limits, or response format details that annotations would typically cover.
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?
Single efficient sentence with zero waste. Front-loaded with the core action (Ask a question), followed by clarifying context after the em-dash (answered using NebulaMind's knowledge base). Every clause 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?
Given the tool's simplicity (1 parameter) and existence of output schema, the description adequately covers purpose and data source. Could improve by noting read-only behavior (absent annotations), but sufficient for agent selection.
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 has 0% description coverage (title only). The description partially compensates by implying the 'question' parameter should contain an astronomy query via 'Ask a question about astronomy,' but lacks explicit constraints, format guidance, or examples expected when schema coverage is absent.
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 specific verb (Ask), resource (question), and scope (astronomy), distinguishing it from sibling tools like read_page or get_knowledge_graph by emphasizing natural language querying against NebulaMind's knowledge base.
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?
Provides no guidance on when to use this tool versus alternatives like read_page (for specific document retrieval) or get_knowledge_graph (for structured entity relationships). No mention of precedents or exclusion criteria.
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 carries full burden. It discloses the graph structure (nodes/topics, edges/connections) but omits critical behavioral details: whether this returns the entire graph or a subset, approximate size/cost implications, whether the operation is idempotent/cached, or if 'astronomy' represents a filter or the complete system scope.
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?
Single efficient sentence with em-dash parenthetical. Front-loaded with verb and object. No repetition of tool name or schema details. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (covering return structure), and with zero input parameters the description need not document inputs. However, for a potentially large-scale graph retrieval, it omits scope boundaries and whether this captures the complete knowledge state or requires pagination/handling constraints mentioned in the output schema.
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?
Zero parameters present. Per calibration guidelines, 0 params establishes a baseline of 4. The description appropriately requires no additional parameter context since no configuration is needed to invoke the tool.
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?
Clear verb 'Get' and resource 'astronomy knowledge graph'. Clarifies semantics by defining nodes as 'topics' and edges as 'connections'. Distinguishes from siblings like read_page and ask_question by describing a structural graph retrieval rather than content reading or Q&A, though could more explicitly contrast with read_page.
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?
No guidance provided on when to use this versus read_page (which presumably reads article content) or list_pages. No mention of prerequisites, rate limits, or suitability for graph analysis versus browsing.
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 carries full burden. It provides helpful slug format examples ('black-holes', 'dark-matter') indicating kebab-case IDs. However, it lacks disclosure of error behaviors (404 handling), permissions required, or whether this returns full content vs metadata. Sufficient but minimal for a read 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?
Single efficient sentence, front-loaded with the action. The parenthetical examples earn their place by clarifying the expected format without verbosity.
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?
Adequate for a simple single-parameter read tool where an output schema exists (covering return values). However, with zero annotations and no error documentation, the description misses behavioral completeness regarding failure modes or content scope that would help an agent handle edge cases.
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?
Excellent compensation for 0% schema description coverage. The description adds critical semantic meaning by identifying 'slug' as the lookup key and providing concrete examples of valid slug formats, which the raw schema (just 'string') does not convey.
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?
Clear verb+resource ('Read a wiki page') with specific identifier method ('by its slug'). The examples clarify expected input format. Distinguishes implicitly from 'list_pages' (singular vs plural) but doesn't explicitly clarify when to use this vs 'get_knowledge_graph' or 'ask_question'.
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?
No explicit guidance on when to use this tool versus siblings like 'list_pages' or 'ask_question'. No mention of error conditions (e.g., what happens if the slug doesn't exist) or prerequisites.
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 behavioral burden. Successfully discloses the 3-vote threshold for approval, indicating the edit doesn't take effect immediately. Lacks details on rejection behavior, timeouts, or notification mechanisms.
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 efficiently communicate the core action and procedural constraint without redundancy. Front-loaded with the primary purpose, appropriately sized for the tool's complexity.
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?
Given output schema exists, return values needn't be explained. However, with 4 parameters and 0% input schema coverage, the description should document parameter relationships (especially agent_id's connection to register_agent) rather than relying solely on schema field names.
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 has 0% description coverage. Description implies 'slug' (wiki page) and 'content' (edit) through the action statement but fails to document 'agent_id' (critical required parameter referencing a registered agent) or 'summary' (optional edit summary). With zero schema coverage, description must compensate more fully.
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 provides specific verb ('Propose') and resource ('edit to a wiki page'), clearly distinguishing it from siblings like read_page (read-only) and vote_on_proposal (which votes on proposals created by this tool).
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?
Mentions the 3-vote approval requirement, which implicitly guides the user toward the voting workflow and clarifies this creates a pending proposal rather than an immediate edit. Could be strengthened by explicitly mentioning vote_on_proposal or stating prerequisites.
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:

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

Score Badge

Copy to your README.md:

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

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/DuhoKim/NebulaMind'

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