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

No annotations are provided, so the description carries the full disclosure burden. It does that meaningfully by stating deterministic output, SHA-256 hashing, and the critical fact that nothing is uploaded or published. It omits some edge-case behavior, but the core behavioral profile is clear and safety-relevant.

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

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

Two sentences with no filler. The core action and output are front-loaded, and the side-effect disclaimer is cleanly separated. Every word earns its place.

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 four parameters including a nested object, no annotations, and no output schema, yet the description does not explain return values, destinations, rootDir behavior, or how include/exclude rules are interpreted. An agent would need to infer too much to invoke it correctly on the first attempt.

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 for the schema's silence. It mentions include/exclude rules but gives no semantics for rootDir, no pattern syntax for include/exclude entries, and no explanation of the destinations object. Four parameters remain effectively undocumented from the agent's perspective.

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

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

The description names a specific verb ('Build') and resource ('deterministic repository-independent SHA-256 manifest'), and its side-effect disclaimer ('Never uploads or publishes files') clearly differentiates it from siblings like upload_file and publish_draft. The agent can tell what this tool is for without inspecting 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?

The 'Never uploads or publishes files' clause gives useful routing context and implies this is a local, side-effect-free preparation step. However, it does not explicitly state when to prefer this tool over build_publication_package or other alternatives, nor does it describe preconditions.

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 of behavioral disclosure. It usefully states 'Never writes to a repository,' which is a strong side-effect guarantee, but it does not disclose what the tool returns, whether it reads from the filesystem, or how it handles errors or missing files.

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 brief sentences with no filler. The core action and the key side-effect constraint are front-loaded, making the description easy to scan and process.

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 five parameters, no output schema, no annotations, and multiple siblings, yet the description provides minimal workflow context. It does not explain the return value, how to structure metadata, or how destinations are used, leaving substantial gaps for an agent deciding to invoke it.

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 the parameters, but it only vaguely gestures at 'metadata' and 'file manifest.' It does not explain rootDir, include, exclude, or destinations, leaving an agent to guess their roles despite five parameters and nested objects.

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

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

The description names a specific action ('Build') and a concrete deliverable ('canonical metadata + file manifest') plus a distinguishing output ('package SHA-256 identity'). It is clear enough to differentiate from sibling tools like build_file_manifest, though it does not explicitly call out that distinction.

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 no guidance about when to use this tool versus siblings such as build_file_manifest, create_draft, or validate_deposition. 'Never writes to a repository' is a behavioral constraint, not a usage guideline, and there is no mention of prerequisites or workflow context.

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 is responsible for behavioral disclosure. It does add useful detail: metadata validation happens, the result is an unpublished draft rather than a published record, and the default environment is Zenodo Sandbox. However, it does not disclose permissions, error behavior, or what the operation returns.

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 no filler. The primary action is front-loaded, and the default backend is stated as a separate, useful second sentence. Every word earns its place.

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 simple one-parameter tool, but with no output schema or annotations, the description leaves gaps: it does not mention the return value, how the draft is referenced later, or how it fits into the workflow with upload_file and publish_draft. It is minimally viable but not 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?

The schema shows a required 'metadata' property with no description, and schema description coverage is 0%. The description names metadata and says it is validated, but does not explain the expected structure, required fields, or format, so it fails to compensate for the empty 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 identifies the action ('create') and resource ('unpublished repository draft'), and mentions an additional validation step. This differentiates it from siblings like get_draft, update_draft, and publish_draft by verb and state, though it does not explicitly name an alternative tool.

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

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

There is no explicit guidance on when to use this tool versus validate_deposition, update_draft, or publish_draft. The default-backend note gives environment context but does not explain prerequisites, sequencing, or when not to use the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one useful trait: 'Does not expose secrets', which is a safety note. However, it does not mention whether the operation is read-only, any performance implications, or what the report contains beyond the generic phrase. The note is a positive, but coverage 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?

The description is a single, concise sentence that front-loads the primary action and resource. It avoids redundancy and every word adds value, including the secret-safety caveat. It is appropriately sized for the tool's simplicity.

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's low complexity (no parameters, no output schema), the description covers the essential purpose and a key safety behavior. It could potentially elaborate on what 'safety configuration' includes or how the report is used in a workflow, but for a status query it is largely sufficient. The lack of output schema means the description should hint at the return value, which it does implicitly by stating what it reports.

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 has zero parameters, so the schema already provides complete coverage (100%). The description does not need to add parameter details since none exist. The baseline for 0 parameters is 4, and no deduction is warranted because there is nothing to describe.

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 clear verb 'Report' and a specific resource 'deposition backend and safety configuration'. It distinguishes itself from sibling tools like validate_deposition, build_file_manifest, etc., which focus on actions, whereas this one is a status query. The purpose is unambiguous.

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 use this tool versus alternatives. It does not mention scenarios where it should be called, such as before validation or publication, nor does it state when not to use it. The description simply describes the function without contextualizing its role among 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 full burden of behavioral disclosure. 'Retrieve' implies a read-only operation, but the description does not state whether the result is the full draft, what happens for missing IDs, or whether any side effects or permissions are involved. This is minimal coverage for a tool with no annotation safety hints.

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, well-formed sentence with no redundant words. It front-loads the core action and object, making it easy for an agent to scan and understand quickly.

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 simple one-parameter retrieval tool, the description is minimally viable: the agent knows the action, the resource, and the existence condition. However, with no output schema and no annotations, it leaves room for ambiguity about the return payload and does not help an agent choose this tool over related read-oriented siblings.

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 has a single required 'id' parameter with zero description coverage, and the tool description does not explicitly explain what 'id' refers to beyond the inferred draft ID. The only added semantic is that the draft must be 'existing,' which is too thin to compensate for the missing parameter documentation.

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 the specific verb 'Retrieve' and names the resource, an existing unpublished deposition draft. This clearly distinguishes it from create_draft, update_draft, and publish_draft, though it does not explicitly contrast it with deposition_status or other read-adjacent siblings.

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 about when to use this tool versus siblings like validate_deposition, publication_review, or deposition_status. The phrase 'existing unpublished' hints at when the draft is retrievable, but there is no explicit when-to-use or when-not-to-use instruction.

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 it does disclose the key non-publishing behavior plus the out-of-band approval flow. However, it does not state whether the tool is fully read-only, what side effects 'rebuild' might have, or any permission requirements.

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

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

Two sentences with no filler; the primary action is front-loaded and the critical 'Does not publish' constraint is its own sentence. Every part earns its place.

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 tool with 6 parameters, nested objects, no output schema, and no annotations, this description is too sparse. It does not describe the approval request return format, the meaning of metadata/destinations, or any prerequisites, leaving significant gaps for correct invocation.

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

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

Schema description coverage is 0%, yet the description only hints that id relates to the draft and that metadata/rootDir/include contribute to 'package identity'. It does not explain exclude, destinations, or metadata semantics, so the agent cannot reliably map parameters to their roles.

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 concrete actions ('rebuild the exact package identity', 'retrieve the draft', 'return the approval request') and explicitly states what it does not do ('Does not publish'). This clearly separates it from sibling publish_draft and makes its role obvious.

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 clear context: this is for obtaining an out-of-band human approval request before publishing. The phrase 'Does not publish' acts as a when-not, though it does not explicitly name an alternative such as publish_draft.

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. It discloses that publication is gated by process-level enablement and a valid receipt matching recomputed data, which is behavioral, but it does not describe the effect of the action, return value, error behavior, or side effects. Significant gaps remain.

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, concise sentence that front-loads the critical condition. It is efficient and not verbose, though it is dense and may reduce readability. Still, it earns its place with 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?

For a tool with 7 parameters, including nested objects (metadata, destinations), and no output schema, the description is grossly inadequate. It only states preconditions and leaves agents to guess parameter meanings, return values, and error handling. This is far below the minimum needed for a complex mutation 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 description coverage is 0%, and the description does not explain any of the 7 parameters. It mentions 'receipt' and 'draft' conceptually but does not map them to the schema properties (id, receipt, metadata, rootDir, include, etc.). The description fails to compensate for the lack of schema documentation.

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 the verb 'Publish' and implies the resource (draft) via the tool name. It adds a specific conditional context that distinguishes it from sibling tools like create_draft or update_draft, but it does not explicitly name the resource in the description 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 ('Publish only when...') which implies when it should be used, but it does not mention alternatives, exclusions, or when not to use it. The condition is useful but lacks explicit routing to sibling tools.

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 provided, the description carries the full burden of behavioral disclosure. It says the operation validates and replaces metadata, but it does not explain whether replacement is partial or full, what happens if validation fails, whether the operation is reversible, or what the response will contain. This is a significant gap 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 a single focused sentence that front-loads the primary action and resource scope. Every word carries meaning, and there is no repetition or 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?

Given no annotations, no output schema, and 0% parameter description coverage, the description is too sparse. An agent would not know the expected metadata shape, validation behavior, error conditions, or what the tool returns after success.

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 by explaining the parameters. It gives some context by indicating that 'metadata' is replaced and 'id' refers to an existing draft, but it does not define the metadata object structure, validation rules, or any id semantics beyond a required string. The meaning added over the bare schema is 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?

The description clearly states the action ('Validate and replace metadata') and the target resource ('an existing unpublished draft'). It distinguishes itself from creation (create_draft), retrieval (get_draft), and publication (publish_draft), though it does not explicitly name a sibling or draw out the difference from validate_deposition.

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 phrase 'existing unpublished draft' implies it should be used for already-created, not-yet-published drafts, giving some contextual guidance. However, there is no explicit statement of when to choose this tool over validate_deposition or publish_draft, and no excluded use cases are listed.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose a key behavioral trait: the operation never publishes the draft, which is valuable. However, it doesn't mention whether the upload is additive, whether it replaces existing files, whether it requires authentication, or what happens if the draft is already published. The single behavioral guarantee is helpful but incomplete for a mutation-like operation.

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 no filler. The key action and the critical non-behavior (never publishes) are front-loaded. Every word earns its place.

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 tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. An agent needs to know what 'id' refers to, whether the file is added or replaces existing content, and what the result of the upload is. The sibling tools suggest a draft workflow, but the description doesn't connect to that workflow explicitly. The 'never publishes' note is good, but overall the description leaves too much to inference.

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 for the three parameters. It does not explain what 'id' refers to (presumably the draft ID), what 'filePath' means (local path vs. remote path), or what 'remoteName' does. The description only mentions 'local file' and 'existing draft,' which partially maps to filePath and id, but remoteName is entirely unexplained. This is 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 clearly states the action ('Upload a local file') and the target resource ('an existing draft'), and distinguishes it from publishing by explicitly saying 'Never publishes the draft.' This is a specific verb+resource pairing that an agent can act on. It doesn't explicitly name a sibling alternative, but the contrast with publish_draft is implicit and clear.

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 the tool is for adding files to a draft, and the explicit 'Never publishes the draft' provides a useful exclusion. However, it doesn't state when to use this tool versus alternatives like build_file_manifest or update_draft, nor does it mention prerequisites like the draft needing to exist or the file path being accessible. Usage context is implied but not fully specified.

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 behavioral burden. It discloses two meaningful traits: the validation is 'deterministic' and it 'never publishes anything.' These provide clear side-effect expectations, though it does not explicitly state whether the tool is fully read-only or what the response 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?

Two short sentences with no filler. The core purpose is front-loaded and the crucial safety qualifier ('Never publishes anything') is clearly separated. Every word earns its place.

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 tool with no annotations, no output schema, and an undocumented parameter, the description is incomplete. It does not explain how to construct the metadata argument or what kind of result is returned (boolean, error list, etc.). The description covers intent and side effects but leaves the agent guessing about invocation and response.

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 has 0% description coverage and the single required parameter is just named 'metadata' with no type or structure. The description adds context that it is 'research deposition metadata' and 'repository-independent,' but it does not specify the expected structure, required fields, or format. This does not sufficiently compensate for the schema 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 uses a specific verb ('validate') and a well-defined resource ('repository-independent research deposition metadata'), and the phrase 'Never publishes anything' distinguishes it from sibling tools like publish_draft and create_draft. An agent can clearly tell what this tool does and what it is not.

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 safe pre-publication usage by stating 'Never publishes anything,' but it does not explicitly say when to call this tool (e.g., before publish_draft) or how it relates to alternatives like publication_review. No positive usage instruction is given, only a negative exclusion.

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