Storskarvia

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered, and the description adds a genuinely useful behavioral fact: ownership is enforced and a foreign check_id raises an error instead of leaking data. It does not describe pagination or result-size 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?

Very short and front-loaded, leading with what the tool returns and following with the ownership constraint. The awkward line wrapping aside, every sentence carries 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 not be explained, and the description covers the read-only nature plus the ownership/error constraint. The main gap is the absence of any pointer to how a check_id is obtained relative to prepare_factcheck or submit_findings.

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% for the single check_id integer, so the description must carry the load. It does add that check_id must belong to the authenticated user or an error is raised, which is real semantic value, but it never says where check_id originates or what form it takes.

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

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

The description names the resource (findings) and scopes it to one of the authenticated user's fact-check or continuity runs, which is specific enough to separate it from the write-oriented sibling submit_findings. It lacks an explicit verb ('Retrieve'), relying on 'Findings for...' to imply 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?

There is no statement of when to use this tool versus alternatives such as submit_findings or ground_claim, and no prerequisite context (e.g., where a valid check_id comes from). The only conditional given is the ownership error case.

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=true and openWorldHint=false, so safety and scope are covered structurally. The description adds useful context by naming the return payload ('Summary and URL') and the slug-validity precondition, but with an output schema present the return details are largely duplicative, so this sits at a solid baseline rather than above it.

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 what is returned, with the prerequisite second. Nothing is wasted, though the description is terse enough that it leaves gaps rather than being optimally structured for a lookup 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?

Output schema exists so return values need not be re-explained, and the required slug prerequisite chain is stated. For a single-parameter read tool this is nearly complete; the only missing element is what happens on an invalid or unknown slug.

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% for the single parameter, so the description must carry the load. It does reinforce that the parameter is a slug used for lookup and that it must come from list_guides, which adds meaning about valid values, but it gives no syntax, format, or case-sensitivity 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?

Specific verb+resource: retrieves 'Summary and URL for one guide', with the lookup key ('slug') called out. The word 'one' plus the lookup mechanism cleanly distinguishes it from the sibling list_guides, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite and the alternative path: 'Call list_guides first to get valid slugs.' That is clear when-to-use guidance with a named source of valid inputs, though it stops short of stating when NOT to use 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 declare readOnlyHint=true and openWorldHint=false. The description does add real behavioral context beyond that: the data is generated from config.PLANS, is live rather than hand-maintained, and includes the founder/founding-seat block that other surfaces offer. That context is useful, but it arrives wrapped in historical narrative rather than stated as a guarantee about freshness or scope.

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?

Only the first sentence is front-loaded with what the tool returns; the remaining two paragraphs are an internal post-mortem about past drift and historical pricing mistakes. That backstory, while motivating, does not help an agent decide to call or not call the tool and consumes most of the description.

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 read-only annotation covers safety. What is missing is any operational framing (e.g., that this is the authoritative answer for cost questions and that no freshness check is needed), which the description gestures at only indirectly.

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 nothing for the description to disambiguate and the baseline of 4 applies. The description correctly describes no arguments, only output content.

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 sentence names a specific resource (pricing tiers, features, monthly fact-check quotas) that an agent can match to a cost question. It does not, however, distinguish itself from adjacent siblings such as get_skarvia_info or get_guide, so the boundary is left to inference.

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, via the closing anecdote that an agent asked what Storskarvia costs should not answer from stale prose. There is no explicit 'use this when X, otherwise use Y' and no sibling is named as an alternative for general company questions.

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 provide readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds no behavioral traits beyond that—its content describes the product domain (AI writing studio) rather than how the tool behaves, returns data, or any constraints like auth or rate limits.

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 sentences with no wasted words and front-loads the tool's purpose. The first sentence is slightly fragmented but effective as a heading, and the second elaborates efficiently.

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 no parameters, a rich output schema, and annotations covering safety, the description need only convey the tool's scope. It does so adequately, though it omits usage guidance compared to siblings, which is a minor 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?

There are zero parameters, so the baseline is 4 per the rubric. The description adds no parameter information, which is appropriate since none exist.

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

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

The description names the specific resource (Storskarvia) and its content (what it is and how it's positioned), and distinguishes it from siblings like get_guide and list_features. However, it uses a noun phrase rather than a clear verb like 'returns' or 'gets', so it's not maximally explicit.

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 guidance is given on when to use this tool versus alternatives such as get_guide or list_features. The description only states what the tool is about, leaving context and exclusions 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the retrieval backends (Wikipedia + searxng), the fact that it returns sources without a verdict, and a real auth constraint: it requires a personal Storskarvia API key as a Bearer token and is not an open retrieval API. That is exactly the kind of context an agent cannot get from structured fields.

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 step and purpose, then adds constraints and auth. Three short sentences with no filler, though the parenthetical backend list and auth aside could be tightened slightly.

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 detailed, and the description confirms it returns sources. Auth requirements and behavioral boundaries are covered. Minor gap: no guidance on claim input constraints or on handling empty/insufficient retrieval results.

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

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

There is one parameter, 'claim', with 0% schema description coverage. The description implies the one-claim-at-a-time granularity ('for one claim'), which adds some meaning, but says nothing about expected format, length limits, or whether multiple claims can be passed. Adequate but thin for a zero-coverage schema.

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

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

States a specific verb and resource ('Runs ... server-side retrieval ... for one claim and returns the sources') and places itself precisely in the pipeline as 'Step 2' of the fact-check, which separates it from prepare_factcheck and submit_findings. It also explicitly declares what it does not do ('no verdict, no judgment'), removing ambiguity about its role.

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 clear operational context: use during the bring-your-own-agent fact-check flow and judge the claim ONLY against the returned sources, never outside knowledge. It stops short of naming the sibling tools or stating the precondition that the claim must first be prepared, which is left to be inferred from 'Step 2'.

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=true and openWorldHint=false, so the safe-read profile is covered. The description usefully discloses the data source (the 'On staff' section of the current landing page), which hints at staleness/static content, but says nothing about caching, completeness, or scope.

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 content and then the provenance. No filler, though the second line is arguably implied and the first lacks an action verb.

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 read tool with an output schema and covering annotations, the description supplies what the agent needs: what data comes back and where it is sourced from. Return values need not be described given the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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 names the content returned (the AI staff on Storskarvia and each member's role) but gives no verb, so it reads as a data label rather than an action. It also does not distinguish this from sibling tools like get_skarvia_info or get_guide, and the name 'list_features' versus 'staff' adds mild ambiguity.

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 statement of when to use this tool, when not to, or which sibling covers overlapping information. The agent must infer usage purely from the returned content.

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 safe-read profile (readOnlyHint=true), but the description adds genuinely useful behavioral context: the data is read live from app.main and cannot drift from what is published at /guides, which tells the agent the results are authoritative and fresh. It does not mention result size or pagination, but the added freshness guarantee is meaningful beyond the annotations.

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

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

The payload information (what fields come back, live/fresh data) is front-loaded, which is good. However, the parenthetical about a lazy import and a comment on the import below is internal implementation detail that adds no decision value for an invoking agent and dilutes the signal.

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 an output schema present, return-value detail need not be in the description, and the description correctly focuses on provenance and freshness instead. For a zero-parameter read tool this is nearly complete; only the sibling-routing guidance is thin.

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 per the rubric the baseline is 4; there is no parameter syntax for the description to explain and none is 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?

The first sentence states a specific resource (Storskarvia's evergreen craft/how-to guides) and the exact fields returned (titles, slugs, URLs), so an agent knows this is a metadata listing rather than full content. It does not explicitly contrast itself with get_guide (single-guide retrieval), but the 'list' semantics plus returned fields make the distinction inferable.

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 by the verb 'list' and the field inventory; there is no statement of when to choose this over get_guide or get_findings, and no exclusions or prerequisites. Adequate but leaves the agent to infer the routing decision.

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=true and openWorldHint=false, so the safety profile is covered. The description adds a non-obvious operational requirement — a personal Storskarvia API key as a Bearer token — and clarifies the data is scoped to the authenticated user's own projects, which the annotations do not convey. No rate limits or empty-result behavior are 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?

Three sentences, front-loaded with purpose, then return detail, then the auth constraint. Every sentence carries weight, though the return-structure detail is somewhat redundant given an output schema exists.

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, read-only list with a full output schema, this is complete: what is returned, whose data, the ordering, the downstream consumer of the ids, and the auth requirement. An agent has everything needed to call it correctly.

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

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

The tool takes no parameters, so per the baseline this scores 4. The description correctly adds no parameter noise, keeping the schema as the single source of truth for invocation arguments.

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 (list) and resource (authenticated user's Storskarvia projects), and concretizes the resource with examples (novels, screenplays, video scripts). It also specifies the return shape — id, title, binder folder in binder order — so the agent can distinguish it from the sibling list_guides/list_features 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?

Explicitly links output to workflow: 'A document id is what prepare_factcheck and submit_findings take', telling the agent this is the precursor for those tools. It gives clear context but no when-not guidance or explicit mention of the sibling list tools as alternatives.

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=true and openWorldHint=false, so safety is covered. The description adds meaningful non-schema context: document ownership is enforced, a personal API key bearer token is mandatory, and the response carries a mandated 'disclosure and method' the agent must follow. It does not describe failure modes (e.g. non-owned document, missing key) or rate limits.

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 workflow role, then returns, then auth, then next steps. Two tight paragraphs with no filler, though the formatting is slightly broken by the indentation and mid-sentence line break.

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 described, and the workflow with sibling tools is fully mapped. The remaining gap is the single required parameter, whose semantics are only partially covered by the description.

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 there is one undocumented parameter, so the description must compensate. It adds that the document must be one the authenticated user owns ('ownership enforced'), which is real semantic content, but gives no guidance on ID format or source. Adequate but incomplete.

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 ('fetches one of the authenticated user's documents') and situates it precisely as 'Step 1 of a bring-your-own-agent fact-check.' An agent can immediately distinguish it from siblings like ground_claim, submit_findings, and get_findings, which are named as downstream steps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly sequences the workflow: after this, call ground_claim(claim) once per checkable claim, then submit_findings(...). It also states the required context ('Requires a personal Storskarvia API key as a Bearer token'). It does not spell out when NOT to use it or what to do if the bearer token is missing, so it falls just short of 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?

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false): it discloses the Bearer-token auth requirement, enforced document_id ownership, a ToolError on non-verbatim disclosure, and wholesale rejection with 'nothing partial is stored'. These are exactly the failure modes an agent needs to know before invoking.

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

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

Front-loads purpose and workflow position before the precondition and validation details, and every sentence earns its place. It is slightly long, but no clause is redundant given the low schema coverage.

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 an output schema present, return values need not be explained; what remains — auth, ownership enforcement, precondition, per-item validation, atomicity — is fully covered. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 0% and the findings array is an opaque object, so the description carries the full burden — and does so: disclosure must be REQUIRED_DISCLOSURE verbatim, each finding needs a non-empty quote/explanation, a problem in {contradicted, misleading}, and a non-empty sources list. This is more than the schema conveys.

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 ('Stores your agent's findings as a real Storskarvia Check') and situates it as step 3 of a bring-your-own-agent fact-check. This clearly separates it from the read-oriented sibling get_findings and from prepare_factcheck.

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 'Step 3 of a bring-your-own-agent fact-check' framing tells the agent when in the workflow to call it, and it names prepare_factcheck-adjacent context implicitly. It does not explicitly name an alternative tool or state when not to use it, keeping it 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.