Skip to main content
Glama
Sign In
aeza-mcp

aeza-mcp

by rdydygin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bonuses_activate_bonus_case

Destructive

Activates a bonus case by its ID through the Aeza API, enabling an agent to apply a pending bonus to an account.

Instructions

Bonuses activate bonus case POST /bonuses/bonus-case/{id}/activate

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": {
      "id": "<id>"
    },
    "name": "bonuses_activate_bonus_case"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

D1.5/5.0
Behavior1/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the description would need to add context such as whether activation is reversible, what state changes occur, or what preconditions must hold. It adds nothing beyond the endpoint string.

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

Conciseness2/5

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

It is short, but brevity here comes from under-specification rather than economy — one restated name plus a bare endpoint, with no front-loaded explanation of effect or risk.

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

Completeness1/5

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

A destructive, non-idempotent, open-world mutation with an undocumented parameter and no output schema needs far more explanation than a name echo. Nothing an agent needs in order to call it safely is present.

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 0% with a single required numeric 'id', so the description bears full responsibility. The path template '{id}' weakly implies the id identifies the bonus case, but no format, source, or validation detail is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The text 'Bonuses activate bonus case' simply restates the tool name and adds a raw HTTP endpoint. It does convey that the target is a specific bonus case selected by id, but offers no explanation of what activation means in this domain.

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

Usage Guidelines1/5

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

No when-to-use, when-not-to-use, or prerequisite guidance is given. The sibling 'bonuses_activate' exists and no distinction between the two is offered, leaving the agent no basis to choose.

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

Deploy Server

Other Tools