Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Inflectra Spira MCP Server Show me my assigned tasks in Spira"
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.
A Model Context Protocol (MCP) server that lets AI assistants interact with Inflectra Spira — covering project management, test management, and requirements management.
Works with SpiraTest, SpiraTeam, and SpiraPlan.
Related MCP server: TestRail MCP Server
Install from PyPI:
pip install mcp-server-spiraAdd to your MCP client config:
{
"mcpServers": {
"inflectra-spira": {
"command": "python",
"args": ["-m", "mcp_server_spira"],
"env": {
"INFLECTRA_SPIRA_BASE_URL": "https://myinstance.spiraservice.net",
"INFLECTRA_SPIRA_USERNAME": "mylogin",
"INFLECTRA_SPIRA_API_KEY": "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}"
}
}
}
}For Cline, add "type": "stdio" to the server config. For Claude Desktop:
mcp install src/mcp_server_spira/server.py --name "Inflectra Spira Server"Set these environment variables (or use a .env file):
Variable | Required | Description |
| Yes | Base URL for your Spira instance |
| Yes | Your Spira login name |
| Yes | API Key (RSS Token) from your Spira user profile |
| No | Default product ID — avoids passing |
13 tools organized by scope. All data-retrieval tools return structured JSON with field projection, filtering, and a consistent response envelope.
Tool | Description |
| Your assigned items (task, incident, requirement, test_case, test_set) with filtering and field projection |
| Search artifacts in a product (11 types). Supports cross-product fan-out, server-side filtering, and nested sub-artifact includes. |
| Single artifact by ID with full details and optional sub-artifact includes |
| Search program-level artifacts (capability, milestone) |
Tool | Description |
| Create artifacts (incident, task, requirement, test_case, risk, release, test_set, build, test_step, mitigation, requirement_step) |
| Update existing artifacts |
| Record automated test results from CI/CD |
| Add a comment to an artifact |
| Link two artifacts (related-to, depends-on, coverage) |
Tool | Description |
| List products, programs, or product templates with field projection |
| Get a single product, program, or template by ID |
| Types, statuses, priorities, severities, custom properties, and more for a template |
| Field schema for any artifact type (local-only, no API call) |
Try these prompts with your AI assistant:
Show me my assigned tasks in SpiraList all products in my Spira instanceGet the open incidents in product 55Search for critical requirements across products 55 and 60Get the field schema for incidentsMIT — see LICENSE.
Built with MCP Python SDK · Spira REST API v7.0
Returns the field schema for a Spira artifact type as JSON.
Args:
artifact_type: One of: task, incident, requirement, test_case,
release, risk, test_set, test_run, automation_host,
capability, milestone
Returns:
JSON: {"artifact_type": "...", "fields": [{"name", "type",
"description"}, ...]}
or {"error": "...", "valid_types": [...]} for unknown types.
Call get_artifact_schema(artifact_type='task') to see fields.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds value by specifying the return format (success/error) and behavior for unknown types. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, example). Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, presence of output schema, and annotations, the description is complete. It covers purpose, parameters, return format, error handling, and usage example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by listing all valid artifact types and providing an example call. This adds critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the field schema for a Spira artifact type as JSON, listing all valid artifact types. It distinguishes itself from sibling tools (e.g., search, create) by focusing on schema retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example call and lists valid artifact types, giving clear usage context. However, it does not explicitly state when to use this tool over siblings or exclude cases like non-existent types (though error return is specified).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | No | ||
| fields | No | ||
| status | No | ||
| priority | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records an automated test result in Spira.
Maps to Spira API: POST /projects/{product_id}/test-runs/record
Use this to push automated test results from CI/CD pipelines into Spira for quality tracking.
Args:
product_id: The numeric ID of the product (e.g., 55 for PR:55). If omitted, uses SPIRA_PROJECT_ID from environment.
test_name: The name of the test being run
short_message: Brief result description (50 chars or less)
long_message: Full test outcome description in plain text
error_count: Number of errors during test (0 if none)
test_case_id: Test case ID without TC prefix (e.g., 12 for TC:12)
execution_status_id: Status (1=Failed, 2=Passed, 3=Not Run, 4=N/A, 5=Blocked, 6=Caution)
Returns:
JSON: {"test_run_id": "TR:123", "message": "Test run recorded successfully"}
Error Responses:
Returns structured JSON with error, error_code, details, and suggestion.
Common error codes: INVALID_PARAMETER, API_ERROR, NOT_FOUND
Example Usage:
result = record_automated_test_run(
product_id=55, test_name="test_login", short_message="Passed",
long_message="Login successful", error_count=0, test_case_id=123, execution_status_id=2
)
| Name | Required | Description | Default |
|---|---|---|---|
| test_name | Yes | ||
| short_message | Yes | ||
| long_message | Yes | ||
| error_count | Yes | ||
| test_case_id | Yes | ||
| execution_status_id | Yes | ||
| product_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the REST method (POST), return format, error responses with common codes, and even includes an example. It goes well beyond the minimal annotations, offering rich behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into purpose, API mapping, usage, args, return, errors, and example. Every section serves a purpose, and it is not overly verbose for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and 6 required, the description covers return values (sample JSON), error responses, and example usage. It is complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 each parameter: product_id's default from environment, short_message's 50-char limit, test_case_id without prefix, execution_status_id with status mapping. It adds essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Records an automated test result in Spira' and maps to the specific API endpoint. It distinguishes from sibling tools like product_create_build by focusing on test run recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: 'Use this to push automated test results from CI/CD pipelines.' While it doesn't explicitly exclude alternatives, the purpose is well-defined among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new CI/CD pipeline build entry in Spira.
Maps to Spira API: POST /projects/{product_id}/releases/{release_id}/builds
Use this to record CI/CD build results and associate commits with releases.
Args:
product_id: The numeric ID of the product (e.g., 55 for PR:55). If omitted, uses SPIRA_PROJECT_ID from environment.
release_id: Release/sprint ID without RL prefix (e.g., 12 for RL:12)
build_status_id: Build status (1=Failed, 2=Passed)
name: Build name (typically project name + date/time)
description: Detailed build description (what was included and why)
commits: Array of Git commit hashes included in the build
Returns:
JSON: {"build_id": "BL:123", "message": "Build created successfully"}
Error Responses:
Returns structured JSON with error, error_code, details, and suggestion.
Common error codes: INVALID_PARAMETER, API_ERROR, NOT_FOUND
Example Usage:
result = create_build(
product_id=55, release_id=10, build_status_id=2,
name="Build 2024-02-13 v1.5.0", description="Production build",
commits=["abc123", "def456"]
)
| Name | Required | Description | Default |
|---|---|---|---|
| release_id | Yes | ||
| build_status_id | Yes | ||
| name | Yes | ||
| description | Yes | ||
| commits | Yes | ||
| product_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description confirms creation. It discloses return format and error responses, adding value beyond annotations. However, it does not mention side effects like notifications or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, mapping, args, returns, errors, example), but includes slightly redundant information (e.g., API endpoint). Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (5 required) and no schema descriptions, the description covers inputs, output format, errors, and provides an example. It lacks details on rate limits or authentication, but is largely complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 each parameter, including default behavior for product_id, value mapping for build_status_id, and expected format for commits. Example usage further clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new CI/CD pipeline build entry in Spira, with a direct API mapping. It distinguishes itself from sibling tools like product_create_automated_test_run by focusing on builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it ('record CI/CD build results and associate commits with releases'), providing clear context. However, it does not explicitly exclude alternative tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | Yes | ||
| artifact_id | Yes | ||
| product_id | No | ||
| release_id | No | ||
| include | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | Yes | ||
| product_ids | No | ||
| fields | No | ||
| status | No | ||
| release_id | No | ||
| priority | No | ||
| starting_row | No | ||
| number_of_rows | No | ||
| include | No | ||
| requirement_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | Yes | ||
| program_id | Yes | ||
| fields | No | ||
| status | No | ||
| priority | No | ||
| starting_row | No | ||
| number_of_rows | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves template metadata sections for a product template.
metadata_type (list[str], required): Sections to fetch.
- "types": Artifact type definitions per artifact kind
(e.g. Requirement types: Use Case, User Story).
- "custom_properties": Custom field definitions per artifact kind.
- "statuses": Status definitions per artifact kind
(Requirement, Incident, Task, Risk, Release, Test Case, Document).
- "priorities": Priority definitions per artifact kind
(Incident, Task, Test Case).
- "severities": Severity definitions (Incident only).
- "importances": Importance definitions (Requirement only).
- "probabilities": Probability definitions (Risk only).
- "impacts": Impact definitions (Risk only).
template_id (int, required): Numeric ID of the product template
(e.g. 45 for PT:45).
artifact_type (str, optional): Filter to a single artifact kind
(e.g. "Requirement"). When omitted, all artifact kinds are fetched.
Returns JSON with template_id, sections dict, and warnings list.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | ||
| metadata_type | No | ||
| artifact_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds transparency about the return structure (JSON with template_id, sections dict, warnings list) and that it fetches data for given types and optional artifact filter. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for each parameter and a return note. It is detailed but not overly verbose, though the list of metadata_type values could be slightly trimmed. Front-loads the main purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's moderate complexity (3 parameters, one required, enum values), the description covers all necessary aspects: parameter meanings, usage context, and return format. It is complete 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for each metadata_type value, template_id, and artifact_type, significantly augmenting the schema which has 0% coverage. However, it inaccurately marks metadata_type as required, whereas the schema shows it's optional (default null). This minor error reduces precision.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves template metadata sections for a product template, specifying the exact metadata types available. It distinguishes itself from sibling tools like get_artifact_schema or search tools by focusing on template metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining each metadata_type option when to fetch specific sections. However, it does not explicitly state when not to use this tool or mention alternatives like get_artifact_schema for artifact definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_type | Yes | ||
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_type | Yes | ||
| program_id | No | ||
| fields | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.1get_artifact_schemamywork_search_artifactsproduct_create_automated_test_runproduct_create_buildproduct_get_artifactproduct_search_artifactsprogram_search_artifactstemplate_get_metadataworkspace_getworkspace_searchMultiple search tools (mywork, product, program, workspace) exist with no descriptions, making it ambiguous what each searches. Also, product_get_artifact and product_search_artifacts overlap in purpose without clear distinction.
Tool names follow a verb_noun pattern with scope prefixes like product_, but inconsistency arises with get_artifact_schema (no scope) and mywork_search_artifacts (different prefix). Overall pattern is partially consistent but not uniform.
10 tools is a reasonable number for an ALM server like Spira, covering essential operations without being excessive. Some tools could be merged, but count is appropriate.
The tool set lacks fundamental CRUD operations for key artifact types (e.g., create artifact, update, delete). It focuses on retrieval, test run recording, and build creation, leaving significant gaps for typical project management workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect to Atlassian Jira, Confluence, and Compass to search, create, and manage your work.
Manage Kanera workspaces, boards, cards, checklists, comments, notes, automations, and reports.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Connect AI assistants to Stellary projects, boards, documents, and governed agent workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Inflectra/mcp-server-spira'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
