Ta med historikken

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

The description explicitly states 'Idempotent — kan køres igjen; bare endrede økter får ny versjon', which directly contradicts the annotation idempotentHint=false. This is an annotation contradiction, so the behavioral-disclosure score is capped at 1 despite the otherwise useful local-only/no-login and 10-minute auto-read context.

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 and 'alt (anbefalt)' are front-loaded, then a dense but useful per-source list, then usage triggers and dryRun guidance. It is long, but nearly every clause adds operative detail; only the sheer wall-of-text formatting keeps it from a 5.

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 7-source import with no output schema, the description is unusually complete: it covers sources, triggers, dry-run workflow, idempotency expectations, and the web/mobile limitation. The main residual gap is that it describes 'vis tallene' only loosely re: what the dry-run report contains, but nothing critical for 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%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains what each enum value actually scans (e.g. code = ~/.claude/projects, cowork = audit.jsonl, finder = AI-origin docs by reference only), and it ties the lenke parameter to kilde=lenke. That elevates it above the 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?

The opening states a specific verb and resource: 'Importer tidligere samtaler og dokumenter som søkbare atomer', and the per-source breakdown (code, cowork, desktop, finder, lenke, innboks) makes it unmistakable how this differs from siblings like tua_save or tua_list. An agent knows exactly what this tool produces 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 concrete user triggers ('ta med historikken', 'importer samtalene mine', 'hent inn gamle økter', 'lagre denne delte lenken'), prescribes a dryRun=true dry pass first, and gives an explicit fallback for web/mobile-only conversations. Both when-to-use and when-not (internal API never called) are covered.

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