> For the complete documentation index, see [llms.txt](https://cleyrop.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cleyrop.gitbook.io/docs/documentation-fr-en/the-factory/deployer-des-apps-et-des-tools.md). # Deploy Apps and Tools {% hint style="info" %} The terminology of The Factory has evolved: * The Factory for Agents becomes **The Factory**, * the **Agent Apps** and **Agent Tools** become the **Apps** and **Tools** — the whole set being referred to as **Apps** * the **AI contexts** become the **Agents**. {% endhint %} The Factory allows **to create, deploy, and administer** applications - **Apps** and MCP servers - **Tools** within the Cleyrop platform. It provides a secure, standardized framework for developing applications and extensions based on AI models and external connectors. *** ## Understand the types of apps ### Application - App An App is an **standalone application** deployed on Cleyrop. It has a **dedicated URL** and runs independently of the Druide. It can be used to expose an interactive user interface, for example a Gradio dashboard or a small processing app, a ML model, an API... Apps can be used from outside via a whitelisted IP with the app URL or from the Cleyrop services platform via the internal URL: a **Dataflow, an App, a DevSpace** or a **Codelab notebook.** ### MCP server - Tool A Tool in Cleyrop corresponds to a **MCP server** declared and managed from The Factory . It makes it possible to extend the **capabilities of the Druide** by giving it access to external services, APIs, or internal tools. It is also available to be used in a **Dataflow, an App** or a **Codelab notebook.** 👉 For developers wishing to create their own tools, see the official MCP documentation: **Key principles** * Each Tool exposes a **MCP-compatible endpoint** (/mcp/metadata, /mcp/tools, /mcp/run). * The tools defined in the server can be **enabled or disabled** from the Druide. * The **user variables** (e.g., API keys, business filters) can be configured directly in the assistant or at the app listing level. * Communication happens in **real time** : the assistant calls the server, executes the action, then returns the response to the user. **Use cases** * Automatic generation of documents (Word, PDF…). * Sending emails or notifications. * Data extraction from internal or external APIs. * Interaction with business tools (Jira, Lucca, CRM…). **Best practices for Tool developers** To ensure smooth integration and optimal use of your tools: * By default, all Tools are enabled in the Druide: **describe** the function of each tool in its documentation. * Clearly specify the expected inputs and outputs: types, formats, constraints, possible values, return structure, JSON format, key fields. * Respect the **schema consistency** between tools to make it easier to combine them in the same context. * **Test your tools in the Druide** before sharing them with end users. **Retrieving a user variable in an MCP Tool** When a user configures a Tool user variable (via the configuration gear in the Druide, or via the Tool details page), this value is not exposed to the MCP server as an environment variable. Instead, the Druide sends user variables in the headers of each HTTP request sent to the Tool. Each tool call therefore includes the variable(s) specific to the user who triggered it. To retrieve these values in your Tool code, use `get_http_request()` (provided by FastMCP), then read the desired header on `request.headers`. The header name corresponds to the user variable name. **Code example:** ```python """Utility for extracting user access token from FastMCP request headers.""" import logging from typing import TYPE_CHECKING, Optional from fastmcp.server.dependencies import get_http_request from src.config.corpus_mcp_config import get_corpus_mcp_config if TYPE_CHECKING: from starlette.datastructures import Headers from starlette.requests import Request logger = logging.getLogger(__name__) def get_user_access_token() -> Optional[str]: """Extract the user access token from the request headers.""" request: Request = get_http_request() headers: Headers = request.headers return headers.get(get_corpus_mcp_config().user_access_token_header) ``` #### Cleyrop native Tools Cleyrop provides several **native Tools**, visible in the Apps and Tools list just like yours: * **Cleyrop Corpus** — allows you to[query a corpus of documents](/docs/documentation-fr-en/le-druide/interroger-un-corpus-de-documents.md) from the Druide * **Cleyrop Dataset** — allows you to[query datasets](/docs/documentation-fr-en/le-druide/interroger-des-datasets.md) from the Druide * **Cleyrop Internet** — allows internet searches from the Druide Unlike your own Apps and Tools, only the action **Configure** (token management) is accessible on their details page. {% hint style="info" %} The tool **Cleyrop Internet** does not require token configuration. {% endhint %} ## Create an App Creation happens in two stages: * first the App creation (name and description) * then the image and instance configuration. ### **Step 1: Create the App** 1. Go to **The** **Factory** → Apps 2. Click **Create** 3. Enter: * **Name** : unique identifier for your App (max 50 characters, duplicates not allowed) * Enable **Mark this app as a Tool** if it is an MCP server * **Description** : free text supporting markdown (headings, bold, italics, lists, links) 4. Select, if needed, the **Apps and Tools** that your App will be able to call from the list of apps available on the platform. By default, no access is configured. 5. Click **Create** At this stage, no image or instance is configured.
### **Step 2: Configure images and instances** From the App details page, you can: * [**Create and build an image**](/docs/documentation-fr-en/the-factory/gerer-les-images.md) from a Git repository in the Cleyrop internal registry * [**Create and deploy an instance**](/docs/documentation-fr-en/the-factory/gerer-les-instances.md) from an image in the internal registry or from an external registry {% hint style="info" %} The first instance created automatically becomes the App's main instance. {% endhint %} {% hint style="warning" %} As of today, for outbound traffic to the internet only ports 443 and 22 are authorized {% endhint %} ## Use an App You can find the list of apps available from Applications > Apps/Tools. You can filter them by Status. * An App can be opened directly from its card or via the URL on its details page. * Successfully deployed Tools can be used directly from the Druide. It is possible to enable or disable each tool present on each deployed Tool. {% hint style="warning" %} Apps are accessible by **whitelisted IPs** {% endhint %}
Some Tools need to be configured before they can be used, and you will then see a button appear :gear: on the card or details page. You will then see the list of environment variables to fill in so you can use the Tool with your credentials.
### View the tools of a Tool You can access the full list of tools offered by a Tool, as well as their input and output parameters, to understand the use cases covered. In a Tool's details page, a Tools tab appears automatically. This tab is not present on Apps. It allows you to consult the **list of tools** and for each available tool: * **Description** : what the tool does, and when to use it. * **Input parameters** : the expected fields, their type, and their purpose. * **Output parameters** : the structure of the returned data. This view lets the user quickly understand how to use a Tool in the Druide or during advanced development. ### Access Apps from a DevSpace Apps created in The Factory can be accessed from a DevSpace to make development and testing easier. **Configure access** 1. When creating or editing a DevSpace, go to the "Apps" section. 2. Search for your App by name. 3. Check the Apps that the DevSpace should be able to connect to. 4. Save the changes. ### Monitor resources A summary of resource usage is available from the **Resources used** button at the top right of The Factory . It displays CPU and RAM usage (minimum and maximum) for all Apps, images, and DevSpaces deployed in your environment.
*** ## Best practices * Use lightweight Docker images, tested locally, and compatible **linux/amd64**. * Give explicit names and document variables to make maintenance easier. * Regularly check the logs and use automatic rollback in case of deployment failure. * Consider modularizing your apps: a model, an embedding module, a business tool → a clear Tool.