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

Annotations already cover the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description only needs to add context. 'Server-side ownership, connector trial, and failure semantics apply' gestures at entitlement and failure behavior without saying what those semantics actually are, which leaves the agent guessing about error modes for an open-world side-effecting call.

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 tight sentences with the action front-loaded and no filler. Nothing is wasted, though the brevity is arguably at the cost of the missing detail noted elsewhere.

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?

There is no output schema, so the description should say what comes back from a save versus an Obsidian handoff (confirmation, URL, item key). Instead it defers to a vague 'failure semantics apply' clause, leaving the return shape of an open-world write undefined.

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

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

Schema description coverage is 100%, so the schema already explains connector and doc_id. The description's Zotero/Obsidian split repeats what the connector enum description already states, and the optional 'vault' parameter is never mentioned. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Save one document to Zotero or open a metadata-only Obsidian handoff'), and the word 'one' implicitly separates it from the sibling conceptio_connectors_send_all. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

The dual-mode phrasing implies when each connector applies, but there is no explicit guidance on when to prefer this over conceptio_connectors_send_all, no prerequisites spelled out, and no exclusions. Usage must be inferred from the connector semantics.

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 the write/non-idempotent/open-world profile, and the description adds a genuinely new behavioral fact not in structured data: a paid-licence prerequisite with no free-trial fallback. It does not disclose duplicate-creation risk (idempotentHint=false) or partial-failure behavior on large batches, keeping it below 5.

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

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

Two short sentences, zero waste, with the core action front-loaded and the eligibility constraint immediately after. Every clause 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 simple two-parameter tool with no output schema, the essentials (what it does, who can use it) are covered. But a bulk mutation accepting up to 500 IDs should say something about duplicate handling or partial-save outcomes, which is exactly the gap left by idempotentHint=false and destructiveHint=false.

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

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

Schema coverage is 100%, so doc_ids range (1-500) and the single-value 'zotero' enum are already fully documented. The description's 'Bulk-save' and 'to Zotero' merely restate what the schema declares, adding no syntax, ordering, or ID-provenance detail. Baseline 3 applies.

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

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

Specific verb+resource+destination: 'Bulk-save selected documents to Zotero.' The word 'Bulk' implicitly distinguishes it from the sibling conceptio_connectors_send, but the sibling is never named, so the agent must infer the single-vs-many split.

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 hard gating condition ('Pro, institutional, or licensed access is required; no free trial path'), which is useful eligibility context. However, it never says when to choose this over conceptio_connectors_send, nor what to do when access is absent — usage is only implied by the word 'Bulk'.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false; the description resolves the most confusing part of that profile by clarifying that the write is to a local file path, and adds the real constraint that only open-access originals can be fetched. It stops short of covering overwrite behavior for an existing output file or failure modes on network errors.

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, front-loaded with the action and resource, second sentence covering the accepted input forms. No filler or restated title matter.

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

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

With no output schema, the description adequately conveys the effect (a file written to the given local path) and the two accepted input forms. A brief note on what is returned (e.g., saved path or success confirmation) and overwrite behavior would close the remaining gap for a tool with openWorldHint=true.

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

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

Schema description coverage is 100%, so both parameters (doc_id_or_url, output_path) are already documented in the schema, and the description roughly restates that an ID or URL is accepted. It adds the provenance hint that the ID comes from conceptio_search, but nothing about path semantics or ID format beyond the schema.

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

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

States a specific verb (download) and resource (the original open-access PDF of a paper, standard, or book) plus the destination (a local file path). An agent can tell this apart from read-only siblings like conceptio_get_document, though the differentiation is implicit rather than stated.

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

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

The description implies when to use it by naming the input sources — a Conceptio document ID 'from conceptio_search' or a direct PDF URL — which hints at a search-then-download flow. It gives no explicit when-not conditions or alternatives, and doesn't say what to do if the paper is not open-access.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint false-destructive, so the safety profile is covered. The description adds nothing beyond that: it does not mention whether the citation is derived locally or fetched externally (relevant given openWorldHint=true), nor what happens with missing metadata.

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

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

One short, front-loaded sentence with no filler. The only inefficiency is the partial format enumeration, which consumes space while understating the actual enum.

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?

A simple read-only, two-parameter tool with a fully documented schema and no output schema, so the description need not explain return values. The remaining gap is the untold story of the extra formats and of what happens when citation data 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?

Schema coverage is 100% and the enum parameter is fully documented in the schema, so baseline 3 applies. The description does add the practical framing of which formats exist, but it lists only four of the eleven supported formats, which could mislead an agent into assuming those are the only options.

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 ('Get') and resource ('academic citation') tied to a document, and names the output formats. It is distinguishable from siblings like conceptio_get_document or conceptio_search by the citation-rendering angle, though it never explicitly contrasts with them.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as conceptio_get_document when metadata rather than a formatted citation is wanted. Usage is only inferable from the name and the doc_id parameter.

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, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds value by specifying the returned field set, which helps distinguish it from the download sibling, but says nothing about behavior on an invalid/unknown ID or any 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?

A single front-loaded sentence with the verb and resource first and the payload enumerated after; every word earns its place and nothing is padded.

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

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

There is no output schema, but the description compensates by listing the metadata fields returned, which is the key thing an agent needs. Minor gaps remain around failure behavior for a bad ID, but nothing essential to calling it 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?

Only one parameter with 100% schema description coverage, so the schema carries the semantics. The description only restates 'document ID' and adds no hint about where the ID comes from (e.g., a prior search result), so baseline 3 is correct.

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 ('Fetch') and resource ('complete metadata') and enumerates exactly what comes back (title, author, source, license, description, direct PDF URL). It does not distinguish itself from siblings like conceptio_search or conceptio_download_pdf, which is the only gap.

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?

'for a document ID' implicitly signals the tool applies when an ID is already known (as opposed to search), but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer the boundary against conceptio_search and conceptio_download_pdf on its own.

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 state readOnly and idempotent behavior, and the description adds useful context beyond them: the walk is metadata-only and spends no credits, and dangling targets appear as claimed nodes. It also explains the shape of returned nodes and edges, though it does not discuss rate limits or auth.

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 action and remains dense without obvious filler. A few phrases like 'the compliance walk' add flavor but do not obstruct selection.

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?

There is no output schema, but the description sufficiently explains that results include nodes with distances and canonical edges with relation kinds. It also covers the dangling-target case, leaving only minor edge cases like pagination unspecified.

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

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

Schema coverage is 100%, so parameter meaning is already well documented. The description reinforces direction and kind filtering but mostly restates what the schema provides, making the baseline 3 appropriate.

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

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

The description uses a specific verb and resource: walk the reference graph from a seed source_id. It distinguishes the operation from keyword search and names the provenance use case, so an agent can select it confidently over siblings like conceptio_search.

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

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

It explicitly says when to use the tool: when an agent needs provenance, such as finding what cites a regulation two hops out. It also contrasts this directly with keyword search, giving a clear alternative path.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds genuinely new behavior: unrecognized identifiers silently degrade to a text search, which an agent needs to know to interpret results correctly. It does not mention rate limits, auth, or what the returned documents look 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?

The verb and resource lead, and the long enumerations are load-bearing because they define what 'recognized' means. The format list could be compressed (e.g. grouped by ID family), but nothing is redundant.

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

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

For a two-parameter read-only lookup with full schema coverage and annotations, the description covers the identifier vocabulary, the failure mode, and the precision intent. It leaves the return shape (single document vs. ranked list) and behavior when one citation matches multiple documents unspecified, and no output schema exists to fill that in.

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

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

Schema coverage is 100% so the baseline is 3, but the description earns extra credit by illustrating the accepted id syntaxes (RFC, doi:, arXiv, PMID, PMC, NIST/FIPS, W3C shortname, US legal citation/docket) far beyond the schema's two examples. It says nothing about how limit interacts with ambiguous identifiers, which is the remaining 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?

States a specific verb ('Resolve') and a specific resource ('known identifier' to 'document(s) in the archive'), then enumerates the identifier families it accepts. This is clearly distinguishable from conceptio_search, whose job is free-text lookup rather than exact citation resolution.

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 says when to reach for it ('when an agent has a concrete citation/reference it wants to locate precisely') and notes the fallback path for unrecognized identifiers. It stops short of naming conceptio_search as the alternative for vague queries, so the routing is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds two things annotations cannot convey: the auth requirement and the license-aware access model, which tells the agent results carry rights constraints rather than being freely reusable.

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 the scope statement followed by the blocking prerequisite and the query syntax example. No filler, though the query directive example is redundant with the schema and could be dropped or used for something more informative.

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?

Scope, auth, and license semantics are covered, but with no output schema the description never hints at the shape of results (do results include citation metadata, licenses, snippets?). For a search tool the agent still has to discover the return format empirically.

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

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

Schema coverage is 100%, so all four parameters are already documented, including the enum for `license` and the category list. The description's only added value is the 'source:nist zero trust' directive hint, which the schema's own `query` description already repeats verbatim, so there is little incremental meaning.

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

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

The description opens with a specific verb and resource ('Search the open-access archive') and enumerates the content domains (papers, standards, textbooks, legal sources) plus the license-aware angle. It implicitly separates itself from get_document/download_pdf, but never distinguishes it from the equally named conceptio_search_batch sibling.

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

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

It supplies a real prerequisite ('Requires an API key: run `conceptio auth` once first'), which is useful operational context, but gives no guidance on when to choose this tool over conceptio_search_batch or conceptio_graph_walk. Usage is implied by the content scope rather than stated as a selection rule.

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

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

The description discloses important behavior beyond the annotations: queued execution returns an opaque job handle, polling is done via the public API or `conceptio search-job`, and sync mode returns all results in one response. It also states that each fresh subquery consumes one search credit, which aligns with the non-read-only and non-idempotent 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 description is front-loaded with the purpose, then efficiently covers both modes, polling, and credit cost. Every sentence adds useful information without 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?

For a two-parameter tool with full schema coverage and annotations, the description supplies the operational details an agent needs: mode selection, return behavior, polling path, and credit implications. No output schema exists, yet the return shape for each mode is adequately described.

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

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

Schema coverage is 100%, so the schema already documents the sync and queries parameters. The description adds useful meaning by explaining credit usage per subquery and clarifying the queue-versus-sync limits, though it does not expand on the query object fields beyond the schema.

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

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

The description states a specific verb and resource: run multiple independent searches in one call. It clearly distinguishes the batch operation from a single search and explains both execution modes.

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

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

It clearly explains when to use the default queued mode versus sync:true, including the 1–50 and 1–10 limits. It does not explicitly name conceptio_search as the alternative for single searches, but the batch context is inferable.

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