Skip to main content
Glama
Vergil333

JSM Assets MCP Server

by Vergil333
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

JSM Assets MCP Server

A Model Context Protocol (MCP) server that provides AI assistants like Claude access to Jira Service Management (JSM) Assets data through standardized tools.

🆕 New Features: Robust automatic pagination, Claude Code support, and reliable complete data retrieval!

🚀 Quick Start

Get started in under 5 minutes: Quick Start Guide →

Related MCP server: MCP Atlassian

Features

  • 🔍 Search Assets with AQL: Use Assets Query Language for complex searches with robust pagination

  • 📋 Browse Object Schemas: List all available asset schemas

  • 🏗️ Explore Object Types: View object types within schemas

  • 📝 Inspect Object Attributes: Get detailed attribute information

  • 🌳 Find Child Objects: Search hierarchical object relationships with automatic pagination

  • ⚡ Robust Pagination: Never miss data with reliable multi-page retrieval

  • 🖥️ Multi-Platform: Works with Claude Desktop (.dxt) and Claude Code (CLI)

Installation

Multiple installation options available: Complete Installation Guide →

Quick Options

🚀 Claude Desktop (Recommended)

# Build and install .dxt package
npm run build:dxt
# Double-click jsm-assets-mcp.dxt → Install

⚡ Claude Code

claude mcp add jsm-assets \
  -e JSM_WORKSPACE_ID="your-id" \
  -e JSM_AUTH_TOKEN="Basic your-token" \
  -- node /path/to/jsm-assets-mcp/dist/index.js

🛠️ Traditional Setup

git clone <repo-url> && cd jsm-assets-mcp
npm install && npm run build
cp .env.example .env  # Edit with your credentials

Configuration

Environment Variables

Create a .env file with the following variables:

JSM_WORKSPACE_ID=your-workspace-id
JSM_AUTH_TOKEN=Basic your-encoded-token
JSM_BASE_URL=https://api.atlassian.com/jsm/assets/workspace

Claude Desktop Integration

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "jsm-assets": {
      "command": "node",
      "args": ["/path/to/jsm-assets-mcp/dist/index.js"],
      "env": {
        "JSM_WORKSPACE_ID": "your-workspace-id",
        "JSM_AUTH_TOKEN": "Basic your-encoded-token",
        "JSM_BASE_URL": "https://api.atlassian.com/jsm/assets/workspace"
      }
    }
  }
}

Available Tools

1. search_assets_aql

Search assets using AQL (Assets Query Language) with robust automatic pagination.

Parameters:

  • aqlQuery (required): AQL query string

  • autoPages (optional): Enable automatic pagination (default: false for backward compatibility)

  • maxPages (optional): Maximum pages to fetch when autoPages=true (default: 10, safety limit)

  • pageSize (optional): Objects per page when autoPages=true (default: 1000)

  • startAt (optional): Starting index for single-page requests when autoPages=false (default: 0)

  • maxResults (optional): Max results for single-page requests when autoPages=false (default: 1000)

Examples:

# Basic search (single page)
objectType="Installation Package" AND Key startswith IASM

# Automatic pagination to get ALL results
{
  "aqlQuery": "objectType=\"Installation Package\"",
  "autoPages": true,
  "maxPages": 20
}

Pagination Behavior:

  • When autoPages=false: Traditional single API request (backward compatible)

  • When autoPages=true: Uses robust pagination that continues fetching until returned count < requested count

  • Avoids relying on potentially unreliable API metadata (total, isLast)

  • Provides clear feedback about pages fetched and potential limits reached

2. get_object_schemas

List all object schemas in the workspace.

Parameters: None

3. get_object_types

Get object types for a specific schema.

Parameters:

  • schemaId (required): Schema ID number

4. get_object_attributes

Get attributes for a specific object type.

Parameters:

  • objectTypeId (required): Object type ID number

5. search_child_objects

Search for child objects of a parent type with automatic pagination and optional filters.

Parameters:

  • parentObjectType (required): Parent object type name

  • filters (optional): Object with optional filters:

    • dateFrom: Start date (YYYY-MM-DD HH:mm)

    • dateTo: End date (YYYY-MM-DD HH:mm)

    • keyPrefix: Key prefix filter

  • autoPages (optional): Enable automatic pagination (default: true for child objects)

  • maxPages (optional): Maximum pages to fetch when autoPages=true (default: 10, safety limit)

  • pageSize (optional): Objects per page when autoPages=true (default: 1000)

Note: Child object searches default to automatic pagination since hierarchical queries often return large result sets.

Robust Pagination

This MCP server implements a reliable pagination strategy that doesn't rely on potentially unreliable JSM API metadata:

The Problem

JSM Assets API responses include total and isLast fields that can sometimes be inaccurate, leading to incomplete data retrieval.

The Solution

Our robust pagination uses this reliable pattern:

  1. Request N objects (e.g., 1000)

  2. If exactly N objects are returned, assume more pages exist

  3. Continue requesting until returned count < requested count

  4. This ensures complete data retrieval without relying on API metadata

Benefits

  • ✅ Reliable: Gets all data regardless of API metadata accuracy

  • ✅ Safe: Built-in maxPages limits prevent runaway requests

  • ✅ Backward Compatible: Single-page requests still work as before

  • ✅ Transparent: Clear feedback about pages fetched and limits reached

Usage Examples

Get ALL Installation Packages (automatic pagination):

Ask Claude: "Search for ALL Installation Package assets with automatic pagination"
# Uses autoPages=true to fetch complete results across multiple pages

Large Hierarchical Queries:

Ask Claude: "Find all child objects of Hardware type - get complete results"
# Child object searches use automatic pagination by default

Single Page (traditional):

Ask Claude: "Search for Installation Package assets starting with IASM (single page only)"
# Uses autoPages=false for single API request

Example Queries

Basic Asset Search

Ask Claude: "Search for all Installation Package assets that start with IASM"

Complete Data Retrieval

Ask Claude: "Get ALL Hardware assets with automatic pagination - don't miss any results"

Hierarchical Search

Ask Claude: "Find all child objects of Hardware type created in the last month"

Schema Exploration

Ask Claude: "What object schemas are available in this workspace?"

Attribute Analysis

Ask Claude: "What attributes are available for object type ID 123?"

API Reference

JSM Assets API Endpoints Used

  • POST /object/aql - AQL searches

  • GET /objectschema/list - List schemas

  • GET /objectschema/{id}/objecttypes/flat - Get object types

  • GET /objecttype/{id}/attributes - Get attributes

Authentication

Uses Basic Authentication with pre-encoded tokens. The token should be Base64 encoded in the format:

email:api_token

Development

Scripts

  • npm run build - Build the TypeScript project

  • npm run dev - Watch mode for development

  • npm run start - Run the built server

  • npm run clean - Clean build artifacts

Project Structure

src/
├── index.ts              # Main MCP server
├── api/                  # JSM API client
│   └── jsmClient.ts
├── tools/                # MCP tool implementations
│   ├── searchAssetsAql.ts
│   ├── getObjectSchemas.ts
│   ├── getObjectTypes.ts
│   ├── getObjectAttributes.ts
│   └── searchChildObjects.ts
├── types/                # TypeScript type definitions
│   └── index.ts
└── utils/                # Utility functions
    └── index.ts

Error Handling

The server includes comprehensive error handling:

  • Input validation for all parameters

  • API error transformation and reporting

  • Graceful fallbacks for missing data

  • Debug logging when enabled

Debugging

Enable debug logging by setting:

DEBUG=true
NODE_ENV=development

Troubleshooting

Common Issues

  1. Authentication Errors

    • Verify your token is correctly encoded

    • Check workspace ID is correct

    • Ensure you have proper JSM Assets permissions

  2. Connection Issues

    • Verify the base URL is correct

    • Check network connectivity

    • Confirm workspace exists and is accessible

  3. Query Errors

    • Validate AQL syntax

    • Check object type names exist

    • Verify schema IDs are correct

Support

For issues with the MCP server implementation, check:

  • Server logs for detailed error messages

  • Environment variable configuration

  • Network connectivity to JSM APIs

  • Token permissions and expiration

License

ISC License - see LICENSE file for details.

Available Tools

5 tools
get_object_attributesC

Get all attributes (fields) for a specific object type. Attributes define what data can be stored for objects of this type.

ParametersJSON Schema
NameRequiredDescriptionDefault
objectTypeIdYesThe ID of the object type to get attributes for

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 full burden but lacks behavioral details. It states this is a read operation ('Get'), but doesn't disclose permissions needed, rate limits, pagination, error conditions, or what the return format looks like. It adds minimal context beyond the basic purpose.

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 two concise sentences with zero waste. It is front-loaded with the core purpose and efficiently explains what attributes are, earning its place without unnecessary elaboration.

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?

Given no annotations and no output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what the return values look like (e.g., list of attributes with details), error handling, or behavioral constraints, leaving significant gaps for an agent to use it effectively.

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%, so the schema already documents the single parameter 'objectTypeId'. The description adds no additional meaning about the parameter, such as where to find object type IDs or format examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('attributes for a specific object type'), specifying what data is retrieved. It distinguishes from sibling tools like 'get_object_types' by focusing on attributes rather than types or schemas, though it doesn't explicitly name alternatives.

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 alternatives like 'get_object_schemas' or 'get_object_types'. It mentions attributes define data storage, but offers no explicit context, exclusions, or prerequisites for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_object_schemasB

List all object schemas available in the JSM Assets workspace. Schemas contain related object types.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/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 behavioral disclosure. It mentions that 'Schemas contain related object types', adding some context about the data structure, but fails to address critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of schema names vs. full details). This leaves significant gaps for a tool with zero annotation coverage.

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, efficient sentence that front-loads the core action ('List all object schemas') and adds necessary context ('available in the JSM Assets workspace') without any wasted words. Every part earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks usage guidelines, behavioral details (e.g., read-only nature, output format), and differentiation from siblings. For a basic list tool, this is minimally viable but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids redundant parameter details, and the baseline score for zero parameters is 4, as it doesn't need to compensate for any gaps in schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all object schemas') with context ('available in the JSM Assets workspace'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_object_types' or 'get_object_attributes', which might have overlapping scopes, preventing a perfect score.

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 alternatives such as 'get_object_types' or 'search_assets_aql'. It lacks explicit instructions on use cases, prerequisites, or exclusions, leaving the agent with minimal context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_object_typesC

Get all object types for a specific schema. Object types define the structure and properties of assets.

ParametersJSON Schema
NameRequiredDescriptionDefault
schemaIdYesThe ID of the object schema to get types for

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 behavioral disclosure. It states the action ('Get all object types') but lacks details on permissions required, rate limits, pagination, or what 'all' entails (e.g., if there are limits on the number returned). The second sentence explains what object types are, but this is conceptual rather than behavioral. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences: the first states the purpose, and the second provides conceptual context about object types. It is front-loaded with the core action. However, the second sentence, while informative, could be considered slightly extraneous if the agent already understands object types from other sources, but it doesn't significantly detract from conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects like permissions or output format. Without an output schema, the description doesn't clarify what is returned (e.g., a list of type names or full definitions), which is a gap. It meets basic needs but leaves room for improvement in context.

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% description coverage, with 'schemaId' clearly documented as 'The ID of the object schema to get types for'. The description adds no additional parameter information beyond what the schema provides, such as format examples or constraints. Since schema coverage is high (>80%), the baseline score of 3 is appropriate, as the schema does the heavy lifting without extra value from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('all object types for a specific schema'), making the purpose understandable. It distinguishes from siblings like 'get_object_attributes' or 'get_object_schemas' by focusing on types rather than attributes or schemas themselves. However, it doesn't explicitly differentiate from 'search_assets_aql' or 'search_child_objects', which might also involve object types indirectly.

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 alternatives. It doesn't mention prerequisites (e.g., needing a schema ID), exclusions, or comparisons to siblings like 'get_object_schemas' (which might list schemas before selecting one for types). Usage is implied through the parameter 'schemaId', but no explicit context is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_assets_aqlA

Search JSM Assets using AQL (Assets Query Language). Supports complex queries with filters and robust automatic pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
aqlQueryYesAQL query string (e.g., "objectType=\"Installation Package\" AND Key startswith IASM")
autoPagesNoEnable automatic pagination to fetch all results (default: false for backward compatibility)
maxPagesNoMaximum number of pages to fetch when autoPages=true (default: 10, safety limit)
pageSizeNoNumber of results per page when autoPages=true (default: 1000)
startAtNoStarting index for single-page requests when autoPages=false (default: 0)
maxResultsNoMaximum number of results for single-page requests when autoPages=false (default: 1000)

TDQS

A3.5/5.0
Behavior3/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 adds some context: 'Supports complex queries with filters' and 'robust automatic pagination,' which hints at capabilities beyond basic search. However, it does not cover critical aspects like authentication needs, rate limits, error handling, or what 'robust' pagination entails, leaving gaps in transparency for a search tool.

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 concise and front-loaded: it states the core purpose in the first sentence and adds key features in the second. Every sentence earns its place by providing essential information without waste, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and hints at capabilities but lacks details on return values, error cases, or integration with sibling tools. Without an output schema, the description should ideally explain what results look like, but it doesn't, making it adequate but not fully comprehensive.

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% description coverage, so the schema already documents all parameters thoroughly. The description does not add any meaning beyond the schema (e.g., it doesn't explain AQL syntax or pagination behavior further). According to the rules, with high schema coverage, the baseline is 3, which is appropriate here as the description doesn't compensate but doesn't detract either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search JSM Assets using AQL (Assets Query Language).' It specifies the verb ('Search'), resource ('JSM Assets'), and method ('using AQL'), which is specific and informative. However, it does not explicitly distinguish this tool from its siblings (e.g., 'search_child_objects'), missing full differentiation for a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning 'Supports complex queries with filters and robust automatic pagination,' suggesting it's for advanced searches. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'search_child_objects') or any exclusions, leaving usage context implied rather than clearly defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_child_objectsA

Search for child objects of a specific parent object type, with optional filters and robust automatic pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
parentObjectTypeYesName of the parent object type to search children for
filtersNoOptional filters to apply to the search
autoPagesNoEnable automatic pagination to fetch all results (default: true for child objects)
maxPagesNoMaximum number of pages to fetch when autoPages=true (default: 10, safety limit)
pageSizeNoNumber of results per page when autoPages=true (default: 1000)

TDQS

A3.5/5.0
Behavior3/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 mentions 'robust automatic pagination,' which adds valuable context about how results are fetched. However, it doesn't disclose other important behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what the return format looks like. The description adds some behavioral context but leaves significant gaps.

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, well-structured sentence that efficiently communicates the core functionality: searching child objects, optional filters, and automatic pagination. Every element earns its place with zero wasted words, making it appropriately sized and front-loaded for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters with nested objects, no output schema, and no annotations), the description is moderately complete. It covers the main purpose and hints at behavior (pagination), but lacks details on return values, error handling, or how this tool relates to siblings. Without annotations or output schema, the description should ideally provide more context about what results look like and operational constraints.

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%, so the schema already documents all parameters thoroughly. The description mentions 'optional filters' and 'robust automatic pagination,' which aligns with the schema but doesn't add significant semantic meaning beyond what's already in the parameter descriptions. No additional parameter context or examples are provided in the description, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for child objects of a specific parent object type' - this is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_assets_aql' or 'get_object_types', which might also involve searching or retrieving object information. The description is clear but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through 'with optional filters and robust automatic pagination,' suggesting this is for retrieving child objects with filtering capabilities. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_assets_aql' or 'get_object_types,' nor does it mention any prerequisites or exclusions. The usage is implied rather than explicitly stated.

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.

  1. 5 tool updates
    • First observedget_object_attributes
    • First observedget_object_schemas
    • First observedget_object_types
    • First observedsearch_assets_aql
    • First observedsearch_child_objects
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

B3.4/5.0

Scored across 5 tools

Disambiguation4/5

The tools are mostly distinct, with clear separation between metadata retrieval (get_object_attributes, get_object_schemas, get_object_types) and search operations (search_assets_aql, search_child_objects). However, the two search tools could potentially be confused, as both handle search with filters and pagination, though they target different scopes (general AQL vs. child-specific).

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structure (e.g., get_object_attributes, search_assets_aql). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count4/5

With 5 tools, the count is reasonable for a JSM Assets server, covering core metadata and search operations. It is slightly lean but well-scoped, as each tool serves a distinct purpose without obvious bloat or redundancy, though it might benefit from additional CRUD tools for completeness.

Completeness3/5

The toolset provides good read/search capabilities for JSM Assets, including metadata exploration and asset queries. However, there are notable gaps in CRUD operations—no tools for creating, updating, or deleting assets or schemas, which limits agents to read-only workflows and may cause failures in scenarios requiring modifications.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers