DigitalK2

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

Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=false and destructiveHint=false, so the write/non-idempotent profile is covered structurally. The description adds real value beyond that: it explains the mechanism (simulating a button press), the required user-consent step, and names the return values (clicked and a snapshot) despite there being no output schema.

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

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

Four compact sentences, front-loaded with purpose, then boundaries, then the consent rule, then the return. Each sentence carries distinct information; nothing is repeated or filler.

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

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

For a mutation tool with no output schema, the description supplies both the return shape (clicked text plus snapshot) and the alternative routing for form questions. It stops short of covering edge cases such as a mismatched option or duplicate button labels beyond the `prompt` hint, so it is strong but not exhaustive.

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

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

Schema description coverage is 100%, so every parameter (option, prompt, inputs, draft_id) is already well documented in the schema, including examples. The description adds only indirect context (`förifyllning från förra året` as a typical prompt type), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it answers a dialog shown by the guide by pressing the same button the user would. It further distinguishes itself from siblings by naming what it is NOT for (form questions handled by set_first_annual_report and update_fields). An agent can route correctly without opening any other schema.

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

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

Explicit when-to-use (only prompts returned by get_state and next_step, e.g. prefill from last year, small deviation confirmation, reminder), when-not (form questions: step 1 via set_first_annual_report, steps 3-6 via update_fields), and an operational rule to always explain the question and obtain an explicit user answer first.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false; the description adds the crucial context of what is modified (step 2 amounts), that entries mirror read_tax's to_book, that it self-skips when already applied, that user confirmation is required, and what it returns (applied and a snapshot). Nothing material is withheld.

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

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

Front-loads the core effect, then layers the button equivalence, no-op condition, prerequisites, and confirmation. Slightly dense with domain terms (to_book, ink2Help, aktuellSkattHelp), but every sentence carries operational information; nothing is padding.

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

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

For a destructive, state-mutating tool with no output schema, the description covers prerequisites, no-op behavior, confirmation, and return values. An agent has enough to decide and call it safely.

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

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

The single draft_id parameter has 100% schema description coverage, already stating the source (list_drafts) and the ownership constraint. The description adds no parameter-level detail, so the schema does the work and the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it adjusts the income statement and balance sheet in step 2 using the tax from step 3. It also ties itself to a concrete sibling (read_tax / to_book) and to the equivalent UI button, so an agent can distinguish it from read_tax and update_fields.

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

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

Gives explicit preconditions (step 3 completed and the tax calculation visible via ink2Help/aktuellSkattHelp), an explicit no-op case (applied = false, nothing already adjusted), a confirmation requirement ('Fråga användaren först'), and points to read_tax for the underlying data. When-to-use and when-not-to-use are both covered.

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

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

Goes beyond the annotations by disclosing that it replaces the row's current amount (matching destructiveHint), requires user confirmation first, and returns a snapshot afterwards. This is useful context, though it does not describe any auth/permission requirements or what the snapshot contains.

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

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

Front-loads the core action, then adds the trigger equivalence, the destructive effect, the confirmation requirement, and the return behavior in four tight sentences with no filler.

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

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

For a destructive mutation tool with no output schema, the description covers the trigger, the effect on existing data, the confirmation requirement, and the return behavior. It is largely complete, missing only permission/auth prerequisites.

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

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

Schema description coverage is 100% with a single parameter whose meaning (draft_id, must belong to the connected account) is already fully documented in the schema. The description adds nothing parameter-specific, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Bokar) and target resource (årets resultat från resultaträkningen på raden Årets resultat i balansräkningen) and even pins the step (steg 2). It is unambiguous about the operation, though it does not name or contrast any sibling tool (e.g. set_first_annual_report, apply_tax_adjustment).

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

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

Gives a concrete trigger condition: the same action as when the user answers Ja to the guide's suggestion, which appears when årets resultat saknas i balansräkningen. Also instructs 'Fråga användaren först'. No alternatives or when-not-to-use conditions are given, so it stops short of a 5.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world creation call. The description adds genuine context beyond that: the draft starts empty, the returned link must be opened while logged in, and an existing draft should be reused rather than duplicated. It does not cover rate limits or error behavior, so it stops short of a 5.

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

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

Front-loads the core action and return value, then the usage condition, then the workflow. Every sentence carries operational value; the workflow guidance is slightly verbose but not redundant.

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

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 explains what comes back (draft_id and url) and how to proceed afterward, including the duplicate-draft case. An agent has everything needed to call it and to handle the response correctly.

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

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

The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. The description correctly notes the call is parameterless in effect and instead documents the return values (draft_id, url), though those are outputs rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Skapar ett nytt, tomt årsredovisningsutkast') plus the return artifact (link to open in AI mode). It is clearly distinguishable from siblings like list_drafts and upload_sie, which it names explicitly.

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

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

Gives explicit when-to-use ('Använd när användaren vill göra en ny årsredovisning'), the follow-up action (open link, then upload_sie), and a clear exclusion/alternative: if a draft already exists for the company and year, use list_drafts instead.

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

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

Well beyond the annotations, which only say it is a non-read-only, non-destructive, non-idempotent operation. The description adds the operational constraints an agent cannot infer: the link lasts 15 minutes, works once, is bound to this draft, is capped at 10 MB, and the file is transferred byte-for-byte so encoding is preserved. It also names the return fields, which is important since no output schema exists.

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

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

Front-loaded with the purpose in the first sentence, then the primary usage flow, then the fallback path, then the return payload. Despite being multi-sentence, every clause carries actionable information (expiry, single-use, draft binding, size cap, encoding, return fields) with no filler.

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

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

No output schema exists, and the description compensates by enumerating the returned fields (upload_url, upload_id, expires_in_seconds, curl_example). Combined with the documented 15-minute expiry, size limit and the upload_sie(draft_id, upload_id) handoff, an agent has everything needed to complete the multi-step upload correctly.

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

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

There is a single parameter and schema description coverage is 100%, so the schema already explains draft_id, its provenance (list_drafts) and the ownership requirement. The description adds nothing about the parameter beyond the schema, so the baseline of 3 for high-coverage schemas applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Skapar en tillfällig uppladdningslänk för en SIE-fil') plus the precise scope: files too large to send in a tool call. It clearly differentiates itself from the sibling upload_sie, which is named as the follow-up reader, so an agent can route between the two without opening either schema.

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

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

Gives explicit when-to-use ('när du har tillgång till filen lokalt, t.ex. i Claude Code eller Cursor'), names the exact command source (curl_example), and specifies the fallback when the environment cannot reach upload_url (Claude.ai sandbox network block), including the manual drag-and-drop alternative and the verification step read_draft(overview) / sie_file_name. Both the happy path and the exclusion case are covered.

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

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

Annotations already declare destructiveHint=true and idempotent=true, but the description goes further and specifies exactly what is overwritten: existing company details and signatories in step 6 unless manually changed. It also notes the return value ('Returnerar snapshot efteråt'), which matters since there is no output schema. All of this is consistent with the annotations.

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

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

Front-loaded with the core action, then sequencing and side effects. Every sentence carries information (what it fills, what it replaces, the prerequisite, the return). Slightly dense with step references, but no wasted text.

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

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

With no output schema, the description compensates by noting it returns a snapshot, and it covers authoritative side effects, required prerequisites, and where the org number comes from. An agent has enough to call it correctly; the minor gap is the absence of explicit failure/auth behavior for the open-world Bolagsverket call.

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

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

Schema description coverage is 100%, so both parameters (org_nr, draft_id) are fully documented in the schema, making a 3 the baseline. The description adds only the workflow hint that org_nr originates from the SIE file or the search field, which is marginal additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (hämtar/fyller i) plus resource (företagsuppgifterna från Bolagsverket) and a precise list of what gets populated (namn, räkenskapsår, företrädare, säte, verksamhet). It also names fill_input as a related tool, so an agent can separate this fetch-and-fill action from generic field editing siblings.

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

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

States a clear precondition ('Krävs innan steg 1 kan lämnas') and explains the input flow for org_nr (from the SIE file, or written into the search field with fill_input first). No explicit when-not-to-use or named alternative, but the context is actionable.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered by structured data. The description adds the typing analogy and the return payload ('filled, value och snapshot'), but never discloses that this destructive write may overwrite an existing field value or what happens when the label is not present. With annotations carrying most of the load, this is adequate but has a clear gap.

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

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

Front-loaded with the core action, then usage and follow-up, so the important routing information comes first. Every sentence carries weight, though the two-line layout could be tightened slightly.

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

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

With no output schema, the description usefully names the return fields (filled, value, snapshot) and covers the workflow context and where valid labels come from. Only the overwrite/error behavior on a destructive write is left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents label, value, and draft_id with exact formats (NNNNNN-NNNN, ÅÅÅÅ-MM-DD). The description's only addition is pointing at snapshot.inputs via get_state as the source of valid labels, which is a modest supplement rather than new semantic detail; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Skriver i ett formulärfält i steg 1') scoped to step 1, and explicitly contrasts it with the sibling used for later steps ('För steg 2 till 6, använd update_fields'). An agent can distinguish it from update_fields without opening either schema.

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

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

Explicitly states when to use it (step 1, manual entry when the company is filled in without a SIE file), the alternative for other steps (update_fields), and the follow-up action (fetch_company_details). Both the selection condition and the exclusions are spelled out.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description goes beyond them by disclosing the data source (the /skapa-mcp page the user has open), the fallback behavior when the page is closed (last known state with live=false plus a link to open), and the snapshot contents. It does not discuss latency or staleness windows beyond the live flag, which is minor given the read-only profile.

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

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

Front-loaded with the purpose, then usage, then the live/fallback caveat, then the return shape. Dense but every section earns its place, including the return enumeration that substitutes for a missing output schema; slightly longer than strictly necessary.

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

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

With no output schema, the description compensates by naming the returned fields (live, url, step 1-7, step_name, next_enabled, prompts, messages) and by explaining the live=false fallback. Nothing an agent needs to call or interpret this read tool is missing.

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

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

Schema coverage is 100% and the single draft_id is fully documented in the schema (source list_drafts, must belong to the connected account). The description adds nothing further about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (shows where a draft stands in the web guide) and enumerates the exact facets returned: current step, whether Nästa is clickable, open prompts/dialogs, and blocking error messages. It also names the sibling relation (prompts are answered with answer_prompt), so an agent can distinguish it from read_draft or next_step without opening a schema.

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

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

Gives explicit when-to-use guidance: before doing anything in a draft and after every action when unsure of the state. It also routes the prompt sub-case to answer_prompt, so both the trigger and the handoff alternative are named.

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

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

Annotations already declare the safety profile (idempotentHint true, destructiveHint false, readOnlyHint false), so the bar is lower, and the description adds real context beyond them: going backward implies re-running all checks on the way forward, and it names the return payload ('Returnerar step och snapshot'). It does not state whether state in later steps is preserved or discarded, which is the main remaining behavioral gap.

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

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

Short and front-loaded: the action is stated first, then the usage condition, then the return value. Every sentence carries information, though the first line and the usage line slightly overlap on the same 'go back to a prior step' idea.

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

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

For a low-complexity two-parameter navigation tool with rich annotations and a fully documented schema, the description is nearly complete, and it compensates for the absent output schema by naming the returned step and snapshot. Missing only the effect on in-progress data in later steps.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 1-7 range and the 'only previous or current' rule. The description adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Går tillbaka till ett tidigare steg i webbguiden') and explicitly separates itself from the sibling next_step for forward navigation. An agent can distinguish this tool from next_step without opening either schema.

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

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

It gives explicit when-to-use guidance ('Använd för att ändra något i ett steg som redan är klart') and names the only alternative for the opposite direction ('Framåt går man bara med next_step'). Nothing is left to inference about which navigation tool to pick.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial behavior: results are sorted most-recently-changed first, status values are enumerated with their meanings (draft/submitted/registered/rejected/action_required), the current step span (1–7) is disclosed, and each item carries a web link.

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

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

Front-loads the essential fact (saved drafts, newest first) and then a compact usage sentence followed by a return-field list. The return enumeration is long but each field earns its place for a tool with no output schema.

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

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

With no output schema, the description fully carries the burden: it names every returned field (draft_id, company name, org number, fiscal year, status, step, paid flag, last-modified UTC, link) and decodes the status vocabulary. Nothing needed to call or interpret the tool is missing.

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

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

Schema coverage is 100% and the single org_nr parameter already documents the hyphen-optional format with an example. The description never mentions filtering by organisation number, so it adds no meaning beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Listar användarens sparade årsredovisningsutkast') with an ordering guarantee, and pins the concept to a concrete user-visible surface ('Samma utkast som syns under Mina sidor på digitalk2.se'). This clearly separates it from the singular sibling read_draft.

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

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

Explicitly says when to use it: to find the right draft to continue working on, or to check whether a report is already paid or submitted. It gives positive conditions but does not name alternatives (e.g. read_draft for a single draft) or state exclusions, so it falls short of a full routing rule.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds context those hints cannot convey: the AI-mode prerequisite, the explicit 'inget skickas in och inget betalas' no-side-effect guarantee, and the fact that generation uses the same code path as the step-7 preview (so output is representative). That is meaningful value beyond the annotations.

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

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

Front-loads the purpose, then usage, precondition, side effects, and return format in short declarative sentences. Slightly more content than strictly needed for a one-parameter read tool, but every sentence carries operational information.

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

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

With no output schema, the description usefully documents the return value (line-by-line text with '|' separating table cells, plus characters), and it covers the prerequisite and side-effect profile. The only missing element is an explicit pointer to which sibling to use if you do not want the full document (e.g., read_draft).

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

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

There is a single parameter and the schema description already has 100% coverage, including where draft_id comes from (list_drafts) and the account-ownership constraint. The description adds nothing about draft_id beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Förhandsgranskar årsredovisningen som text') and immediately distinguishes itself from sibling read_draft by scoping the output to the whole document generated by the same code as the step-7 preview. An agent can tell this apart from list_drafts/read_draft without opening any schema.

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

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

Explicitly says when to use it: read through the entire document before the user proceeds to step 7 and to verify that changes landed correctly. It also states the enabling precondition ('Kräver att utkastet är öppet i AI-läge'). It stops short of naming alternative siblings for the same task, so not a full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial behavior the annotations cannot express: whether the draft is open in AI mode determines if unsaved changes are read live versus the last saved version, and no open tab is required in the saved case. It also discloses the sign-convention divergence (step-2 amounts positive in the guide vs. stored SIE signs) and that computed values are recalculated at document generation.

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

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

Front-loads what it does and the primary use case before the edge cases, and every sentence carries distinct information. It is dense and long, but there is little filler; a slight trim of the sign-convention aside would tighten it further.

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

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

There is no output schema, so the description must describe returns — and it does, naming source, step and data for the selected section. Combined with the live/saved distinction, the sign-convention caveat, and the recomputation note, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the schema already documents section, draft_id and full, making 3 the baseline. The description goes past that by linking returned field names to update_fields' accepted inputs and by noting the 'source' value (live vs. saved), which is semantic information the parameter schema does not carry.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Läser innehållet i ett utkast, en del i taget') and pins the scope to a single section, which separates it from broad reads like get_state. It explicitly carves out sibling territory by directing tax results to read_tax and final computed values to preview_report, so an agent can distinguish it without opening any schema.

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

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

Gives a concrete when-to-use ('granska siffror och texter innan du föreslår ändringar eller trycker på Nästa') and names two alternatives with their selecting conditions (read_tax for tax/INK2 results, preview_report for final values). Nothing about routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful context the annotations lack: the required server-side state (AI mode, step 3) and the instruction not to recompute platform numbers. It does not, however, describe failure behavior or what happens if the preconditions aren't met.

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

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

Front-loaded with purpose, then preconditions, then the return contents. All three blocks carry real information, though the enumerated return list is dense and slightly verbose. Nothing is redundant enough to flag as waste.

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

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

No output schema exists, so the description carries the burden of explaining returns, and it does so thoroughly (result contents, to_book, ink2r_balanced, sru_ready). Combined with the precondition and navigation guidance, an agent has everything needed to call this tool correctly.

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

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

Schema description coverage is 100% and the single parameter (draft_id) is already fully documented in the schema, including its source (list_drafts) and ownership constraint. The description adds nothing about draft_id, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Läser/Reads) and resource (skatteberäkningen and INK2), and pins the scope to 'exactly as step 3 in the web guide shows them'. It also names the sibling that handles the follow-up mutation (apply_tax_adjustment), so the agent can distinguish this read tool from the adjustment tool.

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

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

Gives explicit preconditions (draft must be open in AI mode and standing on step 3) and names the navigation tools (next_step, go_to_step) to reach that state. It further routes the follow-up action to apply_tax_adjustment, so when-to-use and what-to-do-next are both explicit.

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

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

Annotations declare destructiveHint=true, but the description supplies the crucial detail annotations cannot: that true zeroes prior-year income-statement and balance-sheet figures and that they 'do not come back with false' — an explicit irreversibility warning. It also notes the false-branch dependency on prior fiscal-year dates.

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

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

Front-loaded with the core purpose, then the true/false branches, then the caution. Every sentence carries information; slightly dense but no filler.

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

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

For a state-mutating workflow tool with no output schema, the description covers the effect, the irreversibility, the conditional dependency, the required user confirmation, and the return ('Returnerar snapshot efteråt'). Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% (baseline 3), but the description goes further by explaining the downstream consequences of the is_first boolean rather than merely restating its meaning, adding real semantic value beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (sets the 'first annual report' flag) and immediately explains the concrete effect of each value, so an agent knows exactly what the tool does and how it differs from generic field setters like update_fields.

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

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

Gives a clear condition for use ('answers the question in step 1'), branch-specific guidance for true vs false, and an explicit instruction to ask the user first. It does not name alternative sibling tools, so it stops short of a 5.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: it only switches the tab and changes no data, it may trigger a guide prompt about reviewing the balance sheet, and it returns a snapshot. That UI-state and side-effect disclosure goes beyond what annotations convey.

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

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

The core action is front-loaded in the first sentence, with supporting notes on side effects and the read_draft routing following. Slightly more sentences than strictly needed (the guide-review detail is tangential), but every sentence carries information.

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

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

With no output schema, the description covers the return ("Returnerar snapshot efteråt"), the mutation-free nature, the workflow position, and the read_draft handoff. It is complete enough to invoke correctly, with only minor detail about the snapshot's content left implicit.

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

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

Schema description coverage is 100% and the enum already maps income_statement/balance_sheet to their Swedish labels and explains draft_id. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Visar resultaträkningen eller balansräkningen i steg 2" states a specific verb (visar) and a specific resource, and adds that it only switches tabs rather than editing data. The explicit pointer to read_draft for the actual numbers cleanly separates it from the sibling that reads values, so an agent can route 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.

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

It names the alternative explicitly ("Siffrorna läses med read_draft"), which tells the agent when to use read_draft instead of this tool, and situates the tool in step 2 of the workflow. It does not state exclusions or preconditions for calling it, but the routing context is clear.

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

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

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description nevertheless adds real value: it names the objects created (tomma resultat- och balansräkningar), states the state guard limiting when it may run, and notes a snapshot is returned. It stops short of describing failure modes if the precondition is violated.

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

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

Front-loaded with the core action, then the side effect, then the precondition, then downstream steps. Four short sentences, none redundant.

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

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

A write tool with one fully-documented param and no output schema, yet the description covers purpose, guards, side effects, downstream tools, and the return ('snapshot'). An agent has everything needed to call it correctly and in the right order.

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

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

Schema description coverage is 100% and the single draft_id parameter is fully documented there (including the 'must belong to the connected account' constraint). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Väljer manuell inmatning i steg 1') and immediately scopes it to the no-SIE-file case. It also spells out the side effect (skapar tomma resultat- och balansräkningar), which lets an agent distinguish it from the SIE siblings like upload_sie and create_sie_upload.

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

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

Gives an explicit precondition ('när det inte finns någon SIE-fil') and an exclusion ('Går bara att välja innan någon SIE-fil eller några företagsuppgifter finns i utkastet'). It also routes the agent to the correct follow-up tools (update_fields, fill_input, fetch_company_details), so sequencing is unambiguous.

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

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

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=false, so the bar is lower, yet the description adds real substance: fields are overwritten, lists are replaced wholesale while objects merge, only fields present in read_draft with a matching type are accepted, and one invalid field aborts the whole change. It also explains the write routes through the same update path as the form so the guide's recalculations run.

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

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

Purpose is front-loaded in the first sentence, followed by behavior, validation constraints, routing, and return values in a logical order. It is dense and longer than typical, but each sentence carries operational information rather than filler.

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

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

For a destructive, nested-object mutation tool with no output schema, the description covers the return contract (applied plus a snapshot with messages on failure), the overwrite/merge semantics, validation failure behavior, and step ownership. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100% and the schema descriptions are already detailed, so baseline is 3. The description adds semantic constraints the schema does not state — the read_draft/type-match validation rule and the fact that invalid fields cause no change at all, which directly affects how values should be constructed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (ersätter/skrivs över) and resource (fält i steg 2–6) and explicitly scopes itself against the sibling fill_input, which handles step 1. An agent can distinguish this tool from fill_input and read_draft without opening any schema.

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

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

Gives explicit when (steps 2–6, including yes/no questions in steps 3–6) and when-not (step 1 goes to fill_input), and names the sibling tools that handle step 1. It also adds an operational rule: ask the user for unknown data rather than inventing it.

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

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

Annotations declare destructiveHint=true, but the description goes well beyond them by enumerating precisely what is overwritten (company details, fiscal year, P&L, balance sheet, notes, periodization funds) and by promising that the file is validated as SIE before anything changes. It also discloses the 5 MB ceiling and that loaded plus snapshot are returned, which is exactly the context a destructive mutation needs.

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

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

Front-loaded with the action and its step context, then layered with replacement scope, input modes and preconditions in a logical order. The clause comparing it to a user selecting a file in the wizard is decorative but minor; the rest is dense with non-redundant information.

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

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 names the return values (loaded and snapshot) and covers atomicity, size limits and step/AI-mode preconditions. It does not explain what the snapshot contains or how a validation failure is surfaced, leaving a small gap for a destructive tool.

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

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

Schema description coverage is 100%, so the schema already documents draft_id, filename, upload_id and content_base64, including the ~30 kB recommendation and 5 MB limit. The description restates those same tradeoffs rather than adding syntax, encoding or default behavior beyond them, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Läser in en SIE-fil (SIE4) i steg 1') and immediately scopes it by naming exactly which draft data gets replaced. It is clearly distinguishable from the sibling create_sie_upload, which only stages bytes, because this tool is the one that parses and applies the file.

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

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

Gives concrete preconditions (draft must be open in AI mode and at step 1) and routes between the two input modes, recommending upload_id for larger files and content_base64 for exact-byte fidelity. It never states when to avoid the tool or what breaks if the step precondition is violated beyond the implicit requirement, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description goes beyond that by disclosing the exact return contents (email, connection name, granted permissions, links) and by decoding the permission model (view = read, write = prepare drafts), which materially affects how an agent interprets its own capabilities.

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

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

Three tightly packed sentences: purpose first, then usage triggers, then the sibling distinction and return contents. Every sentence carries distinct information with no filler.

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

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

There is no output schema, so the description carries the return-value burden and does so completely, enumerating the returned fields. Combined with annotations covering safety, an agent has everything needed to call and interpret this tool.

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

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

The tool takes zero parameters, so the baseline of 4 applies. Schema description coverage is trivially 100% and there is nothing for the description to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Visar vilket DigitalK2-konto och vilka behörigheter den här anslutningen har') and explicitly differentiates itself from the sibling list_drafts. An agent can tell exactly what it gets back without opening a schema.

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

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

Gives two concrete triggering conditions (start of conversation to confirm the right account is connected, or when a tool is denied on permission grounds) and names the alternative tool with the condition that selects it ('för att se användarens årsredovisningar, använd list_drafts'). Nothing is left to inference.

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