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 does not disclose whether this is a read-only operation, what the response contains, or any limitations (e.g., coverage, availability). The description adds minimal behavioral context beyond the name.

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 short and front-loaded, but it is under-specified rather than efficiently concise. It earns a middle score because it is not verbose, yet it omits useful 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?

With no annotations, no output schema, and a single parameter, the description is too thin to fully guide an agent. It does not explain what 'abstract details' includes, how to format the Scopus ID, or what to expect in the response.

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

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

Schema description coverage is 0%, and the description only says 'for a Scopus id' without explaining the expected format, whether it is a numeric ID or a URL, or how it relates to the abstract. The description adds little meaning beyond the schema's property 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 and resource ('Scopus abstract details for a Scopus id'), so an agent can tell it retrieves abstract details for a Scopus identifier. However, it does not distinguish it from sibling tools like get_paper or search_scopus, and the phrasing is terse.

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

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

No guidance is given on when to use this tool versus alternatives such as get_paper or search_scopus. The description implies it is for Scopus IDs but does not state exclusions or context.

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

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

There are no annotations, so the description must carry the full burden of behavioral disclosure. It says nothing about whether the operation is read-only, side effects, rate limits, or what the response looks like. It only states the resource name, which is insufficient.

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?

While the description is extremely short, this is under-specification rather than conciseness. The single phrase does not earn its place; it provides no actionable information. It is not front-loaded with key details because there are no details at all.

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 tool with one parameter and no output schema, the description is still completely inadequate. It fails to mention what the tool returns, any prerequisites, or how the author_id should be structured. The tool is practically unusable from the description alone.

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 by explaining what author_id is, its format, or how it's used. The description provides zero information about the parameter, leaving the agent without any semantic understanding beyond the raw type 'string'.

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 bare noun phrase 'Scopus author profile' that essentially restates the tool name without a verb or action. It doesn't state what the tool does (e.g., 'Retrieve the Scopus profile for a given author ID'), and it doesn't distinguish from sibling tools like scival_author_lookup, which likely also provide author profiles. This is closer to a label than a purpose statement.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or mention sibling tools. The agent is left to infer the use case entirely.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool collects a citation graph from three sources; it does not mention pagination, rate limits, error handling, or what happens when an identifier is invalid. There is no indication of whether the result includes full citation details or just counts, and no mention of authentication requirements. This is a significant gap for a cross-source aggregating tool.

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

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

The description is a single, front-loaded sentence with no fluff or repetition. It efficiently conveys the core purpose and the involved sources. It is concise but not over-minimal – it earns its place. A 5 would require slightly more detail about the return behavior without adding length.

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 aggregating three sources, the lack of annotations, and no output schema, the description is incomplete. It does not explain the response structure, how limit interacts with the graph, or any edge cases. An agent would need to either infer behavior from the schema (which has no descriptions) or risk making incorrect assumptions. More context is necessary 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%, so the description must compensate by explaining the parameters. It does not. The identifier is implied by the phrase 'one paper', but the limit parameter is completely unexplained – what does it limit? Number of citations per source, total results, or something else? No additional meaning is provided, leaving the agent to guess.

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 ('Collect') and a specific resource ('cross-source citation graph') for one paper, and names the three sources (Scopus, OpenAlex, Semantic Scholar). It clearly distinguishes itself from sibling tools like get_paper or search_* by specifying the multi-source citation gathering intent. However, it leaves 'citation graph' somewhat vague (does it return citing papers, counts, or metadata?), so it's not a 5.

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 does not provide any explicit when-to-use guidance, nor does it mention alternatives or exclusions. It implies usage for collecting citations across the named sources, but there is no instruction on when to prefer this over get_paper or search_* tools. An agent would have to infer the use case from the tool name and brief 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions merging metadata and attaching open-access links, which is useful, but it does not describe error handling, response format, or confirm the operation is read-only. The description is adequate but not comprehensive.

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

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

The description is a single, well-structured sentence that front-loads the action and resource. Every word adds value, and it is concise without sacrificing 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?

For a tool with one parameter and no output schema, the description covers the main purpose and accepted input types. It is close to complete, though it could benefit from specifying the return format or behavior when an identifier cannot be resolved. Given the simplicity and lack of annotations, it is adequately complete.

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

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

The schema has 0% description coverage, so the description must compensate. It lists the accepted identifier types (DOI/arXiv/Scopus/OpenAlex), giving meaning beyond the bare 'string' type. However, it omits format specifics and does not clarify which identifiers are prioritized or how they are combined, so it only partially compensates.

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 ('resolve') with a clear resource (DOI/arXiv/Scopus/OpenAlex id) and the intended outcome (merge metadata, attach open-access links). It clearly distinguishes itself from the search sibling tools by focusing on resolving an existing identifier rather than searching.

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

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

The description implies the tool is for when you have an existing identifier, but it does not explicitly contrast with the many search_* siblings or state when not to use it. It lacks guidance on alternatives or conditions for selection, leaving usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the resource and status; it does not state whether this is a read-only call, whether it consumes quota, or how the status data is represented or refreshed.

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 short and front-loaded, which makes it easy to scan. However, it stops short of a complete definition—no verb and no explanation of what 'status' includes—so brevity shades into under-specification rather than efficient completeness.

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 zero-parameter tool needs little invocation guidance, but with no output schema and no annotations the description should say what the quota status contains (e.g., current usage, limit, reset date) or when to call it. The one-line definition leaves those gaps.

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 and the empty input schema fully defines the invocation contract. The description does not need to add parameter-level detail, so the baseline for a no-parameter tool applies.

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

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

The description clearly identifies the target resource ('Scopus API quota') and the task ('status'), and no sibling tool name overlaps with quota/status functionality. It lacks a verb or detail about which specific quota limits are reported, but the intent 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?

The description provides no guidance on when to check quota status, e.g., before bulk operations, or how it relates to the sibling search/get tools. An agent must infer its use entirely from the name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'lookup,' which implies a read operation, but it does not mention result format, pagination, count behavior, name matching semantics, or any limitations. This is a minimal disclosure rather than a transparent one.

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

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

The description is a single focused sentence with no filler, and it fronts the key information: what is being looked up and how. It could be more informative without hurting conciseness, but as written it is efficiently structured.

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

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

Given no annotations, no output schema, and a sibling list containing similar author tools, this description is not complete enough. It omits return behavior, count semantics, disambiguation guidance, and any differentiator from get_author_profile or other search tools. The agent can guess the basic intent but lacks adequate context for reliable 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?

The description adds meaning to the required 'query' parameter by indicating it should be an author name, which the schema itself does not say. However, the optional 'count' parameter is not addressed, leaving its semantics to the schema's default and type. Partial compensation for low schema coverage.

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

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

The description clearly identifies the resource (SciVal author) and the lookup operation, and specifies that lookup is by name. It does not explicitly distinguish itself from sibling tools like get_author_profile, but the resource and lookup action are clear enough.

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 'by name' implies the tool should be used when searching for a SciVal author using a name query, but it provides no explicit guidance about when to prefer this over alternatives or when not to use it. Usage context is implied rather than 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it says nothing about return values, read-only status, required author_id, time-range handling, or data source. It is effectively empty of behavioral information.

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 short, but this is under-specification rather than conciseness. A single noun phrase contains no actionable content and is not meaningfully front-loaded.

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 3-parameter tool with no output schema and no annotations, the description is far too thin. It omits what metrics are returned, how year_from and year_to are used, and how this differs from related SciVal 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?

Schema description coverage is 0%, and the description adds no meaning to author_id, year_from, or year_to. An agent cannot determine expected formats, units, or how the parameters affect the returned metrics.

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 'SciVal author metrics.' is a noun phrase that essentially restates the tool name, with no verb indicating what the tool does. It does not distinguish this tool from siblings like scival_author_lookup or get_author_profile.

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 scival_author_lookup, scival_topic_metrics, or search_all. The description provides no context, prerequisites, or 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 provided, the description carries the full burden of behavioral disclosure. It states only 'lookup,' which implies a read operation, but does not mention matching behavior, pagination, rate limits, or what the response contains.

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 six words and contains no filler. The resource is front-loaded and every word contributes meaning. It is extremely concise, even if additional context would be helpful 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?

Given no output schema and no annotations, the description is too thin to fully support correct invocation. It does not indicate whether the result is a list, an ID, or a full institution profile, nor does it explain how this relates to scival_institution_metrics. An agent may be uncertain how to use the result in downstream calls.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It clarifies that 'query' is an institution name, but it does not explain the 'count' parameter or its default behavior. This is only minimal added meaning over 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 resource (SciVal institutions) and operation (lookup by name), which distinguishes it from author lookup and metrics tools. However, 'lookup' is somewhat generic and does not clarify what the returned data represents.

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 scival_author_lookup, scival_institution_metrics, or search_all. 'By name' is an implicit hint, but no explicit context, prerequisites, or alternative routing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says nothing about side effects, data scope, rate limits, or return behavior. For a tool that presumably queries institution-level metrics, there is zero transparency about what 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 under-specified rather than concise. While it is short, the single sentence does not earn its place because it conveys no actionable information. It reads like a placeholder, not a purposeful summary.

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, no output schema, and no annotations, the description is completely inadequate. It lacks any detail about the return value, parameter semantics, or use cases, making it impossible for an agent to use the tool correctly without external documentation.

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 mention any of the three parameters (institution_id, year_from, year_to). It adds no meaning beyond what the bare schema already shows, failing to explain required vs. optional parameters or their format.

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 'SciVal institution metrics' is essentially a restatement of the tool name. It does not specify an action (e.g., 'Retrieve', 'List', 'Calculate') or what kind of metrics are provided. It vaguely indicates the domain but fails to differentiate from sibling tools like scival_author_metrics or scival_topic_metrics, which likely have similar minimal descriptions.

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

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

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios that would select this tool over the many sibling tools. An agent has no basis to decide whether to invoke 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states nothing about side effects, output format, data freshness, authentication, or any operational details. The description is essentially a label, offering zero behavioral 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?

While the description is extremely short, this is under-specification rather than deliberate conciseness. It provides no structural benefit or front-loaded information. Every sentence (there is only one) is vague and doesn't earn its place.

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

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

For a tool with three parameters (one required), no output schema, and no annotations, the description is completely inadequate. It fails to explain the tool's purpose, parameters, or expected behavior, leaving an agent with no actionable information.

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%, meaning none of the three parameters (topic_id, year_from, year_to) are described in the schema. The description does not compensate by explaining any of them. An agent cannot infer what these parameters mean or how they should be formatted.

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 resource ('SciVal topic') and implies an operation ('metrics'), but it's a noun phrase with no explicit verb. It doesn't distinguish itself from sibling tools like scival_author_metrics or scival_institution_metrics beyond the resource name, and it doesn't specify what metrics are returned or how they are computed.

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 use cases, prerequisites, or exclusions. An agent has no way to decide between this and other SciVal metric tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful behavioral traits: parallel execution across sources and de-duplication by DOI or title. However, it does not disclose response shape, failure behavior, rate-limit implications, or how the list of searched sources is determined when the 'sources' parameter is omitted.

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. Every word contributes to the core meaning: searching, all sources, parallel execution, and duplicate merging by DOI/title. It is appropriately concise for its high-level message.

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?

Despite the large sibling set and 6 parameters, the description provides only a high-level overview. It does not define the sources parameter, explain filtering limits, describe the merged result format, or advise when to prefer individual source-specific tools. This is insufficient for an agent to reliably invoke the tool with correct parameter values.

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

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

Schema description coverage is 0%, so the description must compensate for entirely undocumented parameters. The description only vaguely implies the 'query' parameter through 'Search', and it completely fails to explain 'sources', 'year_from', 'year_to', 'tech_only', or 'limit_per_source'. For a 6-parameter tool, this is a critical gap.

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

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

The description clearly identifies the action ('Search all journal sources'), the resource ('all journal sources'), and a distinctive behavior ('merge duplicate results by DOI/title'). It differentiates this tool from source-specific siblings like search_scopus and search_arxiv by emphasizing parallel aggregation across all sources.

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 'all journal sources in parallel' implies the intended use case: a broad cross-source search rather than a single-source query using search_scopus or search_arxiv. However, the description does not explicitly state when to choose this tool over the individual source-specific tools, nor does it mention exclusions or fallback scenarios.

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, but it only says 'Search arxiv only.' It does not mention return format, pagination, ordering, or any side effects. Search is inherently read-only, yet the description adds no behavior context beyond the bare action.

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 efficient sentence with zero filler, making it concise. However, it borders on under-specification—it provides no contextual front-loading about behavior or scope beyond the tool name, so while it is concise, it sacrifices substance.

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 five parameters, no output schema, and a long list of sibling search tools, an agent needs more context about what the results look like, how 'arxiv only' differs from search_all or other source-specific tools, and how parameters like year_from/year_to shape the search. The one-line description leaves all of this unstated.

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 input schema fully documents all five parameters, including defaults and descriptions. The tool description adds no additional semantic detail about parameters, matching the baseline for fully documented schemas.

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?

'Search arxiv only.' states a clear verb (Search) and resource (arxiv), and the word 'only' signals scope that distinguishes it from broader or other-source search tools. It doesn't specify what kind of results are returned (papers, metadata, full text), but the core purpose is unambiguous.

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

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

The word 'only' implies this tool is for arxiv-specific search and not for other indexes, but it never names alternatives like search_all or search_scopus or states explicit when-to-use/when-not-to-use conditions. Guidance is implied rather than explicit, so an agent must infer the boundary from sibling names alone.

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, but it only states the basic operation. It does not mention rate limits, authentication, return format, pagination, or any constraints. This is a significant gap for a search tool and offers no behavioral transparency beyond the action itself.

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

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

The description is a single, concise sentence with zero unnecessary words, and it is front-loaded with the core purpose. It is efficient, though it may be too brief for the tool's complexity, but as a concise statement it scores well.

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 five parameters, no annotations, and no output schema, the description is far too sparse. It does not explain what results look like, how the year/tech filters work, or any limitations. An agent lacks essential context to invoke the tool correctly beyond the basic search intent.

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 100% description coverage, so each parameter (query, count, year_from, year_to, tech_only) is already documented. The description adds no additional semantic meaning to these parameters, so it meets the baseline of 3 without any enhancement.

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

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

The description clearly states the action 'Search' and the resource 'Crossref', which gives a definite purpose. The word 'only' hints at exclusivity but does not name alternative tools or specify what kind of search is performed, so it is clear but lacks explicit differentiation from sibling search 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?

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'crossref only' implies it is for Crossref-specific searches, but it does not state when to prefer it over search_all, search_scopus, or other siblings, nor does it give any exclusions or context.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It merely states 'Search dblp only' with no information about read-only nature, rate limits, pagination, response format, or any side effects. The description is entirely silent on behavioral traits, leaving the agent to guess.

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, efficient sentence that front-loads the core purpose. There is no wasted text, and the structure is clear. While extremely brief, it is appropriately concise for a tool with a simple function, though it could benefit from a second sentence about usage.

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 5 parameters, no output schema, and no annotations. The description is just 'Search dblp only,' providing no information about return values, pagination, result sorting, or any operational details. An agent cannot fully understand how to call this tool correctly or what to expect in the response.

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

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

Schema description coverage is 100%, meaning every parameter has a description in the schema. The tool description adds no parameter-specific meaning beyond what the schema already provides. Per the baseline, a score of 3 is appropriate when the schema does the heavy lifting and the description doesn't enrich it.

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 ('Search') and a clear resource ('dblp'), and the word 'only' signals that this tool is scoped exclusively to dblp, distinguishing it from the many sibling search tools (e.g., search_scopus, search_arxiv). However, it doesn't explain what dblp is or elaborate on the scope, so it's clear but slightly minimal.

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 provides no guidance on when to use this tool versus the sibling search tools. It only says 'Search dblp only,' which implies exclusivity but does not state conditions, alternatives, or when to prefer another search. No prerequisites or context are given.

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 disclosing behavior. It only states scope; it does not mention rate limits, result shape, pagination, or how query, year filters, and tech_only affect execution. There is nothing to prepare the agent for side effects or response structure.

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?

Four words is concise, but this is under-specification rather than efficiency. The sentence contains no information beyond the tool name and therefore does not earn its place as a functional description.

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

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

For a search tool with five parameters, no output schema, and no annotations, a one-sentence description is far from complete. The agent cannot determine what a successful call returns, how results are limited, or how the search behaves in the wider toolset.

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?

Input schema covers 100% of parameters with descriptions (query, count, year_to, tech_only, year_from), so the baseline is 3. The description itself adds no parameter-level meaning, but the schema already carries that burden.

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 'Search openalex only' essentially restates the tool name without clarifying what OpenAlex is or what kind of content is searched. It names a resource but adds no detail about results (papers, authors, venues), leaving the purpose vague beyond the name itself.

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

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

The word 'only' hints at a single-source search but provides no guidance about when to choose OpenAlex over sibling tools like search_scopus, search_arxiv, or search_all. No context, prerequisites, or alternative routing is given.

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 present, so the description carries the full behavioral burden. It does not disclose whether this operation is read-only, how many results are expected, whether pagination or rate limits apply, or what the response structure looks like. 'Search' implies a read operation but nothing more.

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 short, which is concise, but it is under-specified for a tool with five parameters and no output schema. It does not earn its place as a complete definition because it omits essential 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?

With no annotations and no output schema, the description should explain return values and selection context, but it only names the target database. An agent gets enough to know this searches Scopus, but not enough to understand what a successful invocation returns or when this is the preferred 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 100%, so the baseline is 3 even without additional parameter explanations. The description adds no parameter semantics beyond what the schema already documents, but the schema itself covers all five 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 specifies a concrete action ('search') and a concrete resource ('Scopus'), and the word 'only' hints that this tool targets Scopus specifically rather than all sources. However, it reads almost like a restatement of the tool name and gives no detail about what kind of records are searched or what kind of results are returned.

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

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

No guidance is provided about when to use this tool versus alternatives like search_arxiv, search_openalex, or search_all. The word 'only' implies a limitation to Scopus, but there is no explicit condition or comparison to inform tool selection.

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 must carry the behavioral burden. 'Search' reasonably implies a read-only lookup and 'only' defines the source boundary, but nothing is said about result format, pagination, filtering effects, or API behavior, so transparency is minimal.

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

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

The sentence is short and front-loaded, and it avoids padding. However, most of it restates the tool name; only 'only' contributes new scope information, making this closer to under-specification than to well-structured concision.

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?

In a context with 17 siblings, a non-trivial 5-parameter schema, and no output schema or annotations, this description is completely inadequate for selecting and invoking the tool correctly. It neither explains return values nor the specific use cases that distinguish it from the other 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?

Schema description coverage is 100%, so the baseline is 3 even though the tool description itself explains none of the parameters. The description adds no new meaning about query, count, date filters, or tech_only beyond what the schema already provides.

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

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

The description states a clear verb ('search') and a specific resource ('semanticscholar'), and the word 'only' signals that this tool is intentionally restricted to that source. It does not fully define what kind of records are searched (papers, authors, citations), so it falls short of the strongest sibling-differentiating statements.

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 choose this tool over the many search siblings such as search_scopus, search_arxiv, search_openalex, or search_all. 'Only' implies a source restriction but does not state a use case, prerequisite, or exclusion condition.

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