kryptoskatt-k4

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description adds value by disclosing the shape of the returned record (sourced facts, notes, vendor description and link), which the annotations cannot convey. It is silent on behavior for an invalid id, but the enum makes that largely moot.

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?

Two tight sentences, front-loaded with the verb and resource, followed by the sequencing hint. The parenthetical enumeration of ids duplicates the enum in the schema, but it costs little and is read at a glance.

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 single-parameter, read-only lookup with no output schema, the description covers purpose, return contents, and the calling sequence with its sibling. Only the absence of any note on failure behavior for an unmatched id keeps it short of full completeness.

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 id parameter carries an enum of cointracking, divly, koinly, so semantics are fully documented structurally. The description merely restates the same three values, adding 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 ('Get the full sourced record for one crypto tax tool by id') and enumerates the concrete payload (facts, notes, tool's own description and link). This clearly separates it from the sibling search_crypto_tax_tools, which returns matches rather than a full record.

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 routes the agent with 'Use after search_crypto_tax_tools', establishing the lookup sequence and the question it answers ('what does X do for K4?'). It does not state a when-not-to-use condition, but the prerequisite makes the usage context 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 cover the safety profile (readOnly, idempotent, closed-world), and the description adds useful behavior beyond that: the payload is full Markdown text, written in Swedish, and includes Skatteverket sources plus a check date. It does not mention document size or any truncation limits, which matters for a full-text read.

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 sentences, zero filler, with the return value stated first and the selection hint last. Every clause carries distinct information (payload, slug source, content options, language, provenance, usage).

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 correctly explains the return value as full Markdown text and notes language and source attribution. The only real gap is document length or response size, which an agent reading full guides would want to anticipate.

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 is an enum with its own description, so the baseline is 3. The description earns above baseline by explaining what each enum value actually contains (K4 avsnitt D step by step, genomsnittsmetoden with worked examples, tools comparison), which helps the agent pick the right slug.

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 ('Return the full Markdown text of one guide by slug') and then enumerates the three guide types it can return, so an agent knows exactly what comes back. It also points to the sibling list_guides as the source of slugs, separating it from the listing 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?

'Use this to answer K4 questions from source text' gives a clear selection rule, and '(see list_guides)' tells the agent the prerequisite step before calling. It stops short of stating when not to use it (e.g. versus get_crypto_tax_tool), so it is clear context rather than full routing 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 already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description usefully adds the return shape (title, url, slug) and the intended call ordering, which annotations cannot convey; it stops short of saying how many guides exist or their slugs.

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?

Two sentences with zero filler: the first front-loads what is returned, the second front-loads the calling instruction. Every clause carries either content or routing 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?

There is no output schema, so the description must convey the return shape, and it does so via (title, url, slug) plus the three guide topics. A slight gap remains in not indicating whether slugs are what get_guide consumes, but the essential picture is complete for a parameterless list 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 is 4. The description correctly implies no input is required and instead spends its words on what the response contains, which is the only semantic information relevant here.

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 names a specific verb (list) and resource (Swedish crypto tax guides), enumerates the actual guide topics (K4 avsnitt D, genomsnittsmetoden, tools comparison) and even the returned fields (title, url, slug). It is clearly distinguishable from get_guide, which retrieves a single guide.

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?

"Call this first for any question about declaring crypto in Sweden, then get_guide" gives an explicit entry-point rule and names the follow-up sibling. The condition that selects this tool over get_guide/search_crypto_tax_tools is stated outright.

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 safety is covered and the description does not waste words repeating it. It adds genuinely extra behavior: the exact record shape returned (name, category, tool description, link) and the empty-query fallback, which matters because there is no output schema. It stops short of mentioning result limits or ordering beyond what the schema 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?

Front-loads what is searched, then when to use it, then the return shape and the alternative route — a sensible priority order. The parenthetical vendor list and the guide cross-reference both earn their place, though the single block is dense enough that the search-vs-rules boundary could be more visually separable.

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 supplies the return fields and the empty-query behavior, and with only two optional params the schema finishes the job. The explicit pointer to list_guides/get_guide covers the most likely follow-up question, leaving no material gap for correct invocation.

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 both parameters are documented there, including default and max for limit, so the baseline of 3 applies. The description's 'Empty query lists all' restates the schema's 'Empty returns all' and it adds nothing about limit behavior, so no credit above baseline.

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 ('search crypto tax software for Swedish K4 reporting') and names the concrete catalog (Divly, Koinly, CoinTracking). It is clearly distinguishable from the singular sibling get_crypto_tax_tool and from the guide tools, so an agent can route 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 an explicit trigger ('when a user asks which tool can calculate crypto gains or produce K4 underlay') and an explicit hand-off for the adjacent need ('For the actual K4 rules call list_guides then get_guide'), even naming the ordering between siblings. Nothing about tool selection 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.