DigitalK2

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is largely covered. The description adds what annotations cannot: it acts on the user's behalf like a real button press, requires explicit user consent beforehand, and (with no output schema present) documents the return value 'clicked' plus the post-answer snapshot. It stops short of stating outright that the answer is consumed and cannot be replayed, which the non-idempotent hint implies but never says.

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 short paragraphs are front-loaded with the core action, then routing rule, then return values. Every sentence carries weight, though the middle paragraph is dense enough that the press_button exclusion could be surfaced slightly earlier for scannability.

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 four parameters at full schema coverage, no output schema, and annotations covering the safety profile, the description fills the remaining gaps: workflow position relative to get_state/next_step, the press_button boundary, the consent requirement, and the return shape. Only edge behavior (e.g. what happens if option text does not match any prompt option) is left unstated.

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 every parameter (draft_id, option, prompt, inputs) is documented in the schema itself, so the baseline is 3. The description reinforces parameter sourcing by pointing at snapshot.prompts[].options, .title for disambiguating duplicate button texts, and .inputs for pre-filled values, adding mapping context but no syntax beyond the schema.

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 answers a dialogue prompt shown by the guide by pressing the button the user would press. It also explicitly demarcates itself from the sibling press_button, which handles form buttons and Ja/Nej questions in snapshot.actions, so an agent can route correctly 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?

Explicit when: only for questions returned by get_state and next_step as prompts (prefill from last year, confirmation of a small deviation, reminder). Explicit when-not: form buttons in snapshot.actions go to press_button. It even adds a procedural rule (explain the question to the user and obtain an explicit answer first), leaving nothing 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 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 readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by describing the interaction model ('as when the user writes'), the discovery prerequisite via get_state, and the post-call action. It falls short of a 5 only because it doesn't state failure modes or permission requirements.

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 one line, followed by a compact workflow paragraph and a one-line return statement. Every sentence carries routing or prerequisite information; only the trailing return sentence is somewhat redundant given it could be inferred.

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, yet the description names the return payload (filled, value, snapshot), so an agent knows what comes back. Combined with the prerequisite pointer to get_state and the follow-up press_button step, nothing needed to call this 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 description coverage is 100%, so the schema already explains label, value and draft_id in detail, including format examples (NNNNNN-NNNN, ÅÅÅÅ-MM-DD). The description reinforces the field-discovery path but adds no syntax or constraint 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 (skriver) and resource (formulärfält) scoped to step 1, and explicitly separates itself from update_fields which handles steps 2-6. An agent can distinguish this from every sibling 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?

Names the exact condition for use (step 1, manual company entry without a SIE file), tells the agent where to find valid fields (snapshot.inputs via get_state), routes steps 2-6 to update_fields, and names the follow-up tool (press_button). When-to-use, alternatives, and sequencing are all 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 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?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds valuable behavior beyond these: the failure mode (guide won't advance, returns prompts/messages), and the manual-override for step 7. Does not discuss side effects of advancing (e.g. what state changes), which keeps it from a 5 given the low annotation bar.

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, then conditions, alternatives, and return values in a logical order. Slightly long but every sentence carries distinct information; 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?

Despite no output schema, the description names the return values (moved, from_step, snapshot), covers the failure response shape, and clarifies the manual step-7 boundary. An agent has everything needed to call 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 coverage is 100% for the single draft_id parameter, and the schema description already explains its origin (list_drafts) and the account-ownership constraint. The tool description adds no parameter detail, 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 ('Trycker på Nästa i webbguiden' – presses Next in the web guide) and clarifies it mimics the user's own action with the same controls. It distinguishes itself from siblings go_to_step (backwards navigation) and answer_prompt (handling missing answers) 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?

Explicit when-to-use ('när allt i aktuellt steg är ifyllt och granskat'), when-not (guide won't proceed if something is missing or a question must be answered), and routes to the correct alternative tools: answer_prompt for prompts, go_to_step for going back. Also notes step 7 is always done by the user on the web.

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 only declare the mutation profile (readOnly=false, idempotent=false, destructive=false). The description goes well beyond them: it discloses the return value ('Returnerar clicked och snapshot efteråt'), a step-based limitation (step 7 payment/signing/submission is manual), the source of valid button labels (snapshot.actions via get_state), and an authorization/consent requirement ('Fråga användaren innan du svarar på frågor åt hen').

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 cases, alternatives and constraints in a logical order. Every sentence carries information, though the single dense paragraph is 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 still states the return shape, and it covers the routing rules, the step-7 limitation and the consent requirement. Nothing an agent needs to invoke this 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 description coverage is 100%, so the schema already explains label, context and draft_id in detail, including the exact source and disambiguation role of context. The description only restates that buttons come from snapshot.actions, adding little beyond the schema. Baseline 3 applies when structured fields do the heavy lifting.

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 target ('Trycker på en knapp eller Ja/Nej-fråga i själva formuläret, som när användaren klickar'), which precisely distinguishes it from answer_prompt (dialoger) and next_step (gå vidare). An agent can tell what this does and what it is not 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?

Explicit when-to-use cases (Ja/Nej-frågor, hämta företagsuppgifter från Bolagsverket, automatisk skattejustering i steg 3) and explicit alternatives ('Dialoger ... besvaras med answer_prompt i stället', 'Gå vidare med next_step, inte med den här'). It even names a hard exclusion ('Fungerar inte i steg 7').

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 and non-destructive behaviour, so the safety profile is covered. The description adds genuinely new behavioural context: the required draft state (open in AI mode, on step 3) and the directive not to recompute the platform's figures. It does not, however, cover failure modes or what happens if the preconditions are unmet.

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 return shape; each sentence carries information. The return-value enumeration is dense but earns its place given the absence of an 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 carries the return-shape burden and does so thoroughly, naming result, to_book, ink2r_balanced and sru_ready and explaining the to_book follow-up action via press_button. Preconditions and platform-calculation caveat close the remaining gaps.

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 parameter (draft_id) is fully documented in the schema itself, including the ownership constraint. The description adds no syntax or format detail beyond the schema, so the baseline of 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 (read) and resource (the tax calculation and INK2), plus a precise scope anchor: 'exakt som steg 3 i webbguiden visar dem'. An agent can distinguish this from read_draft or preview_report 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?

Explicit preconditions are given ('Kräver att utkastet är öppet i AI-läge och står på steg 3') along with the alternative tools to satisfy them ('gå dit med next_step eller go_to_step'). Nothing about when this tool is callable 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 readOnly=false, destructive=false, idempotent=true, but the description adds materially more: validation is atomic (an invalid field means nothing changes), the write goes through the form's own update path so guide calculations and controls re-run, and the return payload (applied plus a post-change snapshot with messages) is described.

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 purpose in the first sentence and each subsequent sentence carries distinct information (validation, side effects, sibling routing, return shape). Slightly dense across six sentences, 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 nested-object mutation tool with no output schema, the description covers prerequisites (draft_id ownership, section/step match), accepted field constraints, failure behavior, side effects, sibling alternatives, and the return shape — nothing essential 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%, so the baseline is 3, but the description adds real semantics beyond the schema: values must mirror read_draft names/types, section must correspond to the step the guide is currently on, and the draft must belong to the connected account.

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 (fills in / changes fields) scoped to steps 2–6, and explicitly contrasts with fill_input (step 1) and press_button (Yes/No questions and buttons). An agent can distinguish this from every relevant sibling 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?

Explicit routing rules: use fill_input for step 1, press_button for buttons and Yes/No questions, and only fields present in read_draft with matching type are accepted. It also instructs the agent to ask the user rather than invent values, which is actionable when-to/when-not guidance.

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 only give the generic safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), while the description adds real operational context: the file must be transmitted byte-for-byte unmodified, #PROGRAM and #ORGNR lines must survive, and the ingestion fills company, fiscal year, income/balance statements, notes and periodiseringsfonder using the same code path as manual upload. It also states the return ('snapshot efter inläsningen'), which no output schema covers.

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 transport guidance, then prerequisites/workflow. The 'skriv aldrig av eller redigera filen' warning is repeated in the description and again in the content_text schema field, which is mild redundancy, but every paragraph otherwise carries unique 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?

For a five-parameter, state-dependent ingestion tool with no output schema, the description covers transport method, size limits, encoding, prerequisite draft state, side effects on draft data, and the return value. Nothing an agent needs in order to invoke 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%, so the baseline is 3, but the description adds selection logic the schema does not: upload_id is recommended for files over ~30 kB, content_text only when the user pasted the text themselves, and content_base64 preserves the character encoding. That is genuine decision support beyond the field descriptions.

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 ('Laddar upp en SIE-fil (SIE4) till utkastet och läser in den i steg 1') and explicitly contrasts itself with the sibling create_sie_upload, which only stages the file. An agent can distinguish it from create_sie_upload 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 an explicit preferred path (create_sie_upload → curl --upload-file → upload_sie with upload_id) plus a fallback (content_base64 for small files), and names the prerequisite state (draft open in AI mode, on step 1, otherwise go_to_step 1). It also routes the next actions (get company data, press_button, next_step), so the agent knows both when to call it and what to do after.

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.