import { describe, it, expect } from 'vitest' import { tools, deriveToolMeta } from '../server' describe('tools/list payload size guard', () => { it('keeps the projected tools/list payload under the context-budget ceiling', () => { // Mirror the real tools/list serializer, including the derived staging // _meta (requires_approval / approve_tool / preflight) merged over any // literal _meta: otherwise the guard under-measures the wire payload. const projection = tools.map((t) => { const meta = { ...(deriveToolMeta(t) ?? {}), ...(t._meta ?? {}) } return { name: t.name, ...(t.title ? { title: t.title } : {}), description: t.description, inputSchema: t.inputSchema, ...(t.outputSchema ? { outputSchema: t.outputSchema } : {}), annotations: t.annotations, ...(Object.keys(meta).length > 0 ? { _meta: meta } : {}), } }) const payload = JSON.stringify({ tools: projection }) const approxTokens = Math.round(payload.length / 4) // Ceiling progression: 20K → 25K → 30K → 31K → 31.5K → 32K → 36K. // * 20K → 25K when item 8 of the agent-native API plan landed // (additionalProperties: false on all inputSchemas + period_status in the // staged operation envelope). // * 25K → 30K when the agentic branch merged with main: catalog grew from // ~75 to 83 tools (added gnubok_create_supplier, gnubok_list_pending_operations, // gnubok_approve_pending_operation, gnubok_reject_pending_operation, // gnubok_set_inbox_extracted_data from main + gnubok_get_agent_briefing, // _remember_fact, _forget_fact, _feedback from the agent branch). // * 30K → 31K when gnubok_match_batch_allocate and // gnubok_bulk_book_transactions landed (PRs #603/#606/#608/#610). Each // adds the shared STAGED_OPERATION_SCHEMA + a non-trivial inputSchema // for the multi-tx flows. Descriptions already trimmed to 230-260 chars. // * 31K → 31.5K when gnubok_link_transaction_to_journal_entry landed (PR // #614). Same family as match_batch_allocate / bulk_book_transactions: // closes the MCP parity gap with the existing REST endpoint so agents // can attach a bank tx to an already-posted verifikat without creating // duplicate bookkeeping. Description trimmed to ~180 chars. // * 31.5K → 32K when gnubok_find_voucher_candidates_for_supplier_invoice + // gnubok_link_supplier_invoice_to_voucher landed: the supplier-side // mirror of the customer find/link voucher tools. The link tool inlines // the shared STAGED_OPERATION_SCHEMA. Lets agents mark a leverantörs- // faktura paid against an already-posted verifikat (no new bokföring), // which is exactly the fix for invoices imported from Fortnox as open // payables while their payment already exists in the SIE-imported GL. // * 32K → 36K when top-level Tool.title (MCP spec 2025-06-18) landed on all // 92 tools for Connectors Directory readiness; the ~10 longest descriptions // were trimmed toward 180-200 chars to partly offset. Headroom reserved for // the upcoming Skatteverket tools. // * Held at 36K when gnubok_list_accrual_schedules (add/bokslut) merged with // the categorize vat_amount override (#717): the combination crossed the // ceiling by ~75, offset by trimming the 8 longest descriptions to ~200 chars. // * 36K → 38K with the MCP legibility pass: the machine-readable staging // contract now emits `_meta { requires_approval, approve_tool, preflight }` // on every staging write (~40 tools) so an agent can tell: without reading // prose: which writes need a follow-up gnubok_approve_pending_operation and // which have a pre-flight; gnubok_get_agent_briefing also gained a `company` // identity block in its outputSchema. This is wire data the agent depends // on, not trimmable prose: hence a bump rather than a description trim. // * 38K → 40K as the catalog grew from 92 to 103 tools (gnubok_link_document_ // to_voucher #804, gnubok_bulk_book_inbox_items, the categorize-core additions, // plus per-line supplier-invoice overrides). Each new tool carries its // inputSchema + staging _meta; the growth is genuine wire data, not prose, // so descriptions are already at their trimmed floor (~180-220 chars). // * 40K → 42K with dimensions PR3: gnubok_list_dimensions + // gnubok_list_dimension_values (nested registry output schemas) + staged // gnubok_create_dimension_value (STAGED_OPERATION_SCHEMA + _meta), the // dims bag + default_dimensions on create_voucher/correct_entry, and the // agent-briefing dimensions block. Descriptions were trimmed first // (~200 tokens recovered); the remainder is schema structure agents // depend on for resolve-don't-select, not trimmable prose. // * 42K → 43K with dimensions PR4 reports: gnubok_get_dimension_pnl (the // value-as-column matrix outputSchema is the wire contract agents read // the report through), the shared `dimensions` filter arg + echo props // on trial balance / income statement / general ledger, and // group_by/group_by_dimension + totals_scope + groups on // gnubok_query_journal. Descriptions trimmed first (~100 tokens // recovered); the ~55-token remainder is schema structure. // * 43K → 44K with dimensions PR7 producers: default_dimensions + per-item/ // per-line dims bags on gnubok_create_invoice, gnubok_create_supplier_ // invoice_from_inbox, gnubok_categorize_transaction and // gnubok_bulk_book_transactions (8 new object properties). Descriptions // already use the compact "Dims bag" form (~90 tokens trimmed first); // the remainder is schema structure the resolve-don't-select contract // depends on, not trimmable prose. // * 44K → 45K when the rot/rut branch merged with main: main's #877 put // qualified identifiers in all tool output schemas (+~260 across 103 // tools: wire contract, not prose) and the branch added // gnubok_generate_rot_rut_file (~444: begäran-om-utbetalning file flow, // eligible/blocked per-invoice output). Each side alone was under the // ceiling; the combination crossed it by ~220. Descriptions are at // their trimmed floor per the entries above. // * 45K → 45.5K when payment_link_url landed on gnubok_create_invoice // (manual payment-link MVP): one optional string property with an // already-minimal ~24-token description. Headroom before the change was // under 10 tokens, so even this smallest possible addition crossed; // other descriptions are at their trimmed floor per the entries above. // Long-term answer to growth is leaning harder on gnubok_search_tools: if this // fires again, prefer trimming descriptions or making a tool opt-in via search // before bumping further. expect(approxTokens).toBeLessThan(45_500) }) })