Jira Insights(JSM) 자산 스키마를 관리하기 위한 MCP(모델 컨텍스트 프로토콜) 서버입니다.
최종 업데이트: 2025-04-09
이 MCP 서버는 모델 컨텍스트 프로토콜을 통해 Jira Insights(JSM) 자산 스키마와 상호 작용하는 도구를 제공합니다. Jira Insights에서 객체 스키마, 객체 유형 및 객체를 관리할 수 있습니다.
Related MCP server: MCP Atlassian
개체 스키마 관리(생성, 읽기, 업데이트, 삭제)
객체 유형 관리(생성, 읽기, 업데이트, 삭제)
객체 관리(생성, 읽기, 업데이트, 삭제)
AQL(Atlassian Query Language)을 사용하여 객체 쿼리
Node.js 20 이상
Docker(컨테이너화된 배포용)
API 액세스가 가능한 Jira Insights 인스턴스
적절한 권한이 있는 Jira API 토큰
저장소를 복제합니다.
지엑스피1
종속성 설치:
npm install프로젝트를 빌드하세요:
npm run buildDocker 이미지를 빌드합니다.
./scripts/build-local.shClaude나 Model Context Protocol을 지원하는 다른 AI 어시스턴트와 함께 이 MCP 서버를 사용하려면 다음 방법 중 하나를 사용하여 MCP 구성에 추가하세요.
프로젝트를 로컬로 빌드한 경우 다음 구성을 사용하세요.
{
"mcpServers": {
"jira-insights": {
"command": "node",
"args": ["/path/to/jira-insights-mcp/build/index.js"],
"env": {
"JIRA_API_TOKEN": "your-api-token",
"JIRA_EMAIL": "your-email@example.com",
"JIRA_HOST": "https://your-domain.atlassian.net",
"LOG_MODE": "strict"
}
}
}
}Docker 이미지를 사용하려는 경우(대부분 사용자에게 권장) 다음 구성을 사용하세요.
{
"mcpServers": {
"jira-insights": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e", "JIRA_API_TOKEN",
"-e", "JIRA_EMAIL",
"-e", "JIRA_HOST",
"ghcr.io/aaronsb/jira-insights-mcp:latest"
],
"env": {
"JIRA_API_TOKEN": "your-api-token",
"JIRA_EMAIL": "your-email@example.com",
"JIRA_HOST": "https://your-domain.atlassian.net"
}
}
}
}이 Docker 기반 구성은 GitHub Container Registry에서 최신 이미지를 가져와서 필요한 환경 변수와 함께 실행합니다.
로컬 개발 및 테스트를 위해:
# Build the Docker image
./scripts/build-local.sh
# Run the Docker container
JIRA_API_TOKEN=your_token JIRA_EMAIL=your_email JIRA_HOST=your_host ./scripts/run-local.shCRUD 작업을 통해 Jira Insights 개체 스키마를 관리합니다.
{
"operation": "list",
"maxResults": 10
}CRUD 작업을 통해 Jira Insights 객체 유형을 관리합니다.
{
"operation": "list",
"schemaId": "1",
"maxResults": 20
}CRUD 작업과 AQL 쿼리를 사용하여 Jira Insights 객체를 관리합니다.
{
"operation": "query",
"aql": "objectType = \"Application\"",
"maxResults": 10
}MCP 서버는 Jira Insights 데이터에 액세스하기 위한 여러 리소스를 제공합니다.
jira-insights://instance/summary - Jira Insights 인스턴스에 대한 고급 통계
jira-insights://aql-syntax - 예제를 포함한 자산 쿼리 언어(AQL) 구문에 대한 포괄적인 가이드
jira-insights://schemas/all - 모든 스키마와 해당 객체 유형의 전체 목록
jira-insights://schemas/{schemaId}/full - 객체 유형을 포함한 특정 스키마의 완전한 정의
jira-insights://schemas/{schemaId}/overview - 메타데이터 및 통계를 포함한 특정 스키마 개요
jira-insights://object-types/{objectTypeId}/overview - 속성 및 통계를 포함한 특정 객체 유형에 대한 개요
Jira Insights MCP의 기능과 사용성을 향상시키기 위해 여러 가지 개선 작업을 진행하고 있습니다.
향상된 오류 처리
특정 검증 문제가 있는 보다 자세한 오류 메시지
일반적인 오류에 대한 제안된 수정 사항
사용자가 문제를 해결하는 데 도움이 되는 작업별 예
AQL 쿼리 개선
AQL 쿼리에 대한 검증 및 포맷팅 유틸리티
스키마별 예제 쿼리
쿼리 문제에 대한 더 나은 오류 메시지
속성 발견 향상
객체 유형에 대한 속성 검색이 개선되었습니다.
더 나은 성능을 위한 캐싱
"확장" 매개변수의 더 나은 처리
객체 템플릿 생성
객체 유형에 따라 객체를 생성하기 위한 템플릿
유형별 플레이스홀더 생성
템플릿의 검증 규칙
예제 쿼리 라이브러리
스키마별 예제 쿼리
컨텍스트 인식 쿼리 제안
일반적인 작업을 위한 쿼리 템플릿
개선된 문서
향상된 AQL 구문 문서
작업별 문서
일반적인 오류 시나리오 및 솔루션
계획된 개선 사항에 대한 자세한 내용은 다음을 참조하세요.
TODO.md - 모든 작업을 우선순위별로 정리한 포괄적인 할 일 목록
IMPLEMENTATION_PLAN.md - 우선순위가 높은 개선 사항에 대한 자세한 구현 계획
HANDLER_IMPROVEMENTS.md - 각 핸들러 파일에 필요한 특정 변경 사항
IMPROVEMENT_SUMMARY.md - 계획된 개선 사항에 대한 간략한 요약
docs/API_MIGRATION_TODO.md - API 마이그레이션 상태 및 계획된 개선 사항
npm run build : TypeScript 코드 빌드
npm run lint : ESLint 실행
npm run lint:fix : 자동 수정으로 ESLint 실행
npm run test : 테스트 실행
npm run watch : 변경 사항을 확인하고 다시 빌드합니다.
npm run generate-diagrams : TypeScript 종속성 다이어그램 생성
./scripts/build-local.sh : Docker 이미지 빌드
./scripts/run-local.sh : Docker 컨테이너를 실행합니다.
AQL 쿼리 검증 오류
공백이 포함된 값은 따옴표로 묶어야 합니다: Name = "John Doe"
논리 연산자에는 대문자를 사용하세요: AND , OR (not and , or )
스키마에 개체 유형과 속성이 있는지 확인하세요.
객체 유형 속성 문제
"속성"과 함께 "확장" 매개변수를 사용할 때 개체 유형이 존재하는지 확인하십시오.
속성을 볼 수 있는 권한이 있는지 확인하세요
API 연결 문제
Jira API 토큰에 필요한 권한이 있는지 확인하세요.
Jira 호스트 URL이 올바른지 확인하세요
네트워크에서 Jira API에 대한 연결이 허용되는지 확인하세요.
MIT
Manage Jira Insights objects with CRUD operations and AQL queries
| Name | Required | Description | Default |
|---|---|---|---|
| aql | No | AQL query string. Required for query operation. IMPORTANT: For comprehensive AQL documentation, refer to the "jira-insights://aql-syntax" resource using the access_mcp_resource tool. This resource contains detailed syntax guides, examples, and best practices. Guide to Constructing Better Jira Insight AQL Queries: Understanding AQL Fundamentals: - Object Type Case Sensitivity: Use exact case matching for object type names (e.g., ObjectType = "Supported laptops" not objectType = "Supported laptops"). - String Values in Quotes: Always enclose string values in double quotes, especially values containing spaces (e.g., Name = "MacBook Pro" not Name = MacBook Pro). - Attribute References: Reference attributes directly by their name, not by a derived field name (e.g., use Name not name). - LIKE Operator Usage: Use the LIKE operator for partial string matching, but be aware it may be case-sensitive. Effective Query Construction: - Start Simple: Begin with the most basic query to validate object existence before adding complex filters: ObjectType = "Supported laptops" - Examine Response Objects: Study the first responses to understand available attribute names and formats before using them in filters. - Keyword Strategy: When searching for specific items, try multiple potential keywords (e.g., "ThinkPad", "Lenovo", "Carbon") rather than just exclusion logic. - Incremental Complexity: Add filter conditions incrementally, testing after each addition rather than constructing complex queries in one step. Managing Complex Queries: - AND/OR Operators: Structure complex conditions carefully with proper parentheses: ObjectType = "Supported laptops" AND (Name LIKE "ThinkPad" OR Name LIKE "Lenovo") - NOT Operators: Use NOT sparingly and with proper syntax: ObjectType = "Supported laptops" AND NOT Name LIKE "MacBook" - Reference Object Queries: For filtering on related objects, use their object key as a reference: ObjectType = "Supported laptops" AND Manufacturer = "PPL-231" - Pagination Awareness: For large result sets, utilize the startAt and maxResults parameters to get complete data. | |
| attributes | No | Attributes of the object as key-value pairs. Optional for create/update. | |
| expand | No | Optional fields to include in the response | |
| includeAttributes | No | Should the objects attributes be included in the response. If this parameter is false only the information on the object will be returned and the object attributes will not be present. | |
| includeAttributesDeep | No | How many levels of attributes should be included. E.g. consider an object A that has a reference to object B that has a reference to object C. If object A is included in the response and includeAttributesDeep=1 object A's reference to object B will be included in the attributes of object A but object B's reference to object C will not be included. However if the includeAttributesDeep=2 then object B's reference to object C will be included in object B's attributes. | |
| includeExtendedInfo | No | Include information about open Jira issues. Should each object have information if open tickets are connected to the object? | |
| includeTypeAttributes | No | Should the response include the object type attribute definition for each attribute that is returned with the objects. | |
| maxResults | No | Maximum number of objects to return. Used for list and query operations. Can also use snake_case "max_results". | |
| name | No | Name of the object. Required for create operation, optional for update. | |
| objectId | No | The ID of the object. Required for get, update, and delete operations. Can also use snake_case "object_id". | |
| objectTypeId | No | The ID of the object type. Required for create operation. Can also use snake_case "object_type_id". | |
| operation | Yes | Operation to perform on the object | |
| resolveAttributeNames | No | Replace attribute IDs (attr_xxx) with actual attribute names in the response. This provides more meaningful attribute names for better readability. | |
| schemaId | No | The ID of the schema to use for enhanced validation. When provided, the query will be validated against the schema structure, providing better error messages and suggestions. | |
| simplifiedResponse | No | Return a simplified response with only essential key-value pairs, excluding detailed metadata, references, and type definitions. Useful for reducing response size and improving readability. | |
| startAt | No | Index of the first object to return (0-based). Used for list and query operations. Can also use snake_case "start_at". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'CRUD operations and AQL queries' but lacks details on permissions, side effects, rate limits, or response formats. For a tool with 16 parameters and complex operations like delete/update, this is insufficient—it doesn't explain what 'manage' entails beyond high-level operations.
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 overly concise to the point of under-specification—it's a single sentence that fails to convey necessary details for such a complex tool. It lacks front-loaded critical information and doesn't structure guidance effectively, making it inefficient despite its brevity.
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 tool's complexity (16 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, leaving significant gaps. For a multi-operation tool managing objects, more comprehensive guidance is needed to support effective agent use.
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 adds minimal parameter semantics beyond the input schema, which has 100% coverage. It implies parameters relate to CRUD and AQL operations but doesn't elaborate on specific usage or interactions. Since schema coverage is high, the baseline is 3, but the description doesn't compensate with additional insights like parameter dependencies or examples.
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's purpose: 'Manage Jira Insights objects with CRUD operations and AQL queries.' It specifies the resource (Jira Insights objects) and the operations (CRUD + AQL queries). However, it doesn't explicitly differentiate from sibling tools like 'manage_jira_insight_object_type' or 'manage_jira_insight_schema,' which likely manage different resources.
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 no guidance on when to use this tool versus its siblings or alternatives. It mentions CRUD operations and AQL queries but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this is for basic object management while siblings handle types/schemas, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Jira Insights object types with CRUD operations
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Description of the object type. Optional for create/update. | |
| expand | No | Optional fields to include in the response | |
| icon | No | Icon for the object type. Optional for create/update. | |
| maxResults | No | Maximum number of object types to return. Used for list operation. Can also use snake_case "max_results". | |
| name | No | Name of the object type. Required for create operation, optional for update. | |
| objectTypeId | No | The ID of the object type. Required for get, update, and delete operations. Can also use snake_case "object_type_id". | |
| operation | Yes | Operation to perform on the object type | |
| schemaId | No | The ID of the schema. Required for create operation. Can also use snake_case "schema_id". | |
| startAt | No | Index of the first object type to return (0-based). Used for list operation. Can also use snake_case "start_at". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states 'CRUD operations' without detailing permissions, side effects, rate limits, or response behavior. It lacks critical information for a mutation-capable tool.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for the tool's 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?
For a tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral nuances needed for safe and effective use.
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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond the generic 'CRUD operations', which aligns with the baseline for high schema coverage.
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 states the tool performs CRUD operations on Jira Insights object types, which is a clear purpose. However, it doesn't differentiate from sibling tools like 'manage_jira_insight_object' or 'manage_jira_insight_schema', leaving ambiguity about scope boundaries.
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?
No guidance is provided on when to use this tool versus its siblings or alternatives. The description mentions CRUD operations but doesn't specify contexts, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Jira Insights object schemas with CRUD operations
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Description of the schema. Optional for create/update. | |
| expand | No | Optional fields to include in the response | |
| maxResults | No | Maximum number of schemas to return. Used for list operation. Can also use snake_case "max_results". | |
| name | No | Name of the schema. Required for create operation, optional for update. | |
| operation | Yes | Operation to perform on the schema | |
| schemaId | No | The ID of the schema. Required for get, update, and delete operations. Can also use snake_case "schema_id". | |
| startAt | No | Index of the first schema to return (0-based). Used for list operation. Can also use snake_case "start_at". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states 'manage with CRUD operations.' It doesn't describe authentication requirements, rate limits, error conditions, what 'delete' actually destroys, or response formats. For a multi-operation tool with mutation capabilities, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core purpose, though it could benefit from more detail given the tool's 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?
For a complex tool with 7 parameters supporting 5 different operations (including destructive ones like delete) and no output schema or annotations, the description is inadequate. It doesn't explain return values, error handling, or operational constraints, leaving the agent with insufficient context to use the tool effectively.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no parameter-specific information beyond the generic 'CRUD operations' mention, which doesn't provide additional semantic context about individual parameters or their relationships.
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 states the tool manages Jira Insights object schemas with CRUD operations, which provides a general purpose but lacks specificity about what 'manage' entails. It doesn't distinguish this schema management tool from its sibling object and object type management tools, leaving the scope vague.
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?
No guidance is provided about when to use this tool versus its siblings (manage_jira_insight_object and manage_jira_insight_object_type). The description mentions CRUD operations but doesn't specify contexts, prerequisites, or exclusions for choosing this schema management tool over alternatives.
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.0.0manage_jira_insight_objectmanage_jira_insight_object_typemanage_jira_insight_schemaEach tool has a clearly distinct purpose targeting different Jira Insights components: objects, object types, and schemas. The descriptions specify unique domains (objects, object types, schemas) with no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern with 'manage_jira_insight_' prefix followed by the specific component (object, object_type, schema). This predictable naming convention enhances readability and usability across the tool set.
With only 3 tools, the count feels thin for a server named 'Jira Insights MCP', which might imply broader functionality. However, it covers core management areas adequately, though it could benefit from additional tools for querying or reporting to be more comprehensive.
The tools provide CRUD operations for key Jira Insights components (objects, types, schemas), covering essential management tasks. A minor gap exists in lacking dedicated query or analysis tools beyond AQL mentioned in one description, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for Product Management
An MCP server that provides access to Testiny projects, test cases and test runs
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aaronsb/jira-insights-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
