Skip to main content
Glama
Sign In
aeza-mcp

aeza-mcp

by rdydygin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

billing_transactions_get_one

Read-onlyIdempotent

Retrieve a specific billing transaction by its ID to inspect payment details, status, and related account charges.

Instructions

Get transaction by id GET /billing/transactions/{id}

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": "billing_transactions_get_one"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that — no note on not-found behavior, no indication the endpoint reaches an external/payment system despite openWorldHint=true, and no return shape.

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?

Two short lines, front-loaded with the verb and resource. The raw 'GET /billing/transactions/{id}' line adds little for an agent beyond the path hint, but nothing is bloated.

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 single-parameter read tool with full annotations and no output schema, the basics are covered. Still missing are the id format expectation and what happens when the transaction does not exist, which matter for correct 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 0%, so the description must compensate, and it only implies the parameter is a transaction id via 'by id'. The schema's ambiguous type (number|string) and any expected id format remain unexplained in both places.

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 ("Get transaction by id"), which implicitly separates it from the sibling billing_transactions_get_list. It is clear but minimal, with no explicit sibling differentiation beyond the 'by id' qualifier.

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?

There is no when-to-use guidance, no precondition (e.g., needing a known transaction id), and no mention of the list sibling as an alternative for discovery. The agent must infer that this is the lookup path once an id is known.

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