Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_agents_factory_finalize

Validates proposed tools against the real catalog, resolves or creates the target office, blocks duplicates, and creates the agent inactive for human review. Returns the activation command.

Instructions

Finalize an Agent Factory draft: validate the proposed tools against the real catalog, resolve/create the target office, guard against duplicates, and create the agent INACTIVE (active=0) for human review. Returns the activation command. Use AFTER you've researched the domain, synthesized the system prompt, and picked tools via kernel_tool_search.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "system_prompt": "<system_prompt>"
    },
    "name": "kernel_agents_factory_finalize"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesShort human agent name, 2-4 words
briefNoOriginal domain brief — stored on the agent for provenance.
providerNoLLM provider override; default = system default
tool_idsNoCandidate tool names from kernel_tool_search. Hallucinated/unknown names are dropped automatically.
flow_nameNoTarget office (flow) name. Resolved case-insensitively; created if missing. Default: 'No office'.
rationaleNoOne line: why these tools / this design
descriptionNoOne-line description of what the agent does
goal_templateNoDefault goal prompt for runs; may use {{variables}}
system_promptYesFull synthesized system prompt governing the agent
__caller_agent_idNo[internal] injected by the agent executor when this tool is invoked from an agent run. Not meant to be set by external callers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses that the agent is created INACTIVE (active=0) for human review, that unknown tool names are silently dropped, that the office is created if missing, and that an activation command is returned. It stops short of stating required permissions or what happens to a failed validation.

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

Conciseness5/5

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

Two dense sentences with no filler; the operation sequence and the human-review safeguard are front-loaded before the usage prerequisite. Every clause adds distinct information.

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

Completeness4/5

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

For a 10-parameter, no-output-schema mutation tool, the description covers the lifecycle (validation, dedupe, inactive creation, activation command) that an agent needs to call it correctly. Minor gaps remain around failure modes and idempotency of re-finalizing an existing agent.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including the internal __caller_agent_id is already documented. The description reinforces the semantics of tool_ids (validated against the real catalog) and flow_name (resolved/created), but adds little syntax or format detail beyond the schema.

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 ('Finalize an Agent Factory draft') and enumerates the concrete sub-steps: validate tools against the real catalog, resolve/create the office, dedupe, and create the agent inactive. This clearly distinguishes it from siblings like kernel_agents_create (direct creation) and kernel_agents_flows_create (office creation alone).

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

Usage Guidelines4/5

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

Gives explicit sequencing: 'Use AFTER you've researched the domain, synthesized the system prompt, and picked tools via kernel_tool_search,' naming the sibling that supplies tool_ids. It lacks an explicit when-not-to-use (e.g., use kernel_agents_create for an agent with no tool research), but the prerequisite chain is unambiguous.

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

Deploy Server

Other Tools