Skip to main content
Glama
manikumarkv

imageright-mcp

by manikumarkv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

imageright-mcp

An MCP server that helps AI coding assistants work correctly against Vertafore ImageRight on your product version (24.x, 25.x, or 7.2).

Status: pre-alpha (M0 scaffold). Only the ir_get_config tool exists so far. The planned phase-1 tools are an offline API explorer covering REST v1, REST v2, and SOAP, a version-aware client, a custom error catalog, and dry-run previews. None of them are here yet.

Install

pip install imageright-mcp   # not published yet; for now: pip install -e ".[dev]"

Related MCP server: code-context

Run

The server speaks MCP over stdio:

imageright-mcp

Claude Code:

claude mcp add imageright -e IMAGERIGHT_VERSION=24.x -- imageright-mcp

Configuration

Values come from environment variables first, then an optional JSON config file, then built-in defaults. ir_get_config reports the effective value of each setting and where it came from.

Setting

Env var

Default

irVersion

IMAGERIGHT_VERSION

24.x

restBaseUrl

IMAGERIGHT_REST_BASE_URL

none

soapUrl

IMAGERIGHT_SOAP_URL

none

authMode

IMAGERIGHT_AUTH_MODE (password | jwt | saml)

password

surfacePreference

IMAGERIGHT_SURFACE_PREFERENCE (comma-separated)

rest-v2,rest-v1,soap

writeMode

IMAGERIGHT_WRITE_MODE (deny | dry-run | allow)

dry-run

dryRun

IMAGERIGHT_DRY_RUN

false

username

IMAGERIGHT_USERNAME

none

password

IMAGERIGHT_PASSWORD (env only)

none

Set IMAGERIGHT_CONFIG_FILE to the path of a JSON file whose keys are the setting names above. The file may not hold secrets. Credentials are read from the environment only, are never accepted as tool arguments, and are always redacted in output.

Tools

Tool

Description

ir_get_config

Effective configuration with secrets redacted, the catalog profile the version maps to, and the source of each value

Development

python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
ruff check . && ruff format --check . && mypy && pytest

Trademarks and affiliation

This is an independent, unofficial project. It is not affiliated with, endorsed by, or sponsored by Vertafore, Inc. "ImageRight" and "Vertafore" are trademarks of Vertafore, Inc., and belong to their respective owner. They are used here only to describe what this software works with. The API descriptions in this project are written in our own words, and no Vertafore documentation or OpenAPI files are redistributed.

License

MIT

Available Tools

1 tool
ir_get_configGet effective configurationA
Read-onlyIdempotent

Show the configuration this server is using right now: ImageRight version and the catalog profile it maps to, REST and SOAP endpoints, auth mode, surface preference, write mode, and dry-run default. Each field reports where its value came from (env, file, or default). Secrets are always redacted.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the operation as read-only and idempotent, so the description does not need to restate safety. It adds useful behavioral context beyond the annotations: secrets are always redacted, and each field includes provenance (env, file, or default). This meaningfully informs the agent about what to expect from the response.

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 dense, front-loaded sentence followed by two crisp notes on provenance and redaction. Every clause adds a distinct piece of useful information, with no filler or repetition of the title.

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

Completeness5/5

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

For a zero-parameter, read-only inspection tool, the description covers what is reported, where the values come from, and the redaction guarantee. Since there is no output schema, enumerating the config categories is sufficient for an agent to know exactly what it will get back.

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 tool has zero parameters and the schema is empty, so the parameter-semantics burden is minimal. The description credits that this is a no-input snapshot operation, and there is nothing else the description must explain about arguments.

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 a specific verb ('Show') with a precise resource ('configuration this server is using right now') and enumerates exactly which fields are reported, from version and endpoints to auth mode and dry-run default. It clearly differentiates itself as the effective configuration view rather than a generic configuration tool.

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

Usage Guidelines4/5

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

With no sibling tools, there is no alternative to contrast, but the description gives clear context for when it should be used: when you need the server's currently effective configuration and its value sources. It does not over-explain invocation prerequisites, but the read-only, inspect-this-state framing is evident.

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. 1 tool updatev0.0.1
    • First observedir_get_config
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

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of overlapping purposes or misselection. The tool's purpose is singular and well-defined.

Naming Consistency5/5

The name ir_get_config follows a clear verb_noun pattern with a consistent product prefix. Even though there is only one tool, the naming convention is predictable and readable.

Tool Count2/5

A single configuration-inspection tool is far too few for a server named after the ImageRight document management platform. The tool count suggests a stub rather than a functional MCP server, leaving agents with no actual operations to perform.

Completeness1/5

The server only exposes configuration details and provides zero tools for interacting with ImageRight documents, folders, or workflows. This is a severely incomplete surface for the implied domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers