Zero-code integrations — AiHummer Docs

The Tier-3 plugins are zero-code: you make an existing service available to agents without writing or deploying any integration code. There are two source types — OpenAPI and MCP — and both resolve their secrets from the encrypted vault rather than from configuration in the clear.

OpenAPI: one tool per operation

Point AiHummer at any OpenAPI 3.x spec via its spec_url and the platform synthesizes one tool per operation in the spec. Each operation becomes a callable tool the agent can use during a function-calling turn — no glue code, no per-endpoint wiring.

{
  "slug": "acme-api",
  "name": "Acme API",
  "version": "1.0.0",
  "kind": "openapi",
  "spec_url": "https://api.acme.example/openapi.json"
}

Auth via the spec’s securityScheme

Authentication is taken straight from the spec. AiHummer reads the OpenAPI securityScheme, and the actual secret is pulled from the vault at call time — so the credential is never inlined into the manifest, the prompt or the logs.

[!NOTE] The synthesized tools follow the spec’s own operations and security. Keep your OpenAPI document accurate: the operations it declares are exactly the tools the agent will see.

Ready-made personal integrations (per-user OAuth)

This same OpenAPI mechanism backs a large set of ready-made personal integrations: each is a per-user OAuth integration that a person connects to their own account, after which the tools act on their behalf. Already available are Gmail, Google Calendar, Google Contacts, Google Tasks, Google Drive, YouTube, Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Fitbit, Oura Ring, Spotify, Samsung SmartThings and more. Connecting a personal account is covered in per-user Connections.

MCP: connect any server

The second source type connects any MCP server. AiHummer talks to it over a stdio or http transport, calls its tools/list, and exposes the returned tools to the agent. As with OpenAPI, this needs no integration code.

{
  "slug": "acme-mcp",
  "name": "Acme MCP",
  "version": "1.0.0",
  "kind": "mcp",
  "transport": "http",
  "url": "https://mcp.acme.example/"
}

A stdio-transport server is configured by the command that launches it instead of a URL:

{
  "slug": "local-mcp",
  "name": "Local MCP",
  "version": "1.0.0",
  "kind": "mcp",
  "transport": "stdio",
  "command": "my-mcp-server"
}

Secrets via vault → env

For MCP servers, secrets flow from the vault into the environment the server runs with. You store the secret once in the vault; AiHummer injects it as an environment variable when launching or connecting to the server, so the secret material stays out of the manifest and out of the model context.

OpenAPI vs MCP at a glance

	OpenAPI	MCP
Input	An OpenAPI 3.x `spec_url`	An MCP server (stdio or http)
Tools produced	One per operation in the spec	Whatever `tools/list` returns
Auth	The spec’s `securityScheme` → vault	Vault → env for the server
Code required	None	None

When to use which

Reach for OpenAPI when the service already publishes an OpenAPI document — you get its full operation set as tools automatically.
Reach for MCP when you want to connect an existing MCP server, or run a local tool server over stdio.

[!TIP] Both source types are defined by the same one-file manifest.json as every other plugin — see the Plugin SDK for the openapi and mcp kinds and aihummer plugin validate.

Where to next

Plugin SDK — manifest fields for openapi and mcp.
Marketplace overview & tiers — where zero-code (Tier 3) sits.
Personal vs shared credentials — how the vault secrets these tools use are scoped.