CoderSwap MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of the workflow: project management (create, list, get stats), job monitoring (get job status), ingestion (research_ingest, log_session_note), and search operations (search, validate_search). There is no overlap in functionality that would cause misselection.
Naming Consistency5/5
All tools follow a consistent 'coderswap_verb_noun' pattern throughout, using snake_case uniformly. The verbs are descriptive and appropriate for each action (e.g., create_project, get_job_status, list_projects), making the naming highly predictable and readable.
Tool Count5/5
With 8 tools, the count is well-scoped for a vector search project management server. Each tool earns its place by covering essential operations: project lifecycle (create, list, get stats), ingestion workflows (research_ingest, log_session_note), job monitoring, and search functionality (search, validate). This is neither too sparse nor bloated.
Completeness4/5
The tool set provides comprehensive coverage for core CoderSwap workflows, including project CRUD, ingestion, and search. A minor gap exists in the lack of update or delete operations for projects, which might limit full lifecycle management, but agents can likely work around this given the server's focus on ingestion and search.
Average 3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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?
With no annotations, the description carries full burden but only states it 'records' a summary, implying a write operation. It doesn't disclose behavioral traits like permissions needed, idempotency, rate limits, or what 'session continuity' entails operationally, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence, with no wasted words. However, it could be more structured by explicitly separating purpose from constraints or usage notes.
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 5 parameters with 0% schema coverage and no annotations, the description is incomplete—it doesn't explain parameters or behavioral details. The presence of an output schema mitigates this slightly, but overall, it's inadequate for a tool with multiple undocumented inputs.
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 but adds no parameter-specific information. It doesn't explain what 'project_id', 'summary_text', 'job_id', 'ingestion_metrics', or 'tags' mean or how they relate to the tool's purpose, failing to address the coverage gap.
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 states the action ('Record') and resource ('lightweight ingestion summary for session continuity'), specifying it's for 'non-DSL' contexts. However, it doesn't explicitly differentiate from sibling tools like 'coderswap_research_ingest' or 'coderswap_validate_search', which might involve similar concepts.
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 minimal guidance by mentioning 'session continuity' and 'non-DSL', but lacks explicit when-to-use rules, prerequisites, or alternatives compared to siblings. No clear context for choosing this over other tools is given.
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 states the tool retrieves statistics and information, implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what happens if the project doesn't exist. This leaves significant gaps for safe and effective use.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, though it could be slightly more structured (e.g., by listing key statistics) to enhance clarity without sacrificing brevity.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks details on behavioral traits and usage context, leaving room for improvement in supporting the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter is for identifying a project but doesn't specify format (e.g., numeric ID, string), constraints, or examples. This adds minimal meaning beyond the schema's basic type and requirement, meeting the baseline for low coverage without fully addressing gaps.
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 states the verb ('Get') and resource ('statistics and information about a specific project'), making the purpose understandable. It distinguishes from siblings like 'coderswap_list_projects' by focusing on a single project rather than listing multiple. However, it doesn't specify what types of statistics or information are included, keeping it from being fully specific.
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. It doesn't mention prerequisites (e.g., needing a valid project ID), exclusions, or comparisons to siblings like 'coderswap_get_job_status' or 'coderswap_search'. The agent must infer usage from the tool name and context alone.
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 of behavioral disclosure. It mentions the tool's actions (e.g., 'web crawling, chunking, embedding, and optional DSL generation') but doesn't specify critical details like required permissions, rate limits, whether it's a long-running job (implied by sibling coderswap_get_job_status), or what happens on submission. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Submit research summary and URLs') and lists the processing steps without unnecessary words. Every part earns its place, making it highly concise and well-structured for quick comprehension.
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 complexity (6 parameters, no annotations) and the presence of an output schema (which reduces the need to describe return values), the description is moderately complete. It covers the high-level purpose but lacks details on parameter usage, behavioral traits, and differentiation from siblings, making it adequate but with clear gaps that hinder full understanding.
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 mentions 'research summary and URLs' and 'optional DSL generation,' which loosely maps to some parameters (research_summary, urls, generate_dsl) but doesn't explain the purpose or usage of project_id, intent, or depth. This partial coverage fails to fully clarify the semantics, especially for key required parameters like project_id.
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 states the tool's purpose with specific verbs ('submit research summary and URLs') and resources ('for web crawling, chunking, embedding, and optional DSL generation'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like coderswap_search or coderswap_validate_search, which might also involve research or URL processing, keeping it from a perfect score.
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, such as coderswap_search or coderswap_validate_search, nor does it mention prerequisites like needing an existing project. It implies usage for research ingestion but lacks explicit context or exclusions, leaving the agent with minimal direction.
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 burden for behavioral disclosure. It mentions 'DSL-powered ranking' which hints at ranking behavior, but doesn't explain what 'hybrid search' entails, whether it's read-only or has side effects, authentication requirements, rate limits, or what the output contains. This leaves significant gaps for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool description and front-loads the essential information about what the tool does.
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 that there's an output schema (which reduces the need to describe return values), but with 4 parameters having 0% schema coverage and no annotations, the description is incomplete. It covers the basic purpose but lacks crucial details about parameter meanings, behavioral characteristics, and usage context that would make it fully adequate for this search tool.
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 for all 4 parameters, the description provides no information about parameter meanings beyond what's in the schema. It doesn't explain what 'project_id' refers to, what format 'query' should take, what 'top_k' controls, or what 'snippet_length' affects in the results. The description fails to compensate for the complete lack of schema descriptions.
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 states the action ('execute a hybrid search query') and target resource ('against a CoderSwap project'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like coderswap_validate_search or coderswap_research_ingest, which might have overlapping search-related functionality.
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. There's no mention of prerequisites, appropriate contexts, or comparisons to sibling tools like coderswap_validate_search (which might be for validation) or coderswap_research_ingest (which might involve data ingestion).
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 burden for behavioral disclosure. It states the tool creates something but doesn't mention permissions required, whether this is idempotent, what happens on duplicate names, rate limits, or what the output contains. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 creates a project (a mutation operation) with no annotations and an output schema exists, the description is minimally complete. It identifies the action and resource but lacks details on behavior, parameters, or context. The output schema may cover return values, but the description doesn't address permissions, errors, or integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the schema provides. With 0% schema description coverage, the schema documents the parameters (name, description) but without descriptions. The description doesn't explain what 'name' or 'description' represent in context, their constraints, or examples. However, with only 2 parameters and a simple structure, the baseline is 3 as the schema provides basic typing.
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 states the action ('Create') and resource ('new vector search project in CoderSwap'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'coderswap_list_projects' or 'coderswap_research_ingest' in terms of when to use creation versus other operations.
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. It doesn't mention prerequisites, when creation is appropriate versus listing existing projects, or any context about the project lifecycle. Users must infer usage from the tool name alone.
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 of behavioral disclosure. It states this is a 'check' operation, which implies read-only behavior, but doesn't confirm if it's safe, idempotent, or has side effects. It lacks details on authentication needs, rate limits, error conditions, or what the status check entails (e.g., polling, immediate response). The description adds minimal behavioral context 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?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy with the tool name and title, and every part of the sentence contributes directly to understanding the tool's function. No fluff or wasted space is present.
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 low complexity (1 parameter) and the presence of an output schema (which likely defines status values), the description is minimally adequate. However, with no annotations and incomplete parameter semantics, it leaves gaps in understanding behavioral traits and usage context. It meets basic needs but doesn't fully compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description doesn't mention the 'job_id' parameter at all, failing to explain what it is, where to get it, or its format. However, with only one parameter, the baseline is higher; the tool's purpose inherently implies a job identifier is needed, but explicit parameter guidance is missing.
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 states the verb ('Check') and resource ('status of a research ingestion job'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'coderswap_research_ingest' (which likely creates jobs) and 'coderswap_get_project_stats' (which focuses on projects rather than jobs). However, it doesn't specify what a 'research ingestion job' entails or what status values might be returned.
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. It doesn't mention prerequisites (e.g., needing a job ID from a previous operation), exclusions, or relationships to siblings like 'coderswap_research_ingest' (which might create the jobs being checked). Usage is implied only through the tool name and description context.
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 mentions 'non-DSL quality check', which hints this might be a read-only or diagnostic operation, but it doesn't clarify if it's destructive, requires specific permissions, has rate limits, or what the validation entails. For a tool with zero annotation coverage, this is a significant gap in 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 highly concise and front-loaded in a single sentence: 'Run validation queries to test search quality and coverage (non-DSL quality check)'. Every word earns its place by conveying purpose and scope without redundancy, making it efficient for an agent to parse.
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 has an output schema (which reduces the need to describe return values), 3 parameters with 0% schema coverage, and no annotations, the description is moderately complete. It covers the core purpose and hints at behavior, but lacks details on usage guidelines, parameter semantics, and behavioral traits, leaving gaps that could hinder effective tool invocation.
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 for undocumented parameters. It adds some meaning by implying 'validation queries' relate to 'test_queries' and 'search quality' relates to 'project_id', but it doesn't explain what 'run_full_suite' does or provide details on query formats or project context. With 3 parameters and low coverage, the description offers marginal value beyond the bare 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 clearly states the tool's purpose: 'Run validation queries to test search quality and coverage' with the specific verb 'run' and resource 'validation queries', and it distinguishes this from regular search operations by specifying it's a 'non-DSL quality check'. However, it doesn't explicitly differentiate from sibling tools like coderswap_search or coderswap_research_ingest, which keeps it from a perfect score.
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 minimal guidance: it implies this tool is for testing rather than production use through 'test search quality', but it doesn't specify when to use this versus alternatives like coderswap_search or coderswap_research_ingest, nor does it mention prerequisites or exclusions. This leaves the agent with insufficient context for optimal tool 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 of behavioral disclosure. It states the tool lists projects 'available to your API key,' hinting at authentication and scope, but lacks details on pagination, rate limits, error handling, or output format. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('List all CoderSwap projects') and includes essential context ('available to your API key'). Every part of the sentence earns its place, making it highly concise and well-structured.
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 (0 parameters, output schema exists), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., pagination, error handling) that aren't provided by annotations. The output schema should handle return values, so the description doesn't need to explain those. However, for a list tool with no annotations, more context on behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied for tools with zero parameters, as there's nothing to compensate for, and the description doesn't introduce confusion.
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 states the verb ('List') and resource ('CoderSwap projects'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'coderswap_search' or 'coderswap_get_project_stats', which might also retrieve project information in different ways. The description is specific about scope ('all...available to your API key') but lacks sibling distinction.
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. It doesn't mention sibling tools like 'coderswap_search' (which might filter projects) or 'coderswap_get_project_stats' (which might provide detailed metrics), leaving the agent without context for tool selection. The only implied usage is for listing all accessible projects, but no exclusions or alternatives are specified.
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:

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

Score Badge

Copy to your README.md:

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

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/njlnaet/mcp-server'

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