Skip to main content
Glama
Sign In

DigitalK2

by se.digitalk2
OverviewDiscussionsAdmin

Gå till nästa steg

next_step

Går från steg from_step till steg from_step + 1 i webbguiden, som knappen Nästa.

Stegen: 1 Ladda upp och företagsuppgifter, 2 Granska resultat- och balansräkning, 3 Skatteberäkning och INK2, 4 Förvaltningsberättelse, 5 Noter, 6 Underskrifter, 7 Slutför. Kör samma kontroller som för användaren, sparar utkastet med det innehåll det redan har och byter steg; inga värden ändras. Om något saknas eller en dialog är öppen stannar guiden kvar, och svaret innehåller prompts (besvaras med answer_prompt) och messages (vad som behöver rättas). Från steg 6 öppnar verktyget steg 7, där användaren själv betalar, signerar och lämnar in; verktyget gör inget av det. Tillbaka till ett tidigare steg går man med go_to_step.

Returnerar moved (bool), from_step, to_step och snapshot efter försöket.

Input Schema

NameRequiredDescriptionDefault
draft_idYesUtkastets id (draft_id), t.ex. från list_drafts. Utkastet måste tillhöra det anslutna kontot.
from_stepYesSteget guiden står på och som ska lämnas, som get_state visar. Guiden går till from_step + 1: 1 Ladda upp och företagsuppgifter -> 2 Granska resultat- och balansräkning -> 3 Skatteberäkning och INK2 -> 4 Förvaltningsberättelse -> 5 Noter -> 6 Underskrifter -> 7 Slutför. Stämmer det inte flyttas ingenting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / from_step
      Added value: +{
+  "description": "Steget guiden står på och som ska lämnas, som get_state visar. Guiden går till from_step + 1: 1 Ladda upp och företagsuppgifter -> 2 Granska resultat- och balansräkning -> 3 Skatteberäkning och INK2 -> 4 Förvaltningsberättelse -> 5 Noter -> 6 Underskrifter -> 7 Slutför. Stämmer det inte flyttas ingenting.",
+  "maximum": 6,
+  "minimum": 1,
+  "title": "From Step",
+  "type": "integer"
+}
    • changedInput schema / required
      Previous value: -[
-  "draft_id"
-]New value: +[
+  "draft_id",
+  "from_step"
+]
  2. First observed

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 discloses that the same validations run as for a human user, that the draft is saved with its existing content and no values are changed, that progress can be blocked by missing data or an open dialog, that the response carries prompts/messages, and that at step 7 payment, signing and submission are left to the user. This is exactly the extra context the readOnly/idempotent/destructive hints cannot convey.

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 core action and organized into purpose, behavior, edge cases and return values. The full seven-step list duplicates the mapping already present in the from_step schema description, which is mild redundancy, but every other sentence carries distinct information.

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?

No output schema exists, yet the description names the return values (moved, from_step, to_step, snapshot). Combined with the annotation coverage of the safety profile, an agent has everything needed to invoke this correctly and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so both draft_id and from_step are already fully documented, including the step mapping and the 1-6 bounds. The description restates the from_step -> from_step + 1 relationship but adds no new parameter semantics, so the baseline 3 applies.

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: it moves the web guide from from_step to from_step + 1, explicitly likened to the 'Nästa' button. It enumerates the seven steps so the agent understands exactly what 'advancing' means, and it distinguishes itself from go_to_step, which handles the opposite direction.

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

Usage Guidelines5/5

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

Explicit alternatives and conditions: 'Tillbaka till ett tidigare steg går man med go_to_step' names the sibling for backward navigation, and it explains that prompts must be answered with answer_prompt. It also states the failure condition (missing content or an open dialog keeps the guide in place), so an agent knows when this call will not succeed.

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

All DigitalK2 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