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

With no annotations provided, the description carries the full behavioral burden and does disclose key safety behavior: mutations require explicit confirmation, confirmation timing is constrained, and DELETE is permanent. It does not cover permission requirements or side effects for non-delete changing actions, but it covers the central risk profile well.

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 description is short, front-loaded with what the tool does, and then immediately covers the critical confirmation and permanence rules. Every sentence contributes to safe invocation guidance.

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?

The tool has no annotations, 0% schema description coverage, and an open-ended action string, so the description must carry substantial context. It covers the most important safety rules and the source of action names, but it leaves finnkode unexplained and does not enumerate or constrain the full action set. The output schema exists, so return-value explanation is not required.

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 0%, so the description must explain all parameters. It clarifies the action parameter by saying names come from my_ads and giving DELETE as an example, and it explains confirm=true semantics in detail. However, it never explains the required finnkode parameter, leaving a significant gap.

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: 'Run an action finn.no offers for one of the user's ads,' and gives DELETE as an example. It clearly identifies the ad domain and points to my_ads as the source of action names, though it does not explicitly distinguish itself from sibling tools such as update_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?

It gives important usage context: action names come from my_ads, changing actions require confirm=true, and confirmation must follow explicit user agreement in chat. It does not explicitly state when to use this tool instead of alternatives like update_draft or delete-related siblings.

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 no annotations, the description carries the burden and does well: it discloses that photos are compared by perceptual hash and titles against finn.no ads in any state (active, sold, expired, draft) — non-obvious behavior that materially affects interpretation of results. It omits any statement about permissions, rate limits, or the cost of the scan, and defers match/return semantics to the output schema.

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

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

Two short sentences, front-loaded with the purpose, then the when-to-use rule, then the matching mechanics. No filler or restatement of the tool name.

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 read-only check with an output schema available, the description covers what is compared and against what sources, which is the information an agent needs to call it correctly. Only the optionality of photo_paths and the distinction from confirm_not_duplicate are left implicit.

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

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

Schema coverage is 0%, so the description must compensate, and it does partially: it explains that photo_paths feed perceptual-hash matching and that title is the matching key for finn.no. It does not state that photo_paths is optional or what happens when it is omitted, nor the expected path format.

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 (check whether an item was already listed) and scopes it to two distinct backends: local records and the user's finn.no account. It also distinguishes the matching mechanism per backend, so an agent understands exactly what 'duplicate' means here.

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 BEFORE preparing a new ad" gives an explicit trigger point in the workflow, which is stronger than most sibling definitions. It does not name or contrast with the obvious sibling confirm_not_duplicate, leaving the agent to infer the distinction between detection and confirmation.

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 discloses that the tool updates last_checked_at and last_finnkodes, which are side effects beyond the schema. It also explains the first-call behavior. Since no annotations are provided, the description fully carries the transparency burden.

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 description is extremely concise: two sentences and a list of side effects. Every line serves a purpose, and the main verb 'Run' leads the text. No superfluous content.

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 the tool has an output schema (not shown but known), the description adequately covers the behavior and side effects. However, it could explain the term 'last_finnkodes' and provide more context about the input format, but it remains sufficient for a simple 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?

Only one parameter 'name' exists, and the description does not mention it at all. With schema coverage at 0%, the description should add meaning (e.g., what names are valid or how to construct them), but it fails to do so.

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 clearly states the action: run a saved search and return new listings. It specifies the resource (saved search) and the unique behavior (only new results). This distinguishes it from siblings like search_finn or list_saved_searches.

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?

The description explains that on the first call all results are new, implying subsequent calls yield only new changes. However, it does not explicitly state when to use this tool versus alternatives like search_finn, nor does it list preconditions or exclusions.

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?

No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool mutates the draft state and unblocks publish_draft, plus a user-confirmation requirement, but it omits permissions, reversibility, and what happens if the draft is not actually a duplicate.

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 description is two short sentences, front-loaded with the action and outcome. The precondition follows immediately and there is 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?

An output schema exists, so return values need not be explained. For a simple one-parameter state flag, the description supplies purpose and a user-confirmation precondition; the remaining gaps are behavioral rather than blocking 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 description coverage is 0%, and the only parameter, draft_id, is undocumented in the schema. The description says 'a draft' but does not explain the identifier format or where to obtain it, so it adds little beyond the field name.

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: 'Mark a draft as a genuinely different item.' It also names the downstream effect on the sibling tool publish_draft, so an agent can distinguish this from check_duplicate and publish_draft itself.

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?

The description gives a clear precondition: 'Only call after the USER said in chat that it is not the same item.' This defines when to call it, but it does not explicitly name check_duplicate as the alternative or explain other cases where calling would be inappropriate.

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?

No annotations exist, so the description carries the full burden, and it does well: it discloses that the draft is local-only, that photos are auto-rotated, EXIF/GPS-stripped and resized, and that the first photo becomes the cover. It does not disclose authentication/prerequisite state or what happens to existing drafts on repeat calls, leaving some behavioral gaps for an unannotated mutation tool.

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 single most important fact (local, nothing published), then compact enum glossaries and a clearly labelled PRICE POLICY block. Slightly longer than needed, and the parenthetical 'use suggest_category after push_draft if unsure' is easy to misread as an instruction for this call rather than a later one.

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 10 parameters, no annotations and an output schema present, the description covers the world-facing essentials: environment (local), side effects on photos, enum code meanings, currency units, and the price-decision policy. Remaining undocumented fields (attributes, postal_code, captions) are optional conveniences rather than things needed to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for the hard parameters: category as a numeric LEAF id with an example, all five condition codes spelled out, trade_type 1=Til salgs, and price as whole NOK. Five of ten parameters (title, description, attributes, postal_code, photo_captions) still get no semantic explanation anywhere.

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

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

Specific verb+resource: 'Create a LOCAL draft ad', immediately qualified with '(nothing is sent to finn.no yet)', which cleanly separates it from push_draft and publish_draft. An agent can tell which of the draft-related siblings to call 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 pre-call routing is given for price (use the user's named price, otherwise call suggest_price first and cite comparables) and for category (fall back to suggest_category via push_draft). No explicit exclusion such as 'use update_draft to modify an existing draft', so the when-not case is left implicit.

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 no annotations, the description provides basic behavioral details: it deletes by name and returns True if it existed. However, it does not disclose whether the action is reversible, required permissions, or the behavior on invalid input. The mention of return value adds some transparency but is minimal.

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 convey the purpose and a key behavioral detail with no unnecessary words. The description is front-loaded and efficient, earning its space.

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 the existence of an output schema (context signal), the description covers the return value concisely. However, it lacks context about error handling, prerequisites, or relation to sibling tools like check_saved_search. It is adequate for a simple tool but has room for improvement.

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 schema provides no description for the 'name' parameter (0% coverage). The description adds meaning by specifying that the tool operates 'by name', clarifying the parameter's role as the identifier of the saved search to delete. This compensates for the schema gap effectively for a single string parameter.

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?

Description clearly states the verb (Delete) and resource (saved search) with a specific identifier (by name). It distinguishes from siblings like save_search, list_saved_searches, and check_saved_search by describing a unique delete operation.

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?

No explicit guidance on when to use this tool versus alternatives, such as using check_saved_search first or handling non-existence. The description implies it can be used to delete a saved search, but does not provide context or exclusions.

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 no annotations, the description carries full burden. It discloses caching for 24 hours, fallback probing of verticals, and cache hint behavior, offering solid transparency for a read-only tool.

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 clearly separated paragraphs: one for purpose, one for behavior. Concise without excess, though could add bullet points for readability.

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 simple parameters and an existing output schema, the description covers main behavior and caching. It omits return format but that's delegated to output schema.

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 0%, so description adds value: it explains vertical's behavior when omitted (cache hint, probing). Finnkode is only named, but its role is obvious from 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?

The description clearly states 'Fetch a full listing by its finnkode', providing a specific verb and resource. It distinguishes from sibling search/save tools by focusing on single listing retrieval.

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?

The context implies use when a finnkode is known, but no explicit when-to-use/alternatives are given. Siblings like search_finn are not mentioned, leaving the agent to infer usage.

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?

No annotations are provided, so the description carries the full behavioral burden. "List" implies a read, but the definition doesn't state whether it is side-effect free, whether results are user-scoped, how "local" differs from server-side drafts, ordering, or whether an empty result is possible. The output schema covers return shape, but the operation's semantics remain under-disclosed.

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 single sentence is front-loaded with the verb and free of padding. However, its extreme brevity reflects under-specification rather than disciplined economy, leaving key scoping ambiguous.

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 zero-parameter list tool with an output schema, the description is minimally viable, but with no annotations the meaning of "local" and the relationship to other draft tools are unresolved. It stops short of what an agent needs to decide between list_drafts and siblings like preview_draft or my_ads.

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 there is no parameter semantics to document. Baseline 4 applies, and the description introduces no confusing parameter claims.

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?

"List local drafts" states a specific verb (list) and resource (drafts), with the modifier "local" narrowing scope. Siblings like create_draft, update_draft, and publish_draft are clearly different operations, though the description never explicitly contrasts itself with 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?

There is no guidance on when to call this tool, what precondition makes drafts "local," or which sibling to use instead (e.g., preview_draft or push_draft). The agent must infer usage entirely from the name.

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?

No annotations are provided, so the description carries the full burden. It explicitly states the tool returns all saved searches and orders them by name. It does not mention side effects or permissions, but for a read-only listing operation, the description is adequately transparent.

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 description is a single sentence that conveys the essential information without unnecessary words. It is front-loaded and efficient.

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 no parameters, no annotations, and the presence of an output schema, the description is fairly complete. It could potentially mention that the output is a list or the ordering, but the output schema likely covers the return format. Overall, it is adequate.

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 are no parameters, and schema description coverage is 100%. The description does not add parameter-level meaning because none exist. Baseline for zero parameters is 4, which 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?

The description clearly states the tool returns every saved search in the local store, ordered by name. It uses a specific verb ('Return') and resource ('saved searches'), and differentiates from sibling tools like save_search, delete_saved_search, etc.

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?

The description does not explicitly state when to use this tool versus alternatives such as get_listing or search_finn. Usage is implied by the name and description, but no exclusions or comparison guidelines are provided.

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 no annotations, the description does real work: it discloses that a visible browser window is opened, that the flow is passwordless (e-mail + one-time code from login.vend.no), that the assistant must not type credentials, and that the session persists in the local profile. It omits whether the call blocks until login completes, what happens on timeout, and what failure looks like.

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 in the first sentence, then three short supporting sentences with no filler. Only a minor deduction for the stray formatting/line-break artifacts and the fact that the most important constraint (the wait window) is absent.

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?

An output schema exists, so return values needn't be explained, and the auth flow is well described. Still, for a tool whose only knob is a 300-second blocking timeout, neither the schema nor the description explains the wait/failure behavior, leaving the agent without a basis for setting the parameter or handling expiry.

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

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

The single parameter timeout_seconds has 0% schema description coverage, and the description never mentions it. The reader cannot tell from either source that the call waits up to 300 seconds by default for the user to finish, or what happens when it expires.

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

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

Specific verb and resource: opens a visible browser window on finn.no for manual user login. An agent can tell this is the interactive authentication step, though it never explicitly distinguishes itself from the sibling login_status (which presumably checks whether a session exists).

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: the mention that the session is kept in the local profile hints that repeated logins aren't needed, and 'the assistant never types credentials' tells the agent to hand off to the user. But there is no explicit 'call this when X, use login_status when Y' routing, and no prerequisites or failure 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?

With no annotations, the description carries the burden: 'Check' implies a non-mutating read, and mentioning the 'saved browser profile' usefully discloses that state comes from persisted credentials rather than a passed token. It does not state what happens when no profile exists or whether the check is side-effect free.

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?

A single front-loaded sentence with no wasted words, sized appropriately for a trivial no-argument predicate tool.

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?

An output schema exists, so return values needn't be explained, and with zero parameters there is little else required. Only minor gap is not stating behavior when no saved profile is present.

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?

Zero parameters, so the baseline of 4 applies; there is nothing to disambiguate and the description correctly implies no inputs are needed.

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 ('Check') and a precise resource/scope: whether the saved browser profile is logged in to finn.no. This is distinguishable from the sibling 'login' tool, which presumably performs the login rather than reporting state, though the description doesn't name that distinction 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?

Usage is only implied — an agent can infer it should be called before authenticated actions, but there is no explicit when-to-use, when-not, or reference to the 'login' alternative when the answer is negative. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read/list operation, but it does not state authentication requirements, whether the operation is read-only, pagination behavior, or any rate limits or side effects.

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 description is short, front-loaded with the main purpose, and the second sentence adds useful facet context without unnecessary exposition. There is no wasted text.

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

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

An output schema exists, so return values need less explanation, but the description still omits authentication context, pagination semantics for limit/offset, and when to choose this tool over sibling listing tools. For a no-annotation tool with 0% schema description coverage, more contextual detail is needed.

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 0%, and only the facet parameter is explained in the description, with allowed values ALL and DRAFT. The limit and offset parameters are not described at all, leaving two of three parameters with no added semantic meaning.

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

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

The description gives a specific verb and resource: "List the user's ads on finn.no ('Mine annonser') with state and available actions." That is clear enough for an agent to understand what the tool does. It does not explicitly distinguish itself from the sibling tool list_drafts, so it falls short of a 5.

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?

The description mentions that facet may be ALL or DRAFT and that the response facets field lists others, but it gives no guidance on when to use this tool instead of siblings such as list_drafts or search_finn. There are no when-not conditions or alternative routing instructions.

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?

No annotations are provided, so the description carries the full burden; 'Show' implies a read-only, non-mutating operation and it usefully discloses that validation problems are returned. However, it does not state that the draft is unmodified, whether any permissions are required, or whether the preview reflects the saved or unsaved state — relevant for a tool whose siblings include push_draft and publish_draft.

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?

One sentence, zero filler, with the outcome ('exactly as it would be sent to finn.no') and the secondary value ('plus blocking problems') both front-loaded. Nothing restates the name or title.

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?

An output schema exists, so return values need not be explained, and the description still calls out the two things an agent cares about from that output. For a single-parameter read tool this is nearly sufficient; only the missing read-only assurance and draft_id meaning keep it short of complete.

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 0% and the single required parameter draft_id is undocumented in both schema and description. The name is largely self-explanatory for a drafts-oriented tool, and sibling list_drafts/create_draft establish the ID concept, so the shortfall is not severe, but the description adds no meaning beyond the property name.

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 ('Show') and resource ('a draft') plus what is produced: the exact payload sent to finn.no and any blocking problems. That contrasts naturally with publish_draft and push_draft, though it never names those siblings explicitly, so differentiation is inferred rather than stated.

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 only implied — 'blocking problems' hints it is a pre-publish check, but the description never says when to call it versus publish_draft or push_draft, nor what to do with the blocking problems it surfaces. No exclusions or alternatives are given.

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 no annotations, the description carries the full burden and does well: it discloses the multi-step flow (duplicate check local + finn.no account, push as private draft, finn.no validation, then publish), and warns that the effect is public. It omits auth/login requirements and what happens when the duplicate check or validation fails.

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

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

Front-loaded with the action and the PUBLIC warning, then the flow, then the confirm rule — every line earns its place. Minor deduction for the fragmented 'PUBLIC.' and indented multi-line formatting that reads less cleanly than a single tight paragraph.

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?

An output schema exists so return values needn't be explained, and the description covers the main risk (irreversible public posting gated by confirm) plus the internal validation sequence. Missing details are auth prerequisites and error/duplicate-failure behavior for what is an externally visible mutation.

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 0%, so the description must compensate. It explains 'confirm' thoroughly as a publish gate that should only be true after user approval, but 'draft_id' is never described beyond its name — the agent must infer it comes from create_draft/list_drafts.

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 (publish a draft on finn.no) and adds the crucial scope qualifier that the result is PUBLIC, which distinguishes it from sibling preview_draft/push_draft operations.

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 gating condition: call with confirm=true ONLY after the user saw the preview and said yes in chat, which implicitly routes the agent to preview_draft first. The when-to-use rule is unambiguous and enforceable.

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 zero annotations the description carries the full burden and does well: it discloses upsert semantics (creates draft if needed), side effects (uploads photos, saves fields), non-publication, and idempotency. It omits auth/permission requirements and any rate/latency caveats, keeping it below 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?

Three tight sentences; the private/non-published guarantee is front-loaded ahead of the mechanics and return summary. Nothing 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?

An output schema exists, so the return-value mention is bonus rather than necessity, and the behavioral profile is unusually complete for an annotation-free tool. The only real gap is the meaning/origin of draft_id.

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?

Single parameter draft_id at 0% schema coverage. The phrase 'upload a local draft' implies draft_id identifies a local draft rather than a finn.no id, but the description never states this explicitly or says where the id comes from (e.g. create_draft or list_drafts). Additive but thin.

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

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

Specific verb+resource: uploads a local draft to finn.no as a PRIVATE draft. The parenthetical '(not published, not visible)' clearly separates it from publish_draft and preview_draft, even though no sibling is named 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?

'Safe to call repeatedly' and 'creates the finn.no draft if needed' imply when to use it (iterative sync of local edits), but there is no explicit when-not guidance or pointer to publish_draft/create_draft/update_draft as the alternative for other flows.

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?

No annotations are provided, so the description must disclose behavioral traits. It only says 'persist', implying a write operation, but lacks details about side effects, permissions, rate limits, or what the response contains. This is inadequate for a mutation tool.

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 description is very concise (one sentence), but it sacrifices necessary detail. It is front-loaded with purpose but lacks parameter explanations and behavioral context, making it underspecified.

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 the complexity (4 parameters, 3 required, write operation) and the presence of an output schema, the description should at least explain parameter roles. It does not, leaving significant gaps in understanding. The description is minimally adequate for a simple tool but insufficient for its actual complexity.

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 0%, and the description adds no information about any of the 4 parameters (name, query, filters, vertical). The schema provides types and enums, but the description fails to explain their meaning or usage, leaving the agent without guidance.

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 clearly states the tool persists a named search for repeated monitoring via check_saved_search. It uses specific verb 'persist' and resource 'named search', and distinguishes its purpose from siblings like list_saved_searches or delete_saved_search.

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?

The description explicitly states that this tool is for repeated monitoring via check_saved_search, providing clear usage context. However, it does not explicitly mention when not to use it or list alternatives beyond check_saved_search.

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 no annotations, the description carries full burden. It discloses return behavior (up to ~50 SearchResult entries, empty list valid), unsupported backend (cars_new), and extra URL-query parameters for filters. This is thorough for behavioral expectations.

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?

Description is extremely concise: two short paragraphs front-loading the purpose, then details on parameters and return behavior. No redundant sentences; every line adds 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?

Given the tool complexity (4 params, output schema), the description covers essentials: verticals, query, filters, return limits, and unsupported items. Missing page parameter explanation is minor, and output schema details are not needed since it exists separately. Adequate for informed use.

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 0%, so description must compensate. It adds meaning to vertical (expands enum with descriptions), query (free-text), and filters (dict example). However, it omits the 'page' parameter entirely. Thus partial coverage, baseline 3.

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 clearly states 'Search finn.no within a vertical', specifying the verb (search) and resource (finn.no within a vertical). It lists all vertical options (bap, homes, lettings, etc.) and distinguishes from sibling tools (get_listing, save_search, etc.) which have different purposes.

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?

The description implies usage through naming and vertical specification, but does not explicitly state when to use this tool vs. alternatives (e.g., 'use for general search; use get_listing for a single item'). No exclusions or when-not-to-use guidance is provided.

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?

No annotations exist, so the description carries the full burden. It usefully discloses that the suggestion is derived from previously uploaded photos and depends on push_draft having run, but says nothing about whether the call is read-only, whether it can fail when no photos exist, or any cost/latency.

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?

A single short sentence with the prerequisite front-loaded alongside the purpose; every clause earns its place and nothing is padded.

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?

An output schema exists so return values need not be explained, and the one required parameter plus the push_draft dependency are covered. What remains missing is failure/no-photo behavior, but the definition is adequate to call the tool correctly.

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

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

Only one parameter (draft_id) with 0% schema description coverage. The description implies the id refers to a draft that has already been pushed with photos, adding indirect meaning, but never states the expected format or where to obtain the id.

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 (suggests) and resource (category) plus the data source (the draft's uploaded photos), which distinguishes it from suggest_price. It stops short of explicitly contrasting itself with that sibling, but the purpose is unmistakable.

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?

The parenthetical '(needs push_draft first)' is an explicit prerequisite that tells the agent the correct call order relative to a sibling. No when-not-to-use guidance or alternative suggestions are given, so it falls short of a 5.

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

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

With no annotations, the description does real work: it discloses the statistical method (median), outlier handling (IQR), rounding, and that representative `examples` come back and should be surfaced to the user. It omits failure behaviour — e.g. what happens when too few comparables exist — which matters for a price estimate.

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: method first, then default-usage rule, then parameter naming guidance, then output handling. The line break layout is slightly noisy but every sentence adds 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?

An output schema exists, so return values need no explanation, and the description still usefully flags `examples` as a field to show. The main gap is the undocumented `condition` parameter and unstated behaviour when no comparable ads are found.

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 0%, so the description must carry all parameter meaning. It compensates well for `query` by defining it as short brand+model search words with a concrete example, but `condition` (the 1-5 enum) is never mentioned, leaving half the parameters undocumented.

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 with its exact derivation method ("median of comparable 'Til salgs' ads on finn.no Torget"), which no sibling tool offers. It is clearly distinguishable from suggest_category and the search tools.

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?

"Default price source whenever the user did not name a price" gives an explicit selection rule an agent can act on. It stops short of naming an alternative tool or stating when not to call it (e.g. category mismatch), so it is not full when/when-not coverage.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only says fields are changed. It does not disclose permissions, error behavior, whether existing unspecified fields are preserved, or any side effects beyond local draft mutation.

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 definition is a single front-loaded sentence with an embedded example, and no sentence is wasted. It is appropriately sized for a short mutation tool.

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?

This is a mutation tool with no annotations, low parameter documentation, and nested object input. Although an output schema exists and reduces the need to describe return values, the description remains too thin about valid draft IDs, allowed changes, and mutation behavior.

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 0%, and the description only partially compensates by showing one example object for "changes". It does not describe allowed keys or value constraints, and it says nothing meaningful about "draft_id" beyond the parameter name.

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 uses a specific verb ("Change fields") and resource ("local draft"), and the inline example clarifies the kind of payload involved. It does not explicitly distinguish itself from siblings such as create_draft, publish_draft, or preview_draft, so it stops short of full clarity.

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 no guidance on when to use this tool versus alternatives like create_draft, publish_draft, push_draft, or preview_draft. There are also no stated preconditions, exclusions, or workflow context.

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