Skip to main content
Glama

neurogenesis__create_agent

[neurogenesis — developmental agents: genome -> evaluation-driven growth with safety axioms + audit ledger] Create a developmental agent from a digital genome: {agent_name, purpose, initial_nodes (unique, >=1), fitness_metrics (>=1)…

Instructions

[neurogenesis — developmental agents: genome -> evaluation-driven growth with safety axioms + audit ledger] Create a developmental agent from a digital genome: {agent_name, purpose, initial_nodes (unique, >=1), fitness_metrics (>=1), optional growth_rules / safety_axioms}. Returns agent_id + initial graph summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
genomeYes
request_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.13
    • addedInput schema / properties / request_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Request Id"
      +}
  2. Addedv0.1.12

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses the genome constraints ('initial_nodes (unique, >=1)', 'fitness_metrics (>=1)') and the return shape ('agent_id + initial graph summary'), plus the safety-axioms/audit-ledger framing. However, it says nothing about permissions, whether created agents persist or are mutable, or side effects of supplying growth_rules.

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?

Two compact units: a bracketed domain tagline then a single front-loaded sentence covering inputs and outputs. Every element carries information about required fields or constraints. The bracket is slightly heavy but serves as domain scoping.

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?

With no annotations, no output schema, and a nested opaque object, the description covers creation semantics, the required genome fields with their constraints, and the return payload. It omits prerequisites and lifecycle/persistence behavior, which is a meaningful gap for a mutation tool, but the core call guidance for the genome argument is present.

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 description coverage is 0% and the genome object is opaque (additionalProperties: true) with no field metadata, so the description must compensate. It does so well by enumerating agent_name, purpose, initial_nodes (with uniqueness and cardinality constraints), fitness_metrics (>=1), and the optional growth_rules/safety_axioms. Only request_id is left unexplained, which keeps it from a 5.

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

Purpose4/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 developmental agent from a digital genome', with an enumerated genome shape. An agent can immediately tell this is the construction entry point for the neurogenesis lifecycle. It does not name a sibling or draw a boundary against list_agents/get_agent, so it stops short of a 5.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites (e.g., whether a compute profile or registration is required first), and no routing against siblings like get_agent, list_agents, or import_state. The tagline implies the agent belongs to the 'developmental agents' lifecycle, but nothing tells the agent when this call is appropriate versus the alternatives.

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