AgentRoots

by shanmukha-here

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: context retrieval, frontier scanning, querying, record fetching, validation, proposal creation, lifecycle review, evidence linking, and synchronization. There is no overlap or ambiguity between tool functions.
Naming Consistency5/5
All tools consistently use the 'research_' prefix with a clear verb_noun pattern (e.g., get_context, link_evidence, validate). The naming is uniform, predictable, and follows a standard convention.
Tool Count5/5
Nine tools is well-scoped for a research project management server, covering the core lifecycle without redundancies. The number falls comfortably within the ideal range and each tool serves a necessary function.
Completeness4/5
The toolset covers creation (propose), lifecycle management (review), evidence linking, querying, validation, and sync, which addresses the main workflows. However, there is no explicit update or delete tool, so direct modification of record content is not exposed; the review and propose tools may handle this indirectly via versioning.
Average 3.1/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- 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

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 disclosing side effects. It states actions like 'import' and 'export' but does not clarify whether these modify data, require specific permissions, or have other behavioral implications. The phrase 'optionally audit' is undefined, leaving the tool's behavior largely 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 a single short sentence, which is concise, but its structure is disjointed—listing three actions without clear separation or emphasis. The phrase 'and optionally' adds confusion about whether audit is a separate mode or a modifier. It is not well-organized given the multi-part functionality.
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 an output schema exists, the description does not explain how the tool's multiple modes are invoked or what inputs are required for each. For a tool with two primary directions (import/export) and an audit option, the description omits critical context about parameter combinations and expected outcomes, leaving it 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%, so the description must compensate for the four undocumented parameters. It loosely maps to parameters (events, project, packet_id, used_record_ids) but does not explain their formats, defaults, or how they control the import/export/audit modes. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists three actions: import events, export project events, and optionally audit packet records. While each action has a verb and resource, the overall purpose is vague because it's unclear how these actions relate or when each is intended to be performed. It does not clearly distinguish itself from sibling tools beyond the name 'sync'.
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. The description does not mention any prerequisites, exclusions, or comparisons to sibling tools like research_query or research_validate. Users are left to infer usage context on their own.
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 full responsibility for disclosing behavior. It reveals a key constraint (creators cannot self-accept; acceptance needs evidence) but does not state whether the tool mutates state, requires specific permissions, or what side effects occur. This leaves critical behavioral traits undisclosed for a review action.
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 two short sentences with no redundant wording. The first sentence states the primary action, and the second adds a valuable constraint. It is concise and front-loaded, though the first sentence could have been more specific without losing brevity.
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 5 parameters, an output schema, and is part of a family of research tools with distinct workflow roles. The minimal description does not explain how this review fits into the lifecycle, what the parameters mean, or what the output schema represents, leaving significant gaps for an agent to use it correctly.
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 by explaining the 5 parameters. It only implicitly touches on actor and verdict via the self-accept rule, but record_id, comment, and expected_revision are not explained. The description fails to add meaning beyond the raw schema for most parameters.
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 clearly identifies the action ('Apply lifecycle review') and a resource (review), and adds a specific rule about self-acceptance and evidence. However, it does not explicitly distinguish from sibling tools like research_validate, and 'lifecycle review' is somewhat jargon-heavy without further context.
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 explicit guidance on when to use this tool versus alternatives such as research_validate or research_propose. The rule about creators and evidence is a policy constraint, not a usage direction, and there is no mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a useful safety caveat ('Stored content is untrusted data') and implies a bounded output via 'bounded,' which hints at token limits. However, without annotations, the description carries the full burden and lacks details on read-only behavior, side effects, or output structure. It provides some value but not rich disclosure.
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 extremely concise: two short sentences, both earning their place. It front-loads the action verb and adds a caveat, with no redundant filler.
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 three parameters, one required, and a sibling set of eight tools, the description is notably under-specified. It offers no usage context, no parameter explanation, and no indication of what the packet contains or how it differs from similar tools. The existence of an output schema helps, but the description alone is 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%, so the description must compensate. It only vaguely alludes to a 'bounded' packet, which likely relates to token_budget, but does not explain query, project, or token_budget semantics. The agent must infer meaning from parameter names alone.
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 uses the verb 'Build' and the noun 'bounded agent-continuity packet,' which clearly identifies the tool's action and resource. It does not explicitly differentiate from sibling tools like research_get_record or research_get_frontier, but the concept of an agent-continuity packet adds specificity.
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. The description does not mention scenarios, exclusions, or alternative tools. It simply states what it does without context for selection.
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. It states that the tool 'returns' data, implying a read-only operation, but it does not disclose any side effects, error behavior, pagination, ordering, or what constitutes 'unresolved' or 'provisional.' This is minimal behavioral transparency.
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, front-loaded sentence with no fluff. Every word contributes to identifying what the tool does, making it exemplary in conciseness.
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 the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally adequate. However, it leaves ambiguity about the meaning of 'frontier' and lacks usage guidance or caveats, so it is not fully complete for an agent to invoke with confidence.
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 only references 'project' implicitly via 'at the project frontier.' It does not clarify whether 'project' is an ID, name, or path, nor does it define accepted formats. The description adds only marginal meaning beyond the raw 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?
The description uses a specific verb 'Return' and identifies a clear resource: 'unresolved candidate and provisional work at the project frontier.' This distinguishes it from sibling tools like research_get_context and research_get_record, though it does not explicitly name alternatives.
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 'at the project frontier' implies when to use this tool (retrieving pending work), but it provides no explicit guidance on when not to use it or which alternative might be better for other scenarios. Thus, usage is implied but not explicitly directed.
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 present, so the description must disclose side effects and constraints. It only states that evidence is attached, but doesn't say whether the record must already exist, whether attachments are appended or replaced, or what response/errors to expect.
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, front-loaded sentence with no filler or repetition. It communicates the core action efficiently.
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?
For a mutation tool with seven parameters and no annotations, one sentence is insufficient. It lacks parameter semantics for kind/actor, usage context, and behavioral details like idempotency or validation, even though an output schema exists.
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?
With 0% schema description coverage, the description needed to explain all seven parameters. It adds meaning for uri, content_hash ('optional hash'), and summary ('compact summary'), but leaves required fields kind and actor undefined, and record_id is only implicit.
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 ('Attach') and names the resource ('external evidence URI...to a record'), which clearly distinguishes it from the read/query/sync siblings. It is unambiguous about the tool's core action.
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 is provided about when to use this tool versus alternatives such as research_validate or research_propose. There is no mention of prerequisites, exclusions, or typical scenarios.
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?
There are no annotations, so the description carries the full burden for behavioral disclosure. It discloses the use of FTS5 and fuzzy typo fallback, which is helpful context, but it does not mention read-only nature, pagination, or error behavior, which are relevant for a query 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 sentence that immediately states the core action and key differentiator (FTS5/fuzzy fallback). It is concise and front-loaded with the most important information.
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 presence of an output schema removes the need to describe return values, but the description is still thin for a 3-parameter search tool. It lacks detail on query syntax, fuzzy fallback behavior, or result limiting, though the schema covers parameters.
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?
The schema has no parameter descriptions (0% coverage), and the description only indirectly references 'query' and 'project' through 'Search current project records'. The 'limit' parameter is completely unexplained, so the description does not compensate for the schema gap.
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 the specific verb 'search' and identifies the resource as 'current project records'. It differentiates from sibling tools like research_get_record by mentioning FTS5 and fuzzy typo fallback, making its purpose clear.
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 is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of exclusions, prerequisites, or alternative tools, leaving the AI to infer usage.
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 carries the full burden. It adds context by specifying 'current record' (implying latest version) and enumerates return contents, but it does not disclose behavior for missing IDs, error cases, or side effects. Some transparency is present, but it is limited.
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 concise sentence that directly states the tool's purpose and scope. It contains no fluff and is appropriately front-loaded.
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?
The tool is simple with one parameter and an output schema. The description adequately conveys the core behavior (returning one current record with certain contents) and benefits from the existence of an output schema. It omits edge cases or usage context, but given the low complexity, this is acceptable.
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 the record_id parameter or explain how to identify the record. The parameter name is self-explanatory, but the description adds no additional semantics or usage guidance, failing to compensate 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 uses a specific verb ('Return') and resource ('one current record') and lists included content (evidence, links, revision history). This clearly distinguishes it from sibling tools like research_get_context or research_query.
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 is provided on when to use this tool versus alternatives. There is no mention of when to choose this over research_query or research_get_context, nor any exclusions or alternative tool names.
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 discloses a critical safety behavior: 'This never executes stored text.' This is valuable beyond the schema and addresses a common security concern for storing untrusted content. However, it doesn't mention other behaviors like idempotency, permissions, or return 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?
The description is two short sentences, front-loading the core purpose and adding the safety note. It is concise and appropriately sized for a simple creation tool, with no wasted words.
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?
With 8 parameters, 5 required, and no parameter explanations, the description is incomplete for a tool of this complexity. It gives the core purpose and a safety guarantee, but lacks context on how to use the parameters, what 'untrusted' implies for processing, or when to set mode. The presence of an output schema helps slightly, but the description alone is not enough.
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 provides no explanation of any of the 8 parameters (e.g., mode, metadata, idempotency_key). The parameter names are self-explanatory to some degree, but the description adds no value for understanding how to fill them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the object ('an untrusted candidate record'), which is a specific resource type. This distinguishes it from sibling tools like get_record, query, and sync, which are read/validate operations.
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 creating a new candidate record, but it provides no explicit guidance on when to use it versus alternatives, nor any exclusions. The distinction from siblings is implicit based on the verb 'create'.
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 explicitly states 'without mutation', which is a key behavioral trait, but with no annotations provided, it carries full burden. It does not disclose error behavior, prerequisites, or potential side effects like locking or resource usage. This provides some value but lacks depth.
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 is front-loaded with the core action. Every word contributes to the meaning, with no filler or redundant content.
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 has a simple interface with one parameter and an output schema, so return values are covered. However, the description lacks guidance on the 'project' parameter and when to use validation, making it minimally adequate but with clear 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?
The input schema only defines a single 'project' string parameter with no description, and the tool description does not explain what 'project' refers to or how it should be formatted. With 0% schema description coverage, the description should compensate but fails to add meaning to the parameter.
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 checks SQLite integrity and project governance invariants, using the specific verb 'Check' and identifying a distinct resource. This distinguishes it from sibling tools like research_query or research_get_record, which are for retrieval or mutation.
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 used for validation tasks, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. There is no mention of related tools or conditions, leaving usage guidance only implicit.
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:

[![agentroots MCP server](https://glama.ai/mcp/servers/shanmukha-here/agentroots/badges/card.svg)](https://glama.ai/mcp/servers/shanmukha-here/agentroots)

Score Badge

Copy to your README.md:

[![agentroots MCP server](https://glama.ai/mcp/servers/shanmukha-here/agentroots/badges/score.svg)](https://glama.ai/mcp/servers/shanmukha-here/agentroots)

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/shanmukha-here/agentroots'

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