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

No annotations are provided, so the description carries the full behavioral burden. It reveals the upsert semantics (add OR update), which is genuinely useful, but says nothing about permissions, conflict behavior when a seed already exists, or which fields can be updated versus only set on creation.

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, front-loaded sentences with no waste. The second sentence is telegraphic enough to be slightly cryptic, but nothing is padding.

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

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

An output schema exists so return values need no explanation, but with 7 undocumented parameters, no annotations, and no stated conflict/permission behavior, the description is too thin for a mutation tool. An agent would have to guess which fields are meaningful and what happens on a duplicate seed.

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% across 7 parameters, so the description must compensate. It only touches s2_id, doi, and title_query (partially — it never explains that title_query is a lookup rather than an identifier). arxiv_id, paper_id, notes, and enabled are entirely unexplained, and no format examples (DOI syntax, S2 ID shape) are given.

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 pair and resource: 'Add or update a seed paper in the DB.' The upsert nature is conveyed, and it is distinguishable from siblings like list_seeds or resolve_seed. 'In the DB' is slightly vague about which store, but the intent is 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?

'Prefer s2_id or doi; title_query returns candidates' gives real guidance on identifier precedence, which is the main decision an agent faces here. However, it never says when to use this tool versus siblings such as resolve_seed, list_seeds, or set_seed_enabled.

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 disclosure burden and does well: it declares idempotency ('safe when already initialized'), the default data location, the MY_LIT_DATA_DIR override, and the artifacts created. It does not explain what `force` does or whether it can destroy/reinitialize existing data, which leaves a real behavioral gap for a mutation-style tool.

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

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

Front-loaded with the core action, then usage, then parameter guidance, then the idempotency guarantee. Sentences earn their place; only the trailing 'Idempotent' line could arguably be folded into the opening.

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

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

An output schema exists so return values need no explanation, and the config/DB/PDF and override details are covered. However, with zero annotations and an unexplained `force` parameter, an agent cannot know whether force overwrites or wipes an existing .my-lit directory.

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

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

Schema coverage is 0%, so the description must compensate. It adequately explains project_root ('absolute path of the workspace/repo') and data_dir/the env var, but `force` is never mentioned anywhere, leaving one of three parameters semantically undefined.

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 ('Create project-scoped .my-lit') plus the exact contents it manages (config, DB, PDFs), and the conditional 'if missing' scopes it precisely. Nothing here could be confused with the metric/search/seed 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?

'Call this first in a new project' gives an explicit when-to-use trigger, which is the key routing signal for an initialization tool. It does not name exclusions or alternatives, but for a bootstrap tool with no sibling overlap that is a minor omission.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait, that the returned text is truncated, but it omits everything else: no mention of the max_chars cap interaction, no auth or error behavior, and no note on what happens when no full text is stored.

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

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

A single short sentence with no filler, and the core action is front-loaded. It is efficient, though the terseness is arguably the source of the coverage gaps rather than a virtue here.

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 restated. But for a two-parameter tool with zero schema description coverage and zero annotations, the description is far too thin: an agent still cannot tell how truncation is controlled or how this differs from the sibling full-text search 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 neither parameter is explained in the description. The word 'truncated' hints at a length limit but never connects it to max_chars (default 20000) or clarifies that paper_id is the lookup key, so the description adds no semantic value over the bare 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 clear verb and resource ('Return stored full text'), so an agent knows this retrieves content. However, it never explains that retrieval is keyed by paper_id, nor does it distinguish itself from the sibling search_fulltext or get_paper, so the purpose is only loosely delineated.

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 guidance at all: no statement of when to pick this over search_fulltext or get_paper, and no prerequisites. The only implied usage is that a paper must already be identified.

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 burden. 'Fetch' strongly implies a read-only retrieval and mentions included feedback/parse status, but it does not explicitly state side-effect profile, permissions, error behavior, 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?

A single, front-loaded sentence with no filler. Every word contributes to stating what is fetched and what is included.

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 single-item fetch with an output schema, the description adequately covers what is returned and need not explain return values. However, the absence of parameter semantics and usage guidance leaves gaps for an agent choosing between this and retrieval 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?

Schema description coverage is 0%, so the description should compensate, but it never mentions paper_id or its expected format. The singular 'one paper' weakly implies an identifier, but the description adds almost no semantic detail beyond the schema's parameter name.

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

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

The description states a specific verb (Fetch) and resource (one paper), and notes that feedback and parse status are included. It is clear what the tool does, though it does not explicitly distinguish itself from similar retrieval siblings such as get_fulltext.

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 siblings like get_fulltext, list_queries, or search_local. The only implied usage is fetching a single paper by identifier, with no prerequisites or exclusions stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It suggests a read-only listing operation but does not disclose permissions, result ordering, pagination, or whether all configured queries are returned.

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 that contains no filler. It is appropriately sized for a zero-parameter listing 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?

With zero parameters and an output schema, the description does not need to explain return values. However, it still leaves ambiguity about what 'configured ingest queries' are and in what context they should be listed, which is a minor gap for an otherwise simple tool.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline score of 4 applies because there is nothing for the description to compensate for or clarify.

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 ('configured ingest queries'), so the agent knows what the tool does. It does not distinguish this tool from any sibling, but no sibling appears to list ingest queries, so the purpose remains 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?

There is no guidance on when to use this tool, when not to use it, or what alternatives exist. The agent can infer it is for listing configured ingest queries, but no explicit usage context is provided.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether this is a safe read, whether pagination or result limits apply, or how disabled seeds are treated. 'List' and 'stored in the local DB' imply read-only and data source, but that is inference, not disclosure.

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

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

A single short sentence, front-loaded with the action and resource, with the source-of-truth note appended. No wasted verbiage, though the brevity comes partly from omitted needed 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-value explanation is not required, and the tool is simple with one optional parameter. Still, the undefined enabled_only semantics and the absence of any behavioral note for an annotation-free tool leave a meaningful 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 single parameter 'enabled_only' (default false) is undocumented in both schema and description. The description does not explain whether disabled seeds are returned by default, which is exactly the decision the parameter controls.

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

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

States a specific verb+resource ('List seed papers') and narrows the scope to the local DB, which separates it from a config.yaml source and from siblings like list_queries. It does not, however, differentiate itself from search_local or similar listing 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?

The parenthetical '(preferred over config.yaml)' gives implied guidance about which source to consult, but there is no explicit when-to-use vs when-not-to-use guidance against the many sibling tools, nor any prerequisite or exclusion stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says 'upsert' and lists labels, but omits whether existing feedback is overwritten, permission/auth needs, validation behavior, or what happens if paper_id is invalid.

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. Its brevity, however, reflects under-specification as much as deliberate conciseness.

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. But for a 3-parameter mutation tool with no annotations and 0% schema descriptions, the missing paper_id/notes semantics and usage context leave it substantially 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 description coverage is 0%, so the description must compensate. It supplies the label value domain, which is useful, but says nothing about the required paper_id or the optional notes parameter.

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

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

States a specific action, 'Upsert feedback', and enumerates the allowed labels relevant | not_relevant | must_read. It broadly distinguishes this from generic sibling tools, but does not address overlap with the sibling tool must_read.

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?

Provides no when-to-use, when-not-to-use, or alternative guidance. It does not explain how this relates to the sibling must_read tool or when a caller should choose this over other feedback/seed 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?

No annotations are provided, so the description bears the full behavioral burden, and it discloses nothing: not whether results are paged, sorted, cached, personalized, or what 'high-score' is measured against. For a read tool with zero annotation coverage this is a critical gap.

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?

It is short, but shortness here is under-specification rather than conciseness — a single fragment sentence that omits the verb entirely. Nothing is front-loaded because there is effectively no content to prioritize.

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-value explanation is not required, but for a one-parameter catalog tool with no annotations the description should at minimum state it returns a curated/ranked list of papers and explain the `limit` behavior. It does neither.

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%: the single `limit` parameter has a default of 50 but no description. The description never mentions `limit`, its units, or its maximum, so it fails to compensate for the missing 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 is a noun phrase fragment ('High-score or must_read-labeled papers.') with no verb or resource statement, so it never says what the tool actually does (list/return papers). It largely restates the tool name 'must_read', with 'high-score' as the only added nuance.

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 when-to-use guidance, no conditions, and no mention of alternatives among the many siblings (similar_to, new_since, search_local, get_paper) that also surface papers. The agent must guess whether this is a listing, search, or filter 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the ingestion-time filter but says nothing about ordering, pagination behavior, default result count, or whether results are metadata-only or include content, all of which matter for a feed-style retrieval 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?

A single front-loaded fragment with no filler; every word contributes. It is terse to the point of under-specification, but that shortfall is more a completeness issue than a structural one.

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

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

An output schema exists so return values need not be described, but with no annotations, 0% parameter coverage, and an unmentioned limit default, the definition is too thin for an agent to call it confidently beyond the basic filter.

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, yet it only clarifies that 'since' is an ISO timestamp. The 'limit' parameter (default 50) is never mentioned, leaving half the parameters undocumented in both schema and description.

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 concrete resource (papers) and a precise filter (ingested after an ISO timestamp), which is enough for an agent to distinguish this retrieval tool from siblings like similar_to or search_fulltext. It lacks an explicit verb such as 'list' and never references any sibling, but the scope 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 such as list_seeds, search_local, or must_read, nor any stated prerequisites or exclusions. The agent must infer the use case entirely from the one-line filter description.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no indication of whether the counts are live or cached, how fresh 'Last run' is, or whether the call is read-only. For a zero-param status tool the safety profile is low-risk, but the reporting semantics (snapshot vs. live, units, time windows) remain entirely undisclosed.

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?

It is a single telegraphic fragment list with no wasted words, so it is certainly concise. However, it is under-specified rather than well-structured: there is no sentence structure, no verb, and the four comma-separated items read as raw field names without framing.

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

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

An output schema exists, so the description need not enumerate return values, and with no parameters the input surface is trivially complete. Still, a 16-sibling server with no annotations warrants at least a word on when to consult this status tool and whether the numbers are point-in-time, which is absent.

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

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

The tool takes zero parameters, so there is no parameter meaning for the description to supply. Baseline 4 applies; nothing here misleads about inputs.

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 fragment list identifies the resource (pipeline status: last run, OpenAlex daily calls, PDF parse counts, seed count) but never states an action verb or that the tool returns these values. An agent can infer it is a read of pipeline health metrics, but must lean on the tool name to do so. It is distinguishable from siblings only because none of them deal with pipeline metrics.

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 on when to call this tool, what triggers it, or how it relates to siblings like ensure_workspace or list_seeds. The agent is left to guess that this is a diagnostic/health-check tool consulted before or after running the pipeline.

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, and it only supplies the bare fact that this deletes. It omits whether deletion is permanent or reversible, what happens on an unknown ID, what occurs if both or neither identifier is supplied, and whether any authorization is required.

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 that names the action and both identifier forms with zero filler. Nothing is wasted or buried.

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. Still, for a destructive tool with no annotations and two nominally optional parameters, the description should at minimum resolve which identifier to pass and note irreversibility; that gap keeps it at minimum-viable.

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 is the only source of parameter meaning, and it does clarify that seed_id is the local identifier while s2_id is a Semantic Scholar identifier. However, it leaves the mutual-exclusivity/optionality contract and precedence when both are provided entirely unstated.

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 (Delete) and resource (seed) and identifies the two accepted identifier types, so the operation is unambiguous. It does not differentiate from siblings such as add_seed, resolve_seed, or set_seed_enabled, so an agent gets no help distinguishing this from the rest of the seed family.

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 guidance, no mention of prerequisites, and no alternatives. Crucially, the description never says that exactly one of the two identifiers is needed, even though the schema marks both as optional with null defaults.

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

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

No annotations are provided, so the description carries the full burden. It discloses one useful trait (non-persistent, 'without saving'), but with five optional identifier parameters it never explains precedence/conflict resolution between them, error behavior, or whether an external API is queried.

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, front-loaded sentences with no filler. The purpose and the routing hint each earn their 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?

An output schema exists so return values need no explanation, but for a five-optional-parameter resolver with no annotations the description omits the essential semantics of the inputs and their precedence, leaving the agent unable to call it confidently.

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 names none of the five parameters (doi, s2_id, arxiv_id, paper_id, title_query). The critical question of which identifier takes precedence, or whether one is required, is left entirely undocumented.

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

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

States a specific verb+resource ('look up seed candidate metadata') and explicitly scopes it as non-persistent ('without saving'). It differentiates from the sibling add_seed, though it doesn't distinguish itself from other lookup tools like get_paper or similar_to.

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 context and a named alternative: 'Use before add_seed if unsure.' This is an explicit when-to-use with a routing recommendation, though it stops short of stating when NOT to call it.

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 bears full responsibility for disclosing behavior. It states the search target but omits read-only nature, pagination, result ordering, permissions, rate limits, and whether unparsed PDFs are silently excluded.

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

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

The single sentence is front-loaded, has no wasted words, and is easy to parse. It is arguably too sparse for the tool's complexity, but as a conciseness measure it is efficient.

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

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

For a three-parameter search tool with no annotations and no schema descriptions, the description is incomplete. The output schema covers return values, but the description should still explain search scope, parameter semantics, and when to prefer this over sibling search tools.

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 three parameters and 0% schema description coverage, the description provides no meaning for query, limit, or source. It does not describe query syntax, the purpose of source, or how limit affects results.

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 (Search) and resource (parsed PDF body text), and the word 'only' clarifies that this tool is scoped to full text rather than metadata or broader sources. It is clear enough on its own, but it does not explicitly differentiate itself from siblings such as search_local or get_fulltext.

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 on when to use this tool versus search_local or other search tools. The only implied usage condition is that PDFs must already be parsed, which is not stated as an explicit prerequisite or alternative.

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 are absent, so the description carries the full burden. It does not disclose read-only status, permissions, pagination behavior, rate limits, or result handling; only the search scope is given.

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 fragment states the core operation with no filler. However, for a five-parameter tool with no annotations, the extreme brevity is under-specification rather than effective conciseness.

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 explained. But with no annotations, 0% schema coverage, and five parameters, the description omits required usage and parameter context, leaving the agent under-informed for a non-trivial search 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% for five parameters, and the description does not explain any parameter such as query syntax, label, limit, since, or source. It adds no semantic meaning beyond the bare field names in 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 'Search' and resource 'local corpus', plus searched fields title/abstract/fulltext. It is clear what the tool does, but does not distinguish itself from sibling search_fulltext or explain the local vs remote scope.

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 when-to-use, when-not-to-use, or alternative tool guidance. The description merely states the operation; an agent must infer from the tool name that this is for local-corpus search rather than search_fulltext.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one genuine trait — the operation is reversible/non-destructive relative to deletion — but omits permissions, whether disabled seeds are excluded from search, and whether the change persists immediately.

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

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

A single front-loaded sentence with no waste. It is efficient, though the brevity borders on under-specification for a mutation tool with zero annotation support.

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 state-mutating tool with no annotations, no parameter descriptions, and an output schema only, the description is too thin. It leaves side effects, permissions, and the meaning of the enabled default undocumented.

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 two parameters, and the description adds nothing about them beyond the word 'enable/disable' loosely implying the boolean flag. It never explains seed_id, nor the default enabled=true behavior.

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 pair (enable/disable) and resource (seed), so the operation is unambiguous. It implicitly separates itself from remove_seed via the 'without deleting it' clause, but does not name that sibling explicitly.

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

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

The 'without deleting it' phrase implies this is the soft-toggle alternative to remove_seed, so usage is inferable but never stated as explicit when/when-not guidance. No mention of prerequisites or conditions under which a disabled seed should be preferred.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'Local title-keyword similarity', which gives minimal context about the computation basis (local, title keywords) but says nothing about permissions, return format, rate limits, or side effects. A score of 2 reflects this very limited disclosure for a tool with no annotation support.

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 fragment, not a properly structured sentence. While extremely short, it is under-specified rather than genuinely concise—every sentence cannot earn its place because there is barely a sentence. A 2 reflects this lack of useful structure.

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

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

Given the complexity of a 2-parameter tool with no annotations and an output schema, the description is completely inadequate. It does not explain when to use the tool, what it returns, or how the parameters work. The presence of an output schema does not excuse the missing behavioral and usage context.

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 two parameters (paper_id, limit) with 0% schema description coverage, meaning neither the schema nor the description explains them. The description adds no meaning beyond the parameter names. With low coverage, the description should compensate but does not, so a 1 is appropriate.

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

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

The description 'Local title-keyword similarity' is a fragment that hints at the computation method but omits a clear verb and resource. It does not specify that the tool takes a paper_id and returns similar papers, nor does it distinguish itself from siblings like search_local or search_fulltext. An agent would struggle to know exactly what the tool does without opening 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?

There is no guidance on when to use this tool versus alternatives such as search_local or search_fulltext. The description provides no context, preconditions, or exclusions. An agent is left to infer usage entirely from the name and schema.

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