GravityPort

stack_add_assets

Append saved assets to an existing stack after its current members; duplicates are skipped, and assets assigned to another stack cause the call to fail without changes.

Instructions

Add saved assets to an existing stack, after its current members. Assets already in this stack are skipped and listed in alreadyInStack. If any asset belongs to a different stack the call fails with ASSET_ALREADY_STACKED and nothing changes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "stackId": "<stackId>",
      "assetIds": "<assetIds>"
    },
    "name": "stack_add_assets"
  }
}

Input Schema

Name	Required	Description	Default
`stackId`	Yes
`assetIds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations, which only say this is not read-only, not destructive and closed-world. The description discloses append ordering, idempotent skipping with the alreadyInStack result, and strong atomicity semantics ('fails with ASSET_ALREADY_STACKED and nothing changes') — exactly the partial-success and rollback behavior an agent needs before mutating.

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 tight clauses with the primary action first, then the dedupe rule that returns alreadyInStack, then the fatal precondition. No filler and nothing that could be cut without losing behavior.

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?

There is no output schema, so mentioning alreadyInStack and the ASSET_ALREADY_STACKED error is essential and present. For a two-parameter mutation the coverage is good; only the nonexistent-stack case and per-call limits are left to inference.

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?

With 0% schema description coverage the description must carry the burden, and it does partially: it implies stackId targets an existing stack and that assetIds may contain assets already in this stack or in another stack, establishing a one-stack-per-asset constraint. It does not cover ID format, the 2000-item cap, or what happens with a nonexistent stackId, so the second parameter's full semantics remain ambiguous.

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?

Names a specific verb and resource ('Add saved assets to an existing stack') plus the placement rule 'after its current members', which separates it cleanly from stack_create and stack_remove_assets without needing to name them.

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?

Makes the applicable context explicit: the stack must already exist, and the tool appends rather than replaces. It also states the exact failure precondition (an asset already in a different stack), though it doesn't point at a sibling for the create-a-stack-first case.

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