How do I use genicam-mcp?

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., "@genicam-mcp List available cameras" 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.

genicam-mcp

by finnhyun12

Overview Schema Source Related Servers Discussions Admin

Python

Local

genicam-mcp

Vendor-neutral industrial camera control via GenICam GenTL.

An MCP server that enumerates, connects to, configures, and captures from industrial cameras through the GenICam GenTL standard — not through a single vendor's SDK.

Point it at any GenTL producer (.cti) and you get the camera's entire GenICam feature tree: exposure, gain, trigger, ROI, pixel format, and everything else the camera exposes.

Why this exists

Existing camera MCP servers bind to one vendor's SDK (typically pypylon, Basler-only) and expose a single "grab a frame" call. This one goes through the vendor-neutral GenTL layer instead, so one code path is meant to drive any GenTL-compliant camera — Basler, HIKrobot, Teledyne FLIR, Allied Vision, XIMEA — regardless of vendor. (Actually tested producers are listed under Verified below.) It also exposes feature control, not just capture.

No vendor SDK is imported. The only path to the hardware is harvesters → .cti. That constraint is the point of the project.

Related MCP server: dwf-mcp-server

Install

Requires Python 3.12 (the genicam wheels this depends on are version-specific).

git clone https://github.com/finnhyun12/genicam-mcp.git
cd genicam-mcp
uv venv --python 3.12
uv sync

Claude Desktop setup

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "genicam": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/genicam-mcp", "run", "genicam-mcp"]
    }
  }
}

If uv is not on your PATH, point at the venv interpreter directly:

{
  "mcpServers": {
    "genicam": {
      "command": "/absolute/path/to/genicam-mcp/.venv/bin/python",
      "args": ["-m", "genicam_mcp.server"]
    }
  }
}

On Windows use .venv\\Scripts\\python.exe and escape backslashes in JSON.

Tools

Tool	Purpose
`add_producer(cti_path)`	Register a GenTL producer (`.cti`). Call this first. Multiple producers may be registered.
`discover_cameras()`	List cameras: `index`, `vendor`, `model`, `serial`, `tl_type`.
`connect(index)`	Open a camera. Required before feature access or capture.
`disconnect()`	Release the camera.
`list_features(category=None)`	Walk the node map. Returns name, type, readable/writable, current value, range or options.
`get_feature(name)`	Read one feature with its type and `min`/`max` (or enum options).
`set_feature(name, value)`	Write any GenICam feature — `ExposureTime`, `Gain`, `TriggerMode`, `PixelFormat`, `Width`… Values are cast to the node's type.
`grab(save_path=None)`	Capture one frame → PNG. Returns `width`, `height`, `pixel_format`, `saved_path`.

Feature names are case-sensitive and vary by camera. Use list_features() to see what a given camera actually offers rather than guessing.

Finding a `.cti` producer

Vendor SDKs install their producers and register the directory in the GENICAM_GENTL64_PATH environment variable:

# Linux / macOS
echo $GENICAM_GENTL64_PATH

# Windows
$env:GENICAM_GENTL64_PATH

Common locations:

Vendor	Producer
Allied Vision Vimba X	`.../Vimba X/cti/VimbaGigETL.cti`, `VimbaUSBTL.cti`
Basler pylon	`.../pylon 6/Runtime/x64/ProducerGEV.cti`, `ProducerU3V.cti`
HIKrobot MVS	`.../Common Files/MVS/Runtime/Win64_x64/MvProducerGEV.cti`, `MvProducerU3V.cti`

If add_producer is given a bad path, the error message lists the .cti files it found on your machine.

Demo without hardware

Allied Vision Vimba X ships a Camera Simulator TL — a GenTL producer that presents simulated cameras with real test-pattern frames. No camera required.

Install Vimba X (free).
Register the simulator producer and grab a frame:

add_producer("C:\\Program Files\\Allied Vision\\Vimba X\\cti\\VimbaCameraSimulatorTL.cti")
discover_cameras()
connect(0)
set_feature("TestPattern", "GreyVerticalRamp")
grab("frame.png")

This is the exact producer path used for the end-to-end verification below. On that machine it enumerated three simulated cameras; index 0 was Camera Simulator (G1-030_VSWIR) at 656×520 Mono8. TestPattern accepts Off, GreyVerticalRamp, GreyVerticalRampMoving, ColorVerticalBar, ColorHorizontalBar, and ColorVerticalBarMoving — check get_feature("TestPattern") on your install rather than assuming, since the simulator's model list can differ by Vimba X version.

Note: a vendor's virtual camera feature is not the same thing as a simulator transport layer. Basler's pylon Camera Emulator (PYLON_CAMEMU) and HIKrobot's MVS Virtual Device both live above the GenTL layer and are visible only through their own vendor SDKs — GenTL consumers cannot see them. Vimba X's Camera Simulator is itself a .cti, which is why it works here.

Verified

✅ End-to-end (enumerate → connect → feature R/W → grab → PNG): Allied Vision Vimba X — Camera Simulator TL (GenTL producer)
✅ Producer load & camera enumeration: Basler pylon ProducerU3V.cti

genicam-mcp is built against the GenICam GenTL standard and is expected to work with any compliant producer (Basler, HIKrobot, Teledyne FLIR, Allied Vision, XIMEA, …). Only the producers listed above are actually tested; others are unverified — field reports welcome.

Development

uv run pytest                    # fake-GenTL suite; no hardware, no SDK

The real-producer suite is gated on an env var so day-to-day runs stay fast:

GENTL_CTI=/path/to/Producer.cti uv run pytest -m real_producer -v -s

If GENTL_CTI is set but no camera is found, the suite fails rather than skipping — a gate that silently passes is not a gate.

Known quirks

These are documented because each one looks like a broken server when you hit it cold. Knowing them in advance turns a bug report into a shrug.

First add_producer can be slow. Basler's ProducerU3V.cti took over 60 s on its first load (USB bus enumeration). Nothing is wrong — it is enumerating the bus. Allow a generous tool timeout on the first call; a short client timeout will cancel the request and can tear down the MCP session with it.
A bad producer can take the process down. MvFGProducerCML.cti segfaults (0xC0000005) when loaded without Camera Link hardware. This happens inside the native library, so no Python try/except can catch it — register only producers that match your hardware.
Trigger mode blocks capture. If TriggerMode is On, grab() waits for a trigger and then times out. Set set_feature("TriggerMode", "Off") for free-run.

Implementation notes

Three findings shaped this code. They are recorded here because none of them is visible from the source alone, and each cost real time to track down.

A vendor "virtual camera" is not a simulator transport layer. Basler's pylon Camera Emulator (PYLON_CAMEMU) and HIKrobot's MVS Virtual Device both look like the answer to "test without hardware" — and both are invisible to GenTL. They live above the GenTL boundary, inside the vendor SDK, so only that vendor's own tools can see them. Measured on HIKrobot MVS: the vendor SDK enumerated the virtual camera (MV_VIR_GIGE_DEVICE → 1 device, and only when run elevated), while MvProducerGEV.cti reported 0 through the same machine. Vimba X's Camera Simulator works because it is a .cti. The question to ask of any "virtual camera" feature is not whether it exists but which layer it lives in.

Import the native extensions at module load, never inside a tool call. Deferring import harvesters into the tool body seems tidy — it lets the module import cleanly on machines with no SDK. But FastMCP runs tool functions off the event loop, and loading the genicam native extension there hangs forever: the server accepts the CallToolRequest and then simply never answers. A silent hang is far worse than an immediate error, because the client only sees a timeout and the user has nothing to go on. So the import happens at module load and the failure reason is stashed and raised, as a readable message, at first use.

A GenTL buffer is borrowed, not owned. ia.fetch() hands out a buffer from the acquisition queue; once it is returned, the memory is recycled. Keeping a numpy view past that point does not raise — it silently yields whatever the driver wrote next, which in practice means an all-black frame. This surfaced only against the real Vimba simulator, never against the fakes, because a fake buffer is just a live numpy array. The fake now zeroes its data on __exit__ to model the real lifetime contract, so the failure is reproducible without hardware, and test_real_producer.py asserts the frame is not uniformly zero. A capture test that only checks "a PNG exists" passes on a black image.

Scope

One camera at a time; one frame per grab(). Simultaneous multi-camera acquisition, async streaming, GUI, and web serving are deliberately out of scope.

License

MIT — see LICENSE.

Available Tools

8 tools

add_producerA

GenTL producer(.cti) 파일을 등록한다. 다른 모든 툴보다 먼저 호출해야 한다.

.cti 는 카메라 벤더 SDK 가 설치하는 GenTL 표준 드라이버다. 여러 벤더의
카메라를 동시에 쓰려면 이 툴을 여러 번 호출해 복수 등록하면 된다.
경로가 틀리면 이 PC 에서 발견된 .cti 후보를 에러 메시지에 담아 돌려준다.

Args:
    cti_path: .cti 파일의 절대 경로.

ParametersJSON Schema

Name	Required	Description	Default
`cti_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses registration behavior, call order, multi-vendor usage, and error output with candidates. It does not mention persistence or security implications, but the disclosed behavior is sufficient for typical use.

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 brief and front-loaded with the core purpose. Every sentence adds value: registration, ordering, multi-vendor usage, error behavior, and parameter description. No wasted words.

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?

Given the single parameter and existence of an output schema, the description fully explains the tool's purpose, usage prerequisites, multi-call capability, and error handling. It is complete for its complexity.

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 parameter 'cti_path' is explained as requiring an absolute path, adding meaning beyond the schema's plain string type. With 0% schema coverage, this description fully compensates.

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 clearly states the verb 'registers' and the resource 'GenTL producer (.cti) file'. It also distinguishes the tool as a prerequisite that must be called before all other tools, differentiating it from sibling camera operation tools.

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?

The description explicitly states that the tool must be called before all others and can be called multiple times for multiple vendors. It also describes error behavior for incorrect paths. However, it does not explicitly mention when not to use or provide alternatives, which is acceptable given its role as a mandatory setup step.

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

connectA

카메라에 연결한다. feature 제어와 캡처 전에 반드시 필요하다.

이 서버는 한 번에 한 대만 연결한다. 이미 연결된 상태에서 호출하면 기존
연결을 먼저 해제한다.

Args:
    index: discover_cameras() 가 돌려준 index.

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses that the server connects to only one camera at a time and reconnects by disconnecting first. This provides clear behavioral context beyond the name.

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 concise, front-loaded with purpose, and includes usage context and behavioral notes in a well-structured paragraph format.

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

Completeness4/5

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, the description adequately covers prerequisites and connection behavior. It could mention error handling or timeouts, but overall sufficient.

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?

Schema description coverage is 0%, but the description explains the 'index' parameter as coming from 'discover_cameras()', adding crucial meaning beyond the integer type in the schema.

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 clearly states '카메라에 연결한다' (connect to camera) and explains its prerequisite role for feature control and capture, distinguishing it from sibling tools like disconnect.

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?

The description indicates when to use (before feature control and capture) and notes behavior when already connected (disconnects first). However, it lacks explicit guidance on when not to use or alternatives.

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

disconnectA

현재 카메라 연결을 해제한다. 연결돼 있지 않으면 아무 일도 하지 않는다.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses that the tool does nothing if not connected, which is a helpful behavioral trait. No annotations are present, so the description carries the full burden; it is sufficient for a simple action.

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 sentences, each essential. It is front-loaded with the core purpose and covers the edge case, with no wasted words.

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?

Given zero parameters, an output schema exists, and the tool is simple, the description fully covers the tool's behavior and edge case. No additional information is needed.

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?

There are no parameters, so the schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline 4 for zero-parameter tools.

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 clearly states the verb 'disconnects' and the resource 'current camera connection', and explicitly covers the edge case of doing nothing when not connected, distinguishing it from the sibling tool 'connect'.

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 when the agent needs to disconnect a camera, but does not explicitly state when not to use it or provide alternatives. The context of siblings like 'connect' makes it clear, but no further guidance is given.

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

discover_camerasA

등록된 producer 전체에서 연결 가능한 카메라를 열거한다.

각 항목의 index 를 connect(index) 에 넘긴다. 벤더/모델/시리얼/전송규격
(tl_type: U3V, GEV 등)을 함께 돌려준다. 0대가 나오면 카메라 전원·케이블과
등록한 .cti 가 그 카메라의 전송규격과 맞는지 확인하라.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: it's a read-only discovery enumeration, returns specific data, and provides troubleshooting steps. No hidden side effects or contradictions.

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?

Two sentences: first states purpose, second provides usage instructions and output details. All information is essential, no fluff. Front-loaded with key action.

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?

Given the presence of an output schema, the description covers the tool's role comprehensively: what it does, how to use the result, and troubleshooting for empty results. Meets all needs for a no-parameter tool.

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?

There are zero parameters, and schema coverage is 100%. The description does not need to explain parameters; it focuses on output and usage, which is appropriate. Baseline for 0 params is 4.

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 clearly states it enumerates connectable cameras from registered producers, specifying the output includes vendor/model/serial/transport type. It differentiates from sibling tools like connect (which uses the index) and list_features.

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

Usage Guidelines5/5

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

Explicitly instructs to use the index from this tool with connect(index). Provides diagnostic advice when zero cameras are returned: check power, cable, and .cti transport type match. No ambiguity about when to use.

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

get_featureB

feature 하나의 현재 값과 타입, 허용 범위(min/max) 또는 선택지를 반환한다.

Args:
    name: GenICam feature 이름. 대소문자를 구분한다 (예: 'ExposureTime').

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that the tool reads and returns feature properties, implying a read-only behavior. However, it does not mention potential side effects or required state (e.g., must be connected).

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 concise with two sentences and an Args block. It is front-loaded with the main purpose and adds parameter details directly after.

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?

Output schema exists, so return values are partially covered. The description mentions return fields (value, type, range/options). However, given the camera domain and sibling tools, it lacks context like requiring a connection or that the feature must exist.

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?

Schema has 0% coverage for the 'name' parameter, but the description adds meaning: it is a GenICam feature name, case-sensitive, with an example. This provides valuable context beyond the schema.

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 it returns the current value, type, and allowed range/options of a feature. The verb 'returns' and resource 'feature' are specific. Among siblings like 'list_features' and 'set_feature', it distinguishes well.

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 on when to use this tool versus alternatives. The description only states what it does, without mentioning prerequisites (e.g., need connection) or exclusions.

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

grabA

1프레임을 획득해 PNG 로 저장하고 크기·픽셀포맷·저장경로를 반환한다.

TriggerMode 가 'On' 이면 트리거가 들어올 때까지 대기하다 타임아웃된다.
자유 실행 캡처를 원하면 먼저 set_feature('TriggerMode', 'Off') 를 호출하라.

Args:
    save_path: 저장할 PNG 경로. 생략하면 임시 디렉터리에 저장하고 그
        경로를 돌려준다.

ParametersJSON Schema

Name	Required	Description	Default
`save_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: saves to PNG, handles trigger modes, timeout behavior, and returns size/pixel format/path. It does not mention errors or permissions, but for a simple capture tool this is sufficient.

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 extremely concise with two paragraphs. The first sentence states the core purpose, the second adds trigger mode context. Every sentence earns its place, and it is front-loaded.

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?

Given the presence of an output schema (so return values need not be described), the description covers the essential behavior (capture, save, trigger mode, parameter semantics). Sibling tools are unrelated, so no confusion. The description is complete for this tool.

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

Parameters5/5

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

The single parameter save_path has 0% schema description coverage, but the description fully compensates: it explains that if omitted, the file saves to a temp directory and the path is returned. This adds significant meaning beyond the schema.

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 clearly states the verb 'acquire' and resource '1 frame', and specifies the actions: save as PNG, return size/pixel format/path. It is distinct from sibling tools (connect, add_producer, etc.) that manage camera connections and features.

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?

The description explains when to use based on TriggerMode: 'On' waits for trigger, 'Off' for free-run. It suggests calling set_feature('TriggerMode', 'Off') for free-run capture. While it doesn't explicitly list alternatives or exclusions, the context is clear enough.

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

list_featuresA

카메라가 실제로 제공하는 GenICam feature 목록을 반환한다.

카메라마다 지원 feature 가 다르므로, get_feature/set_feature 로 이름을
추측하기 전에 이 툴로 확인하는 것이 확실하다. 각 항목은 이름·타입·
읽기/쓰기 가능 여부·현재 값을 담는다.

Args:
    category: 지정하면 해당 카테고리 서브트리만 반환한다
        (예: 'AcquisitionControl', 'ImageFormatControl'). 생략하면 전체.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

Since no annotations are present, the description carries the full burden. It describes the operation as a read-only list, detailing the output fields (name, type, read/write, current value). While it doesn't explicitly state 'read-only', the context is clear.

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 well-structured: first sentence states purpose, second provides usage advice, third details output content, and finally the parameter description. Every sentence adds value.

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?

Given the simple interface (one optional parameter, no required fields) and the presence of an output schema, the description sufficiently covers behavior and return values. It also fits well within the sibling toolset.

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

Parameters5/5

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

The input schema has one optional parameter (category) with 0% description coverage. The description compensates fully by explaining its purpose (filter by category subtree) and providing concrete examples ('AcquisitionControl', 'ImageFormatControl').

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 clearly states that the tool returns the list of GenICam features provided by the camera. It explicitly distinguishes itself from sibling tools like get_feature/set_feature by emphasizing that it should be used first to avoid guessing.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: use this tool before get_feature/set_feature to verify supported features, as they vary per camera. It also explains the optional category parameter for filtering.

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

set_featureA

GenICam feature 값을 설정한다 (노출·게인·트리거·픽셀포맷·ROI 등).

값은 대상 노드 타입에 맞춰 자동 캐스팅된다. 설정에 실패하면 허용 범위나
선택 가능한 값을 에러 메시지에 담아 돌려준다.

일부 feature 는 선행 조건이 있다. 예를 들어 ExposureTime 을 바꾸려면
ExposureAuto 를 먼저 'Off' 로 두어야 하는 카메라가 많다.

Args:
    name: GenICam feature 이름 (예: 'ExposureTime', 'Gain', 'TriggerMode').
    value: 설정할 값. 숫자/문자열/불리언.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It discloses auto-casting behavior and error handling (failure returns allowed values in error message), and hints at preconditions. However, it does not mention side effects (e.g., implicit changes to dependent features), persistence of settings, or whether the tool requires an active connection. The disclosure is adequate but not comprehensive.

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 reasonably concise, with a short introduction followed by behavior details and parameter documentation. The inclusion of an example in the precondition section adds clarity without excessive length. Minor redundancy (e.g., '설정한다' and '설정에 실패하면' could be tighter) but overall well-structured.

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

Completeness4/5

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

Given the output schema exists, return values are covered externally. The description covers parameter semantics, failure behavior, and preconditions, which are the main contextual needs for a setter tool with two required parameters. One could argue it should mention that a connected camera is implied, but since sibling tools include connect/disconnect, it's reasonably 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?

With 0% schema description coverage, the description must fully explain parameters. It does so for both 'name' (GenICam feature name) and 'value' (number/string/boolean), adding typing info beyond the schema's minimal type definition. While it could be more detailed (e.g., valid ranges for common features), it provides solid semantics for an AI agent to use the tool correctly.

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 clearly states the tool sets GenICam feature values (노출·게인·트리거·픽셀포맷·ROI 등), with specific verb '설정한다' and resource 'GenICam feature'. It distinguishes from sibling tools like list_features, get_feature, and grab by focusing on setting, not reading or listing. Examples further clarify scope.

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?

The description provides guidance on when to use this tool by mentioning auto-casting of values and error messages containing allowed ranges if setting fails. It includes a concrete example of a precondition (ExposureAuto must be 'Off' to set ExposureTime), which helps agents avoid common pitfalls. However, it lacks explicit when-not-to-use or alternatives beyond precondition context.

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.

8 tool updatesv0.1.0Jul 28, 2026
- First observedadd_producer
- First observedconnect
- First observeddisconnect
- First observeddiscover_cameras
- First observedget_feature
- First observedgrab
- First observedlist_features
- First observedset_feature

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.2/5.0

Scored 2026-07-28 10:00 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: registration (add_producer), discovery (discover_cameras), connection (connect/disconnect), feature inspection (list_features, get_feature), feature modification (set_feature), and image capture (grab). No overlap.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern (e.g., add_producer, discover_cameras, set_feature). No mixing of conventions.

Tool Count5/5

8 tools is well-scoped for a camera control server. Each tool serves a necessary role without redundancy or bloat.

Completeness4/5

Covers the full lifecycle: producer registration, camera discovery, connection, feature configuration, image capture, and disconnection. Minor gap: no built-in support for continuous or burst capture, but single-frame grab and trigger control via set_feature suffice for basic use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Caliper A
fit.caliper
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
Design Tools Software Architecture
102
FoundryNet — Industrial Machine Intelligence A
io.github.FoundryNet
Cross-OEM industrial machine intelligence: identity, normalization, automation, attestation.
Monitoring Security Embedded system
2
ChiR24-unreal_mcpOAuth
ai.smithery
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Developer Tools App Automation Multimedia Processing
2866
OmniDebugLink AOAuth
dev.omnidebuglink.api
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Coding Agents Developer Tools
61

Related MCP Servers

OpticMCP
Image & Video Processing Multimedia Processing
Timorleiderman
A
license
Not graded
quality
C
maintenance
Provides camera and vision tools for AI assistants to list available cameras, capture images from USB cameras, and save frames to disk for use with LLMs.
Updated 8 months ago (2026-01-03 08:45 UTC)
4
MIT
dwf-mcp-server
Embedded system
KenosInc
A
license
Not graded
quality
C
maintenance
Enables control of Digilent WaveForms instruments (oscilloscope, AWG, logic analyzer) over USB, supporting devices like Analog Discovery 2/3 and Digital Discovery.
Updated a month ago (2026-08-05 01:14 UTC)
3
MIT
Hikrobot Camera MCP Server
Image & Video Processing Embedded system
pharoskgg
F
license
Not graded
quality
C
maintenance
Enables control of Hikvision industrial cameras via MCP, including enumeration, image capture, parameter adjustment, and firmware upgrade.
Updated 2 months ago (2026-07-13 10:45 UTC)
-
obsbot-mcp
Home Automation & IoT Image & Video Processing
lxman
A
license
B
quality
A
maintenance
Controls an OBSBOT Tiny 2 camera gimbal, zoom, and wake/sleep over UVC/USB without any vendor SDK.
Updated 12 days ago (2026-09-02 00:41 UTC)
34
90 npm
MIT

genicam-mcp

Why this exists

Install

Claude Desktop setup

Tools

Finding a .cti producer

Demo without hardware

Verified

Development

Known quirks

Implementation notes

Scope

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Finding a `.cti` producer