How do I use Panaya MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Panaya MCP Server list all projects" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Panaya MCP Server

by engineersonal

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Panaya MCP Server

A TypeScript-based Model Context Protocol (MCP) server that exposes Panaya REST APIs as MCP tools. It is designed to run over stdio, so it can be connected to Claude Desktop and other MCP-compatible clients.

The server discovers a fixed set of Panaya entities, registers one grouped MCP tool per entity, calls the Panaya REST API with X-Auth-Token, and returns responses in both Claude-readable text and machine-readable structuredContent.

Features

Runs as a local MCP server over stdio.
Connects to Panaya REST APIs using PANAYA_BASE_URL, PANAYA_USERNAME, and PANAYA_TOKEN.
Generates a short-lived Panaya API token through POST /api/accesstoken and sends that generated token as X-Auth-Token.
Registers tools for common Panaya entities:
- projects
- requirements
- tests
- defects
- releases
- cycles
- businessProcesses
Provides a unified action-based tool for each entity.
Supports list, get, create, update, delete, and search actions.
Includes an API operation registry tool, panaya_operations, that can discover, describe, and call documented Panaya REST operations by operationId.
Returns REST responses as formatted JSON text for Claude.
Also returns structured JSON through MCP structuredContent.
Writes server logs to stderr, keeping stdout clean for MCP protocol messages.
Loads .env from the project root even when launched by Claude from another working directory.

Related MCP server: plutio-mcp

Project Structure

src/
  client/
    panayaClient.ts       # Panaya REST client
  config/
    env.ts                # Environment loading and validation
  discovery/
    apiDiscovery.ts       # Entity discovery and metadata lookup
  generator/
    schemaBuilder.ts      # Metadata schema helper retained for future typed schemas
    toolGenerator.ts      # Registers grouped MCP tools for each entity
  generated/
    panayaOperations.ts   # Generated API operation registry
  runtime/
    bootstrap.ts          # Discovers entities and registers tools
  index.ts                # stdio MCP server entry point
  logger.ts               # stderr logger for Claude MCP logs
  server.ts               # MCP server factory

Prerequisites

Node.js 20 or newer is recommended.
npm
A valid Panaya API token.
Claude Desktop, if you want to connect this server to Claude.

Setup

Install dependencies:

npm.cmd install

Create a local .env file from the example:

Copy-Item .env.example .env

Edit .env:

PANAYA_BASE_URL=https://your-panaya-host.example.com
PANAYA_USERNAME=your_panaya_username@example.com
PANAYA_TOKEN=your_long_lived_panaya_access_token_here

PANAYA_TOKEN should be the long-lived access token used by Panaya's /api/accesstoken endpoint. The MCP server exchanges it for a generated API token and uses the generated token in X-Auth-Token.

Do not commit .env. It contains credentials and is ignored by Git.

Build the TypeScript project:

npm.cmd run build

Running Locally

Start the compiled MCP server:

npm.cmd start

This server is intended for MCP stdio clients. When run directly in a terminal, it will wait for MCP JSON-RPC messages on stdin.

Claude Desktop Configuration

Open your Claude Desktop config file:

C:\Users\sonal_sharma\AppData\Roaming\Claude\claude_desktop_config.json

Add this server inside the existing mcpServers object:

{
  "mcpServers": {
    "panaya-mcp-sonal": {
      "command": "node",
      "args": [
        "C:\\Users\\sonal_sharma\\panaya-mcp-sonal\\dist\\index.js"
      ],
      "cwd": "C:\\Users\\sonal_sharma\\panaya-mcp-sonal"
    }
  }
}

If you already have other MCP servers configured, keep them and add only the panaya-mcp-sonal entry.

After editing the config:

Run npm.cmd run build.
Fully restart Claude Desktop.
Ask Claude to use the Panaya MCP server, for example:

Use the Panaya MCP server to list projects.

Available Tools

For each entity, the server registers one grouped tool:

panaya_<entity>

Current tools:

panaya_projects
panaya_requirements
panaya_tests
panaya_defects
panaya_releases
panaya_cycles
panaya_businessProcesses

The server also registers this operation registry tool:

panaya_auth
panaya_operations

Use panaya_auth with { "action": "refresh" } if a long Claude session needs to force-refresh the generated Panaya API token before continuing.

panaya_operations is generated from the official Panaya Postman collection. The current generated registry contains 146 curated API examples from Shared Panaya Catalog of API examples.postman_collection.json. Swagger can still be used as a fallback source if the Postman collection is unavailable.

Each tool accepts this input shape:

{
  "action": "list",
  "id": "optional-id",
  "operationId": "optional-operation-id",
  "projectId": "optional-project-id",
  "pathParams": {},
  "queryParams": {},
  "data": {},
  "query": {}
}

Only action is required. Valid actions are:

list
get
create
update
delete
search
operation

Action field requirements:

Action	Required fields	REST call
`list`	none	`GET /api/v1/<entity>`
`list` with project filter	`projectId`	`GET /api/v1/<entity>?projectId=<projectId>`
`get`	`id`	`GET /api/v1/<entity>/<id>`
`create`	`data`	`POST /api/v1/<entity>`
`update`	`id`, `data`	`PUT /api/v1/<entity>/<id>`
`delete`	`id`	`DELETE /api/v1/<entity>/<id>`
`search`	`query`	`POST /api/v1/<entity>/search`
`operation`	`operationId`, plus required `pathParams`, `queryParams`, and `data`	Calls the matching documented operation

Tool Examples

List all projects:

{
  "action": "list"
}

List requirements for a project:

{
  "action": "list",
  "projectId": "19051"
}

Get one project:

{
  "action": "get",
  "id": "19051"
}

Search an entity:

{
  "action": "search",
  "query": {
    "status": "ACTIVE"
  }
}

Create an entity:

{
  "action": "create",
  "data": {
    "name": "Example"
  }
}

Update an entity:

{
  "action": "update",
  "id": "19051",
  "data": {
    "name": "Updated Example"
  }
}

Delete an entity:

{
  "action": "delete",
  "id": "19051"
}

Call a documented operation from a grouped entity tool:

{
  "action": "operation",
  "operationId": "Create_Defect",
  "pathParams": {
    "projectId": "19051"
  },
  "data": {
    "name": "Example defect"
  }
}

Operation Registry Tool

Use panaya_operations to discover, describe, or call documented REST operations that do not fit the simple grouped entity actions.

List operations:

{
  "action": "list",
  "search": "defect",
  "limit": 10
}

Filter by operation tag/folder:

{
  "action": "list",
  "tag": "Defects",
  "limit": 25
}

Describe one operation:

{
  "action": "describe",
  "operationId": "Create_Defect"
}

Call one operation:

{
  "action": "call",
  "operationId": "Get_All_Defects",
  "pathParams": {
    "projectId": "19051"
  },
  "queryParams": {
    "pageSize": 50,
    "pageNumber": 1
  }
}

Call one paginated page:

{
  "action": "call",
  "operationId": "Get_All_Defects",
  "pathParams": {
    "projectId": "19051"
  },
  "queryParams": {
    "pageSize": 100,
    "pageNumber": 1
  }
}

Fetch all pages for APIs that use pageNumber and pageSize:

{
  "action": "call",
  "operationId": "Get_All_Defects",
  "pathParams": {
    "projectId": "19051"
  },
  "pagination": {
    "all": true,
    "pageSize": 100,
    "maxPages": 20
  }
}

For APIs that use different parameter names, override them:

{
  "action": "call",
  "operationId": "Some_Paginated_Operation",
  "pathParams": {
    "projectId": "19051"
  },
  "pagination": {
    "all": true,
    "pageParam": "page",
    "pageSizeParam": "size",
    "startPage": 0,
    "pageSize": 100,
    "maxPages": 20
  }
}

For operations with a request body, include data:

{
  "action": "call",
  "operationId": "Create_Defect",
  "pathParams": {
    "projectId": "19051"
  },
  "data": {
    "name": "Example"
  }
}

Auth Tool

Force-refresh the generated Panaya API token:

{
  "action": "refresh"
}

Response Format

Tool responses include a text block for Claude:

{
  "content": [
    {
      "type": "text",
      "text": "[{\"projectId\":123,\"projectName\":\"Example\"}]"
    }
  ]
}

They also include structured JSON for MCP clients that support it:

{
  "structuredContent": {
    "data": [
      {
        "projectId": 123,
        "projectName": "Example"
      }
    ]
  }
}

Array responses are wrapped as { "data": [...] } because MCP structuredContent must be an object.

Logging

Logs are written to stderr, which Claude Desktop shows in the MCP server logs. This keeps stdout reserved for MCP protocol traffic.

Example log lines:

[panaya-mcp-sonal] 2026-07-05T11:09:42.590Z tool:start {"name":"panaya_projects","action":"list"}
[panaya-mcp-sonal] 2026-07-05T11:09:42.590Z GET {"path":"/api/v1/projects"}
[panaya-mcp-sonal] 2026-07-05T11:09:42.658Z tool:success {"name":"panaya_projects","action":"list","resultType":"array","count":11}

The logger intentionally avoids printing tokens, headers, or request bodies.

Security Notes

Never commit .env.
Keep PANAYA_TOKEN private.
Keep PANAYA_USERNAME private if it identifies a real user account.
Rotate the token immediately if it is accidentally shared.
Review any create, update, or delete tool usage before allowing Claude or another MCP client to call it.
Avoid logging request bodies if they may contain sensitive business data.
Keep node_modules/ and dist/ out of Git; rebuild from source after cloning.

Development Commands

Build:

npm.cmd run build

Run compiled server:

npm.cmd start

Run TypeScript source directly:

npm.cmd run dev

Regenerate the operation registry from the official Panaya Postman collection:

npm.cmd run generate:operations:postman -- "C:\Users\sonal_sharma\Desktop\Shared Panaya Catalog of API examples.postman_collection.json"
npm.cmd run build

If only Swagger metadata is available, regenerate from Swagger instead:

npm.cmd run generate:operations:swagger -- C:\Users\sonal_sharma\Desktop\Panaya_Swagger.json
npm.cmd run build

Note: On some Windows systems, PowerShell blocks npm.ps1. Use npm.cmd if you see an execution policy error.

Troubleshooting

Claude Shows `Invalid URL`

This usually means PANAYA_BASE_URL was not loaded. Confirm that .env exists in the project root and contains:

PANAYA_BASE_URL=https://your-panaya-host.example.com
PANAYA_USERNAME=your_panaya_username@example.com
PANAYA_TOKEN=your_long_lived_panaya_access_token_here

Then rebuild and restart Claude Desktop.

Panaya Returns 401

Check that PANAYA_USERNAME and PANAYA_TOKEN are valid for the configured Panaya host. The server first calls:

POST /api/accesstoken

Then it sends the generated token using:

X-Auth-Token: <token>

For long-running Claude sessions, call panaya_auth with { "action": "refresh" } and then retry the failed request.

Claude Does Not Show the Server

Check that:

npm.cmd run build completed successfully.
dist/index.js exists.
claude_desktop_config.json points to the correct absolute path.
Claude Desktop was fully restarted after config changes.

Logs Do Not Appear

Claude only captures MCP server logs from stderr. This project logs with console.error() through src/logger.ts.

Git Hygiene

This repository includes a .gitignore that excludes:

.env and other secret files
node_modules/
dist/
logs and temporary files
local IDE/tool state

Before pushing to GitHub, verify that secrets are not staged:

git status

Only commit source, configuration templates, lockfiles, and documentation.

Available Tools

9 tools

panaya_authB

Refresh the Panaya generated API token

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Refresh the generated API token.

TDQS

B3/5.0

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.

panaya_businessProcessesD

Unified tool for businessProcesses operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.7/5.0

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.

panaya_cyclesD

Unified tool for cycles operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

panaya_defectsD

Unified tool for defects operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

panaya_operationsC

Discover and execute any Panaya Swagger operation by operationId

ParametersJSON Schema

Name	Required	Description
`tag`	No	Filter list results by Swagger tag.
`data`	No	Request body for call.
`limit`	No	Maximum operations to return for list. Defaults to 50.
`action`	Yes	Use list to discover operations, describe for one operation, or call to execute it.
`search`	No	Filter list results by text in operationId, path, summary, or tag.
`pagination`	No	Optional pagination helper for call.
`pathParams`	No	Path parameters for call.
`operationId`	No	Swagger operationId for describe and call.
`queryParams`	No	Query string parameters for call.

TDQS

C2.9/5.0

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.

panaya_projectsD

Unified tool for projects operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

panaya_releasesD

Unified tool for releases operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

panaya_requirementsD

Unified tool for requirements operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

panaya_testsD

Unified tool for tests operations

ParametersJSON Schema

Name	Required	Description
`id`	No	Entity identifier. Required for get, update, and delete.
`data`	No	Request body for create and update operations.
`query`	No	Search payload for search operations.
`action`	Yes	Operation to perform against the Panaya entity.
`projectId`	No	Optional project filter for list operations.
`pagination`	No	Optional pagination helper for list and operation actions.
`pathParams`	No	Path parameters for Swagger operation calls.
`operationId`	No	Swagger operationId. Required when action is operation.
`queryParams`	No	Query string parameters for Swagger operation calls.

TDQS

D1.9/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.0.0Jul 31, 2026
- First observedpanaya_auth
- First observedpanaya_businessProcesses
- First observedpanaya_cycles
- First observedpanaya_defects
- First observedpanaya_operations
- First observedpanaya_projects
- First observedpanaya_releases
- First observedpanaya_requirements
- First observedpanaya_tests

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.4/5.0

Scored 2026-07-31 16:35 across 9 tools

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.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

DATPAQ
com.datpaq
34 production API tools over one hosted MCP endpoint.
Developer Tools
2
mcp-server AOAuth
com.httpstatus
AI-callable tools for API mocking, testing, monitoring, security, and automation.
API Testing Testing & QA Tools App Automation
92
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
OneOAuth
ai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
API Testing App Automation
110

Related MCP Servers

QA Studio MCP Server
Testing & QA Tools Project Management App Automation
QAStudio-Dev
A
license
A
quality
C
maintenance
Enables interaction with QA Studio test management platform directly from Claude, allowing users to manage projects, create test runs, view test results, create test cases, and submit manual test results through natural language.
Updated 9 months ago (2025-12-16 19:36 UTC)
7
8 npm
AGPL 3.0
plutio-mcp
CRM Project Management Finance
thecreativelabs
A
license
Not graded
quality
D
maintenance
Enables Claude and other MCP clients to interact with Plutio's business platform resources including CRM, projects, invoicing, and more through structured tools.
Updated a month ago (2026-08-01 05:06 UTC)
17 npm
5
MIT
mcp-jama
Project Management Testing & QA Tools
KeisukeShima
F
license
B
quality
D
maintenance
Enables Claude to interact with JAMA Cloud (Jama Connect) for project management, including creating, updating, and searching items, managing test plans, and adding comments.
Updated 5 months ago (2026-03-29 23:58 UTC)
15
-
hacknplan-mcp
Project Management Workplace & Productivity
mtuska
A
license
B
quality
C
maintenance
Enables Claude to interact with HacknPlan project management via the MCP protocol. Provides tools for managing projects, work items, boards, milestones, time logs, design models, and cross-project portfolio views.
Updated 3 months ago (2026-06-18 01:25 UTC)
75
11 npm
MIT

Panaya MCP Server

Features

Project Structure

Prerequisites

Setup

Running Locally

Claude Desktop Configuration

Available Tools

Tool Examples

Operation Registry Tool

Auth Tool

Response Format

Logging

Security Notes

Development Commands

Troubleshooting

Claude Shows Invalid URL

Panaya Returns 401

Claude Does Not Show the Server

Logs Do Not Appear

Git Hygiene

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Claude Shows `Invalid URL`