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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely non-obvious behavior — that this renders an interactive MCP App surface (M/L buttons, 'Bygget av', 'Synlig for', 'Åpne i …') and degrades to plain text in clients without card support. It does not state ordering/pagination details for the id-mode or any latency/limit behavior beyond the schema's limit field.

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 two modes, then the routing rule and the fallback — a logical order with almost no filler. It is dense (three long sentences) but every clause carries distinct information; only the enumeration of UI chips is slightly listy.

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 read-only renderer with no output schema, the description fully explains what the caller will observe in both modes and what happens when the host cannot render cards. With annotations covering safety and the schema covering all seven parameters, nothing material 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 coverage is 100%, so the per-field descriptions already carry the baseline. The description goes beyond them by explaining how `id` and `query` select entirely different result shapes (single atom card vs. newest-first hit list) and that the ingress level S is rendered first, which the schema alone does not convey.

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 ('Vis et kort fra Tua inne i samtalen') and immediately decomposes into the two operating modes: `id` renders a single atom card with its UI affordances, `query` renders a ranked hit list. It also explicitly names the siblings it is not (tua_search/tua_get), so an agent can discriminate 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 selection rule: use this when the *user* wants to see an atom or hits, use tua_search/tua_get when the agent itself needs the text. It also covers the degraded-client case ('I klienter uten kort-visning får du det samme som tekst'), so the agent knows the call still works when card rendering is unavailable.

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?

Adds substantial behavior beyond the annotations: the tool returns the raw markdown source and does not itself finalize the deliverable, provenance records which version and level were used, and the key parameter makes a re-run replace the previous version. That last point sits in mild tension with idempotentHint=false, though versioned replacement on a stable key is not a true contradiction. No permissions or error behavior 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-loaded with the core action, then the when-to-use triggers, then level rules, then the follow-up workflow. Dense but nearly every sentence carries actionable information; only the house-style/HTML-PDF tail is slightly tangential to invoking the tool correctly.

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 stating exactly what comes back (the markdown source) and what the agent must do next (rewrite and save via tua_save with the same key). For a 9-parameter mutation tool this is close to complete, though failure modes and the exact provenance artifact remain 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 coverage is 89%, so the baseline is 3, but the description genuinely adds meaning: level defaults to M with L only on request, context is capped at the level it was given, and vault-tagged atoms are forced to S. It also clarifies that ids are order-sensitive and that project defaults to the first source atom's project.

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: compose several atoms into one deliverable in markdown and persist it as a new atom with provenance back to sources. The scope, output format and the persisted artifact are all named, making it clearly distinguishable from siblings like tua_get or tua_save.

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 trigger phrases («lag et notat/dokument/sammendrag av disse», «sett sammen X, Y og Z»), specifies the default level (M) and the exception (L only on explicit request), and explains the vault-atom rule (included only as S). It also draws an explicit boundary with the sibling tua_save by saying the write-back happens in a separate call.

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 safety and idempotency are covered. The description adds the shape of what is returned (provenance, related atoms, links, versions) and the fallback that S is derived from L when M is missing, which is useful, but it discloses nothing about permissions, cost, or limits beyond that.

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 its output contents, then the level strategy, then version selection — each sentence carries distinct information. The one long enumeration sentence is dense but each listed item is a genuine return artifact, so little is wasted.

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 carries the burden of describing returns, and it does so thoroughly (provenance, related atoms, map address, links, versions) while explaining level and version semantics. It is complete enough to call correctly, with the only gap being any note on payload size or truncation for L.

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 baseline is 3, and the description adds real strategy beyond the schema: the M-first / L-only-when-needed ordering and the note that a missing M yields the start of L. The `version` behavior (prior version by name) is also echoed clearly, though no new syntax details are added.

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 (hent ett atom) and enumerates exactly what comes back: provenance, related atoms, map address, open-in links, and prior versions. It also names the sibling tools (tua_search/tua_list) as the source of the id, so an agent can tell it apart from the list/search tools 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 selection guidance for the level parameter: fetch M first, use L (everything) only when the answer requires it, and describes how `version` retrieves a prior version. It routes the agent to tua_search/tua_list for obtaining the id, but does not state an explicit when-not-to-use case beyond the level heuristic.

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?

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.

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds genuinely new behavior: the operation is referential not duplicative, the source atom is unchanged, the level can be re-invoked to adjust an existing reference, and L is the default for the owner's own projects. It does not mention permissions or what happens on a failed link, which keeps it 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?

The copy-vs-reference constraint is front-loaded, then usage triggers, then the level semantics and the re-invocation behavior. Dense but every sentence carries information; slightly packed toward the end with the level explanation.

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?

Three parameters, no output schema, and annotations already convey idempotency and non-destructiveness. The description covers semantics, triggers, and level behavior; only error/permission behavior is absent, which is a minor gap for a well-annotated link 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 baseline is 3, but the description adds real meaning beyond the enum: S = bare ingress, M = summary, L = everything (and the L default rationale). The id parameter's provenance (from tua_search/tua_list) is already in the schema. This is meaningful compensation 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+resource (make an atom visible in another project) and immediately disambiguates the semantics that matter most: it creates a REFERENCE, never a copy, and the atom still exists once in its origin project. This distinguishes it clearly from copy-like or duplicate operations and from siblings such as tua_unlink.

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 trigger phrases are given («gjør dette synlig i X», «del dette med prosjekt X», «prosjekt X trenger dette»), plus the extension case: call again with a new level to raise or lower an existing reference. An agent knows exactly when to reach for this tool.

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), so the bar is lower. The description adds genuine value by disclosing the return contents (projects, tags with counts, newest atoms) and the semantics of the `needs` mode, which the annotations 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 overview scope, then usage triggers, then filtering notes, then the `needs` mode. Dense but every clause carries information; only the parenthetical counts phrasing is slightly loose.

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 enumerates what the overview returns and covers both filter axes and the `needs` mode. An agent could call it correctly, though default limit behavior is left to the schema and no return-shape details are given.

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 all four parameters are already documented in the schema (tag, project, limit with default, needs enum). The description only adds that `needs` underpins a «Ny gjennomgang», which is marginal beyond the schema's own text; 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 concretely what the tool produces: an overview of all projects and all tags with counts, plus the newest atoms. That is far more specific than the bare name/title, though it never explicitly distinguishes itself from siblings like tua_search or tua_get.

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 trigger conditions with quoted user utterances («hva har jeg i Tua», «list alt», «hvilke tagger finnes») and explains the special `needs` mode as the basis for a «Ny gjennomgang». It stops short of naming an alternative tool for narrower lookups, so it is 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 declare readOnly, idempotent, and non-open-world behavior, so the bar is lower. The description adds useful behavioral context beyond the annotations: it requires the bridge to be running and restricts targets to a fixed list. It does not explain the return/success signal, but the added constraints are substantive.

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 compact sentences with no filler: context first, then the precise actions and constraints. Every clause earns its place, though the structure is more utilitarian than optimally front-loaded for an agent scanning for the core action.

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?

Given rich annotations, a fully documented two-parameter schema with an enum, and no output schema, the description covers the essentials: what opens, the prerequisite, and the target restriction. It only omits what a successful invocation returns, which is a minor gap for a launcher 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 baseline would be 3. The description improves on this by mapping each enum target ('finder', 'code', 'claude', 'kart') to a concrete outcome, giving the agent meaning beyond the raw enum values. The 'id' parameter is not further described, keeping it from a 5.

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 gives a specific verb ('Åpner') and enumerates exactly what is opened for each case: the atom's file in Finder, the repo in Claude Code, the Desktop project in Claude, or the atom in the map. It is easy to distinguish from the data-oriented siblings, though it does not explicitly name or contrast with any of them.

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 states the invoking context ('Brukes av Tua-kortet'), a prerequisite ('krever at broen kjører'), and a scope limit ('Fast liste, ingen andre mål'). It does not name alternative tools or spell out when an agent should prefer this over, say, tua_get, but the context is clear enough for correct use.

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 and destructiveHint=false, so the agent already knows this is a non-destructive write. The description usefully adds that provenance (source, project, conversation, time) is attached automatically and that there is deliberately no folder hierarchy, which is real context beyond the annotations. It omits, however, the key-collision replacement behavior — that is buried in the schema's 'key' description, not in the tool description.

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 tight sentences, front-loaded with what the tool does, then followed by the two most important call constraints. No filler, though the 'no folder — that's the whole point' aside is personality rather than instruction.

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 14-parameter mutation tool with no output schema and no idempotency guarantee, the description covers the input contract well but says nothing about what comes back. With no output schema to lean on, the return value (e.g. the created or replaced atom id/version) should have been described.

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 genuine call-shaping rules: put the ENTIRE content in 'content', always provide 'short', and add 'medium' when content exceeds ~3000 characters. That sizing guidance goes beyond restating the schema and directly affects how the agent invokes the tool.

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: save content as an 'atom' in the Tua archive, with provenance auto-attached and no folder to choose. This is much sharper than a tautology, but it never contrasts itself with the closest siblings (tua_import, tua_compose), so the agent gets purpose but not sibling differentiation.

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?

Usage is implied (save a piece of AI output or other content), and it gives operational rules about always sending 'short' and sending 'medium' past ~3000 chars. However it never says when to prefer tua_save over tua_import, tua_compose, or tua_link, and gives no exclusion criteria, so the when-to-use dimension 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, idempotent, non-destructive and closed-world behavior, so safety is covered. The description adds useful return-format context (each hit returns S/ingress and the why-line) and a progressive-disclosure workflow, though it doesn't describe ranking or match-count behavior.

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 usage triggers, then result granularity and workflow. Four short sentences with no filler; every sentence contributes routing or behavioral value.

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 read-only search tool whose annotations cover the safety profile and whose parameters are fully documented, the description supplies the missing pieces: when to reach for it, what a hit looks like, and how to drill down. Minor gaps remain around result ordering and paging, but nothing essential to 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 description coverage is 100%, so limit, query, context, and project are already fully documented in the schema. The description's workflow note about levels touches on result depth but adds no parameter syntax beyond what the schema provides, 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 (Søk) and resource (Tua-arkivet) plus explicit scope — across ALL projects and conversations. It also names the sibling tua_get as the follow-up step, so an agent can distinguish it from the detail-fetch tool 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 concrete trigger conditions («hva har jeg om X», «finn det jeg lagde om X», eller når tidligere arbeid kan være relevant) and a directive to use it first. It also names the alternative/next tool (tua_get at level=M) and the sequencing rule (fetch M before L), leaving little 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?

With annotations declaring a non-read-only, non-destructive, idempotent write, the description adds real context: the selection is persisted to ~/.tua/config.json, and a «Tua» folder is created containing a welcome atom and an Inbox. It does not say what happens when re-run or whether an existing archive is touched, which is the only meaningful 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-loads the primary action, then the critical constraint (never guess), then the no-argument behavior, then persistence details. Every clause carries information; nothing is 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 two-parameter, zero-required setup tool with no output schema, the agent has everything it needs: when to invoke it, what each argument selects, the no-argument fallback, side effects, and where state is stored.

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 sti and sted are already fully documented, including the enum values and the absolute-path constraint. The description restates the same set of locations and the custom-path alternative but adds no format or precedence rules beyond it, 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 action (choose/create the archive folder) with exact scope: first run, five named backends or a custom path. It is clearly distinguishable from siblings like tua_save or tua_import, which operate on the archive rather than configuring it.

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 with an exclusion: call ONLY after the user has chosen (an answer to an «oppsett:»-line), never guess. It also documents the zero-argument mode (list existing locations and current selection) and notes the choice can be changed later via settings, covering the main alternative path.

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 idempotentHint=true and destructiveHint=false, but the description adds genuinely non-derived context: the atom itself is not deleted and persists where it originated. That clarifies the blast radius of the mutation beyond what the schema fields or 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?

Two short sentences with zero waste: the action is front-loaded and the second sentence earns its place by clarifying the non-destructive scope. Nothing is padded or repeated.

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 only two fully documented parameters, idempotent/destructive annotations, and no output schema, the description covers the essential effect and non-deletion semantics. It could do slightly more by noting how to reverse the action via tua_link, which is the only real gap.

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 (atom id, project) are already documented in the schema. The description adds no extra syntax, format, or constraint information beyond the field-level descriptions, 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+resource: removing the reference so an atom is no longer visible in a project. An agent can distinguish this from the sibling tua_link (its inverse), though it never names the sibling explicitly, so differentiation must be inferred.

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?

Usage is implied rather than stated: an agent can read that this hides an atom in a project, but the description gives no explicit when-to-use, no note about re-linking via tua_link, and no preconditions.

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