sciencedirect_article_retrieve_by_identifier

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

With no annotations, the description carries the behavioral burden and does it well: it discloses the default view (META), that it is unrestricted, and that full-text body only appears under entitlement-gated views. It also clarifies that the output is a normalized record with specific fields. This goes beyond what the schema reveals and is directly relevant to call expectations.

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

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

Two sentences with zero filler. The main purpose is front-loaded, and the view-related nuance occupies the second sentence. Every clause adds context about what the tool returns and how access is gated.

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

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

The tool has no output schema and no annotations, so the description is the only source of expectations. It lists the record contents and the META/full-text gating, which is good. But it lacks error behavior (e.g., not found), any request details like required authentication or rate limits, and does not contrast with the similarly named sibling sciencedirect_article_object_by_identifier, so an agent might not know which to pick.

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 clarify parameters. It does add meaning by listing valid identifier_type values (pii, doi, pubmed_id, eid) and explaining the view default and gating. However, it does not specify the exact format for the identifier value (e.g., DOI format) nor enumerate possible view values beyond META, leaving ambiguity for a parameter with no enums.

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: 'Retrieve an article record by identifier type... and value.' It names the identifier types (pii, doi, pubmed_id, eid) and lists the return fields (title, authors, journal, identifiers, subjects). It does not explicitly differentiate from the sibling sciencedirect_article_object_by_identifier, 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?

No guidance on when to use this tool versus the many sibling retrieve/search tools. The only contextual hint is about view restrictions (META vs entitlement-gated), which is about behavior, not tool selection. The agent must infer when to prefer this over sciencedirect_article_object_by_identifier or scopus_abstract_detail_by_eid from the name alone.

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