The INDI MCP Server lets you control astrophotography equipment and manage an INDI server via the Model Context Protocol (MCP).
INDI Server Management
Start the INDI server (indiserver) on a specified port (default: 7624)
Stop, restart, and check the running status and port of the INDI server
Driver Management
List all installed drivers from the INDI catalog (name, label, version, family, binary, install status)
Start a driver by its catalog label (e.g. "CCD Simulator")
Stop a running driver by its catalog label
List all currently running drivers
INDI Event Monitoring / Messaging
Start/stop streaming INDI property and message events from the server
Check whether the event stream is active and on which host/port
Retrieve recent INDI events (newest first), optionally filtered by device name
Equipment Control
Send property commands to connected INDI devices — set named elements on a device's property to control mounts, cameras, filter wheels, focusers, and other astrophotography gear
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@INDI MCP Server Connect to the ASI1600MM camera and set exposure to 30 seconds."
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.
An MCP server that controls astrophotography equipment via INDI on a Raspberry Pi (or equivalent device), and exposes it to other computers on the local network.
Equipment control — connect to an INDI server and control mounts, cameras, filter wheels, focusers and other astrophotography gear through MCP tools.
INDI server management — manage the INDI server itself: install/remove drivers, and start, stop or restart the server, all via MCP.
Frame storage — captured frames are stored on the Raspberry Pi and can be listed, inspected and transferred to another computer on the local network via MCP.
Related MCP server: mcp-server-ascom
Deployment — running the server locally (stdio) vs. as a
systemd service on the Raspberry Pi (streamable-http)
Rig YAML Schema — field reference for rigs/*.yaml imaging rig
definitions
Observatory Location YAML Schema — field reference for
observatories/*.yaml location definitions
Script YAML Schema — field reference for the YAML scripting layer;
built-in primitive/composed scripts ship under scripts/
Property/Message JSON Payload Schema — field reference for the
kind/type-tagged JSON carried inside MCP tool results and event streams
indi-mcp-cli is a small standalone tool for manually testing/debugging the INDI server and
driver management tools, without needing an MCP client:
uv run indi-mcp-cli server status
uv run indi-mcp-cli server start --port 7624
uv run indi-mcp-cli driver list
uv run indi-mcp-cli driver start "CCD Simulator"
uv run indi-mcp-cli listen --device "CCD Simulator" # prints incoming events until Ctrl+CThe driver catalog is read from /usr/share/indi/ by default, which only exists where INDI's
drivers are actually installed (e.g. the Raspberry Pi). On a machine with a local INDI install
elsewhere (e.g. Homebrew on macOS, typically /usr/local/share/indi or
/opt/homebrew/share/indi), point the server at it via INDI_MCP_DRIVER_CATALOG_DIR
(INDIMCP-128) — this applies to the MCP server itself, not just indi-mcp-cli's driver
subcommands, since both read the same catalog:
export INDI_MCP_DRIVER_CATALOG_DIR=/usr/local/share/indi
uv run indi-mcp-cli driver listEarly setup stage — MCP server skeleton in place, with INDI server management tools (start/stop/restart/status) implemented.
Python 3.12+, managed with uv
Official Python MCP SDK (mcp)
indipyclient — pure-Python INDI client, used for equipment control
indiweb — used as a library only (its IndiServer/DriverCollection classes), for indiserver process/FIFO control and driver-catalog parsing; its bundled web app is not used
astropy — celestial-geometry computation (Sun/Moon position, illumination) for capture_frame's FITS header enrichment, see docs/FitsHeaders.md
Ruff for linting and formatting
ty for static type checking
pytest, with pytest-asyncio and pytest-cov
pre-commit to run the above on every commit
uv sync --dev
uv run pre-commit installCommon tasks:
uv run ruff check . # lint
uv run ruff format . # format
uv run ty check . # type-check
uv run pytest --cov # testThis project follows a git-flow-style workflow:
main — always releasable; only accepts merges from release/* or hotfix/* branches.
develop — integration branch for ongoing work.
feature/* — branched from and merged back into develop.
A CI check (enforce-merge-policy) rejects pull requests that don't follow these rules.
Report whether the INDI messaging stream is running, and its host/port.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| port | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read-only operation but does not explicitly state non-destructiveness or side effects. Acceptable for a simple status check but could be more explicit.
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 concise sentence that front-loads the purpose. Every word adds value, with no unnecessary information.
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 zero parameters and the presence of an output schema (which covers return values), the description is complete. It states exactly what the tool reports without requiring further detail.
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?
There are zero parameters, so the description adds no additional meaning beyond the empty schema. Baseline 4 is appropriate per guidelines for no parameters.
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 verb 'report' and the resource 'INDI messaging stream', specifying exactly what is reported (running status and host/port). It effectively distinguishes from sibling tools like get_indi_server_status and list_indi_messages.
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 alternatives, such as when to check messaging vs server status. The description only states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether the INDI server (indiserver) is running, and on which port.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| port | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states a read operation, but does not mention whether authentication is needed, error handling, or any side effects. Additional context like latency or dependency on network is missing.
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, clear sentence with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core functionality. However, it could mention that the tool returns additional fields if the server is running, or note that it assumes network access. Output schema exists but is not detailed here.
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?
There are no parameters, and schema coverage is 100%. The description adds value by specifying that the output includes the port, which is not obvious from the name alone. High baseline applies.
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 reports whether the INDI server is running and on which port. The verb 'report' and resource 'INDI server status' are specific, and it distinguishes from siblings like start_indi_server and stop_indi_server.
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 vs alternatives, such as checking status before starting the server. No explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every INDI driver installed on this device, whether or not it is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately describes a read-only listing operation with no side effects, which is adequate for a simple list tool. It does not mention any potential performance or authorization details, but these are not critical for this 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, concise sentence that is front-loaded with the verb and resource. Every word adds value, with no unnecessary information.
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 simplicity (no parameters, output schema present), the description is complete. It explains what the tool does and its scope relative to siblings, leaving no gaps for this use case.
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 tool has zero parameters, so the description need not add parameter details. Baseline for no parameters is 4, and the description does not introduce confusion.
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 verb 'List' and the resource 'every INDI driver installed on this device', and explicitly distinguishes from the sibling 'list_running_indi_drivers' by noting it includes drivers whether or not they are running.
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 implies when to use this tool (when you need all drivers) versus the sibling that lists only running ones. However, it does not explicitly state exclusions or provide alternative tool names, so a slightly lower score is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recently seen INDI events, newest first, optionally filtered to one device.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| device | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions recency and filtering but omits details like default limit behavior, pagination, rate limits, or any side effects.
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?
Single sentence is concise and front-loaded with purpose. However, lacks structure; could be split into bullet points or additional sentences for clarity.
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?
With an output schema present, description need not detail return values, but it fails to explain how to interpret results or what 'events' entails. Lacks context on the nature of INDI events.
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 0%. Description only clarifies the 'device' parameter as optional filter. The 'limit' parameter is not explained; its meaning and default are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List', resource 'INDI events', ordering 'newest first', and optional filter by device. This differentiates from sibling tools like list_indi_driver_catalog.
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 explicit guidance on when to use this tool vs alternatives, no prerequisites or exclusions. Usage is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently running INDI drivers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states that the tool lists 'currently running' drivers, implying a read-only, safe operation. However, it does not explicitly confirm idempotency, lack of side effects, or authentication requirements, which is acceptable for a simple list tool but not highly transparent.
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 with no unnecessary words. It is front-loaded with the core action and resource, earning its place completely.
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 simplicity (0 parameters, no annotations) and the presence of an output schema, the description is complete enough. It conveys everything needed to understand the tool's purpose and scope.
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 tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. Per guidelines, 0 parameters earns a baseline of 4. The description adds no parameter info, which is appropriate.
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 action ('list') and the resource ('all currently running INDI drivers'). It distinctively sets this tool apart from siblings like 'list_indi_driver_catalog' (which lists available drivers) and 'list_indi_messages'.
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 explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where this tool is preferred, nor does it exclude cases where sibling tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the INDI server (indiserver), optionally switching to a new port.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No |
| Name | Required | Description |
|---|---|---|
| port | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions restart and optional port. Missing details such as whether it stops running drivers, disconnects clients, or requires authentication. Minimal behavioral disclosure.
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?
Single sentence, front-loaded with action and resource, no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about restart behavior (stop then start), return values, and impact on connected components. With an output schema and sibling tools, more context is needed for full understanding.
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?
Single 'port' parameter with 0% schema description coverage. Description adds that it 'optionally switching to a new port', which provides some meaning beyond schema (integer/null), but doesn't specify default behavior (keep same port). Partially compensates.
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?
Clearly states the verb 'Restart' and the resource 'INDI server (indiserver)', and includes optional port switching. Distinguishes from siblings like start_indi_server, stop_indi_server.
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?
Indicates optional port change, but lacks explicit guidance on when to use vs alternatives like start or stop. Context is clear but no exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a command to an INDI device, setting elements on its property name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| device | Yes | ||
| elements | Yes |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| name | Yes | |
| type | Yes | |
| state | Yes | |
| device | Yes | |
| message | Yes | |
| elements | Yes | |
| timestamp | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies mutation ('setting elements') but does not disclose side effects, permissions needed, or whether the command is destructive. For a tool that modifies device state, this is insufficient.
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 concise sentence with no redundancy. It front-loads the action and target. However, it could benefit from slight expansion to improve clarity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 3 parameters including a nested object, and an output schema, the description is too short. It fails to explain the purpose of the output, provide examples, or cover edge cases. The tool appears to be a write operation but lacks sufficient context.
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 0%, yet the description only briefly mentions 'property name' and 'elements' without clarifying their meaning or valid values. 'device' is not explained. The description adds minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send a command'), the target ('INDI device'), and the effect ('setting `elements` on its property `name`'). It differentiates from sibling tools which are about listing, starting, stopping, etc. However, it could be more explicit about the relationship between 'command' and 'property'.
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 alternatives like list_indi_driver_catalog or start_indi_driver. There is no mention of prerequisites, common use cases, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the INDI driver identified by its catalog label (e.g. "CCD Simulator").
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes |
| Name | Required | Description |
|---|---|---|
| label | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks disclosure of side effects, failure modes, or requirements like driver availability or permissions.
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?
Single sentence, no redundancy, purpose front-loaded. Could be more efficient but no excess words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and an output schema, but description doesn't reference the catalog or output. Could be more complete for safe invocation.
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 has 0% description coverage; description adds an example but does not explain what constitutes a valid label or how to obtain it.
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?
Clearly states it starts an INDI driver by catalog label with a concrete example. Distinct from siblings like stop_indi_driver or start_indi_server.
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?
Implicitly suggests the label comes from a catalog, but no explicit guidance on when to use vs alternatives, prerequisites, or linking to list_indi_driver_catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the INDI server and start streaming its property/message events.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | localhost | |
| port | No |
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| port | Yes | |
| running | Yes |
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 reveals the tool establishes a connection and starts streaming, but lacks details on lifecycle (e.g., how to stop, behavior if already connected, whether it blocks).
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, well-structured sentence that front-loads the main action. It is concise but could include more detail without becoming verbose.
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 that the tool has only two simple parameters and an output schema exists, the description is minimally adequate. However, it lacks information on the streaming behavior, connection lifecycle, and parameter usage.
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 0%, and the description does not mention the 'host' and 'port' parameters or their meanings. The description adds no value beyond the default values and types already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: connect to an INDI server and start streaming events. The verb 'connect' and resource 'property/message events' are specific, differentiating it from sibling tools like stop_indi_messaging or get_indi_messaging_status.
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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_indi_messaging_status). Usage context is only implied, with no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the INDI server (indiserver) on the given port.
Restarts it if it is already running.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No |
| Name | Required | Description |
|---|---|---|
| port | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the server restarts if already running, which is behavioral. No annotations exist, so this adds value, but lacks details on safety, prerequisites, or side effects.
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?
Two concise sentences, front-loaded with purpose. No wasted words, but could be slightly more structured for clarity.
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?
Adequate for a simple tool with one optional parameter and an output schema. Lacks context on when to use vs. restart_indi_server, and missing details on output or prerequisites.
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 coverage is 0%, and the description only mentions 'on the given port' without explaining the port parameter, default value (7624), or validity. Insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts the INDI server on a given port and includes the restart behavior. However, it does not differentiate from the sibling tool 'restart_indi_server', potentially causing confusion.
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 explicit guidance on when to use this tool versus alternatives like restart_indi_server. Only states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the running INDI driver identified by its catalog label.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes |
| Name | Required | Description |
|---|---|---|
| label | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects, whether the stop is graceful or forceful, or any safety implications. For a stop operation, more transparency is needed.
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?
Single sentence directly conveying the purpose with no extraneous words. Front-loaded with action and target.
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?
Despite having an output schema, the description omits any mention of return values or confirmation. Does not state prerequisites (e.g., driver must be running) or resulting state. Incomplete for a stop tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'label' is described only as 'catalog label', which echoes the schema. Schema coverage is 0%, yet the description does not explain what a catalog label is or how to obtain it, failing to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'stop' and resource 'running INDI driver', and specifies identification method 'catalog label'. Distinguishes from sibling tools like start_indi_driver and stop_indi_messaging.
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?
Implied usage context from the name and sibling tools, but no explicit guidance on when to use this tool vs alternatives, no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from the INDI server and stop streaming its events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| port | Yes | |
| running | Yes |
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 the main effect (disconnect and stop streaming) but lacks details on side effects, required state, or impact on other tools. With zero annotations, this is minimally adequate.
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 clear sentence with no redundant information. It is front-loaded and efficiently communicates the tool's function.
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 has no parameters and is a simple action, the description is adequate but could be more complete by mentioning relationship to sibling tools like stop_indi_server or specifying that it does not stop the server itself. The presence of an output schema does not compensate for missing usage context.
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 tool has no parameters, so schema coverage is 100% by default. The description does not need to add parameter meaning, earning a baseline score of 4.
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 action: 'Disconnect from the INDI server and stop streaming its events.' It uses specific verbs and resources, and distinguishes the tool from siblings like start_indi_messaging and stop_indi_server.
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 on when to use this tool versus alternatives such as stop_indi_server or restart_indi_server. The description does not specify prerequisites or expected state, leaving the agent without 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.
Stop the running INDI server (indiserver).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| port | Yes | |
| running | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Stop the running INDI server'. It does not disclose behavioral traits such as idempotency, error handling if server not running, or side effects.
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 with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists but not shown), the description is adequate but minimal. It could add context about expected behavior (e.g., if the server is not running).
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?
There are no parameters, so the description does not need to add parameter information. Baseline 4 is appropriate.
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 verb 'Stop' and the resource 'INDI server', with the specific command name. It distinguishes from siblings like start_indi_server and restart_indi_server.
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 implies when to use (when you want to stop the server) but provides no explicit guidance on when not to use or alternatives (e.g., if server is already stopped).
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.
v0.1.0get_indi_messaging_statusget_indi_server_statuslist_indi_driver_cataloglist_indi_messageslist_running_indi_driversrestart_indi_serversend_indi_propertystart_indi_driverstart_indi_messagingstart_indi_serverstop_indi_driverstop_indi_messagingstop_indi_serverScored across 13 tools
Every tool targets a distinct operation: server control, driver management, messaging, listing, and property sending. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., start_indi_server, list_indi_driver_catalog, send_indi_property.
13 tools provide complete coverage for managing an INDI server and its drivers without being excessive; each tool serves a clear purpose.
Covers all major operations: server lifecycle, driver start/stop, messaging, and property setting. Minor gap: no dedicated tool to query a driver's current property state, though messages provide partial coverage.
Hosted MCP server for task-first delegation to remote workstations and workers.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
Documentation for the Spektralwerk spectrometer SCPI API as a streamable HTTP MCP Server
