Connectors

Out of the box the agent can run code, use the shell, edit files and browse the web. Connectors let it reach further: your repositories, your databases, your company's knowledge base and any other system that exposes an MCP server.

What connectors are

Windlass connectors use the Model Context Protocol (MCP), an open standard for giving AI agents access to tools. An MCP server describes a set of tools, for example "list open pull requests" or "run a read-only SQL query", and the agent calls those tools when they help with the task.

Because MCP is an open standard, you can use servers published by vendors and the community, or write your own for an internal system. Anything that speaks MCP works with Windlass.

Adding a connector

1. Open the Workspace settings and go to the Plugins/MCP section.
2. Add a server. You can configure it in one of two ways:
   • URL for a remote server that uses the streamable HTTP transport.
   • Command for a server that runs as a process inside your container, for example one installed as a package.
3. Add any credentials the server needs, such as an API token.
4. Save. The server's tools appear to the agent automatically; there is nothing else to register.

From then on, the agent sees the connector's tools alongside its built-in ones and uses them when a task calls for it. You can also ask explicitly: "Use the GitHub connector to open a pull request with these changes."

Where connectors run

Connectors run inside your own isolated container, in the same environment as the agent. Requests to external services go out from your workspace, and the credentials you add are stored in your workspace only. They are not shared with other accounts.

Command-based servers can use anything available in the container, including packages the agent has installed there. A URL-based server can be anywhere your container can reach.

Examples

• Source control. A GitHub MCP server lets the agent read issues, inspect pull requests, review diffs and open new pull requests, all from within a session.
• Databases. A database MCP server gives the agent a way to run queries against a development or analytics database, so it can answer questions about your data or check that a migration did what you expected.
• Knowledge base. An MCP server in front of your company wiki or documentation lets the agent look up internal conventions, runbooks and past decisions instead of guessing.

Security guidelines

Connectors act with whatever access their credentials grant. Keep that access small:

• Use scoped tokens. Create a token that grants only what the connector needs, such as read-only access to one repository or a single database schema, and nothing more.
• Prefer read-only where possible. If the agent only needs to look things up, give it a token that cannot write.
• Review before approving. Depending on your permission preset, the agent asks before risky actions. Read the request carefully when it involves a connector that can change external systems.
• Rotate and revoke. When a token is no longer needed, revoke it at the source and remove it from the connector.
• Treat tool output as data. Content returned by a connector is information for the agent to work with, not instructions it should follow.

More on this in Security and privacy.

Troubleshooting

• The agent does not use a tool you expect. Ask it directly and name the connector. Check that the server is configured and saved in the Plugins/MCP section.
• Authentication errors. Confirm that the token is valid and has the scopes the server needs.
• A URL server does not respond. Confirm that the server supports streamable HTTP and is reachable from your container.
• A command server fails to start. Ask the agent to run the command in the shell and read the error; a missing package is the usual cause.

If you get stuck, email [support email] from the Support page with the server type and the error you see. Leave any tokens out of the message.