Funkel AI

create_agent

Destructive

Create a new draft agent under the request's scoped app. Two-phase: first call previews every setting; second call after user confirmation creates it. The agent's ICP starts from the app's saved ICP; icp_filters keys you supply override only those keys, every other saved field (job_titles, mandatory_keywords, excluded_companies, company_sizes, ...) is kept as-is. Do not restate the full ICP from memory for a vague request like "set it up" — omit icp_filters entirely to inherit the saved ICP untouched, and only pass the specific keys the user actually asked to change. To deliberately clear a list field, pass it as an empty array. excluded_companies stores exact current employer names. If supplied a LinkedIn company URL, Operator saves its slug name there and retains the URL separately for competitor signals; ask the user to verify the name in the approval. Supply signals only when the user selects exact agent discovery signals; each signal must include its supported platform, category, key, label, enabled state, and config. An explicit empty signals array creates no signals. Without signals, defaults seed from the merged ICP filters. A requested keyword such as product launch can be a keyword_tracking_product_launch signal with config.keyword='product launch'. Ask for missing signal details; never claim a requested setting was saved if this schema cannot represent it. Over MCP: call this tool once, without confirmation_token. It runs right away and returns the result.

Input Schema

Name	Required	Description
`name`	Yes	Display name for the new agent (1-100 chars)
`type`	No	Agent type (default 'signal')
`signals`	No	Exact agent discovery signals. Omit to seed from ICP; use [] for none.
`app_name`	No	App name (used in the confirm preview)
`icp_filters`	No	Optional structured ICP filters. Use job_titles, industries, regions, company_sizes, excluded_keywords, and exclude_service_providers. excluded_companies accepts exact employer names or LinkedIn company URLs. URLs become slug names and remain separately in competitor_urls. Ask the user to verify the employer name. Do not use unsupported excluded_industries.
`max_signals`	No	Cap on enabled signals (default 15)
`icp_description`	No	Free-text ICP description for the new agent
`confirmation_token`	No	Phase-2 token (omit on phase-1)
`linkedin_account_ids`	No	Local UUIDs of the workspace LinkedIn accounts selected for searches. Use [] for none.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructive/non-idempotent, and the description adds substantial behavior beyond them: the two-phase preview-then-confirm flow, that the result is a draft agent, ICP merge/override semantics, how empty arrays and empty signal sets behave, and the default signal seeding rule. No contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core contract (create draft agent, two-phase, MCP single-call) is front-loaded and most sentences carry operational rules. It is dense and a few clauses duplicate schema text (excluded_companies URL handling, signal field list), which keeps it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, nested-object tool with no output schema, the description covers the operational essentials: invocation mode, confirmation flow, ICP inheritance/override, signal seeding and defaults, and the limit that some settings can't be represented. An agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: icp_filters keys override only those keys while saved fields persist, excluded_companies stores exact employer names and converts LinkedIn URLs to slug names retained in competitor_urls, and signals entries must carry platform/category/key/label/enabled/config. This goes beyond the schema's field-level text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new draft agent under the request's scoped app') and immediately characterizes it as a two-phase preview-then-create operation. The scope (draft agent, scoped app) is specific enough to separate it from sibling mutation tools like update_icp or enable_agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not guidance: omit icp_filters to inherit the saved ICP untouched, pass only the keys the user asked to change, use [] to clear a list, supply signals only when the user selects explicit signals, and 'call this tool once, without confirmation_token' over MCP. It also tells the agent not to claim a setting was saved if the schema can't represent it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Funkel AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?