Kylas CRM MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: create_lead, get_lead_field_instructions, search_leads, and search_idle_leads are clearly differentiated. However, the four lookup tools (lookup_pipelines, lookup_products, lookup_users, get_pipeline_stages) could cause confusion as they all serve similar 'lookup' functions but for different entities, requiring careful reading of descriptions to distinguish them.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_lead, lookup_pipelines, search_leads) with snake_case throughout. The only minor deviation is get_lead_field_instructions, which uses 'get' instead of 'lookup' or 'search', but it still fits the verb_noun style and is understandable.
Tool Count5/5
With 8 tools, the count is well-scoped for a CRM server, covering core operations like lead creation, field instructions, searching, and lookups for pipelines, products, and users. Each tool serves a specific purpose without bloat, aligning with typical CRM workflows.
Completeness4/5
The toolset provides strong coverage for lead management, including creation, searching (with filters and idle leads), and necessary lookups. A minor gap is the lack of update or delete operations for leads, which might limit full CRUD lifecycle management, but agents can still handle core tasks effectively with the available tools.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context beyond the input schema. It discloses pagination behavior ('fetch all pages and return every user in one response'), caps ('cap 500'), and interaction patterns ('if multiple, ask which one'). It also explains how parameters interact ('Ignored when return_all=True').
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 appropriately sized but not optimally structured. It starts with a clear purpose statement, but then mixes parameter explanations with usage guidance in bullet points. Some redundancy exists (query explanation appears twice). While all content is valuable, the organization could be more front-loaded and streamlined.
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 4 parameters with 0% schema coverage and no annotations, the description provides comprehensive parameter semantics and behavioral context. The existence of an output schema means return values don't need explanation. The description covers search patterns, pagination, caps, and downstream usage, making it largely complete for this lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 4 parameters in detail. It provides syntax examples ('firstName:last', 'name:Last'), default behaviors ('leave default to list all'), constraints ('max 50', 'cap 500'), and parameter interactions ('Ignored when return_all=True'). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Look up users by name, or list all users in the system.' It specifies the verb ('look up') and resource ('users'), and distinguishes between search and list operations. However, it doesn't explicitly differentiate from sibling tools like 'search_leads' beyond implied scope differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use specific features: 'Use return_all=True... to fetch all users' and 'For name search: query in field:value form... If one user is found, use that ID in search_leads; if multiple, ask which one.' It gives practical guidance on parameter combinations and downstream actions, though it doesn't explicitly state when NOT to use this tool versus alternatives.
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?
With no annotations provided, the description carries full burden and adds significant behavioral context beyond the basic function. It discloses that the tool returns specific data (pipeline name, stages with id/name/forecastingType), explains how to use the output with search_leads, and provides guidance on handling ambiguous user queries ('open leads' or 'closed leads'). It doesn't mention error handling or rate limits, but covers key operational aspects.
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 efficiently structured with four focused sentences that each serve distinct purposes: stating the core function, providing usage prerequisites, describing the return format, and explaining downstream applications. It's appropriately sized for the tool's complexity, though the final sentence about pipeline_id could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is remarkably complete. It covers purpose, prerequisites, return data structure, integration with other tools (lookup_pipelines, search_leads), and edge case handling for ambiguous queries. No significant gaps remain for agent understanding.
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 description adds meaningful context for the single parameter: 'pipeline_id: The pipeline ID (from lookup_pipelines).' This clarifies the parameter's source and relationship to another tool. With 0% schema description coverage and only one parameter, the description fully compensates by explaining what the parameter represents and where it comes from.
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: 'Get stages for a pipeline' with specific details about what it returns (pipeline name, list of stages with id, name, forecastingType). It distinguishes from siblings like lookup_pipelines by focusing on stages rather than pipelines themselves. However, it doesn't explicitly contrast with all siblings like search_leads or create_lead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this only after the user has confirmed which pipeline to use (from lookup_pipelines). Do not call before pipeline confirmation.' It names the prerequisite tool (lookup_pipelines) and specifies when NOT to use it, offering clear alternatives for related tasks like using stage IDs in search_leads.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It describes important constraints (max page size of 100, default values, field-specific value formats), lookup requirements, and data validation rules. The only minor gap is not explicitly mentioning pagination behavior or rate limits.
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 information-dense but somewhat lengthy and could be better structured. While every sentence provides value, the information about operators by type at the end might be better placed earlier or in a more scannable format. It's comprehensive but not optimally organized for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, but with output schema), the description is remarkably complete. It covers prerequisites, parameter usage, field-specific rules, lookups, defaults, constraints, and operator guidance. With an output schema present, it appropriately doesn't explain return values, focusing instead on usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter semantics. It explains the complex 'filters' object structure in detail, documents all four parameters (filters, page, size, sort) with their purposes, constraints, defaults, and special handling rules for different field types. This goes well beyond what the bare schema provides.
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 as 'Search/filter leads' with a specific verb and resource. It distinguishes from siblings like 'search_idle_leads' by not specifying a particular lead type, but doesn't explicitly contrast with other search tools. The purpose is clear but sibling differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidance with explicit prerequisites (call get_lead_field_instructions first), field restrictions (only [FILTERABLE] fields), and references to sibling tools for lookups (lookup_users, lookup_products, lookup_pipelines, get_pipeline_stages). It clearly indicates when to use alternative tools for preparatory steps.
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?
With no annotations provided, the description carries full burden and adds substantial behavioral context: it explains the field mapping logic (standard vs. custom fields), data format requirements (e.g., picklists use Option ID), and server behavior (field ID resolution). However, it doesn't mention authentication needs, rate limits, or error handling.
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 sized and front-loaded with the core purpose, followed by structured guidelines. Every sentence adds necessary information, though the bullet-point formatting could be slightly more streamlined for readability.
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 complexity (1 parameter with 0% schema coverage, nested objects, no annotations, but with output schema), the description is largely complete: it covers purpose, prerequisites, parameter details, and behavioral nuances. The output schema existence means return values needn't be explained, but authentication or error details are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for the single parameter 'field_values', including key-value mapping rules, distinction between standard and custom fields, nested structure guidance, and examples for emails/phones/picklists—adding significant value beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a lead in Kylas CRM') and resource ('lead'), distinguishing it from sibling tools like search_leads or get_lead_field_instructions. It specifies the unique approach of using only user-requested fields rather than a static list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'You MUST call get_lead_field_instructions FIRST to get valid API names and Field IDs.' This directly names the alternative tool and specifies when to use it as a prerequisite, with clear sequencing for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It explains the dual-date logic (updatedAt AND latestActivityCreatedAt), clarifies the 'effective last activity' concept, and provides important behavioral details like default values, maximum page size, and the 0-based pagination system. It doesn't mention rate limits or authentication requirements, but covers core operational behavior thoroughly.
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 efficiently structured with the core purpose first, followed by behavioral details, then parameter explanations. Every sentence adds value - no redundant information. The parameter explanations are terse but complete, using minimal words to convey maximum information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, dual-date logic, pagination) and the presence of an output schema (which means return values don't need explanation), the description is complete. It covers all necessary operational context, parameter semantics, and behavioral details that an agent would need to correctly invoke this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 5 parameters. Each parameter gets specific guidance: 'days' explains the threshold logic with an example, 'time_zone' specifies IANA format with defaults, 'page' clarifies 0-based indexing, 'size' states maximum limit, and 'sort' provides format examples. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for idle/stagnant leads' with specific criteria about activity thresholds. It distinguishes from sibling 'search_leads' by focusing specifically on inactive leads rather than general lead searching, making the differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (searching for leads with no activity for a specified number of days). It doesn't explicitly mention when NOT to use it or name specific alternatives, though the sibling list includes 'search_leads' which would presumably be for general lead searching.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's purpose and output format ('cheat sheet with API names, Field IDs, and Picklist Option IDs'), though it doesn't mention potential limitations like rate limits, authentication needs, or error conditions. The description is helpful but could be more comprehensive about operational constraints.
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 efficiently structured into three sentences that each add clear value: stating the purpose, providing usage guidance, and explaining the output's practical use. There is no wasted text, and key information is 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.
Completeness5/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, no annotations, but with an output schema), the description is complete. It explains what the tool does, when to use it, and what the output contains, which is sufficient for an AI agent to understand and invoke it correctly without needing to detail return values (handled by 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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without redundant parameter details, earning a high baseline score for this context.
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 specific action ('Get all lead fields'), resource ('for the current tenant'), and scope ('all lead fields'). It explicitly distinguishes this tool from its sibling 'create_lead' by explaining the relationship between them, making it easy to understand what this tool does uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('CALL THIS FIRST before creating a lead') and why ('to build field_values for create_lead'). It also clarifies when not to use alternatives ('do not use static fields'), giving clear context for tool selection versus sibling tools like 'create_lead'.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns pipelines (id and name), requires user confirmation even for single results, and outlines a multi-step workflow. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose and usage guidelines. It uses bullet points for clarity but includes some redundancy (e.g., repeating parameter details in a list). Every sentence adds value, though it could be slightly more concise by integrating the parameter explanations more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multi-step workflow, 4 parameters with 0% schema coverage) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, behavioral workflow, and parameter semantics thoroughly, leaving no critical gaps for agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all four parameters: 'query' (search string with syntax examples), 'entity_type' (default and purpose), 'page' (0-based), and 'size' (max and default). This adds significant value beyond the bare schema, fully documenting parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up pipelines by name (for leads).' It specifies the verb ('look up'), resource ('pipelines'), and context ('for leads'), distinguishing it from sibling tools like get_pipeline_stages or search_leads. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use when the user asks for leads by stage (e.g. open/closed/won/lost) but does not specify which pipeline.' It also specifies sequencing ('Call this first; do NOT call get_pipeline_stages until after the user confirms the pipeline') and alternatives, making it highly actionable for an agent.
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?
With no annotations provided, the description carries the full burden. It effectively describes the tool's behavior: it's a search operation (implied read-only), explains how to handle different result scenarios (single vs. multiple matches), and provides pagination defaults. It doesn't mention rate limits or authentication requirements, but covers core behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then usage guidelines, then parameter details. Every sentence adds value, though the parameter explanations could be slightly more concise. The bullet points for result handling are effective for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (mentioned in context signals), the description appropriately focuses on purpose, usage, and parameters rather than return values. It provides complete guidance for how to use this tool effectively in the workflow, with clear parameter explanations and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three parameters. It provides clear semantics for 'query' (search string format with examples), 'page' (0-based with default), and 'size' (max 50 with default). The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Look up') and resource ('products by name'), and distinguishes it from siblings by specifying its role in the workflow ('Use this BEFORE filtering leads by product'). It's specific about the resource type (products) and operation (lookup by name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Use this BEFORE filtering leads by product when the user gives a product name') and provides detailed workflow guidance including what to do with single vs. multiple results. It clearly positions this as a prerequisite step for search_leads.
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 MCP server](https://glama.ai/mcp/servers/akshaykylas94/MCP/badges/card.svg)](https://glama.ai/mcp/servers/akshaykylas94/MCP)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/akshaykylas94/MCP'

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