Skip to main content
Glama
xinrong-meng

My Finance MCP Server

store_transactions

Parse and store transaction data from uploaded financial documents. Extract transactions from statements, receipts, and CSV files into a structured format for financial tracking and analysis.

Instructions

Parse and store transaction data from uploaded financial documents.

If you receive unstructured financial data (statements, receipts, CSV files, etc.),
extract transactions into the format: [{"date": "YYYY-MM-DD", "amount": number, "description": "string", "category": "string"}]

Args:
    transactions: List of transaction dictionaries, each containing:
        - date: Transaction date (string, format: YYYY-MM-DD)
        - amount: Transaction amount (number, can be negative for expenses)
        - description: Transaction description (string)
        - category: Transaction category (string, optional, e.g. "Food", "Transport", "Bills")

Returns:
    Success message with count of stored transactions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transactionsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The handler function for the 'store_transactions' tool. Decorated with @mcp.tool() to register it with the MCP server. Parses transaction list, stores embeddings and metadata in ChromaDB for semantic search, and backs up raw data to JSON file.
    @mcp.tool()
    def store_transactions(transactions: List[Dict[str, Any]]) -> str:
        """
        Parse and store transaction data from uploaded financial documents.
        
        If you receive unstructured financial data (statements, receipts, CSV files, etc.),
        extract transactions into the format: [{"date": "YYYY-MM-DD", "amount": number, "description": "string", "category": "string"}]
        
        Args:
            transactions: List of transaction dictionaries, each containing:
                - date: Transaction date (string, format: YYYY-MM-DD)
                - amount: Transaction amount (number, can be negative for expenses)
                - description: Transaction description (string)
                - category: Transaction category (string, optional, e.g. "Food", "Transport", "Bills")
        
        Returns:
            Success message with count of stored transactions
        """
        # Store in ChromaDB
        ids = []
        documents = []
        metadatas = []
        
        for i, txn in enumerate(transactions):
            txn_id = f"txn_{datetime.now().timestamp()}_{i}"
            doc = f"Date: {txn.get('date')} Amount: {txn.get('amount')} Description: {txn.get('description')} Category: {txn.get('category', 'unknown')}"
            
            ids.append(txn_id)
            documents.append(doc)
            metadatas.append(txn)
        
        collection.add(
            ids=ids,
            documents=documents,
            metadatas=metadatas
        )
        
        # Also save to JSON file
        existing = _load_transactions()
        existing.extend(transactions)
        _save_transactions(existing)
        
        return f"Stored {len(transactions)} transactions successfully"
  • Helper function to load existing transactions from JSON backup file, used by store_transactions to append new data.
    def _load_transactions() -> List[Dict[str, Any]]:
        if JSON_FILE.exists():
            with JSON_FILE.open("r") as f:
                try:
                    return json.load(f)
                except json.JSONDecodeError:
                    return []
        return []
  • Helper function to persist transactions list to JSON file, called by store_transactions after appending new transactions.
    def _save_transactions(transactions: List[Dict[str, Any]]) -> None:
        JSON_FILE.parent.mkdir(parents=True, exist_ok=True)
        with JSON_FILE.open("w") as f:
            json.dump(transactions, f, indent=2)
  • The @mcp.tool() decorator registers the store_transactions function as an MCP tool.
    @mcp.tool()
Behavior3/5

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

With no annotations provided, the description carries full burden. It describes the core behavior (parsing and storing transactions) and specifies the expected input format, but doesn't disclose important behavioral traits like authentication requirements, error handling, rate limits, or whether this is a mutating operation (implied by 'store' but not explicitly stated).

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 well-structured and appropriately sized. It begins with the core purpose, provides usage context, details the expected format, and explains the return value. Every sentence adds value with no redundant information.

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 tool's complexity (parsing and storing financial data), no annotations, and an output schema present, the description is reasonably complete. It explains the transformation process and return value, though could benefit from more behavioral context about the storage operation itself (e.g., whether it overwrites existing data).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains the 'transactions' parameter structure, lists all required fields (date, amount, description, category), specifies data types and formats, and provides examples of category values.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('parse and store') and resources ('transaction data from uploaded financial documents'). It distinguishes from siblings by focusing on storage rather than deletion, listing, or querying operations.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('If you receive unstructured financial data...'), but doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools. The guidance is helpful but lacks explicit exclusions.

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/xinrong-meng/my-finance-mcp'

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