Panaya MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
The generic panaya_operations tool overlaps with all resource-specific tools, as it can execute any operation. This makes it unclear whether to use a specific tool or the generic one, especially since the 'unified' tools likely wrap similar operations.
Naming Consistency4/5
Most tools follow a consistent panaya_<resource> pattern with snake_case. However, panaya_businessProcesses uses camelCase, and panaya_operations is not a resource but a catch-all, so it deviates slightly from the naming convention.
Tool Count4/5
With 9 tools, the count is reasonable for a domain-specific server. The inclusion of a generic operations tool alongside resource-specific tools is somewhat redundant but does not make the count inappropriate.
Completeness4/5
The resource-specific tools cover core entities, and panaya_operations fills any gaps by allowing arbitrary operations. Minor gaps may exist in the specific tools (e.g., no explicit update/delete exposed), but the generic tool provides a workaround.
Average 2.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 says only 'operations' without revealing any side effects, permissions, pagination behavior, or that certain actions mutate data. The description is silent on all behavioral traits beyond what the function name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but its brevity comes from under-specification rather than effective conciseness. It contains almost no useful information, making it more a placeholder than a concise summary. Similar to the 'Process' example, this is not concise but simply inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, nested objects, an action enum, and no output schema or annotations. The description fails to explain the action-based dispatch, the 'operation' action requiring operationId, or the pagination helper. This is completely inadequate for the tool's complexity.
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 100%, meaning all parameters already have descriptive text (e.g., 'Operation to perform against the Panaya entity' for action). The description adds no additional parameter meaning, so the baseline of 3 is appropriate given that the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Unified tool for businessProcesses operations,' which is a vague restatement of the tool name without any specific verb or resource detail. It does not mention concrete actions like list, get, create, update, or delete that are defined in the schema's action enum, making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling tools such as panaya_operations or panaya_projects. There is no mention of alternatives, exclusions, or specific contexts, leaving the agent without any decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits such as side effects, permissions, rate limits, or response structure. The single sentence carries the entire burden of behavioral disclosure but says nothing beyond the tool's name, making it completely non-transparent.
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, making it concise and free of unnecessary words. However, it is under-specified and does not use the brevity effectively to communicate key details. It is neither verbose nor adequately informative, placing it at average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, nested objects, an action enum, and no output schema or annotations, this tool requires substantial contextual explanation. The description provides none of that, lacking any mention of return values, use cases, prerequisites, or operational behavior. It is severely incomplete for an agent to confidently invoke.
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 schema provides description coverage for 100% of the 9 parameters, including details about action, pagination, and pathParams. Per the rubric, high schema coverage grants a baseline of 3. The description itself adds no parameter-level meaning, but the schema compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified tool for cycles operations' mentions a resource ('cycles') but lacks a specific verb or scope. It is vague about what operations are supported, leaving the reader to guess whether it covers CRUD, search, or something else. It minimally distinguishes from siblings by naming 'cycles', but does not clearly state the tool's purpose.
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 like panaya_requirements or panaya_tests. The description does not provide any context about appropriate use cases, exclusions, or prerequisites, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description discloses no behavioral traits such as side effects, permission requirements, pagination behavior, or what happens on create/delete. The term 'unified' is uninformative and fails to carry the burden left by missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The single sentence provides no substantive information and does not earn its place; it merely restates the tool's domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, nested objects, and an enum of seven actions, the description is completely inadequate. There is no output schema, no mention of return values, and no context about how the unified interface dispatches to different operations.
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 provides descriptions for all 9 parameters (100% coverage), so baseline is 3. The description itself adds no parameter semantics beyond what the schema already offers, but the schema is sufficient to understand each parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified tool for defects operations' is essentially a restatement of the tool name with the vague addition of 'operations'. It fails to specify any concrete actions (list, create, update) or how it relates to the sibling tools beyond naming the same entity.
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 like panaya_requirements or panaya_tests. The description does not mention prerequisites, exclusions, or scenarios where one action over another is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits whatsoever—no effect on data, no side effects, no return format, no auth requirements. The generic phrase provides zero transparency about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. 'Unified tool for projects operations' is vague and does not provide meaningful information; this is not conciseness but a lack of substance, similar to the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, action enum, pagination), this one-sentence description is grossly insufficient. No output schema exists, so the description should fill in return behavior and usage context, but it does not.
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 covers all 9 parameters with individual descriptions, so the baseline is 3. The tool description does not add any parameter semantics, but it does not need to since the schema is fully self-descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified tool for projects operations' essentially restates the tool name without specifying what operations are performed or what 'projects' means in the Panaya domain. It does not clearly state a specific verb+resource, making it a tautology rather than a clear purpose statement.
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 sibling tools like panaya_operations or panaya_requirements. There is no mention of scenarios, prerequisites, or alternatives, leaving the agent 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects, read/write behavior, or special conditions. It provides none of this. The description gives no indication of whether actions are destructive, require authentication, or have rate limits, leaving the agent to infer everything from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It fails to convey substantive information, making it closer to a placeholder than a useful tool summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 9-parameter tool with nested objects, an action enum, and no output schema. The description is entirely inadequate: it does not explain what 'releases' represents, which actions each do, response expectations, or any constraints. The context is severely incomplete.
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 provides complete descriptions (100% coverage) for all parameters, including the action enum and each field. The description itself adds no parameter-level meaning, but the baseline of 3 is appropriate since the schema already documents parameter semantics thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified tool for releases operations' is vague and essentially restates the tool name without specifying a concrete action or resource. It does not distinguish this tool from sibling tools beyond the entity name, and lacks a clear verb like 'manage', 'list', or 'create'.
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 such as panaya_projects or panaya_tests. The description does not mention use cases, prerequisites, or scenarios where one action (e.g., list vs operation) should be chosen over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states that it is a 'unified tool for requirements operations', offering no insight into side effects (e.g., create/delete mutates data), permissions, pagination behavior, or how the 'operation' action works. This is a complete lack of transparency for a tool that clearly supports mutating actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than truly concise. It fails to convey meaningful information about the tool's purpose or behavior, making it closer to a placeholder than a succinct summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 9 parameters, a complex action enum, and no output schema or annotations. The description provides none of the necessary context to understand CRUD actions, search behavior, the 'operation' action, or pagination logic. It is drastically incomplete for an AI agent to select and invoke the tool correctly.
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 already documents all parameters with descriptions (100% coverage), including action, id, query, pagination, and pathParams. The description text adds no parameter-level semantics beyond what the schema provides, so the baseline score of 3 applies. No additional context or parameter relationships are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Unified tool for requirements operations' which essentially restates the tool name without specifying a concrete verb or resource action. It fails to describe what operations are available (e.g., CRUD, search) and does not distinguish it from sibling tools like panaya_tests or panaya_defects beyond the resource name.
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 explanation of when to use this tool versus alternatives. The description provides no context about which actions are appropriate for which scenarios, and no exclusions or alternative tool references are given. The only implicit hint is the 'requirements' resource, but the actionable guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 provides zero information about side effects, authentication requirements, data mutability, or response behavior. It adds no insight beyond the tool's existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. For a tool with nine parameters and multiple actions, a single vague sentence is not appropriately sized. It lacks the informative substance needed for a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested objects and multiple actions, yet the description provides no context about usage, response format, pagination, or error conditions. There is no output schema to compensate, making this description inadequate.
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 100% coverage with parameter descriptions, so the baseline is 3. The tool description itself adds no parameter context, but the schema already documents all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified tool for tests operations' is vague and essentially restates the tool's name. It does not specify what operations are supported or what 'tests' refers to, and it does not distinguish this tool from sibling tools like panaya_defects or panaya_requirements.
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 prerequisites, use cases, or why one might choose panaya_tests over other Panaya tools.
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 disclosing behavioral traits. It does not mention whether operations are read-only or mutating, potential side effects, authentication requirements, or error behavior. The phrase 'execute any Panaya Swagger operation' suggests arbitrary calls but provides no safety or side-effect 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 a single, front-loaded sentence with no wasted words. It immediately communicates the core function. However, given the tool's complexity, a slightly longer description with the action types could have been more useful without sacrificing conciseness, so it doesn't achieve a perfect 5.
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?
This is a complex tool with 9 parameters, nested objects, and a three-mode action system, yet there is no output schema and the description offers minimal context. It does not explain the workflow (e.g., list to find operations, describe to get details, call to execute), nor does it specify return formats. The description is insufficient for an agent to use the tool effectively without further exploration.
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 covers all 9 parameters with descriptions, including the action enum, operationId, and parameter groups. The description itself adds no parameter-level meaning. Following the baseline for high schema coverage (100%), a score of 3 is appropriate; the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's verb and resource: 'Discover and execute any Panaya Swagger operation by operationId.' This clearly differentiates it from sibling tools like panaya_projects or panaya_tests, which target specific entities. However, it omits the 'describe' action and the three action modes (list, describe, call) that are present in the schema, making the purpose slightly less complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the specific sibling tools. The description is purely declarative and offers no preconditions, recommendations, or alternatives. The agent is left to infer that this is a generic fallback, but the description does not state that explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely restates the action without revealing side effects, prerequisites, security implications, or what happens to the existing token.
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, immediately front-loaded with the verb and resource. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully-documented parameter, but the description fails to convey important behavioral context such as authentication requirements, token invalidation behavior, or rate limits. It is adequate only at a surface level.
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 100%—the single parameter 'action' has a clear enum and description. The tool description adds no new meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 'Refresh' with the resource 'Panaya generated API token', clearly distinguishing this tool from sibling data-access tools like panaya_operations or panaya_projects. It unambiguously states what the tool does.
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 explicit guidance on when to use this tool vs alternatives. While it is implied that it should be used when a token needs refreshing, no when-to-use or exclusion criteria are mentioned.
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:

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

Score Badge

Copy to your README.md:

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

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/engineersonal/panaya-mcp-sonal'

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