TeamShared

agent_create

Create a dedicated agent record (#733/#734): model, tools, standing procedure, memory lens, focus and an optional spend cap. Needs org:admin; agent seats are refused.

Input Schema

Name	Required	Description	Default
`kind`	No	specialist (default) or service. The manager is seeded, not created	specialist
`slug`	Yes	Agent handle: agent-<label> or <label> (lowercase, dashes)
`agent`	No	Override agent attribution label
`focus`	No	Standing strategic binding: objective_ids / key_result_ids / initiative_ids plus optional work_filter (#734)
`model`	No	Router model id every run of this agent uses; omit for the default
`budget_usd`	No	Spend cap in USD for this agent (decimal, "0" blocks every new run). Set it with budget_period, or omit both for no cap.
`namespaces`	No	Memory lens containers (repo:/github:/project:). Narrows recall; not a private store (#734)
`persona_md`	No	Private standing brief for the agent's own prompt (#734)
`mcp_servers`	No	External MCP servers this agent's runs may call (#1264): objects with name, url (https), optional tools (allowlist), secret (vault secret name, never a token) and enabled. Offered only when the run's tool allowlist grants them (all, mcp, or ext_<name>__*)
`skill_slugs`	No	Standing skills this agent always brings (#734)
`display_name`	No	Name people see; defaults to 'Agent <label>'
`github_grant`	No	This agent's GitHub grant (#1379): {repos: [owner/repo, ...], read, write, destructive}, each level off, auto or ask. Repos must be ones the org's GitHub App serves. Omit to keep the org default. Only a person can set it
`budget_period`	No	UTC window the cap resets on: day, week (Monday) or month
`tool_patterns`	No	Tool names or prefix* globs this agent's runs may bind. Narrows the deployment's allowlist, never widens it. Omit for the default
`playbook_slugs`	No	Standing playbooks used when a work item has no playbook_slug (#734)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / github_grant

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "This agent's GitHub grant (#1379): {repos: [owner/repo, ...], read, write, destructive}, each level off, auto or ask. Repos must be ones the org's GitHub App serves. Omit to keep the org default. Only a person can set it"
+}

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / mcp_servers

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "External MCP servers this agent's runs may call (#1264): objects with name, url (https), optional tools (allowlist), secret (vault secret name, never a token) and enabled. Offered only when the run's tool allowlist grants them (all, mcp, or ext_<name>__*)"
+}

Changed2 schema fields changedOct 20, 2026

addedInput schema / properties / budget_period

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "day",
+        "week",
+        "month"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "UTC window the cap resets on: day, week (Monday) or month"
+}

addedInput schema / properties / budget_usd

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Spend cap in USD for this agent (decimal, \"0\" blocks every new run). Set it with budget_period, or omit both for no cap."
+}

AddedOct 19, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioural load, and it does disclose the admin requirement, the seat refusal, and the meaningful "0" blocks every new run semantics for the spend cap. It is silent on mutation-relevant behaviour such as duplicate-slug handling, idempotency, and what side effects creating a record triggers, which matters for a write tool with zero annotation coverage.

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 tightly packed sentences that lead with the action and resource, then the capability surface, then the gating rule; nothing is padding. The issue-tracker references (#733/#734) are the only noise, and they are minor.

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 15-parameter creation tool whose schema is fully documented and which has an output schema, the description covers purpose, the configurable surface, and the permission/seat gate — enough for an agent to decide and call correctly. Remaining gaps (duplicate-slug behaviour, what is auto-provisioned) are refinements rather than blockers.

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% and the schema already documents every parameter, including enums and defaults, so the baseline is 3. The description's summary of configurable aspects (model, tools, standing procedure, memory lens, focus, spend cap) largely restates what the schema fields already say and adds no syntax or constraint detail of its own.

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 dedicated agent record") and enumerates the configurable surface (model, tools, standing procedure, memory lens, focus, spend cap), so an agent knows exactly what is produced. It does not explicitly differentiate itself from the neighbouring agent_update or agent_get, so sibling routing is left to inference from the verb 'create'.

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

Usage Guidelines3/5

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

"Needs org:admin; agent seats are refused" gives a real precondition and a refusal condition, which is more than most definitions offer. However, no alternative is named — it never says to use agent_update to change an existing agent or agent_get to inspect one — so the when-to-use decision against siblings is only implied.

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

All TeamShared tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.