Files
accounted/extensions/general/mcp-server/__tests__/payload-size.bench.test.ts
T
Jakob WennbergandClaude Opus 4.8 43007fa869 feat(mcp): self-describing agent surface — staging _meta, company identity, clean skill summaries (#775)
* feat(mcp): make the agent surface self-describing (staging _meta, company identity, clean summaries)

A pass over the MCP server's agent-facing surface so an agent can act
correctly without parsing description prose:

- Machine-readable staging contract: deriveToolMeta() attaches _meta to
  tools/list (and search detail=full) — { requires_approval, approve_tool,
  preflight? } — keyed off the STAGED_OPERATION_SCHEMA output schema. Literal
  _meta (e.g. UI widget hints) wins on collision. TOOL_PREFLIGHT_MAP names the
  read-only pre-flight for the few writes that have one (year-end readiness,
  VAT validate, depreciation proposal). Guarded by staging-meta.test.ts.
- Company identity in gnubok_get_agent_briefing: returns a `company` block
  (id, name, org_number, entity_type, accounting_method) so the agent can
  confirm WHICH entity it operates on and pick the right settlement account
  (accrual = credit 1510; cash = debit 19xx) before any write. Best-effort —
  a missing row never blocks the briefing. Covered by agent-briefing.test.ts.
- toSummary(): trims the long, keyword-stuffed SKILL.md frontmatter into clean
  one-liners for gnubok_list_skills / gnubok_get_agent_briefing so the client
  never truncates one mid-sentence; full bodies stay in gnubok_load_skill.
  Covered by to-summary.test.ts.
- bank-reconciliation skill: a match/link decision tree (what you have x
  whether a verifikat exists) and kontant- vs faktureringsmetoden settlement
  accounts.
- Prose/description clarifications: "Stages"/"Stages for approval" on the
  link tools; propose_dispositioner/accruals note there is no dedicated MCP
  poster; server-info documents _meta and the legacy gnubok_ tool prefix.

All 34 touched MCP tests pass. Merged cleanly on top of #759/#760 (server.ts).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(mcp): make accounting_method description state the full settlement posting

Review (swedish-accounting-compliance): the agent-briefing schema described
accrual as "credit 1510 on payment", which reads as a one-sided entry. Spell
out both sides (payment debits 19xx AND credits 1510) so an agent can't infer a
single-leg posting that violates BFL 5 kap double-entry. Mirrors the precision
already in the bank-reconciliation skill body. Payload-size guard still passes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-25 13:42:12 +02:00

68 lines
4.3 KiB
TypeScript
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
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.
// 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(38_000)
})
})