Eigent: Advanced features

This page covers six Eigent features that give it more reach. They are connectors and MCP servers, custom skills, custom workers, signed-in browsing, event-driven Automations, and running Eigent from source with a local model. It is the seventh of eight pages, so leave all of it until the first six feel routine, and add one feature at a time.

These notes match version 1.0.7 and the docs as checked on 14 November 2026. Every feature here widens what Eigent can reach, and none of them adds a wall. Eigent's security policy says its approvals are "not an operating-system sandbox," and that stays true for everything below.

Connectors and custom MCP servers

What it is for. Connectors let agents use outside services. A connector "can search data, read or write records, send messages, access calendars, or expose a custom capability through the Model Context Protocol (MCP)," in the docs' words. The guided list can include Notion, Slack, Google Calendar, Gmail, LinkedIn, and Lark. X, WhatsApp, Reddit, and GitHub are marked Coming soon.

How to turn it on. Open the Eigent dashboard and select Connectors. A supported service has its own setup steps. For anything else, you can add a custom MCP server, which is either "a local command-based server or a remote MCP URL" in the docs' terms. In version 1.0.7 the chat box menu also has Add an MCP and Manage connectors.

To give a connector to a Workforce, the docs say to open a Space, add or edit a worker, and open the tool selector. Then select the connector and save the worker. If an MCP server will not start, "Run the configured command independently and review its environment variables and executable path," as the docs advise.

• You gain: agents can read and act in the services you already use. They could add an event to your calendar or post a note to a chat channel.
• You risk: "Connectors can perform actions in external systems," the docs warn, and a page or email with prompt injection could steer those actions. A custom MCP server is a program that runs as you, so a bad one can reach your files too.
• Makes sense when: the connector uses a separate account made for the agent, with the fewest permissions the job needs. Read what a custom server does before you add it. Connecting your main email does not make sense for a beginner.

Custom skills

What it is for. A skill packs instructions, and sometimes scripts or templates, that Eigent uses whenever a task calls for it. That way you stop pasting the same instructions into every job. The docs say Eigent "automatically uses them when relevant to your request." Custom skills, they add, "are individual to each user and saved locally" on your computer.

How to turn it on. Open Settings, and under Global Settings click Skills. The docs call this Homepage > Agents > Skills, an older layout. Upload either a single SKILL.md file or a .zip package with a SKILL.md file in its root. The file needs a name and a description at the top, in this form from the docs:

---
name: your-skill-name
description: Brief description of what this Skill does and when to use it
---

# Your Skill Name

## Instructions
[Clear, step-by-step guidance for Eigent to follow]

## Examples
[Concrete examples of using this Skill]

Click Try in chat to test it. In version 1.0.7 you can also click a Session's title and turn that Session into a skill.

• You gain: a job you do often, such as a weekly summary in your own format, runs the same way each time without long instructions.
• You risk: "Malicious Skills can misuse tools or execute unintended actions, potentially causing data leaks or unauthorized access," the docs warn. Because a skill loads by itself when it seems relevant, a bad one can shape jobs you did not mean it for.
• Makes sense when: you wrote the skill yourself, or you have read every file in it. Its instructions should only read and write in your Space's folder. A skill from a stranger does not make sense until you have checked it line by line.

To compare skills with MCP servers, and to see how other agents add them, read Skills and MCP.

Custom workers in a Workforce

What it is for. A Workforce comes with four ready-made agents, for development, browsing, documents, and media. A custom worker is your own addition. "Configure a system prompt and add any MCP-supported toolkit you want" is how the docs describe it.

How to turn it on. Open a Space and add a worker. Give it a name and a system prompt, pick its tools in the tool selector, and save it. The connectors page gives that order of steps, but this guide could not confirm the exact button names for adding a worker. Version 1.0.7 also has a Sub-agents page in Settings for remote sub-agents from BytePlus ModelArk.

• You gain: a worker built for one kind of job, with only the tools that job needs, does that part more reliably than a general agent.
• You risk: every tool you add is one more thing the worker can do on its own. With several workers running at once, approval requests may be harder to follow.
• Makes sense when: your Workforce jobs have already gone well with the ready-made agents. Give the new worker the fewest tools that its part of the job needs, and keep Ask me first on.

Signed-in browsing

What it is for. By default the browser works logged out. Browser settings let agents use a browser you choose, or the cookies from sites you have signed in to. Then they can work on pages behind a login.

How to turn it on. Open Settings and look under Device, which has Browser, Extension, and Cookies. The docs describe an older dashboard with Connections and Cookies. Under Connections you can open a new managed browser, or connect an existing one that has remote debugging turned on. For Cookies, the docs say to "Open a dedicated login browser, sign in to required services, then let Eigent import the resulting cookie domains" for the agents to use. Browser plugins are marked Coming soon.

• You gain: agents can do research or routine clicks on sites that need you to sign in, such as a library account or a project tool.
• You risk: with your cookies, an agent can act on those sites as you. Opening pages does not ask for approval, so prompt injection on any page it visits could use that login. "Do not connect a remote-debugging port to an untrusted network," the docs add.
• Makes sense when: the login is a separate account made for the agent, on a site where mistakes can be undone. Delete the cookies once the task no longer needs them, as the docs advise. Your email, bank, or store logins do not make sense here for a beginner.

Event Automations

What it is for. A Scheduled Automation runs at set times. An Event Automation "Creates an HTTP endpoint that starts a task when an external system sends a request," in the docs' words. Another service or a script can then start an Eigent task by calling a web address.

How to turn it on. Select Automations in the sidebar, then Create automation, enter a name, pick the Session, and enter the Task Prompt. For an Event Automation, choose Webhook as the trigger type. The same limits apply as for schedules: Max Failure Count, Max Per Hour, Max Per Day, and an Expiration Date.

• You gain: Eigent can react to things as they happen, such as starting a summary when a form is submitted, without you opening the app.
• You risk: anyone who learns the web address can start a task, and nobody may be watching when it runs. The docs' advice is to "Treat webhook URLs as credentials" and to "Add rate limits to event-driven automations" before you rely on one.
• Makes sense when: the task only reads what it is sent and writes notes in its own folder. Hourly and daily limits are set, the address stays private, and you check the execution log for runs you did not expect. It is not a beginner step.

Run Eigent from source with a local model

What it is for. The normal app needs an Eigent account and connects to Eigent's servers. Building it from source, with Eigent's local deployment guide, keeps your account, settings, and chat history on your own computer. A local model then keeps your prompts there too.

How to turn it on. The self-hosting page asks for Git, Node.js 18 through 22, and the Python version the repository's backend needs. It then gives these commands, run in a terminal:

git clone https://github.com/eigent-ai/eigent.git
cd eigent

npm install

npm run dev

The README says this quick start still connects to Eigent's cloud and needs an account. For no account at all, follow the local deployment guide, which runs Eigent's server yourself with Docker, Node.js, and Python. Then start a local model. The local-models page's Ollama example is ollama pull qwen2.5:7b. In Eigent, open Settings, then Models under Global Settings, and connect it, as in Or use a local model on page 2.

• You gain: the most privacy and control Eigent offers, with no per-use model cost on a local model.
• You risk: this is a developer setup that you keep up to date yourself, following the docs' update steps. It still has no wall around your files. Local models are weaker than the best cloud models. The docs also note that large ones "can require substantial memory or GPU capacity" to run.
• Makes sense when: you are comfortable with a terminal and with Docker, privacy matters more to you than convenience, and your computer has plenty of RAM. If the normal app works for you, it does not make sense to switch just to try it.

Shared advanced topics

These pages work with any agent. These five apply to Eigent.

• Local models in depth: Eigent connects to Ollama, LM Studio, vLLM, SGLang, and LLaMA.cpp, and this page helps you pick a model your computer can run.
• Mixing models: Eigent can hold several providers at once. In version 1.0.7, picking a model inside a Session changes it for that Space only.
• Host access and unattended runs: Eigent always runs on your real computer, and Automations and Remote Control run with nobody watching.
• An always-on machine: scheduled runs and Remote Control only work while the computer is on and Eigent is open.
• Relays: Eigent's OpenAI Compatible choice accepts any address, which includes relays, so read this before you paste one in.

Sources

Checked 14 November 2026.

• Eigent security policy ("not an operating-system sandbox")
• Eigent connectors overview (connector types, Coming soon services, custom MCP servers, assigning a connector to a worker, security, and troubleshooting)
• Eigent agent skills (Homepage > Agents > Skills, the SKILL.md format, Try in chat, and the warning about malicious skills)
• Eigent Workforce (the ready-made agents and the custom worker)
• Eigent browser overview (Connections, Cookies, Coming soon plugins, and the security advice)
• Eigent Automation docs (Event Automations, creation steps, limits, and security)
• Eigent self-hosting (requirements, commands, Agents > Models, updates, and memory needs of large models)
• Eigent local models (ollama pull qwen2.5:7b)
• Eigent models overview (the five local programs)
• Eigent bring your own key (OpenAI Compatible for custom endpoints)
• Eigent README (the source quick start connects to Eigent's cloud and needs an account)
• Eigent local deployment guide (what stays on your computer when you run the server yourself)
• Eigent releases (version 1.0.6: scheduled runs need Eigent open; version 1.0.7: Sub-agents page, turning a Session into a skill, and a Session's model choice applying to that Space only)
• Settings menu in the v1.0.7 app code (Models and Skills under Global Settings; Browser, Extension, and Cookies under Device)
• Automation labels in the v1.0.7 app code (Create automation, Task Prompt, Webhook, and the run limits)
• Chat box labels in the v1.0.7 app code (Add an MCP, Manage connectors)
• Eigent research notes

Next

Continue to Eigent: Persona and rules.