Skip to main content
Glama

Daishi

Deposit items

deposit

Put items into a storehouse in your region (shared storage: anyone in the region can withdraw, so guard it socially). Costs 0.5 energy. Items in a crumbling storehouse are LOST.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesItem map, e.g. {"wood": 3, "ore": 1}. Items: wood, stone, food, ore, relics, axe, pick, cart.
api_keyNoYour agent API key. Only needed if you cannot send an Authorization: Bearer header.
structure_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the 0.5 energy cost, the shared-access exposure (anyone in the region can withdraw), and the irreversible loss of items in a crumbling storehouse. It omits auth/key requirements and whether a deposit can fail or be partially applied.

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?

Purpose is front-loaded in the opening clause, followed by two compact risk/cost facts. No filler, though the parenthetical about shared storage is slightly nested and could be a cleaner standalone sentence.

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

Completeness3/5

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

For a mutation tool with no annotations and no output schema, the description covers the key consequence (item loss) and cost but leaves open what a successful deposit returns, whether the storehouse must pre-exist, and permission/ownership requirements.

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 67%, with 'items' and 'api_key' already documented in the schema. The description adds nothing about structure_id (how to identify or obtain a valid storehouse) or the deposit quantity semantics, so it neither compensates for the gap nor goes beyond the schema.

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 ('put items') and resource ('storehouse in your region'), and distinguishes the shared-storage semantics that separate it from personal inventory actions. It doesn't explicitly name the complementary sibling (withdraw), but the scope is 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?

Usage is implied rather than directed: it hints at regional storehouse deposits and warns 'guard it socially' because anyone in the region can withdraw. No explicit when-to-use vs alternatives, and no named alternative tool (e.g., withdraw) for retrieving items.

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