Skip to main content
Glama

AIsa Apollo

Bulk Update Accounts

post_apollo_accounts_bulk_update
Destructive

Update several accounts in one call, each identified by its Apollo id. Partial success is normal; check the response per record. Writes land in the AIsa workspace, which every caller shares: the record becomes visible and editable by others, and there is no per-caller isolation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoRun asynchronously. Default false.
account_idsYesIDs of accounts to update
account_attributesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already mark this as destructive and not read-only. The description adds critical behavioral context: partial success is normal and the response must be checked per record. It also discloses the shared workspace with no per-caller isolation, which is beyond what annotations convey. No contradiction with 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?

Three sentences, front-loaded with the core purpose, followed by two concise behavioral notes. No wasted words.

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 output schema exists, return values are covered. The description covers the key operational caveats: partial success and shared workspace. It does not discuss error handling or idempotency, but idempotency is already declared in annotations as false, so that is covered. The description is adequate 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.

Parameters2/5

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

Schema coverage is 67%, meaning account_attributes lacks a top-level description. The description only clarifies that accounts are identified by Apollo id, which relates to account_ids, but does not explain the structure of account_attributes or the async parameter. It does not compensate for the missing schema descriptions.

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 clearly states the verb (update), the resource (several accounts), and the identifier (Apollo id). It distinguishes from single-account update and bulk create tools by emphasizing 'several accounts' and 'in one call'. It is specific and unambiguous.

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 bulk usage by saying 'several accounts in one call', but it does not explicitly contrast with patch_apollo_accounts_account_id for single updates or state conditions for when to prefer this tool. The context of shared workspace is given, but no exclusions or alternatives are named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources