Custom MCP
Connect an internal or vendor MCP server so an agent can use its tools.
Your company may already have an MCP server for searching internal systems, updating operational data, or calling a vendor's specialized tools. Custom MCP connects that server to Hyperagent so the right agents can use those tools during a run.
The server stays responsible for its tools and authentication. Hyperagent connects to its remote endpoint, reads the available tool definitions, and lets an attached agent call them as the work develops.
Custom MCP connects tools to an agent
Use Custom MCP for a remote server your company or a vendor operates. If Hyperagent already offers a native integration for the same service, use that integration for its managed connection flow and product-specific controls.
When to use Custom MCP
Use tools your team already exposes
Connect an MCP server for proprietary search, operational workflows, or services that only exist inside your company.
Add a specialized external capability
Attach a vendor-hosted MCP server when its tools are not available through Hyperagent's integration catalog.
Equip only the roles that need it
Attach different servers to different agents so each role receives the tools required for its job.
Pick the right connection path
Native integration
Use the product connection when Hyperagent already supports the service. Native integrations provide the most direct OAuth, scope, and configuration experience.
Custom MCP
Use a remote HTTPS MCP server operated by your company or a vendor. Hyperagent reads its tool definitions and makes them available to attached agents.
Skill with scripts
Use a skill with scripts and credentials when you only need to call a small API and do not want to operate an MCP server.
For the broader capability model, see Tools & Integrations.
Connect a server
Add the remote endpoint
Add the MCP server through the Custom MCP connection flow. Enter the remote HTTPS URL supplied by your company or vendor.
Configure authentication
Complete the authentication method required by the server. Depending on the provider, that may be OAuth, a token, or server-specific headers.
Attach it to an agent
Allow the integration on each agent that should be able to call its tools. A connected server that is not attached to the agent will not be available during that agent's runs.
Test a specific tool in a thread
Start with an interactive request that clearly calls for one of the server's tools. Confirm the agent can find the tool, authenticate, and return the expected result.
Review unattended access
Before using the server in a schedule or Live Mode run, check the agent's unattended-write rules and any allow-lists or network restrictions enforced by the server.
Use a reachable HTTPS endpoint
Connect a remote MCP server with a secure HTTPS URL. Local stdio servers and commands that run only on your machine aren't reachable from Hyperagent.
What the agent receives
Attaching a server expands the tools the agent can call. It does not replace the agent's instructions, skills, knowledge access, or other integration settings.
Tool discovery
The agent can inspect the server's tool names, descriptions, and input schemas as the request calls for them.
Server connection
Hyperagent sends tool calls to the configured remote endpoint and returns the server's response to the run.
Authenticated access
Calls use the authentication configured for that connection. The server still decides what those credentials may read or change.
Tool discovery and context
MCP servers can expose many tools, and their schemas can be large. The agent discovers relevant tools as needed instead of carrying every tool definition in the opening context.
A tool may need to be rediscovered
After a long run is compacted, the agent may need to inspect the server's tools again. If it loses the exact input shape, ask it to rediscover the tool before assuming the connection has failed.
Clear tool names, descriptions, and schemas make the server easier for an agent to use correctly. Treat those definitions as part of the interface, not only implementation detail.
Access and security
Connect servers you recognize
An attached server receives the tool calls and inputs sent by the agent. Review the operator, endpoint, and data-handling policy before connecting it.
Limit what credentials can do
Prefer credentials scoped to the systems, records, and actions the agent actually needs.
Keep credentials out of prompts
Use the server's authentication mechanism. Do not place production secrets in the agent's instructions, a skill, or a thread.
Account for every person who can run it
Teammates who can run a shared agent may cause it to call the attached server, subject to the agent's access model and the server's permissions.
Boundaries
Extend an agent's toolset
It can expose internal or vendor tools, keep those tools outside Hyperagent's core product, and give different agents access to different servers.
Override product controls
It cannot bypass knowledge access or unattended-write rules, edit Hyperagent skills or agent configuration, or guarantee that every third-party server behaves the same way.
FAQs
Connect the server, attach it to the right agent, and prove one tool call in an interactive thread before expanding access or scheduling the work.