export declare const AGENT_BUILDER_REFERENCE_URI = "n8n://agents/reference";
export declare const AGENT_CONFIG_JSON_SCHEMA: import("zod-to-json-schema").JsonSchema7Type & {
    $schema?: string | undefined;
    definitions?: {
        [key: string]: import("zod-to-json-schema").JsonSchema7Type;
    } | undefined;
};
export declare const AGENT_BUILDER_GUIDE = "# n8n Agent management\n\nUse the Agent MCP tools to create and edit persisted n8n Agents. The MCP client is the\norchestrator: there is no nested conversational Agent Builder.\n\n## Choose an Agent or workflow\n\nAn n8n Agent is a first-class persisted resource with its own instructions, model, tools, skills,\ntasks, memory, integrations, and lifecycle. An AI Agent node is a node inside a workflow whose\ntrigger, surrounding graph, and lifecycle are owned by that workflow.\n\nIf the request is actually a fixed trigger or schedule with enumerable, repeatable steps, it is\nprobably a workflow \u2014 explain the mismatch and ask before building the alternative. Never substitute\na Chat Trigger plus an AI Agent node for a requested n8n Agent.\n\n## Build sequence\n\n1. Use search_projects to identify the project, or search_agents and get_agent for an existing Agent.\n   By-ID tools (get_agent, mutate_agent, validate_agent, call_agent, publish_agent,\n   unpublish_agent, revert_agent, list_agent_versions, delete_agent, update_agent_integration) take\n   an agentId alone and resolve the project from it.\n2. Use discover_agent_assets plus list_credentials, search_nodes, get_node_types, and\n   explore_node_resources to ground model, tool, workflow, integration, and credential choices.\n3. For a new Agent, call create_agent with the initial config after discovering its assets. The\n   top-level name is injected into config; omit config only when the Agent ID is needed first.\n4. Call mutate_agent once per logical sidecar or subsequent mutation, always passing the latest\n   configHash. Skills, tasks, and custom tools are created after the Agent because they need\n   server-generated IDs.\n5. Call validate_agent and resolve every reported error. A valid Agent is a completed draft; do not\n   publish it merely to finish the build.\n6. After validation succeeds, if call_agent is available and authorized, send one representative\n   message before reporting the draft ready. Otherwise, report the successfully validated draft\n   ready without a test run.\n7. Report that the draft is ready, include a clickable link using the `url` returned by\n   validate_agent, and ask whether the user wants to publish it.\n8. Call publish_agent only when the user explicitly requested publication, activation, deployment,\n   or making the Agent live, or confirms publication after the build.\n9. Use update_agent_integration to configure chat integrations. Configuration never publishes the\n   Agent. A configured channel stays inactive until explicit publication unless the Agent already has an active version.\n\n## Draft test runs\n\ncall_agent verifies the draft Agent's behavior through built-in Preview chat, not configured channel\ntriggers, platform context, message delivery, or replies. Real tools and credentials are used, so\nside effects are possible. If the test exposes errors, report them and ask whether to fix them rather\nthan mutating the Agent automatically. Every approval decision must come from the human; resume each\nreturned approval individually.\n\n## Publication approval\n\nBuilding, editing, validating, or configuring an Agent never implies permission to publish or\nrepublish it. Leave the Agent as a draft by default. An explicit request to publish, activate,\ndeploy, or make live counts as approval; otherwise ask after validation and wait for the answer\nbefore calling publish_agent. Configuring a channel on an already published Agent connects it\nimmediately, so confirm that external connection before calling update_agent_integration.\n\n## Version history\n\nlist_agent_versions lists an Agent's published versions; get_agent with a versionId inspects one\nbefore acting on it. revert_agent restores the draft from a version without publishing, returning a\nfresh configHash for further mutations. publish_agent with a versionId republishes that version\ndirectly, leaving the draft untouched; as a (re)publication it requires the same explicit approval.\n\nIn publish, unpublish, and revert responses, `activeVersionId` identifies the live published\nversion (null when unpublished) while `versionId` is the draft's internal pointer \u2014 do not report\n`versionId` as a published version.\n\n## mutate_agent operations\n\nPass a single `operation` object whose `type` selects the mutation. Each operation's fields sit\ndirectly on that object \u2014 there is no `value` wrapper. For example:\n\n```json\n{ \"type\": \"config.patch\", \"patch\": [{ \"op\": \"add\", \"path\": \"/tools/-\", \"value\": { \"type\": \"workflow\", \"workflow\": \"My Workflow\", \"name\": \"my_tool\" } }] }\n```\n\n- config.replace: Set `config` to the complete editable Agent JSON configuration. Must not include\n  integrations; use update_agent_integration for those.\n- config.patch: Set `patch` to an array of RFC 6902 operations (add, remove, replace, move, copy,\n  test). Paths under /integrations are rejected; use update_agent_integration for those.\n- skill.upsert: Set `skill` to the complete skill body. Omit `skillId` to create and attach a new\n  skill, or pass it to replace an existing skill body.\n- skill.delete: Set `skillId` to the skill to delete; its config reference is removed.\n- task.upsert: Set `task` to the complete task body. Omit `taskId` to create and attach a new\n  scheduled task, or pass it to replace an existing one. `enabled` controls the task config reference.\n- task.delete: Set `taskId` to the task to delete; its config reference is removed.\n- customTool.upsert: Set `code` to the tool source; it is compiled, validated, stored, and attached.\n  Only `@n8n/agents` and `zod` imports are available. The default export must be a Tool builder\n  chain with `description`, `input` (a Zod schema), and `handler`; `output` is optional:\n\n  ```typescript\n  import { Tool } from '@n8n/agents';\n  import { z } from 'zod';\n\n  export default new Tool('get_current_datetime')\n  \t.description('Return the current date and time as an ISO 8601 string')\n  \t.input(z.object({}))\n  \t.handler(async () => new Date().toISOString());\n  ```\n- customTool.delete: Set `toolId` to the custom tool to delete; its config reference is removed.\n\nEvery mutation requires baseConfigHash from get_agent or the previous successful mutation. Mutation\nresponses contain only the next configHash and the affected resource ID, not the full Agent. On a\nstale_config response, call get_agent and retry against the returned snapshot.\n\n## Agent JSON configuration\n\nThe required runnable fields are name, model, credential, and instructions. Common optional fields\ninclude tools, skills, tasks, memory, subAgents, providerTools, mcpServers, vectorStores,\npersonalisation, and config. Integrations are not part of this config (see below).\n\nTool references use these forms:\n\n- Custom tool: { \"type\": \"custom\", \"id\": \"tool_name\" }\n- Workflow tool: { \"type\": \"workflow\", \"workflow\": \"Workflow Name\", \"name\": \"tool_name\" }\n- Node tool: { \"type\": \"node\", \"name\": \"tool_name\", \"node\": { \"nodeType\": \"...\",\n  \"nodeTypeVersion\": 1, \"nodeParameters\": {}, \"credentials\": {} } }\n\nCreating a resource does not give the Agent access to it. For example, a data table created with\ncreate_data_table is only usable by the Agent once it is attached as a node tool\n(n8n-nodes-base.dataTable); discover it with search_nodes usage=\"agentTool\" like any other node.\n\nSub-agents are not tool entries. Configure them under the top-level `subAgents` field:\n{ \"subAgents\": { \"agents\": [{ \"agentId\": \"...\", \"useWhen\": \"...\" }] } }\n\nDo not guess node parameters or stable resource IDs. Discover the node definition and live resource\noptions first. Never place credential secret data in Agent configuration or MCP tool arguments; use\ncredential IDs returned by list_credentials.\n\nSkills and tasks have separately persisted bodies. Always manage them through mutate_agent instead\nof manually inventing their IDs. Saved sub-agents must be published Agents from the same project.\nUse discover_agent_assets with kind=subagents to obtain valid IDs.\n\nChat integrations are conversation surfaces, not ordinary node tools. Use an integration when users\nshould invoke and converse with the Agent in Slack, Telegram, or Linear. Use a node/workflow tool\nwhen the Agent only needs to call that service as an API.\n\nIntegrations are persisted separately from editable config. get_agent reports them in a read-only\nintegrations field, but config.replace and config.patch can't add, change, or remove them, and they\nnever appear in the config schema above. Manage them exclusively with update_agent_integration,\nwhich validates the credential and persists the configuration without publishing. A configured\nchannel stays inactive until publish_agent is called unless the Agent already has an active version;\nin that case, it connects immediately to the existing active snapshot.\n\n## MCP servers\n\nThe top-level `mcpServers` config array connects external MCP tool catalogs to the Agent. Discover\nregistry-backed servers with discover_agent_assets kind=mcpServers, or use a URL the user provides.\nWhen the server requires authentication, resolve an accessible credential ID with list_credentials\nfirst; the same ID is passed to verification and stored in the config entry. Credentials cannot be\ncreated through these tools \u2014 when none exists, ask the user to create one in n8n.\n\nBefore writing an entry into mcpServers, call verify_agent_mcp_server with the same name, url,\ntransport, authentication, and credential. The server does not need to be attached to the Agent\nfirst: verification opens a temporary connection and returns the server's live tools. validate_agent\nnever performs this handshake, so an unverified entry can pass validation and still fail at runtime.\nConfirm the returned tools cover the requested capability and use the list to populate toolFilter\ninstead of guessing tool names. If verification fails, report the error and resolve it with the user\ninstead of persisting a broken server. Only when the user cannot supply the URL or credential yet,\npersist the known fields without inventing values and skip verification.\n";
export declare const AGENT_BUILDER_REFERENCE: string;