Skip to main content
Glama
ALSO Cloud Marketplace MCP Server

ALSO Cloud Marketplace MCP Server

by pitwch

Execute account custom action

execute_account_custom_action

Execute a named custom action on a subscription account by specifying the action name and required account field values.

Instructions

WRITE: ExecuteAccountCustomAction — runs a named custom action on a subscription.

Input Schema

NameRequiredDescriptionDefault
actionYesCustom action name
subscriptionAccountYesSubscription account + action field values

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so 'WRITE:' merely restates structured data. The description adds no context about side effects, idempotency, validation behavior of the free-form field values, or what happens on an unknown action name — the traits an agent most needs for an open-world write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence, front-loaded with a mutation marker, so there is no waste. But the size borders on under-specification rather than genuine conciseness, and the 'WRITE:' label duplicates the readOnlyHint annotation.

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

Completeness2/5

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

For an open-world write tool with a free-form nested parameter object and no output schema, the description should explain field-value expectations, likely failure modes, and result shape. None of that is present, leaving the agent under-equipped for a non-trivial invocation.

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 are documented, giving a baseline of 3. However, the description adds nothing about the nested subscriptionAccount object, whose arbitrary key/value structure depends entirely on the chosen action — a point where description could have supplied real value.

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: running a named custom action on a subscription, and the 'WRITE:' prefix signals mutation. It does not distinguish itself from sibling tools such as get_account_custom_actions, which an agent might otherwise pair with it to discover valid action names.

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

Usage Guidelines2/5

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

No guidance on when to use this versus get_account_custom_actions, nor any note that valid action names should be discovered first. The agent is left to infer the read-then-write workflow entirely.

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