Skip to main content
Glama
shahlaukik

Money Manager MCP Server

by shahlaukik

card_create

Create a new credit card in Money Manager by specifying card details, linking payment assets, and setting balance and payment parameters for financial tracking.

Instructions

Creates a new credit card.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardNameYesCredit card name
linkAssetIdYesLinked payment asset ID
linkAssetNameYesLinked payment asset name
notPayMoneyYesUnpaid balance (negative value)
jungsanDayNoOptional: Balance calculation day (1-31)
paymentDayNoOptional: Payment due day (1-31)

Implementation Reference

  • The handleCardCreate function implements the core logic for the card_create tool. It validates the input using CardCreateInputSchema, sends a POST request to the '/addAssetCard' endpoint with the card details, and returns a CardOperationResponse indicating success and the new card ID.
    /**
     * Handler for card_create tool
     * Creates a new credit card
     */
    export async function handleCardCreate(
      httpClient: HttpClient,
      input: unknown,
    ): Promise<CardOperationResponse> {
      const validated = CardCreateInputSchema.parse(input);
    
      const response = await httpClient.post<ApiOperationResponse>(
        "/addAssetCard",
        {
          cardName: validated.cardName,
          linkAssetId: validated.linkAssetId,
          linkAssetName: validated.linkAssetName,
          notPayMoney: validated.notPayMoney,
          jungsanDay: validated.jungsanDay,
          paymentDay: validated.paymentDay,
        },
      );
    
      return {
        success: response.success !== false && response.result !== "fail",
        cardId: response.cardId || response.assetId,
        message: response.message,
      };
    }
  • Zod schema defining the input parameters for the card_create tool, including validation rules for card name, linked asset, unpaid balance, and optional settlement/payment days. Also exports the inferred TypeScript type.
    /**
     * Input schema for card_create tool
     */
    export const CardCreateInputSchema = z.object({
      cardName: NonEmptyString,
      linkAssetId: AssetIdSchema,
      linkAssetName: NonEmptyString,
      notPayMoney: z.number(),
      jungsanDay: DayOfMonthSchema.optional(),
      paymentDay: DayOfMonthSchema.optional(),
    });
    
    export type CardCreateInput = z.infer<typeof CardCreateInputSchema>;
  • src/index.ts:296-322 (registration)
    MCP tool registration in TOOL_DEFINITIONS array: defines the 'card_create' tool with name, description, and JSON schema for input validation, used by the MCP server's list_tools handler.
    {
      name: "card_create",
      description: "Creates a new credit card.",
      inputSchema: {
        type: "object" as const,
        properties: {
          cardName: { type: "string", description: "Credit card name" },
          linkAssetId: { type: "string", description: "Linked payment asset ID" },
          linkAssetName: {
            type: "string",
            description: "Linked payment asset name",
          },
          notPayMoney: {
            type: "number",
            description: "Unpaid balance (negative value)",
          },
          jungsanDay: {
            type: "number",
            description: "Optional: Balance calculation day (1-31)",
          },
          paymentDay: {
            type: "number",
            description: "Optional: Payment due day (1-31)",
          },
        },
        required: ["cardName", "linkAssetId", "linkAssetName", "notPayMoney"],
      },
  • Internal registration mapping 'card_create' string key to the handleCardCreate handler function within the toolHandlers object, used by executeToolHandler to dispatch calls.
    card_list: handleCardList,
    card_create: handleCardCreate,
    card_update: handleCardUpdate,
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as permissions needed, whether creation is irreversible, error conditions, or typical response format. For a mutation tool with financial implications, this is a significant gap.

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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a tool with good schema coverage, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with financial data and no annotations or output schema, the description is inadequate. It doesn't cover behavioral aspects like side effects, authentication needs, or return values, leaving critical gaps for agent understanding despite good schema coverage.

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 parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying credit card creation, which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the action ('creates') and resource ('new credit card'), making the purpose immediately understandable. It distinguishes from siblings like card_list (read) and card_update (modify), though it doesn't explicitly contrast with asset_create which creates different resources.

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing linked assets), exclusions, or comparisons to sibling tools like asset_create or transaction_create that might handle related financial operations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shahlaukik/money-manager-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server