wallos-mcp

Overview Schema Source Related Servers Discussions Admin

Create a subscription

create_subscription

Add a subscription to Wallos with just a name and price; billing defaults to monthly, start date to today, and missing categories, payment methods, or household members are created automatically.

Instructions

Adds a subscription. Only a name and a price are required: the billing period defaults to monthly, the start date to today, the next payment date is derived from the start date, and the currency to the account’s main one. Categories, payment methods and household members named here are created when missing, so "category: Entertainment" works on a fresh instance.

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": {
      "name": "<name>",
      "price": "<price>"
    },
    "name": "create_subscription"
  }
}

Input Schema

Name	Required	Description
`url`	No	Link to the subscription’s management page.
`name`	Yes	Subscription name, e.g. "Netflix".
`cycle`	No	Raw Wallos cycle: 1 days, 2 weeks, 3 months, 4 years.
`notes`	No	Free text; Markdown is rendered by Wallos.
`payer`	No	Household member who pays, by name or id. Null clears it.
`price`	Yes	Amount charged per billing period.
`notify`	No	Whether Wallos sends payment reminders.
`category`	No	Category name or id. Created if it does not exist, unless create_missing is false. Null clears it.
`currency`	No	Currency code or id, e.g. "EUR". Defaults to the main currency on create.
`inactive`	No	Mark it as cancelled or no longer used.
`logo_url`	No	Image URL that this Wallos instance downloads as the logo. It must be able to reach that URL.
`frequency`	No	Raw Wallos frequency, i.e. how many cycles.
`auto_renew`	No	Whether it renews automatically. Defaults to true in Wallos.
`start_date`	No	First billing date, YYYY-MM-DD. Defaults to today on create.
`next_payment`	No	Next charge date, YYYY-MM-DD. Derived from start_date when omitted.
`billing_period`	No	How often it is charged. Accepts daily, weekly, biweekly, monthly, quarterly, semiannually, yearly, or "every N days\|weeks\|months\|years".
`create_missing`	No	Create categories, payment methods and household members named here when they do not exist. Defaults to true.
`payment_method`	No	Payment method name or id. Created if it does not exist, unless create_missing is false. Null clears it.
`cancellation_date`	No	Cancellation date, YYYY-MM-DD.
`notify_days_before`	No	Days before the charge to notify, when reminders are on.
`replacement_subscription`	No	Id of the subscription that replaced this one. Only kept when the subscription is inactive.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations, the description discloses important behavior: default billing period, start date, derived next payment date, and currency. It also notes that categories, payment methods, and household members are created when missing, which is a meaningful side effect for an agent to know.

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?

The description is front-loaded with the core action, then efficiently covers required inputs, defaults, and side effects. Every sentence adds useful information without unnecessary length.

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?

Given the fully documented schema and the annotations, the description is largely complete for a create tool. It covers required inputs, defaults, and auto-creation behavior, though it could say more about duplicate handling or return behavior.

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 the input schema already documents all 21 parameters. The description adds some useful defaulting context, but much of that is already present in the schema descriptions, so it does not substantially exceed the baseline.

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 opens with a specific verb and resource: "Adds a subscription." This clearly identifies a create operation, but it does not explicitly distinguish the tool from the sibling update_subscription tool.

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?

The description implies usage for creating new subscriptions and clarifies the minimal required inputs, but it does not explicitly state when to use this tool versus update_subscription or when to check for duplicates first.

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