Skip to main content
Glama
gorbabor

mc-iclone8-ui-mcp

by gorbabor
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

mc-iclone8-ui-mcp

Serveur MCP local pour piloter l'interface visible d'iClone 8 comme un utilisateur humain.

État actuel : lot 0, lecture seule. Le serveur sait inspecter la fenêtre iClone 8, gérer le focus sans action destructive, capturer l'écran, lire les métadonnées Win32 accessibles et interrompre un workflow. Aucune action de production n'est déclarée réussie sans vérification.

Principes

  • Les actions de production passent par ui_driver, jamais par RLPy.

  • RLPy n'est pas importé dans ce projet.

  • Les coordonnées seules sont interdites : les futurs sélecteurs devront combiner titre, rôle, nom accessible et position comme dernier recours.

  • Les résultats MCP ont toujours le contrat documenté dans docs/protocol.md.

  • Le serveur reste local : transport stdio uniquement, sans appel réseau.

Related MCP server: umbriel

Installation

Prérequis

  • Windows avec une session utilisateur interactive.

  • iClone 8 installé et ouvert pour les tests UI.

  • Python 3.10 ou plus récent.

  • Le serveur doit rester local : il ne se connecte pas à Internet pendant son exécution.

Installation depuis GitHub

git clone https://github.com/gorbabor/mc-iclone8-ui-mcp.git
cd mc-iclone8-ui-mcp

Si python pointe vers un environnement sans pip, utiliser le Python système (py -3) ou le chemin Python fourni par Codex :

$py = "C:\Users\Christian Bwanakawa\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe"
& $py -m pip install -e ".[windows-ui,screenshots]"

La configuration setuptools inclut uniquement le paquet mc_iclone8_ui_mcp; les dossiers skill/, docs/ et screenshots/ ne sont pas installés comme paquets Python.

Vérification

& $py tests\smoke_test.py
& $py -m compileall -q mc_iclone8_ui_mcp

Résultat attendu : smoke test: ok.

Configuration MCP stdio

Le serveur est lancé par le client MCP, pas comme un serveur HTTP :

{
  "mcpServers": {
    "mc-iclone8-ui-mcp": {
      "command": "C:\\Users\\Christian Bwanakawa\\.cache\\codex-runtimes\\codex-primary-runtime\\dependencies\\python\\python.exe",
      "args": ["-m", "mc_iclone8_ui_mcp"],
      "cwd": "C:\\chemin\\vers\\mc-iclone8-ui-mcp"
    }
  }
}

Le processus MCP utilise stdin/stdout pour JSON-RPC et stderr pour les journaux. Ne pas utiliser le panneau HTTP d'un autre plugin iClone comme remplacement de ce serveur.

Gestion des instances iClone

Pour une session interactive, le client peut suivre cette séquence :

ui.list_instances
→ ui.activate_instance(handle)
→ ui.get_active_instance
→ ui.set_interaction_mode("interact" ou "session")
→ action UI
→ vérification avant/après

Le mode observe ne prend pas le focus. Le mode interact autorise les primitives UI après vérification du focus. Le mode session indique qu’une instance doit rester la cible pendant la séquence, tout en vérifiant le focus avant chaque action.

Toute action UI doit passer par le garde-fou de focus : instance cible détectée, fenêtre restaurée si nécessaire, premier plan confirmé avant l’action, puis focus revérifié avant la preuve après action.

Note UI Automation : iClone 8 peut exposer des identifiants Qt historiques contenant iClone6 MainWindow. Ce sont des métadonnées d'accessibilité de l'interface observée, pas des appels à iClone 6. Le code matche uniquement les suffixes sémantiques et n'utilise ni RLPy ni API d'une autre version.

Lancement manuel

& $py -m mc_iclone8_ui_mcp

Lancement

python -m mc_iclone8_ui_mcp

Le processus utilise JSON-RPC sur stdin/stdout. Les logs vont sur stderr.

Outils MCP read-only

  • ui.inspect_application : détecte les fenêtres iClone 8 visibles et rapporte le focus.

  • ui.list_instances : liste les fenêtres iClone 8 avec handle, PID, projet et focus.

  • ui.get_active_instance : lit l’instance cible et l’état du focus.

  • ui.activate_instance : restaure et place une instance cible au premier plan.

  • ui.set_interaction_mode : configure observe, interact ou session.

  • ui.inspect_accessibility_tree : lit les contrôles directs Windows UI Automation en lecture seule si .[windows-ui] est installé.

  • ui.inspect_named_control : inspecte un contrôle nommé, par exemple Scene, et ses enfants directs.

  • ui.inspect_automation_control : inspecte un contrôle par automation_id, par exemple le conteneur du Scene Manager.

  • scene.read_manager : lit un sous-arbre borné du Scene Manager, sans modification.

  • scene.list_items : extrait les noms des objets TreeItem visibles, sans sélection.

  • scene.select_item : sélectionne un objet par nom accessible, uniquement avec confirm=true et iClone 8 au premier plan. screenshot_dir peut produire les captures avant/après.

  • scene.read_modify : lit le sous-arbre du panneau Modify pour vérifier l’état après une action.

  • workflow.catalog : expose l’état progressif des huit familles de workflows.

  • ui.capture_screen : capture l'écran ou la fenêtre iClone 8.

  • scene.read_visible_state : lit l'état visible connu sans modifier la scène.

  • workflow.stop_all : arrête le workflow local courant.

Références

Roadmap

Voir docs/implementation-plan.md, docs/feature-matrix.csv et docs/limitations.md.

Skill expert : skill/SKILL.md. Référence de procédure manuelle : https://manual.reallusion.com/iclone-8.

Available Tools

5 tools
scene.read_visible_stateB

Lit l'état visible connu de l'interface iClone 8.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/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 that the operation is read-only ('Lit'), but does not mention any side effects, permissions, or output format. For a simple read tool, this is minimal but not sufficiently transparent.

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 a single sentence that is front-loaded with the action. It is concise and to the point, but lacks any structural formatting (e.g., bullet points). It earns its place without redundancy.

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 no parameters, no output schema, and a minimal description, the tool is borderline adequate for a simple read operation. However, the description does not clarify what the 'visible state' entails or how to interpret the output, leaving some ambiguity for the agent.

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 the schema description coverage is 100% (empty). According to guidelines, baseline score is 4 for no parameters. The description adds no parameter information since none exist.

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 that the tool reads the known visible state of the iClone 8 interface, using a specific verb and resource. It distinguishes itself from sibling tools like ui.capture_screen, though it is in French, which may reduce clarity for non-French-speaking agents.

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 guidance is provided on when to use this tool versus alternatives (e.g., ui.inspect_application or ui.capture_screen). The description only states what it does without context or exclusions.

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

ui.capture_screenB

Capture l'écran ou la fenêtre iClone 8 sans modifier la scène.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
window_onlyNo

TDQS

B3.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 carries the full burden. It discloses that the capture does not modify the scene, which is important. However, it does not explain output behavior (e.g., file saving, format, error handling).

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?

A single sentence that efficiently conveys purpose and a key behavioral trait. No wasted words.

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 2 parameters and no output schema or annotations, the description is insufficient. It does not explain parameter usage, output details, prerequisites, or error conditions. A screenshot tool typically requires more context.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds zero information about parameters. The 'path' and 'window_only' parameters are not explained beyond their schema types.

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 action ('capture') and resource ('screen or iClone 8 window'), with a key property ('without modifying the scene'). It distinctly separates from sibling tools like scene.read_visible_state or ui.inspect_application.

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 guidance on when to use this tool versus alternatives. The description lacks any usage context or exclusions.

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

ui.inspect_accessibility_treeB

Lit les contrôles directs Windows UI Automation sans effectuer d'action.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_elementsNo

TDQS

B3.2/5.0
Behavior3/5

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

The description mentions that no action is performed (safe read-only operation), which is helpful. However, with no annotations, it should also disclose potential impacts on UI state, performance considerations, or timeouts. Missing details on return format.

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?

Single sentence, no fluff. Could be slightly more informative without losing 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?

For a simple read tool with one optional parameter, the description is minimally adequate. It lacks details about output format and how to interpret results, but sibling tools are sufficiently different to avoid confusion.

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 description does not mention the single parameter `max_elements`, but the schema provides clear constraints and default. Since schema coverage is 0%, the description could add context (e.g., why limit), but it's not critical.

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 reads UI Automation controls without performing any action, which distinguishes it from sibling tools like ui.capture_screen and workflow.stop_all. However, it could be more specific (e.g., 'accessibility tree' vs 'controls').

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 guidance on when to use this tool vs alternatives like ui.inspect_application. The description does not provide any usage context or exclusions.

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

ui.inspect_applicationA

Inspecte les fenêtres visibles iClone 8 en lecture seule.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. It correctly states 'en lecture seule' (read-only), indicating no mutation, but does not explain what the inspection returns or whether it has side effects beyond reading.

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 without extraneous information. It is front-loaded and every word adds value.

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?

For a tool with no parameters, no output schema, and no annotations, the description provides only minimal information. It does not explain what 'inspect' yields (e.g., window properties, hierarchy) or how to interpret the output.

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 description coverage is 100%. The description does not need to add parameter information, and baseline of 4 is appropriate.

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 ('Inspecte') and resource ('fenêtres visibles iClone 8') with a qualifier ('en lecture seule'), clearly distinguishing from sibling tools like ui.capture_screen and scene.read_visible_state.

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 guidance is given on when to use this tool instead of alternatives like ui.inspect_accessibility_tree or ui.capture_screen. The description does not mention context or exclude scenarios.

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

workflow.stop_allB

Demande l'arrêt propre du workflow UI courant.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior2/5

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

The phrase 'arrêt propre' (clean stop) is vague and does not explain the behavioral implications such as whether the stop is graceful or forceful, whether state is saved, or if it has side effects. No annotations are provided to compensate.

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 sentence that is concise and front-loaded with the core action. No wasted words.

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?

For a simple tool with no parameters and no output schema, the description is minimally adequate. However, it does not clarify the return value or confirm whether the stop is asynchronous or synchronous, which could affect agent decision-making.

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?

There are no parameters, so schema coverage is 100%. The description adds no additional information about parameters, but none is required. Baseline of 3 is appropriate.

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 identifies the action (stop) and the resource (current UI workflow). It uses a specific verb and resource, and the tool's purpose is distinct from all sibling tools which are read/inspection tools.

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 guidance on when to use or not use this tool. No mention of prerequisites (e.g., must have a running workflow) or alternatives. The description is purely a statement of function.

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. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedscene.read_visible_state
    • First observedui.capture_screen
    • First observedui.inspect_accessibility_tree
    • First observedui.inspect_application
    • First observedworkflow.stop_all
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct aspect: screen capture, visible state reading, workflow control, application inspection, and accessibility tree inspection. No ambiguity exists between their purposes.

Naming Consistency5/5

All tool names follow a consistent pattern: <scope>.<action> with snake_case action names (e.g., ui.capture_screen, scene.read_visible_state).

Tool Count5/5

With 5 tools covering capture, state, workflow, and inspection, the count is well-scoped for a UI monitoring server.

Completeness4/5

Covers capture, state reading, and two inspection methods, plus workflow stop. Missing tools for starting workflows or retrieving detailed element properties, but serves its monitoring purpose adequately.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Computer Control MCP

    AB498
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server that provides computer control capabilities including mouse movements, keyboard actions, screenshot capture with OCR, and window management through a unified API.
    165
    MIT

  • umbriel

    ObscuritySRL
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for driving any Windows app through five layers including OCR, UI Automation, and direct OS operations. Enables AI agents to control Windows desktop and OS cursor-free, even on background/locked windows.
    164
    2
    MIT

  • pc-control-agent

    anbu-20012005
    F
    license
    Not graded
    quality
    C
    maintenance
    This MCP server enables an AI agent to control a Windows PC through human-like interactions such as screen capture, OCR, mouse, keyboard, and navigation, without using shortcut APIs.
    -

  • vred-mcp

    krngrover6
    A
    license
    Not graded
    quality
    C
    maintenance
    A local MCP server that enables MCP-compatible AI clients to inspect and control the currently open scene in a running Autodesk VRED Professional 2027 instance via a secure bridge, supporting read-only inspection and gated mutations like selection, visibility, transforms, and screenshots.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gorbabor/mc-iclone8-ui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server