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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool appends a section from stored sources, with no mention of whether an existing bibliography is replaced, the output format, required permissions, or failure 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?

The description is a single, front-loaded sentence with no filler words. The primary action and object are immediately clear.

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 five parameters, no annotations, and zero parameter descriptions, the description is too sparse. It does not explain the required path, how the stored sources are used, or how mode/out affect the operation.

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 explanation for path, mode, style, heading, or out. An agent cannot infer the meaning or role of these parameters from the description, despite the self-explanatory names and defaults.

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, 'Append', and a clear resource, 'References / Works Cited section', while noting it is 'built from the stored sources.' This clearly distinguishes it from sibling tools like add_citation and add_footnote.

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 when to use the tool: after sources have been stored, to append a bibliography section. However, it does not explicitly state when to prefer this over import_references or add_citation, nor does it provide 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 the transparency burden. It is clear that the tool appends an in-text citation and that chicago-notes renders it as a footnote, but it does not disclose other behavioral details such as mutation effects, idempotency, or failure conditions.

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: a direct action sentence followed by one conditional clarification. No filler words or repeated schema details.

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 8 parameters, 3 required, and no annotations, this description is not complete enough for an agent to invoke the tool correctly without guessing the meanings of `path` and `paragraph_index`. The output schema exists, so return values need not be explained, but invocation essentials are missing.

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

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

Schema description coverage is 0%, and the description only adds meaning for `tag` and `style`. Required parameters like `path` and `paragraph_index` and optional ones like `mode`, `page`, `prefix`, and `out` receive no semantic explanation.

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 'Append' with the resource 'in-text citation for `tag` to a paragraph', making the core purpose clear. The chicago-notes nuance adds precision, though it does not explicitly distinguish it from add_footnote.

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 siblings like add_footnote or add_source. The chicago-notes line hints at footnote behavior but does not tell the agent how to choose between add_citation and add_footnote.

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 behavioral burden. It discloses a meaningful side effect: 'Creates word/footnotes.xml and the FootnoteText/FootnoteReference styles on first use.' It also explains the conditional placement behavior for the anchor parameter, which adds transparency beyond the 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?

The description is compact and well-structured: a one-line summary, a conditional placement rule, and a single side-effect note. Every sentence carries useful information without padding or repetition.

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 description covers the core action and key side effects, but it does not fully explain the required parameters or the optional out parameter's role. Given five parameters, zero schema descriptions, and no annotations, the description is adequate but has clear gaps in making the tool fully self-explanatory.

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, but it only explains the anchor parameter's behavior. It does not clarify the semantics of path, paragraph_index, text, or out, leaving the agent to guess their meanings from parameter names alone.

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 opens with a specific verb and resource: 'Attach a footnote to a paragraph.' This clearly states the tool's operation and differentiates it from siblings like list_footnotes, add_source, and add_citation. The additional anchor-placement detail further specifies the exact behavior.

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 should be used when the agent needs to add a footnote to a paragraph, but it does not explicitly state when to prefer this over alternatives such as add_citation or add_source, nor does it mention any prerequisites or when not to use it. The usage context is inferred rather than directly guided.

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 of disclosure. It does reveal the upsert behavior ('Add or replace... matched by tag') and enumerates the accepted source fields and type values. It does not mention prerequisites, side effects on existing data beyond replacement, permissions, or failure 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?

The description is front-loaded with the core purpose and then compactly enumerates the source fields. It is somewhat dense as a run-on list, but it contains no filler or redundant 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?

The tool has no annotations, a mostly open source object, and siblings that overlap with reference management. The description fails to explain `path` and `out`, and does not help an agent choose between adding a source and importing references. The output schema exists, so return values are not the main gap, but invocation context is incomplete.

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 source object allows additional properties, so the description adds real value by listing all source fields and their formats. However, the required `path` parameter and optional `out` parameter are left completely unexplained, which is a significant gap for a tool with only three parameters.

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 verb ('Add or replace') and resource ('bibliography source'), and introduces the tag-matching semantics. It is distinct enough from remove_source and list_sources, though it does not explicitly name or differentiate sibling 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?

The description implies when to use the tool: you add or replace a source by tag. However, it gives no explicit guidance about when to prefer this over import_references, add_citation, or add_bibliography, nor any 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 the full burden of behavioral disclosure. It clearly states that a new .docx is created, but it does not disclose what happens if the file at 'path' already exists, whether parent directories are created, whether existing content is overwritten, or any permissions 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?

The description is a single, front-loaded sentence with no filler. It covers the core action, the resource type, the destination parameter, and the optional content parameters 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?

For a simple creation tool with an output schema and straightforward parameters, the description is mostly adequate. However, given no annotations and no usage guidance, it leaves out important contextual behavior around existing files and side effects, which an agent would need to invoke it safely.

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. It adds natural-language meaning by mapping 'path' to the destination of the .docx and 'title'/'body paragraphs' to the optional content parameters. However, it does not explain formatting expectations, paragraph semantics, or constraints beyond what the schema already exposes.

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 action ('Create'), a specific resource ('.docx'), and a location ('path'), which makes the tool's purpose immediately clear. It also distinguishes itself from sibling tools that deal with footnotes, sources, and citations rather than creating the document 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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as whether the document must not already exist, and no exclusions. The description tells the agent what the tool does but not when to choose it over related 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?

The verb 'List' suggests a read-only operation with no side effects, but the description does not explicitly state that it is non-destructive or that it does not modify the document. With no annotations provided, the description carries the full burden and falls short of explicit transparency.

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, compact sentence that conveys the essential action and output format without unnecessary words. It is well-structured and front-loads the primary purpose.

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 description provides the output format ({index, style, text}) and the intent, which partially covers context. However, it omits any explanation of the 'path' parameter and does not describe the output schema in detail, leaving some ambiguity for an agent unfamiliar with the 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?

The only parameter, 'path', has no description and the schema provides no coverage. The description does not clarify what 'path' refers to (e.g., file system path, document ID, or a path within a document structure), leaving the meaning ambiguous.

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's purpose: 'List every paragraph as {index, style, text} so you can target one.' This distinguishes it from sibling tools, which focus on footnotes, sources, citations, and document creation.

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 a use case ('so you can target one') but does not explicitly state when to choose this tool over siblings. It lacks guidance on context, such as 'use this before adding footnotes' or 'for read-only paragraph inspection.'

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 disclosure burden. It only states the import action and input formats; it does not describe whether existing sources are preserved, overwritten, or merged, nor what side effects or response the agent should expect.

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, front-loaded with the action, and contains no filler or redundant wording. It is concise, but the saved space could have been used to clarify the ambiguous `path` and `out` parameters.

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 four-parameter tool with no annotations and no parameter descriptions, this one-sentence description is not complete enough for reliable invocation. The required `path` parameter is especially ambiguous, and the description does not explain how the import interacts with existing references. The presence of an output schema helps return-value expectations, but the input contract remains underspecified.

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?

With 0% schema description coverage, the description needs to explain the parameters. It clarifies `fmt` ('bibtex'/'csl-json') and the nature of `data` (the source string), but it leaves the required `path` and optional `out` parameters completely unexplained, which is a major gap for correct invocation.

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 names the action ('Bulk-import sources') and specifies the resource and accepted formats (BibTeX or CSL-JSON), so an agent can tell this is a batch-import tool. It does not explicitly contrast it with the sibling `add_source`, though 'bulk' implies the 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 phrase 'Bulk-import' implies using this tool when there is a batch of references in BibTeX or CSL-JSON format, as opposed to adding a single source. However, it never explicitly says when to prefer this tool over `add_source` or whether it appends to or replaces existing references.

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. 'Return existing footnotes' does disclose the core behavioral trait — a read-only list operation with a defined return shape. However, nothing is said about empty-result behavior, invalid or missing path handling, ordering, or whether the result is scoped to the document at the given path.

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 six-word sentence with zero filler; the action and return format are front-loaded. Every word earns its place, and the structure is ideal for quick parsing.

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 is simple (one string parameter, no nested objects) and an output schema exists, so return values need no further explanation. The core purpose is stated, but the meaning of the required 'path' parameter is entirely undocumented and no usage guidance is provided, leaving a real gap 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% and the description never mentions the required 'path' parameter, so nothing compensates for the schema gap. An agent must guess whether 'path' refers to a document path, workspace location, or something else, making correct invocation uncertain.

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 ('Return') and resource ('existing footnotes') plus the output shape ({id, text}), which clearly signals a read/list operation. It implicitly contrasts with the sibling add_footnote via the word 'existing', but it never names an alternative explicitly, so it stops short of full sibling differentiation.

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

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

Usage context is only implied: if an agent needs existing footnotes, this tool returns them. There is no explicit when-to-use guidance, no stated exclusion, and no mention of alternatives such as list_sources or document_outline, leaving the selection reasoning to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'Return' implies a non-mutating read and 'all sources' states the scope, but the description does not mention permissions, ordering, pagination, or potential side effects. It is adequate for a simple read operation but not rich.

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 entire description is one short, front-loaded sentence with no wasted words. It states the action and scope immediately, which is ideal for quick agent scanning.

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 output schema likely covers return-value structure, so the description does not need that detail. However, the sole required parameter 'path' is left unexplained, and there is no guidance on when to invoke this tool beyond its obvious purpose, leaving a moderate completeness gap.

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

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

Schema description coverage is 0%, and the description does not explain the required 'path' parameter at all. While 'the document' hints at what path refers to, an agent cannot determine the expected path format, scope, or what exactly to pass.

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 ('Return') and resource ('all sources') with a clear scope ('stored in the document'), making its purpose unambiguous. It also distinguishes itself from sibling tools like add_source, remove_source, and list_footnotes by resource and operation type.

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 context is only implied: if an agent needs all sources, this is the obvious tool. However, there is no explicit guidance on when to prefer it over alternatives like import_references or list_footnotes, nor any stated exclusions or prerequisites.

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

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

The description explicitly says 'Delete', so the destructive nature is clear. However, with no annotations, the description carries the full burden and does not disclose permanence, side effects on other source-related data, or what happens if the tag does not exist.

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, front-loaded sentence with no filler; it is easy to parse. The brevity is effective but comes at the cost of omitting essential parameter context.

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 three parameters, two of which are required, and no annotation support, this description is too thin for an agent to invoke the tool correctly without guessing. The output schema covers return values, but the roles of 'path' and 'out' and the relationship between path and tag remain unexplained.

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 description gives a minimal role to 'tag' as the identifier, but it does not explain the required 'path' parameter or the optional 'out' parameter. Schema description coverage is 0%, and the schema itself only provides titles and types, so the description does not compensate for the missing parameter semantics.

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 ('Delete') and resource ('source') and identifies the tag as the selection mechanism. It clearly functions as the deletion counterpart to siblings like add_source and list_sources, though it does not define what a 'source' is or how it relates to the required 'path'.

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 about when to use this tool versus alternatives such as add_source, list_sources, or import_references. No prerequisites, conditions, or exclusions are mentioned; only the basic action is stated.

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