Skip to main content
Glama

Create agent config

configs_create

Compiles and saves an immutable agent configuration from YAML or JSON, returning the existing config when the same source still resolves to the same resources.

Instructions

Compiles and saves an immutable agent config (instruction, model, tools, machine_sources, and more) from YAML or JSON and returns it. Sending the same source again returns the existing config, as long as its names still resolve to the same resources.

Input Schema

NameRequiredDescriptionDefault
orgIDYesOrganization ID (org_...).
sourceYesAgent config source as YAML or JSON text, or, with source_format json, as a JSON object.
projectIDYesProject ID (proj_...).
source_formatYesFormat of source: yaml or json.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.4
    • removedInput schema / $defs / AgentConfigDefinition / properties / event_webhook
      Removed value: -{
      -  "$ref": "#/$defs/AgentConfigDefinitionEventWebhook"
      -}
    • removedInput schema / $defs / AgentConfigDefinitionEventWebhook
      Removed value: -{
      -  "additionalProperties": false,
      -  "properties": {
      -    "events": {
      -      "items": {
      -        "enum": [
      -          "agent_input",
      -          "model_output",
      -          "tool_result",
      -          "context_checkpoint",
      -          "tool_call_update"
      -        ]
      -      },
      -      "minItems": 1,
      -      "type": "array",
      -      "uniqueItems": true
      -    },
      -    "signing_secret_id": {
      -      "minLength": 1,
      -      "type": "string"
      -    },
      -    "url": {
      -      "minLength": 1,
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "url",
      -    "events"
      -  ],
      -  "type": "object",
      -  "x-go-type": "json.RawMessage"
      -}
  2. Changed2 schema fields changedv0.1.2
    • addedInput schema / $defs / AgentConfigDefinitionGitCredentials / properties / read_only
      Added value: +{
      +  "description": "Prevents pushing, even if the integration allows it.",
      +  "type": "boolean"
      +}
    • addedInput schema / $defs / AgentConfigDefinitionGitCredentials / properties / repository_ids
      Added value: +{
      +  "description": "GitHub repository IDs the credentials can access. Defaults to every repository the installation can access.",
      +  "items": {
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  "maxItems": 500,
      +  "minItems": 1,
      +  "type": "array",
      +  "uniqueItems": true
      +}
  3. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / orgID / description
      Added value: +"Organization ID (org_...)."
    • addedInput schema / properties / projectID / description
      Added value: +"Project ID (proj_...)."
    • addedInput schema / properties / source_format / description
      Added value: +"Format of source: yaml or json."
  4. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Adds real behavior beyond the annotations: the config is compiled against the schema, the result is immutable, the created config is returned, and identical source deduplicates to the existing config provided names still resolve. The qualification about name resolution is what keeps this consistent with idempotentHint=false rather than contradicting it. Gaps: no statement of permission requirements or what happens when referenced resources resolve differently.

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 sentences, front-loaded with the action and scope, with the deduplication caveat placed last where it belongs. No filler or restatement of the title.

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

Completeness3/5

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

Covers the create/dedupe semantics and notes that the config is returned, which substitutes for the absent output schema. However, for a tool whose huge nested schema references other resources by name, it omits the key operational context: referenced resources must exist and be granted, and immutability means changes require a new config rather than an in-place edit.

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 orgID, projectID, source, and source_format are already documented in the schema. The description only echoes the YAML/JSON duality and the field list, adding no guidance on which format to prefer or how source interacts with source_format.

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 chain (compiles and saves) and resource (immutable agent config), and enumerates the defining fields plus accepted input formats. It does not contrast itself with the sibling configs_get, so the agent must infer that this is the write-side counterpart.

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?

The second sentence implies when re-sending is safe, which is useful context, but there is no explicit when-to-use / when-not guidance and no mention of prerequisites such as referenced models, machine sources, or secrets needing to exist and be granted. Usage is inferable but not stated.

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