AgentsPodium Hosting

Name: AgentsPodium Hosting
Author: agentspodium

by com.agentspodium

Overview Discussions Admin

Server Details

Create, watch, pay for and connect hosted AI agent pods on AgentsPodium. Needs an API key.

Ownership verified

Status: Healthy
Uptime: 99.7% over 21 days
Last Tested: 2026-09-28 18:44
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: agentspodium/agent-gateway
GitHub Stars: 0
Server Listing: AgentsPodium Hosting

TDQS

A4.1/5.0

Scored 2026-09-10 15:14 across 13 tools

Disambiguation5/5

Each tool targets a distinct resource and action: lifecycle (create/delete/list), health/status, billing (term, payment options), configuration (LLM key, peers, webhook), and platform discovery. No two tools have overlapping purposes, so an agent can confidently select the right one.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (e.g., create_instance, pause_instance, set_llm_key, list_platforms). The pattern is uniform across every tool, making the API predictable and easy to navigate.

Tool Count5/5

With 13 tools, the server is well-scoped for a hosting service. It covers CRUD, operational lifecycle (pause/resume/rebuild), configuration (key, peers, webhook), billing, and discovery, without unnecessary bloat or omissions.

Completeness4/5

The tool surface covers the core lifecycle and configuration needs: create, delete, list, health, pause/resume/rebuild, set LLM key/peers/webhook, and billing terms. Minor gaps include no explicit update-instance-metadata or direct plan-change tool, but these are likely handled via external links (e.g., payment options) and rebuild after config changes.

Available Tools

13 tools

create_instanceCreate instanceAInspect

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.

ParametersJSON 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

ParametersJSON 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.

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.

delete_instanceDelete instanceA

Destructive

Inspect

Permanently delete an instance. This cannot be undone.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Id of the deleted instance.
`ok`	Yes	Always true on success.

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true and openWorldHint=true, so the description's job is lighter. It adds meaningful behavioral context by stating that the action 'cannot be undone,' which goes beyond the bare destructive hint and alerts the agent to the permanence of the side effect.

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 short sentences with no filler. The most important fact—permanence—is front-loaded in the first sentence and reinforced in the second. Every word 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?

For a one-parameter destructive action with a documented schema and an output schema present, the description is nearly complete. It could mention what happens to associated resources or billing, especially given openWorldHint=true, but for most agent decision-making purposes the core consequences are clear.

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 only parameter, 'id', is already well documented as 'Instance (agent) id, as returned by create_instance or list_instances.' The tool description itself adds no parameter-level detail, so the baseline score 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 states a specific verb ('delete'), a clear resource ('instance'), and a key qualifier ('Permanently') that distinguishes it from non-destructive lifecycle operations like pause_instance or resume_instance. This is immediately actionable for an agent choosing among the sibling tools.

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 clearly conveys that this tool is for permanent deletion, which gives the agent the main contextual signal for when to use it. It does not explicitly name alternatives or list when-not-to-use conditions, but the irreversibility is a strong implicit exclusion against casual use.

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

get_instance_healthCheck instance healthA

Read-only

Inspect

Check whether an instance is reachable and serving, plus its status and quota state.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance id checked.
`status`	Yes	Lifecycle status reported by the account API.
`serving`	Yes	Whether the instance is currently answering requests, or null if unknown.
`reachable`	Yes	Whether the instance's endpoint responded, or null if unknown.
`quotaStatus`	Yes	Usage quota status, or null if not tracked.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so no side-effect warning is needed. The description adds useful behavioral context beyond the annotations by specifying what 'health' means here—reachable, serving, status, and quota state—and the output schema covers return details.

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?

A single, front-loaded sentence that wastes no words and presents the core purpose first. Every phrase ('reachable and serving', 'status and quota state') adds meaning.

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

Completeness5/5

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

For a one-parameter read-only health check with an output schema, the description plus annotations fully cover what an agent needs to invoke and interpret the tool. It states the scope of the check and does not omit required caveats.

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?

The schema fully documents the only parameter (id) with a clear description ('Instance (agent) id, as returned by create_instance or list_instances'). With 100% schema coverage, the description is not required to repeat parameter details, and it does not add extra parameter-level meaning.

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 opens with the specific verb 'Check' and clearly identifies the resource ('an instance') and the dimensions checked: reachability, serving status, and quota state. This distinguishes it from sibling tools like get_instance_term or create_instance, which concern different operations.

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 gives a clear context: use this tool to verify an instance is reachable and serving, and to inspect status and quota. It does not explicitly name alternatives or state when not to use it, though the sibling list makes the contrast evident.

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

get_instance_termGet billing termA

Read-only

Inspect

Get the billing term (trial/paid/grace) for an instance, including when it renews or expires.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`term`	Yes	Billing term details (status, renewal/expiry dates, etc.), as returned by the account API.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate this is read-only (readOnlyHint=true), and the description adds meaningful behavioral context by specifying what kind of information is returned: billing term category and renewal/expiration timing. This goes beyond merely restating the read-only annotation without being verbose.

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?

A single, well-structured sentence that front-loads the core purpose and then adds the key output detail. Every word earns its place; there is no redundancy or filler.

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

Completeness5/5

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

For a simple one-parameter read-only tool with an output schema, the description covers the essential semantics: what is retrieved and what additional details are included. The annotations handle safety, and the schema handles the parameter and return structure, so nothing critical is missing.

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 'id' parameter is already documented as the instance/agent id returned by create_instance or list_instances. The tool description adds no further parameter-level detail, 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 uses a specific verb ('Get') with a precise resource ('billing term') and lists the possible term categories (trial/paid/grace) plus the time-related details (renews/expires). This clearly distinguishes it from sibling tools like get_instance_health and get_payment_options.

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 gives clear context: use this tool when you need an instance's billing term and renewal/expiration timing. It does not explicitly name alternatives or state when not to use it, but the purpose is evident enough for an agent to route to the correct tool.

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

get_payment_optionsGet payment optionsA

Read-only

Inspect

Get ways to pay for an instance's plan: card/subscription buy links, crypto payment info, and Telegram Stars info (crypto and Stars are in beta testing), plus the instance's current term.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`term`	No	The instance's current billing term.
`stars`	Yes	Telegram Stars payment info (beta testing), as returned by the account API, plus an added 'note' field.
`crypto`	Yes	Crypto payment info (beta testing), as returned by the account API, plus an added 'note' field.
`providers`	No	Card/subscription payment providers and buy links, as returned by the account API.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond annotations by specifying what the tool returns and by flagging that crypto and Telegram Stars are in beta testing, which sets appropriate expectations.

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 a single front-loaded sentence with a colon-separated enumeration of payment options. It conveys the scope, the beta caveat, and the extra current-term field with no filler or repetition.

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 read-only, one-parameter tool with an output schema and annotations, the description is largely complete. The only meaningful gap is not clarifying when the agent should prefer get_instance_term for the term portion, but that is more of a usage-routing concern than a missing invocation detail.

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?

The input schema covers the only parameter, id, with 100% coverage and already explains that it is the instance id returned by create_instance or list_instances. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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?

The description names a specific verb and resource: 'Get ways to pay for an instance's plan', and enumerates the returned categories (card/subscription buy links, crypto, Telegram Stars, current term). It is clear, but it does not explicitly differentiate itself from the sibling get_instance_term even though the description also returns the instance's current term.

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?

There is no explicit guidance about when to use this tool versus alternatives, and no mention of when not to use it. The overlap with get_instance_term could confuse an agent, and the description does not address that or any other routing considerations.

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

list_instancesList instancesA

Read-only

Inspect

List the caller's AgentsPodium instances (agents): id, name, engine, tier, status, endpoint and A2A URL, domain, creation date. Never returns secrets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`instances`	Yes	The caller's instances.

TDQS

A4.1/5.0

Behavior4/5

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

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context by explicitly listing the returned fields and stating that secrets are never returned. This security disclaimer goes beyond the structured annotation and helps set expectations.

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 a single well-structured sentence that front-loads the core operation and then lists the return fields. Every part earns its place, and the important 'Never returns secrets' caveat is included without bloat.

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

Completeness5/5

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

For a parameterless read-only list tool with a provided output schema, the description is complete: it names the resource, scope, returned fields, and security boundary. Nothing essential is missing for an agent to invoke it correctly.

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?

The input schema has zero parameters, so the baseline of 4 applies. No parameter documentation is needed, and the description appropriately focuses on output rather than input semantics.

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 uses a specific verb ('List') with a precise resource ('the caller's AgentsPodium instances') and enumerates the returned fields. It distinguishes this tool from siblings like list_platforms by clarifying it lists instances/agents, not platforms.

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?

The description does not explicitly say when to use this tool versus alternatives such as instance_health or list_platforms. While the operation is clear, there is no guidance about exclusions or conditions that should steer an agent to a sibling tool.

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

list_platformsList platforms and plansA

Read-only

Inspect

List available AgentsPodium engines (platforms) and hosting plans (tiers), with prices and capabilities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`tiers`	Yes	Available hosting plans (tiers) with prices, as published by the account API.
`engines`	Yes	Available runtime engines.

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds minor context by specifying that results are 'available' engines and plans with prices and capabilities, but it does not disclose additional behaviors such as whether results are static, ordered, or require authentication. The annotation coverage lowers the burden, so a middle score is appropriate.

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 a single sentence that front-loads the verb and resource, includes all key details, and contains no filler or redundant phrasing. Every word earns its place.

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

Completeness5/5

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

Given the tool's simplicity (no parameters, no nested objects, present output schema, and annotations covering safety), the description is complete. It clearly states what the tool returns and is sufficiently informative for an agent to invoke it correctly.

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?

The tool accepts no parameters and the schema coverage is 100%, so there is nothing for the description to explain. With zero parameters, the baseline is 4, and the description correctly does not invent unnecessary parameter details.

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 states a specific verb ('List') and resource ('AgentsPodium engines (platforms) and hosting plans (tiers)') and specifies the returned attributes ('prices and capabilities'). This clearly distinguishes the tool from the sibling list_instances, which focuses on instances rather than platform/plan catalog data.

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 makes the context clear: this is the tool for viewing platform and plan information. It does not explicitly mention alternatives or when-not-to-use, but the contrast with siblings like create_instance and list_instances makes the usage intent obvious. No exclusions are stated, which is acceptable for a simple catalog tool.

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

pause_instancePause instanceA

Idempotent

Inspect

Pause an instance: stops it and its billing lease. Data is archived, not deleted.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id.
`name`	Yes	Display name.
`tier`	Yes	Hosting plan id.
`a2aUrl`	Yes	A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.
`domain`	Yes	Customer-owned domain serving the instance, or null.
`engine`	Yes	Runtime engine id (e.g. hermes).
`status`	Yes	Lifecycle status (e.g. running, stopped).
`createdAt`	Yes	ISO timestamp when the instance was created.
`endpointUrl`	Yes	Public HTTPS endpoint for the instance, or null if not yet assigned.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only provide idempotentHint and openWorldHint, so the description carries the burden of explaining the operation's real-world effect. It adds valuable context that data is archived rather than deleted and that billing stops, which goes beyond the schema and annotations.

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 one tight sentence with no filler. It front-loads the action and immediately follows with the most important behavioral qualifier about data retention.

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

Completeness5/5

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

For a single-parameter tool with a clear annotation profile and an output schema, this description is complete. It states the action, the billing impact, and the data retention behavior, leaving no critical gap for an agent to call it correctly.

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 single 'id' parameter is already well described as an instance id from create_instance or list_instances. The description adds no additional parameter meaning, so the baseline of 3 applies.

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 uses a specific verb and resource ('Pause an instance') and clearly states the effect: stopping the instance and its billing lease. It also distinguishes itself from deletion by saying data is archived, not deleted, which helps an agent tell it apart from delete_instance without opening schemas.

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 description implies usage context: pause when you want to stop billing while preserving data. However, it does not explicitly name alternatives like resume_instance or delete_instance or state when not to use this tool, leaving some routing to inference.

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

rebuild_instanceRebuild instanceA

Destructive

Inspect

Rebuild an instance's pod (e.g. after a config change that needs a restart).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id.
`name`	Yes	Display name.
`tier`	Yes	Hosting plan id.
`a2aUrl`	Yes	A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.
`domain`	Yes	Customer-owned domain serving the instance, or null.
`engine`	Yes	Runtime engine id (e.g. hermes).
`status`	Yes	Lifecycle status (e.g. running, stopped).
`createdAt`	Yes	ISO timestamp when the instance was created.
`endpointUrl`	Yes	Public HTTPS endpoint for the instance, or null if not yet assigned.

TDQS

A3.8/5.0

Behavior3/5

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

The annotations already declare destructiveHint=true and openWorldHint=true, so the description does not need to restate that this is destructive. The description adds the restart-after-config-change context, which is useful, but it does not detail what exactly gets destroyed or whether the instance becomes unavailable during the rebuild.

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?

One concise sentence with the core action first and the use case in parentheses. Every word earns its place with no redundant filler.

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 single-parameter tool with annotations covering destructiveness and side effects, the description is nearly sufficient. The only missing piece is a brief note about the operational impact on the running instance, but this is minor given the simple interface.

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 single parameter 'id' already has a clear description referencing create_instance and list_instances. The tool description adds no additional parameter-level information, so the baseline of 3 applies.

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?

The description clearly states a specific action—'Rebuild an instance's pod'—and gives a concrete motivating example. It is distinguishable from siblings like pause_instance or delete_instance, though 'rebuild' is not deeply elaborated.

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?

It gives a clear use case: 'after a config change that needs a restart.' This provides practical context for when to invoke the tool, though it does not explicitly discuss when not to use it or name alternatives.

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

resume_instanceResume instanceA

Idempotent

Inspect

Resume a previously paused instance, rebuilding it from its archive.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id.
`name`	Yes	Display name.
`tier`	Yes	Hosting plan id.
`a2aUrl`	Yes	A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.
`domain`	Yes	Customer-owned domain serving the instance, or null.
`engine`	Yes	Runtime engine id (e.g. hermes).
`status`	Yes	Lifecycle status (e.g. running, stopped).
`createdAt`	Yes	ISO timestamp when the instance was created.
`endpointUrl`	Yes	Public HTTPS endpoint for the instance, or null if not yet assigned.

TDQS

A3.6/5.0

Behavior3/5

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

The description adds useful behavioral context by saying the instance is 'rebuilt from its archive', going beyond the annotations. However, it does not disclose what happens to the current instance state, whether data is replaced, or any side effects despite openWorldHint suggesting possible unspecified behavior.

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 a single efficient sentence that places the main action first and adds a meaningful qualifier ('previously paused', 'from its archive'). No words are wasted.

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 one-parameter tool with an output schema, the description covers the essential trigger condition and the rebuilding behavior. It is adequate, though it could be more complete by clarifying post-resume state or explicit differences from rebuild_instance.

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?

The input schema already provides complete coverage of the single 'id' parameter, including where the id comes from. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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?

The description uses a specific verb-resource pair ('Resume ... instance') and adds the condition 'previously paused', which makes the core purpose clear. It does not explicitly differentiate itself from the sibling rebuild_instance, though the paused-state condition provides some distinction.

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 description implies the tool is for paused instances only, but it does not explicitly state when not to use it or how it differs from rebuild_instance. There are no exclusions or alternative-selection cues.

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

set_llm_keySet LLM keyA

Idempotent

Inspect

Set (or clear, with key=null) the LLM provider API key an instance uses to answer. Required before a freshly created instance can actually respond.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.
`key`	Yes	The provider API key. Stored encrypted, never echoed back.
`model`	No	Model id to use with this provider (e.g. gpt-4o-mini). Optional; the engine defaults if omitted.
`provider`	Yes	LLM provider id, e.g. openai, anthropic, deepseek.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id.
`name`	Yes	Display name.
`tier`	Yes	Hosting plan id.
`a2aUrl`	Yes	A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.
`domain`	Yes	Customer-owned domain serving the instance, or null.
`engine`	Yes	Runtime engine id (e.g. hermes).
`status`	Yes	Lifecycle status (e.g. running, stopped).
`createdAt`	Yes	ISO timestamp when the instance was created.
`endpointUrl`	Yes	Public HTTPS endpoint for the instance, or null if not yet assigned.

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the openWorld and idempotent hints, the description explains that passing key=null clears the key and that this setup is a prerequisite for responses. No destructive side effects are hidden and nothing contradicts the annotations.

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 short sentences front-load the core behavior and add the key prerequisite. There is no filler or redundancy.

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 a fully documented schema, an output schema, and annotations, the description covers the central purpose and timing. It would be more complete if the clearing behavior were expressed in a way consistent with the schema, but nothing essential is missing.

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

Parameters2/5

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

Schema coverage is 100%, so the baseline is 3, but the only parameter-level behavior the description adds—'clear, with key=null'—contradicts the schema, where key is required, type string, and minLength 1. The guidance is therefore unreliable and could lead to an invalid call.

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?

The description names a precise verb and resource: 'Set (or clear...) the LLM provider API key an instance uses to answer.' It is clearly distinct from the sibling instance-management tools, but it does not explicitly name or contrast any sibling, 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 Guidelines4/5

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

'Required before a freshly created instance can actually respond' gives the agent a concrete trigger for using this tool: after creation and before the instance is expected to answer. It does not spell out alternatives or when-not conditions, but the context is clear.

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

set_peersSet A2A peersA

Idempotent

Inspect

Set the list of other A2A agents this instance is allowed to call by name.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id whose peer list is being set.
`peers`	Yes	Full replacement list of peer agents this instance may call (up to 20).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance (agent) id.
`name`	Yes	Display name.
`tier`	Yes	Hosting plan id.
`a2aUrl`	Yes	A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.
`domain`	Yes	Customer-owned domain serving the instance, or null.
`engine`	Yes	Runtime engine id (e.g. hermes).
`status`	Yes	Lifecycle status (e.g. running, stopped).
`createdAt`	Yes	ISO timestamp when the instance was created.
`endpointUrl`	Yes	Public HTTPS endpoint for the instance, or null if not yet assigned.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already carry idempotency and open-world hints. The description adds that the operation updates call permissions and that peers are addressed by name. It doesn't restate the full-replacement behavior, but the schema's 'Full replacement list' phrase already covers that, and there is no contradiction.

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?

One sentence with no redundancy; the action and object are front-loaded. Every word 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?

For a two-parameter configuration tool with a complete schema and an output schema, the definition is nearly complete. It could spell out replacement semantics in prose, but the schema already declares 'Full replacement list' and maxItems, so no critical invocation detail is missing.

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 coverage is 100%, with meaningful descriptions for id, peers, name, url, and token. The description's 'by name' phrasing reinforces the role of the name property but adds no parameter-specific detail beyond what the schema already provides.

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 states a specific action ('Set the list') and a precise resource ('other A2A agents this instance is allowed to call by name'). This clearly distinguishes it from lifecycle and key-management siblings, so an agent can identify when this tool applies.

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 sentence makes the intended use clear: configuring an instance's allowed A2A peer agents. It doesn't explicitly name alternatives or exclusions, but no sibling tool overlaps with peer-list configuration, so the context is sufficient.

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

set_webhookSet event webhookA

Idempotent

Inspect

Register a URL that receives signed POSTs when the instance comes up, stops, fails, is deleted, when a payment is confirmed and before deletion for non-payment — instead of polling get_instance_health. Returns the HMAC secret once.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Instance (agent) id, as returned by create_instance or list_instances.
`url`	Yes	Public http(s) URL to POST signed pod events to. Private and loopback hosts are refused.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Instance id.
`url`	Yes	The webhook URL now in effect.
`events`	Yes	Event types that will be delivered.
`secret`	Yes	HMAC-SHA256 key for X-AgentsPodium-Signature. Shown once — store it.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations include openWorldHint and idempotentHint, which already signal side effects and repeatability. The description adds useful behavioral detail: it returns the HMAC secret once, events are signed POSTs, and it covers specific lifecycle events. This goes beyond the annotations without contradicting them.

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?

The description is two sentences but the first is long and information-dense, listing all event types and the polling alternative. It is front-loaded with the core purpose and avoids redundancy, though it could be broken into shorter sentences for readability. Still, 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?

With an output schema present and annotations covering side effects, the description adequately explains what the tool does, when to use it, and a key return behavior (HMAC secret once). It does not cover error scenarios or security details beyond 'signed POSTs', but these are not critical for invoking the tool correctly given the rich schema.

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 coverage is 100%, so both parameters (id and url) already have meaningful descriptions. The tool description does not add further parameter-level detail, but it does clarify the url's role (receives signed POSTs) and that private/loopback hosts are refused (though this is in the schema). Baseline of 3 is appropriate since the schema does the heavy lifting.

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 states a specific action ('Register a URL') with a precise resource (webhook for instance events), enumerates the exact events covered, and explicitly contrasts itself with the sibling tool get_instance_health. This makes the tool's purpose unmistakable and differentiates it from the alternative without needing to inspect the schema.

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 explicitly names get_instance_health as an alternative and indicates this tool should be used 'instead of polling', giving clear guidance on when to prefer it. It does not, however, state conditions when webhooks are inappropriate (e.g., for short-lived instances), but the core usage context is present.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 9, 2026

Changedcreate_instance3 fields changed

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"
+]

Addedset_webhook

6 tool updatesSep 8, 2026
- Addedget_instance_health
- Addedget_instance_term
- Addedget_payment_options
- Removedinstance_health
- Removedinstance_term
- Removedpayment_options

12 tool updatesSep 8, 2026

Changedcreate_instance1 field changed

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"
+}

Changeddelete_instance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "id": {
+      "description": "Id of the deleted instance.",
+      "type": "string"
+    },
+    "ok": {
+      "const": true,
+      "description": "Always true on success.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok",
+    "id"
+  ],
+  "type": "object"
+}

Changedinstance_health1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "id": {
+      "description": "Instance id checked.",
+      "type": "string"
+    },
+    "quotaStatus": {
+      "description": "Usage quota status, or null if not tracked.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reachable": {
+      "description": "Whether the instance's endpoint responded, or null if unknown.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "serving": {
+      "description": "Whether the instance is currently answering requests, or null if unknown.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "status": {
+      "description": "Lifecycle status reported by the account API.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "quotaStatus",
+    "reachable",
+    "serving"
+  ],
+  "type": "object"
+}

Changedinstance_term1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "term": {
+      "additionalProperties": {},
+      "description": "Billing term details (status, renewal/expiry dates, etc.), as returned by the account API.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "term"
+  ],
+  "type": "object"
+}

Changedlist_instances1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "instances": {
+      "description": "The caller's instances.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "a2aUrl": {
+            "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "createdAt": {
+            "description": "ISO timestamp when the instance was created.",
+            "type": "string"
+          },
+          "domain": {
+            "description": "Customer-owned domain serving the instance, or null.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "endpointUrl": {
+            "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "engine": {
+            "description": "Runtime engine id (e.g. hermes).",
+            "type": "string"
+          },
+          "id": {
+            "description": "Instance (agent) id.",
+            "type": "string"
+          },
+          "name": {
+            "description": "Display name.",
+            "type": "string"
+          },
+          "status": {
+            "description": "Lifecycle status (e.g. running, stopped).",
+            "type": "string"
+          },
+          "tier": {
+            "description": "Hosting plan id.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "engine",
+          "tier",
+          "status",
+          "endpointUrl",
+          "a2aUrl",
+          "domain",
+          "createdAt"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "instances"
+  ],
+  "type": "object"
+}

Changedlist_platforms1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "engines": {
+      "description": "Available runtime engines.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "capabilities": {
+            "description": "Engine-specific capability flags, as published by the account API."
+          },
+          "id": {
+            "description": "Engine id (e.g. hermes).",
+            "type": "string"
+          },
+          "label": {
+            "description": "Human-readable engine name.",
+            "type": "string"
+          },
+          "minTier": {
+            "description": "Cheapest tier this engine can run on.",
+            "type": "string"
+          },
+          "status": {
+            "description": "Engine availability status (e.g. stable, beta).",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "label",
+          "minTier",
+          "status"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "tiers": {
+      "description": "Available hosting plans (tiers) with prices, as published by the account API.",
+      "items": {},
+      "type": "array"
+    }
+  },
+  "required": [
+    "engines",
+    "tiers"
+  ],
+  "type": "object"
+}

Changedpause_instance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aUrl": {
+      "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "ISO timestamp when the instance was created.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Customer-owned domain serving the instance, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "engine": {
+      "description": "Runtime engine id (e.g. hermes).",
+      "type": "string"
+    },
+    "id": {
+      "description": "Instance (agent) id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Lifecycle status (e.g. running, stopped).",
+      "type": "string"
+    },
+    "tier": {
+      "description": "Hosting plan id.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "engine",
+    "tier",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "domain",
+    "createdAt"
+  ],
+  "type": "object"
+}

Changedpayment_options1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "crypto": {
+      "additionalProperties": {},
+      "description": "Crypto payment info (beta testing), as returned by the account API, plus an added 'note' field.",
+      "type": "object"
+    },
+    "providers": {
+      "description": "Card/subscription payment providers and buy links, as returned by the account API."
+    },
+    "stars": {
+      "additionalProperties": {},
+      "description": "Telegram Stars payment info (beta testing), as returned by the account API, plus an added 'note' field.",
+      "type": "object"
+    },
+    "term": {
+      "description": "The instance's current billing term."
+    }
+  },
+  "required": [
+    "crypto",
+    "stars"
+  ],
+  "type": "object"
+}

Changedrebuild_instance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aUrl": {
+      "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "ISO timestamp when the instance was created.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Customer-owned domain serving the instance, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "engine": {
+      "description": "Runtime engine id (e.g. hermes).",
+      "type": "string"
+    },
+    "id": {
+      "description": "Instance (agent) id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Lifecycle status (e.g. running, stopped).",
+      "type": "string"
+    },
+    "tier": {
+      "description": "Hosting plan id.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "engine",
+    "tier",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "domain",
+    "createdAt"
+  ],
+  "type": "object"
+}

Changedresume_instance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aUrl": {
+      "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "ISO timestamp when the instance was created.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Customer-owned domain serving the instance, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "engine": {
+      "description": "Runtime engine id (e.g. hermes).",
+      "type": "string"
+    },
+    "id": {
+      "description": "Instance (agent) id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Lifecycle status (e.g. running, stopped).",
+      "type": "string"
+    },
+    "tier": {
+      "description": "Hosting plan id.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "engine",
+    "tier",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "domain",
+    "createdAt"
+  ],
+  "type": "object"
+}

Changedset_llm_key3 fields changed

addedInput schema / properties / id / description

Added value: +"Instance (agent) id, as returned by create_instance or list_instances."

addedInput schema / properties / model / description

Added value: +"Model id to use with this provider (e.g. gpt-4o-mini). Optional; the engine defaults if omitted."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aUrl": {
+      "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "ISO timestamp when the instance was created.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Customer-owned domain serving the instance, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "engine": {
+      "description": "Runtime engine id (e.g. hermes).",
+      "type": "string"
+    },
+    "id": {
+      "description": "Instance (agent) id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Lifecycle status (e.g. running, stopped).",
+      "type": "string"
+    },
+    "tier": {
+      "description": "Hosting plan id.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "engine",
+    "tier",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "domain",
+    "createdAt"
+  ],
+  "type": "object"
+}

Changedset_peers6 fields changed

addedInput schema / properties / id / description

Added value: +"Instance (agent) id whose peer list is being set."

addedInput schema / properties / peers / description

Added value: +"Full replacement list of peer agents this instance may call (up to 20)."

addedInput schema / properties / peers / items / properties / name / description
```
Added value: +"Name other agents use to address this peer over A2A."
```

addedInput schema / properties / peers / items / properties / token / description

Added value: +"Bearer token to send when calling this peer, if it requires one."

addedInput schema / properties / peers / items / properties / url / description
```
Added value: +"A2A JSON-RPC endpoint URL of the peer agent."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "a2aUrl": {
+      "description": "A2A JSON-RPC endpoint for the instance, or null if A2A is not enabled.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "ISO timestamp when the instance was created.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Customer-owned domain serving the instance, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "endpointUrl": {
+      "description": "Public HTTPS endpoint for the instance, or null if not yet assigned.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "engine": {
+      "description": "Runtime engine id (e.g. hermes).",
+      "type": "string"
+    },
+    "id": {
+      "description": "Instance (agent) id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Lifecycle status (e.g. running, stopped).",
+      "type": "string"
+    },
+    "tier": {
+      "description": "Hosting plan id.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "engine",
+    "tier",
+    "status",
+    "endpointUrl",
+    "a2aUrl",
+    "domain",
+    "createdAt"
+  ],
+  "type": "object"
+}

12 tool updatesSep 8, 2026
- First observedcreate_instance
- First observeddelete_instance
- First observedinstance_health
- First observedinstance_term
- First observedlist_instances
- First observedlist_platforms
- First observedpause_instance
- First observedpayment_options
- First observedrebuild_instance
- First observedresume_instance
- First observedset_llm_key
- First observedset_peers

Related MCP Connectors

ScrollportOAuth
com.scrollport
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Agent Orchestration Developer Tools
1
agentdevx C
io.github.mirajmahmudul
Give your AI hands. Identity, credential vault, and API gateway for autonomous agents.
Agent Orchestration Developer Tools
382
givemeanodeOAuth
com.givemeanode
On-demand GPU nodes for agents: create nodes, run commands, and submit jobs, billed by the minute.
AI & Machine Learning Cloud Platforms Code Execution
1
DynamicEndpoints-autogen_mcpOAuth
ai.smithery
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Autonomous Agents Agent Orchestration Developer Tools
215

Related MCP Servers

agents-mcp
AI & Machine Learning Agent Orchestration Autonomous Agents
DedInc
A
license
Not graded
quality
D
maintenance
Enables running AI agents via OpenAI-compatible APIs with custom system prompts, models, and queries. Supports persistent memory, preset agents, and multi-step workflows like pipelines and swarms.
Updated 7 months ago (2026-03-04 10:03 UTC)
16 npm
MIT
Cisco MCP Pods Server
Cloud Platforms Developer Tools
ruegreen
F
license
A
quality
Not graded
maintenance
Enables AI agents to interact with Cisco API Gateway pods endpoints for complete pod management including CRUD operations, credential updates, and configuration management through natural language. Supports multiple deployment modes including local Claude Desktop integration and cloud deployment for remote AI agents like Webex Connect.
Updated a year ago (2025-10-21 22:56 UTC)
7
-
aimall-mcp
AI & Machine Learning Payments & Billing Autonomous Agents
sukyboor
A
license
Not graded
quality
D
maintenance
Enables autonomous agents to discover, price, and call hosted AI models and tools, and manage payments via a self-serve API marketplace.
Updated 17 days ago (2026-09-11 07:28 UTC)
1
MIT
Agentic AI System MCP Server
Autonomous Agents Agent Orchestration Code Execution
saikumarjash
F
license
Not graded
quality
D
maintenance
Enables deployment of autonomous AI agents with memory and tool execution capabilities through a WebSocket-based MCP protocol. Provides production-ready infrastructure with REST API access, persistent state management, and extensible function registry for building self-hosted AI systems.
Updated a year ago (2025-10-24 05:35 UTC)
-

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources