Skip to main content
Glama
Sign In
wallos-mcp

wallos-mcp

by LovelessCodes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Manage a payment method

manage_payment_method
Destructive

Add, rename, enable, disable or delete Wallos payment methods. Deletion is blocked while subscriptions still reference the method, so you can safely clean up unused options.

Instructions

Adds, renames, enables, disables or deletes a payment method. Wallos refuses to delete one that subscriptions still use.

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": {
      "action": "<action>"
    },
    "name": "manage_payment_method"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoThe entry to edit or delete, by name or id. Required for edit and delete, ignored for add.
nameNoPayment method name, e.g. "Visa". Required for add.
actionYesWhat to do: add a new entry, edit an existing one, or delete it.
enabledNoWhether it shows up when picking a payment method.
icon_urlNoImage URL that the Wallos instance downloads as the icon.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the referential-integrity guard on delete, which the agent could not infer from annotations. It stops short of describing what a successful add returns or what happens to the icon download.

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?

Two sentences, zero filler, with the operation list front-loaded and the destructive caveat immediately after. Nothing could be removed without losing information.

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?

Safety and the delete guard are adequately covered, and no output schema means return values need not be explained. But the description enumerates five operations while the schema's action enum only accepts add/edit/delete, and it never clarifies how 'rename' or 'enable' map onto an edit call — a gap an agent must resolve by guessing.

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 description coverage is 100%, so all five parameters are documented in the schema itself (id required for edit/delete, name required for add, enabled, icon_url). The description adds no syntax or format detail beyond that, so the baseline 3 applies. It also lists five verbs against a three-value action enum, which leaves the rename/enable/disable-to-edit mapping implicit.

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?

The description names a specific resource (payment method) and enumerates the operations (add, rename, enable, disable, delete), so an agent knows exactly what domain this touches. It does not explicitly contrast with siblings like manage_category or manage_currency, which is the only thing keeping it from a 5.

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?

There is one genuinely useful usage rule — deletion is refused when subscriptions still reference the method — which tells the agent a delete can fail for business reasons. However, there is no guidance on when to reach for this tool versus the sibling manage_* tools, nor any note on prerequisites such as needing an existing id for edit/delete.

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