Skip to main content
Glama
Sign In

Kvickd

by com.kvickd
OverviewDiscussionsAdmin

Registrera skattekontots saldo

set_tax_account_statement
DestructiveIdempotent

Registrerar saldot på bolagets skattekonto enligt Skatteverkets kontoutdrag per ett datum, så att avstämningen av skattekontot (bilagan TAX_ACCOUNT, konto 1630) kan stämmas av mot huvudboken. Använd när användaren har ett kontoutdrag från Skatteverket: ta saldot ur utdraget eller fråga användaren, gissa aldrig. Saldot gäller avstämningar per månadsslut från och med datumet tills ett senare saldo registreras; ett nytt saldo för samma datum ersätter det tidigare. Returnerar skattekontoavstämningen för datumets månad med huvudbokens saldo, kontoutdragets saldo och differens i öre. Bieffekt: saldot sparas; attesten ändras inte, den görs av en människa i appen. Kräver behörigheten reconcile.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "orgnr": "<orgnr>",
      "statement_date": "<statement_date>",
      "balance_ore": "<balance_ore>"
    },
    "name": "set_tax_account_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoValfri anteckning, t.ex. Kontoutdrag från Skatteverket hämtat 2026-06-03.
orgnrYesBolagets organisationsnummer, 10 siffror med eller utan bindestreck, t.ex. 559900-1004. Hämta med list_companies.
balance_oreYesSaldot enligt kontoutdraget i öre (heltal), t.ex. 269400 för 2 694 kr. Positivt när bolaget har pengar till godo, negativt när bolaget är skyldigt (samma tecken som konto 1630 i huvudboken).
statement_dateYesKontoutdragets datum (YYYY-MM-DD), normalt månadens sista dag, t.ex. 2026-05-31.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it explains the temporal semantics (the balance applies from the date until a later balance is registered), the overwrite behavior for the same date (matching idempotentHint and destructiveHint), the authorization requirement ("Kräver behörigheten reconcile"), and clarifies that the attest is not changed but done by a human in the app.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and scope, then usage, semantics, return value and side effects in a logical order. It is dense but nearly every sentence carries operational information; the return-value sentence is the only part that could be trimmed slightly.

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

Completeness5/5

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

With no output schema, the description still documents what is returned (monthly tax-account reconciliation with ledger balance, statement balance and difference in öre). Combined with the side-effect and permission notes, an agent has everything needed to call this mutation correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds sourcing guidance for balance_ore (extract from the statement or ask, never guess) and anchors statement_date to the intended meaning (per a date, month-end reconciliations). Sign convention and formatting stay in the schema, which is appropriate.

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?

States a specific verb and resource ("Registrerar saldot på bolagets skattekonto") plus the exact source artifact (Skatteverkets kontoutdrag) and downstream purpose (avstämning mot bilaga TAX_ACCOUNT, konto 1630). An agent can distinguish this write from the read-only sibling read_tax without opening the schema.

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?

Gives an explicit trigger ("Använd när användaren har ett kontoutdrag från Skatteverket") plus a rule for sourcing the value: take it from the statement or ask the user, never guess. No when-not condition or named alternative sibling is given, which keeps it below a 5.

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

All Kvickd toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources