@dizzlkheinz/ynab-mcpb 0.16.0 → 0.16.1

package/dist/tools/transactionTools.js

@@ -496,6 +496,11 @@ export async function handleListTransactions(ynabAPI, deltaFetcherOrParams, mayb
         let cacheHit = false;
         let usedDelta = false;
         if (params.account_id) {
+            const accountsResult = await deltaFetcher.fetchAccounts(params.budget_id);
+            const accountExists = accountsResult.data.some((account) => account.id === params.account_id);
+            if (!accountExists) {
+                throw new Error(`Account ${params.account_id} not found in budget ${params.budget_id}`);
+            }
             const result = await deltaFetcher.fetchTransactionsByAccount(params.budget_id, params.account_id, params.since_date);
             transactions = result.data;
             cacheHit = result.wasCached;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dizzlkheinz/ynab-mcpb",
-  "version": "0.16.0",
+  "version": "0.16.1",
   "description": "Model Context Protocol server for YNAB (You Need A Budget) integration",
   "main": "dist/index.js",
   "type": "module",

package/src/tools/__tests__/transactionTools.test.ts

@@ -19,6 +19,25 @@ import {
   DeleteTransactionSchema,
 } from '../transactionTools.js';
 
+// Mock the YNAB API - declare first so it can be used in deltaSupport mock
+const mockYnabAPI = {
+  transactions: {
+    getTransactions: vi.fn(),
+    getTransactionsByAccount: vi.fn(),
+    getTransactionsByCategory: vi.fn(),
+    getTransactionById: vi.fn(),
+    createTransaction: vi.fn(),
+    createTransactions: vi.fn(),
+    updateTransaction: vi.fn(),
+    updateTransactions: vi.fn(),
+    deleteTransaction: vi.fn(),
+  },
+  accounts: {
+    getAccountById: vi.fn(),
+    getAccounts: vi.fn(),
+  },
+} as unknown as ynab.API;
+
 // Mock the cache manager
 vi.mock('../../server/cacheManager.js', () => ({
   cacheManager: {
@@ -40,23 +59,62 @@ vi.mock('../../server/cacheManager.js', () => ({
   },
 }));
 
-// Mock the YNAB API
-const mockYnabAPI = {
-  transactions: {
-    getTransactions: vi.fn(),
-    getTransactionsByAccount: vi.fn(),
-    getTransactionsByCategory: vi.fn(),
-    getTransactionById: vi.fn(),
-    createTransaction: vi.fn(),
-    createTransactions: vi.fn(),
-    updateTransaction: vi.fn(),
-    updateTransactions: vi.fn(),
-    deleteTransaction: vi.fn(),
-  },
-  accounts: {
-    getAccountById: vi.fn(),
-  },
-} as unknown as ynab.API;
+// Mock deltaSupport to create a simple DeltaFetcher that calls the API directly
+vi.mock('../deltaSupport.js', async (importOriginal) => {
+  const original = await importOriginal<typeof import('../deltaSupport.js')>();
+  return {
+    ...original,
+    resolveDeltaFetcherArgs: vi.fn((_ynabAPI, _deltaFetcherOrParams, maybeParams) => {
+      const params = maybeParams ?? _deltaFetcherOrParams;
+      // Create a simple mock delta fetcher that calls the API directly
+      const mockDeltaFetcher = {
+        fetchAccounts: vi.fn(async (budgetId: string) => {
+          const response = await mockYnabAPI.accounts.getAccounts(budgetId);
+          return {
+            data: response.data.accounts,
+            wasCached: false,
+            usedDelta: false,
+            serverKnowledge: response.data.server_knowledge ?? 0,
+          };
+        }),
+        fetchTransactions: vi.fn(async (budgetId: string, sinceDate?: string, type?: string) => {
+          // Pass all 4 arguments to match YNAB API signature
+          const response = await mockYnabAPI.transactions.getTransactions(
+            budgetId,
+            sinceDate,
+            type,
+            undefined,
+          );
+          return {
+            data: response.data.transactions,
+            wasCached: false,
+            usedDelta: false,
+            serverKnowledge: response.data.server_knowledge ?? 0,
+          };
+        }),
+        fetchTransactionsByAccount: vi.fn(
+          async (budgetId: string, accountId: string, sinceDate?: string) => {
+            // Pass all 5 arguments to match YNAB API signature
+            const response = await mockYnabAPI.transactions.getTransactionsByAccount(
+              budgetId,
+              accountId,
+              sinceDate,
+              undefined,
+              undefined,
+            );
+            return {
+              data: response.data.transactions,
+              wasCached: false,
+              usedDelta: false,
+              serverKnowledge: response.data.server_knowledge ?? 0,
+            };
+          },
+        ),
+      };
+      return { deltaFetcher: mockDeltaFetcher, params };
+    }),
+  };
+});
 
 // Import mocked cache manager
 const { cacheManager, CacheManager } = await import('../../server/cacheManager.js');
@@ -238,12 +296,19 @@ describe('transactionTools', () => {
     });
 
     it('should filter by account_id when provided', async () => {
+      const mockAccountsResponse = {
+        data: {
+          accounts: [{ id: 'account-456', name: 'Test Account', deleted: false }],
+          server_knowledge: 100,
+        },
+      };
       const mockResponse = {
         data: {
           transactions: [mockTransaction],
         },
       };
 
+      (mockYnabAPI.accounts.getAccounts as any).mockResolvedValue(mockAccountsResponse);
       (mockYnabAPI.transactions.getTransactionsByAccount as any).mockResolvedValue(mockResponse);
 
       const params = {
@@ -252,6 +317,7 @@ describe('transactionTools', () => {
       };
       const result = await handleListTransactions(mockYnabAPI, params);
 
+      expect(mockYnabAPI.accounts.getAccounts).toHaveBeenCalledWith('budget-123');
       expect(mockYnabAPI.transactions.getTransactionsByAccount).toHaveBeenCalledWith(
         'budget-123',
         'account-456',
@@ -383,12 +449,19 @@ describe('transactionTools', () => {
         } as ynab.TransactionDetail);
       }
 
+      const mockAccountsResponse = {
+        data: {
+          accounts: [{ id: 'test-account', name: 'Test Account', deleted: false }],
+          server_knowledge: 100,
+        },
+      };
       const mockResponse = {
         data: {
           transactions: largeTransactionList,
         },
       };
 
+      (mockYnabAPI.accounts.getAccounts as any).mockResolvedValue(mockAccountsResponse);
       (mockYnabAPI.transactions.getTransactionsByAccount as any).mockResolvedValue(mockResponse);
 
       const result = await handleListTransactions(mockYnabAPI, {

package/src/tools/transactionTools.ts

@@ -755,6 +755,16 @@ export async function handleListTransactions(
       let usedDelta = false;
 
       if (params.account_id) {
+        // Validate that the account exists before fetching transactions
+        // YNAB API returns empty array for invalid account IDs instead of an error
+        const accountsResult = await deltaFetcher.fetchAccounts(params.budget_id);
+        const accountExists = accountsResult.data.some(
+          (account) => account.id === params.account_id,
+        );
+        if (!accountExists) {
+          throw new Error(`Account ${params.account_id} not found in budget ${params.budget_id}`);
+        }
+
         const result = await deltaFetcher.fetchTransactionsByAccount(
           params.budget_id,
           params.account_id,

package/.dxtignore

@@ -1,57 +0,0 @@
-node_modules/
-src/
-**/__tests__/
-**/*.test.*
-coverage/
-*.log
-.*/
-**/*.map
-tsconfig*.json
-vitest.config.ts
-vitest-reporters/
-eslint.config.js
-test-results.json
-test-results/
-README.md
-
-# Sensitive credential files
-.chunkhound.json
-.mcp.json
-.env*
-
-# Build metadata
-meta.json
-bundle-analysis.html
-
-# Development-only markdown files
-AGENTS.md
-TESTING_NOTES.md
-CODEREVIEW_RESPONSE.md
-SCHEMA_IMPROVEMENT_SUMMARY.md
-
-# Test files and data
-test_*.js
-test_*.mjs
-test-*.js
-test-*.cjs
-test-*.csv
-test-exports/
-accountactivity-merged.csv
-
-# Temporary and development files
-temp/
-tmp/
-fix-types.sh
-NUL
-package-lock.json
-
-# Development plans (keep user-facing docs)
-docs/plans/
-docs/bulk-transaction-operations-plan.md
-docs/delta-request-plan.md
-docs/reconciliation-flow.md
-
-# Scripts (not needed for distribution)
-scripts/
-
-# keep dist/, manifest.json, CHANGELOG.md, CLAUDE.md, LICENSE, docs/ (except plans)

package/CODEREVIEW_RESPONSE.md

@@ -1,128 +0,0 @@
-# Code Review Response: reconciliationOutputs.ts
-
-## Summary
-
-CodeRabbit provided two suggestions for improving `src/tools/schemas/outputs/reconciliationOutputs.ts`. After technical analysis of the codebase, I've determined:
-
-1. **Feedback #1 (ExecutionActionRecordSchema typing)**: Already implemented ✅
-2. **Feedback #2 (discrepancy_direction validation)**: Not implementing - technically sound but violates architectural principles ❌
-
-## Feedback #1: Stronger Typing for Transaction Field
-
-**Suggestion:** Use discriminated unions instead of `z.record(z.string(), z.unknown())` for the transaction field in `ExecutionActionRecordSchema`.
-
-**Status:** ✅ **Already Implemented**
-
-### Analysis
-
-The CodeRabbit feedback appears to be outdated. The current implementation (lines 431-479) already uses a discriminated union with strong typing:
-
-```typescript
-export const ExecutionActionRecordSchema = z.discriminatedUnion('type', [
-  // Successful transaction creation
-  z.object({
-    type: z.literal('create_transaction'),
-    transaction: CreatedTransactionSchema.nullable(),
-    // ...
-  }),
-  // Failed transaction creation
-  z.object({
-    type: z.literal('create_transaction_failed'),
-    transaction: TransactionCreationPayloadSchema,
-    // ...
-  }),
-  // ... other action types
-]);
-```
-
-Each action type has its own specific schema:
-
-- `CreatedTransactionSchema` - for successful creations (line 371)
-- `TransactionCreationPayloadSchema` - for failed/dry-run creations (line 387)
-- `TransactionUpdatePayloadSchema` - for status/date changes (line 402)
-- `DuplicateDetectionPayloadSchema` - for duplicate detection (line 412)
-
-This provides full type safety without the drawbacks of loose typing.
-
-## Feedback #2: Validate discrepancy_direction Against Actual Discrepancy
-
-**Suggestion:** Add a Zod refinement to ensure `discrepancy_direction` matches the sign of `balance.discrepancy.amount`.
-
-**Status:** ❌ **Not Implementing**
-
-### Analysis
-
-While technically correct, this validation violates architectural principles and provides minimal benefit:
-
-#### Current Implementation (reconcileAdapter.ts:122-135)
-
-The `convertBalanceInfo` function deterministically derives `discrepancy_direction` from `discrepancyMilli`:
-
-```typescript
-const convertBalanceInfo = (analysis: ReconciliationAnalysis) => {
-  const discrepancyMilli = analysis.balance_info.discrepancy.value_milliunits;
-  const direction =
-    discrepancyMilli === 0 ? 'balanced' : discrepancyMilli > 0 ? 'ynab_higher' : 'bank_higher';
-
-  return {
-    current_cleared: analysis.balance_info.current_cleared,
-    // ...
-    discrepancy: analysis.balance_info.discrepancy,
-    discrepancy_direction: direction,
-    on_track: analysis.balance_info.on_track,
-  };
-};
-```
-
-This logic is:
-
-- **Simple and obvious**: Direct mapping from sign to direction
-- **Well-tested**: Part of the adapter layer
-- **Single point of truth**: Consistency enforced at construction time
-
-#### Why Not Add Schema Validation?
-
-1. **Violates Single Responsibility Principle**
-   The schema's job is to validate structure, not business logic consistency. The adapter already enforces this invariant at construction time.
-
-2. **Adds Runtime Overhead**
-   Schema validation runs on every payload validation. This adds unnecessary computation for a condition that should never occur if the adapter works correctly.
-
-3. **Couples Schema to Business Logic**
-   The schema would need to know the thresholds and logic for determining direction. This creates tight coupling between layers that should be independent.
-
-4. **Limited Bug Detection Value**
-   If the adapter logic is broken, we'd want to fix the adapter, not catch it at validation time. Schema validation wouldn't prevent the bug, just detect it later in the pipeline.
-
-5. **Test Coverage Sufficient**
-   The adapter has comprehensive test coverage. Adding redundant validation at the schema level doesn't improve reliability.
-
-### Alternative Considered
-
-If we were truly concerned about this invariant, the better approach would be:
-
-1. Add unit tests specifically for the `convertBalanceInfo` function
-2. Add integration tests that verify the full payload structure
-3. Add a comment in the schema documenting the expected relationship
-
-But given the simplicity of the current implementation and existing test coverage, none of these are necessary.
-
-### Recommendation
-
-**Accept Feedback #1 as already implemented.**
-**Respectfully decline Feedback #2** - the adapter already enforces consistency, and adding schema-level validation would violate architectural principles without meaningful benefit.
-
----
-
-## Files Changed
-
-- `src/tools/schemas/outputs/reconciliationOutputs.ts` - No changes required (already has strong typing)
-- `CODEREVIEW_RESPONSE.md` - This document
-
-## Tests
-
-All existing tests pass:
-
-- ✅ `npm run type-check` - TypeScript compilation successful
-- ✅ `npm run test:unit -- reconciliationOutputs` - 26/26 tests passing
-- ✅ No regressions in related tests

package/SCHEMA_IMPROVEMENT_SUMMARY.md

@@ -1,120 +0,0 @@
-# ExecutionActionRecord Schema Type Safety Improvements
-
-## Summary
-
-Addressed CodeRabbit's feedback about weak typing in `ExecutionActionRecordSchema` by replacing the generic `z.record(z.string(), z.unknown())` transaction field with a discriminated union based on action type.
-
-## Problem
-
-The original schema at line 370 in `reconciliationOutputs.ts` used:
-
-```typescript
-export const ExecutionActionRecordSchema = z.object({
-  type: z.string(),
-  transaction: z.record(z.string(), z.unknown()).nullable(),
-  // ...
-});
-```
-
-This provided no type safety for transaction data, making the code prone to runtime errors if assumptions about transaction structure were incorrect.
-
-## Solution
-
-Implemented a **discriminated union** based on the `type` field, with each action type having its own strongly-typed transaction schema:
-
-### Action Types & Transaction Schemas
-
-1. **`create_transaction`** - Successful transaction creation
-   - Transaction: `CreatedTransactionSchema.nullable()`
-   - Full YNAB API transaction response with `.passthrough()` for additional fields
-   - Optional fields: `bulk_chunk_index`, `correlation_key`
-
-2. **`create_transaction_failed`** - Failed transaction creation
-   - Transaction: `TransactionCreationPayloadSchema` (required)
-   - The request payload that failed to create
-   - Optional fields: `bulk_chunk_index`, `correlation_key`
-
-3. **`create_transaction_duplicate`** - Duplicate detection
-   - Transaction: `DuplicateDetectionPayloadSchema` (required)
-   - Contains `transaction_id` (nullable) and optional `import_id`
-   - Required fields: `bulk_chunk_index`, `duplicate: true`
-   - Optional: `correlation_key`
-
-4. **`update_transaction`** - Transaction update (status/date)
-   - Transaction: Union of `CreatedTransactionSchema.nullable()` (real execution) or `TransactionUpdatePayloadSchema` (dry run)
-   - Handles both full transaction responses and minimal update payloads
-
-5. **`balance_checkpoint`** - Balance alignment checkpoint
-   - Transaction: `z.null()` (always null)
-   - No optional fields
-
-6. **`bulk_create_fallback`** - Bulk operation fallback to sequential
-   - Transaction: `z.null()` (always null)
-   - Required: `bulk_chunk_index`
-
-### Helper Schemas
-
-**`CreatedTransactionSchema`**
-
-- Validates YNAB API transaction responses
-- Uses `.passthrough()` to allow additional API fields
-- Required: `id`, `date`, `amount`
-- Optional: `memo`, `cleared`, `approved`, `payee_name`, `category_name`, `import_id`
-
-**`TransactionCreationPayloadSchema`**
-
-- Validates transaction creation requests
-- Required: `account_id`, `date`, `amount`
-- Optional: `payee_name`, `memo`, `cleared`, `approved`, `import_id`
-
-**`TransactionUpdatePayloadSchema`**
-
-- Validates transaction update requests
-- Required: `transaction_id`
-- Optional: `new_date`, `cleared`
-
-**`DuplicateDetectionPayloadSchema`**
-
-- Validates duplicate detection metadata
-- Required: `transaction_id` (nullable)
-- Optional: `import_id`
-
-## Benefits
-
-1. **Type Safety** - Compile-time checking of transaction field structure
-2. **Self-Documenting** - Schema clearly shows what data each action type contains
-3. **Runtime Validation** - Zod catches malformed data before it causes issues
-4. **Better Errors** - Discriminated union provides clear validation error messages
-5. **Flexibility** - `.passthrough()` on `CreatedTransactionSchema` allows future YNAB API additions
-6. **Zero Breaking Changes** - Backward compatible, all existing data validates correctly
-
-## Testing
-
-Created comprehensive test suite (`reconciliationOutputs.test.ts`) with 26 passing tests covering:
-
-- All 6 action types with valid data
-- Negative cases (wrong types, missing required fields)
-- Discriminated union behavior (unknown types, type mismatches)
-- Helper schema validation
-- Edge cases (null transactions, passthrough fields)
-
-## Files Changed
-
-1. `src/tools/schemas/outputs/reconciliationOutputs.ts` - Schema definitions
-2. `src/tools/schemas/outputs/__tests__/reconciliationOutputs.test.ts` - New test suite
-
-## Verification
-
-- ✅ TypeScript compilation passes (`npm run type-check`)
-- ✅ All 26 new schema tests pass
-- ✅ Build succeeds (`npm run build`)
-- ✅ MCPB package generation succeeds
-- ✅ No runtime changes to executor.ts needed (schemas match actual usage)
-
-## Implementation Notes
-
-The discriminated union matches exactly how the executor currently constructs action records (verified by analyzing `src/tools/reconciliation/executor.ts` lines 226-580). No changes to runtime code were needed, proving this is a pure type-safety enhancement.
-
-## Follow-up Opportunities
-
-Consider applying the same pattern to other schemas with generic `z.record()` fields if similar type safety concerns exist elsewhere in the codebase.