AgentsPodium Hosting

Create instance

create_instance

Create (deploy) a new AgentsPodium instance. Returns the instance id and, when enableA2A is true, the a2aUrl and a2aToken the caller should keep. After creating, poll get_instance_health until it is serving, then call set_llm_key to give it a working LLM key.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Display name for the instance.
`tier`	Yes	Hosting plan controlling RAM/CPU/disk. See list_platforms for prices.
`model`	No	Default LLM model id for the engine.
`domain`	No	Customer-owned domain to serve the instance from.
`engine`	No	Runtime engine id (e.g. hermes, openclaw, n8n). See list_platforms for what's available.	hermes
`channels`	No	Channels to enable (web, telegram, ...).
`enableA2A`	No	Turn on the A2A toolset and issue an a2aUrl/a2aToken for this instance.
`extraSoul`	No	Extra system-prompt instructions appended to the persona.
`personaId`	No	Persona/template id from list_platforms; defaults to the general-purpose persona.	personal-assistant
`webhookUrl`	No	Public http(s) URL to receive signed pod events (agent.running, agent.stopped, agent.failed, agent.deleted, payment.confirmed, deletion.warning) instead of polling. The signing secret comes back once as webhookSecret.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Newly created instance id.
`next`	Yes	Suggested next step for the caller.
`a2aUrl`	Yes	A2A endpoint, or null if A2A was not enabled.
`status`	Yes	Initial lifecycle status.
`a2aToken`	Yes	A2A bearer token to keep, or null if A2A was not enabled.
`endpointUrl`	Yes	Public HTTPS endpoint, or null until assigned.
`webhookSecret`	Yes	HMAC key for webhook signatures when webhookUrl was given (shown once), else null.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 9, 2026

addedInput schema / properties / webhookUrl

Added value: +{
+  "description": "Public http(s) URL to receive signed pod events (agent.running, agent.stopped, agent.failed, agent.deleted, payment.confirmed, deletion.warning) instead of polling. The signing secret comes back once as webhookSecret.",
+  "maxLength": 500,
+  "type": "string"
+}

addedOutput schema / properties / webhookSecret

Added value: +{
+  "description": "HMAC key for webhook signatures when webhookUrl was given (shown once), else null.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "status",
-  "endpointUrl",
-  "a2aUrl",
-  "a2aToken",
-  "next"
-]New value: +[
+  "id",
+  "status",
+  "endpointUrl",
+  "a2aUrl",
+  "a2aToken",
+  "webhookSecret",
+  "next"
+]

Changed1 schema field changedSep 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aToken": {
+      "description": "A2A bearer token to keep, or null if A2A was not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "a2aUrl": {
+      "description": "A2A endpoint, or null if A2A was not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint, or null until assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "id": {
+      "description": "Newly created instance id.",
+      "type": "string"
+    },
+    "next": {
+      "description": "Suggested next step for the caller.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Initial lifecycle status.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "a2aToken",
+    "next"
+  ],
+  "type": "object"
+}

First observedSep 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the sparse openWorldHint annotation, the description discloses meaningful behavior: it returns an instance id, conditionally returns a2aUrl/a2aToken that must be kept, and indicates the instance is not immediately usable by prescribing a post-create polling workflow. It does not mention provisioning duration or billing, but it is more transparent than a bare 'create a new instance.'

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?

The description is three sentences with no wasted words. It front-loads the core purpose, then states return values, then gives actionable next steps. Every sentence earns its place.

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?

Given the 10-parameter schema and the presence of an output schema, the description appropriately avoids restating return formats. It covers the core invocation, conditional credentials, and follow-up workflow. It could mention costs or failure handling, but it is adequate for an agent to call the tool and continue the lifecycle.

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 the schema already documents all 10 parameters well. The main description adds useful workflow context around enableA2A but does not add per-parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description begins with a specific verb and resource: 'Create (deploy) a new AgentsPodium instance.' It clearly distinguishes this from lifecycle siblings like list_instances, delete_instance, and get_instance_health, and states what the tool returns.

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?

The description provides clear workflow context by instructing the caller to poll get_instance_health until serving and then call set_llm_key. It does not explicitly state when not to use it or name alternatives for creation, but the context is strong enough that an agent can infer when to invoke it.

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

All AgentsPodium Hosting 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.