Server Quality Checklist

Tool Scores

• pubchem_get_summaryA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the main safety and repeatability traits. The description adds 'Up to 10 per call,' but this repeats the schema maxItems and does not disclose new behavioral context beyond the structured data.

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

  Conciseness5/5

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

  Two sentences with no filler. The main purpose is front-loaded, and the supported entity types are listed compactly without redundancy.

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

  Completeness4/5

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

  The description covers the four entity categories and the batch limit, while the schema and output schema supply parameter and return details. It is sufficient for a read-only lookup tool, though it omits alternative-tool guidance entirely.

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

  Parameters3/5

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

  Schema description coverage is 100%, including detailed identifier formats for each entity type. The description's entity-type list is a useful high-level summary but does not add meaning beyond what the input schema already provides.

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

  Purpose5/5

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

  The description states a clear verb and resource: 'Get descriptive summaries for PubChem entities by ID.' It also enumerates four supported entity types, which distinguishes it from compound-specific siblings like pubchem_get_compound_details.

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

  Usage Guidelines2/5

  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 sibling tools. It does not name alternatives or provide exclusions such as 'for detailed compound data, use pubchem_get_compound_details instead.'

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

• pubchem_get_compound_imageA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the PNG and 2D format details, but provides no additional behavioral context such as response format nuances or error behavior.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence. Every phrase contributes: 'Fetch', '2D structure diagram', 'PNG image', and 'by CID'.

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

  Completeness5/5

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

  For a simple image-fetch tool, the description plus complete input schema, output schema, and read-only annotations provide all necessary information. There are no major gaps that would prevent an agent from invoking it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with cid and size both documented including defaults and enum values. The description only restates 'by CID' and adds no parameter meaning beyond what the input schema already provides.

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

  Purpose5/5

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

  The description uses a specific verb 'Fetch' and identifies the exact resource: a '2D structure diagram (PNG image)' for a compound by CID. It clearly distinguishes this from siblings like pubchem_get_compound_3d_structure by emphasizing 2D and PNG.

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

  Usage Guidelines3/5

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

  The description implies use when a 2D image of a compound is needed, and the schema's cid description hints at resolving CID via pubchem_search_compounds. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions.

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

• pubchem_get_compound_interactionsA
  4.2/5.0
  Behavior5/5

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

  Annotations already declare readOnly, openWorld, and idempotent behavior. The description adds meaningful behavior beyond that: results are paged per kind, each page reports source-record totals and next offsets, each entry carries its source, and coverage varies by drug approval status. No contradiction with annotations.

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

  Conciseness5/5

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

  Four dense sentences with no filler: the action is front-loaded, followed by categories and sources, then pagination behavior, then coverage caveat. Every sentence contributes operational or selection-relevant information.

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

  Completeness4/5

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

  With a complete input schema, an output schema, and readOnly/openWorld/idempotent annotations, the description supplies the missing context: originating sources, pagination contract, and expected data sparsity. The only notable gap is explicit differentiation from the closely related bioactivity tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents cid, kinds, offset, and maxEntries in detail. The description reinforces the per-kind paging concept but does not add parameter-level meaning beyond what the schema provides.

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

  Purpose5/5

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

  States a specific action ('Get a compound's interaction data') and enumerates the exact interaction categories and source databases (DrugBank, BindingDB, ChEMBL). This distinguishes it from sibling tools focused on details, images, safety, or bioactivity.

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

  Usage Guidelines3/5

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

  The description implies when to use it: when interaction records are needed, and it contextualizes expectations with 'Richest for approved drugs; many compounds have no deposited interaction records.' However, it never explicitly names alternatives or says when not to use it, especially relative to pubchem_get_bioactivity, which overlaps on target binding/activity.

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

• pubchem_get_compound_safetyA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare the operation read-only, idempotent, and open-world. The description adds useful context by stating data comes from PubChem depositors and that source attribution is included, which helps set expectations about provenance and potential incompleteness. No behavioral claims contradict the annotations.

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

  Conciseness5/5

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

  Two sentences with no wasted wording. The first sentence front-loads the purpose and input; the second concisely covers output contents and data provenance. Every clause earns its place.

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

  Completeness4/5

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

  For a single-parameter tool with full schema coverage, read-only annotations, and an output schema, the description provides enough information to select and invoke the tool correctly: purpose, input method, expected outputs, and source context. A minor gap is the absence of explicit routing guidance between safety data and the other compound-focused sibling tools, but this is not essential for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents the cids parameter, including the 1-25 count and the resolution pointer to pubchem_search_compounds. The tool description itself adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  States a specific action ('Get'), a specific resource ('GHS hazard classification and safety data for one or more compounds by CID'), and enumerates the concrete return contents (signal word, pictograms, H-codes, P-codes). This clearly differentiates it from sibling tools like pubchem_get_compound_details or pubchem_get_summary.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use the tool: when GHS safety data for known CIDs is needed. It does not explicitly name sibling alternatives or state exclusions, but the domain-specific focus makes the intended use evident. The schema-level hint to resolve CIDs via pubchem_search_compounds adds further guidance.

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

• pubchem_get_bioactivityA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context about the type of data returned and the filtering workflow. Pagination and result-shape details are not in the description, but the schema and output schema carry that burden.

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

  Conciseness5/5

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

  Two sentences with a clear front-loaded purpose, followed by a compact enumeration of outputs and a practical example. Every clause earns its place, and there is no redundant restating of parameter names or schema content.

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

  Completeness5/5

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

  Given a rich input schema, output schema, and annotations, the description provides all essential context: what the tool returns, what filters exist, and how to frame a target-specific question. Nothing critical is missing for an agent to select and invoke it correctly.

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

  Parameters3/5

  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. The description adds a meaningful use case for combining targetGeneId and outcomeFilter, but it does not materially improve on the already-detailed parameter descriptions in the schema.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'Get a compound's bioactivity profile', then enumerates the concrete contents (assays, outcomes, target identifiers, quantitative values). This clearly distinguishes it from sibling tools such as get_compound_details or get_compound_interactions without needing to open the schema.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: retrieve a bioactivity profile and optionally filter by outcome or molecular target. The concrete example 'is this compound active against target T?' makes the intended use immediately actionable. It does not explicitly name exclusions or alternative sibling tools, but for a read-only profile query the context is clear.

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

• pubchem_get_compound_3d_structureA
  4.3/5.0
  Behavior4/5

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

  With annotations already marking the operation as read-only and idempotent, the description adds valuable behavioral context: it explains the json/sdf output split, the default-conformer semantics, the optional alternate-conformer listing, and the concrete limitation that not all compounds have computed 3D coordinates. This goes beyond what annotations alone convey.

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

  Conciseness5/5

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

  The description is compact and front-loaded: three sentences cover the core purpose, format behavior, optional alternate conformers, and a key caveat without any wasted words. Every sentence contributes actionable information.

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

  Completeness5/5

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

  Given the fully covered 100% schema, read-only annotations, and an output schema, the description need not restate return values or parameter details. It supplies the missing context—default-conformer behavior, format intent, alternate conformers, and data-availability caveats—making it sufficient for correct selection and invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the parameter descriptions already explain maxAtoms, maxBonds, includeRawSdf, and includeAlternateConformerIds in detail. The main description adds only light paraphrasing about format behavior and does not introduce significant new parameter semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Get a compound's default 3D conformer — atomic coordinates and bonds — for one CID.' This clearly distinguishes the tool from siblings that search compounds, fetch details, images, or safety data, while also specifying the single-CID scope.

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

  Usage Guidelines4/5

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

  The description gives clear guidance on when to use each format ('format="json"... returns atoms and bonds parsed... format="sdf" returns raw V2000 SDF text') and notes the single-CID scope. It does not explicitly contrast the tool with every sibling or state when not to use it, but the unique 3D-conformer purpose plus the schema's pointer to pubchem_search_compounds for CID resolution provide adequate context.

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

• pubchem_search_assaysA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. Beyond those annotations, the description discloses that results are returned as a paginated page of AIDs and that offset/maxResults control access to additional pages, which is useful behavioral context. It does not cover error behavior, but that is not required given the annotation coverage.

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

  Conciseness5/5

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

  The description is compact and front-loaded: it states the main purpose first, then supported query types, then return/pagination behavior in a short second sentence. Every clause carries useful information for an agent, and there is no filler or repetition of obvious details.

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

  Completeness5/5

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

  For a paginated search tool, the description covers the supported query identifier types, the result shape (AIDs), pagination semantics, and the next step via pubchem_get_summary. The input schema fully documents every parameter and includes examples, while the annotations cover safety characteristics, so an agent has everything needed to select and invoke this tool correctly.

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

  Parameters3/5

  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 because the schema already documents offset, maxResults, targetType, and targetQuery thoroughly. The description restates the identifier types and gives examples such as 'EGFR' and 'P00533', but those same examples appear in the schema's parameter descriptions. It adds little semantic information beyond reinforcing what the schema already provides.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Find PubChem bioassays associated with a biological target.' It also names the accepted identifier types and states it returns a page of assay IDs, which clearly separates it from sibling compound-search and summary tools. The pointer to pubchem_get_summary further establishes that this is the search stage, not the detail stage.

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

  Usage Guidelines4/5

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

  The description gives clear context for when this tool is appropriate: when searching by a biological target identifier and wanting assay IDs. It also provides helpful guidance on pagination and names pubchem_get_summary as the follow-up tool. However, it does not explicitly contrast with alternatives like pubchem_search_compounds or state when not to use this tool.

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

• pubchem_search_compoundsA
  4.3/5.0
  Behavior4/5

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

  The annotations already establish read-only, open-world, and idempotent behavior, so the bar is appropriately lower. The description adds useful behavioral context: results are returned as a page of CIDs, offset pagination reaches matches past maxResults, and property hydration can eliminate a follow-up call. No behavioral claims contradict the annotations.

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

  Conciseness5/5

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

  The description is compact at three sentences and front-loads the core search purpose before pagination and hydration details. Every sentence earns its place: search modes, output/paging behavior, and cross-tool optimization. There is no repetition of annotation or schema content beyond necessary orientation.

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

  Completeness5/5

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

  Given the tool's high complexity—11 parameters, five search modes, conditional requirements—the description, combined with the fully documented schema and existing output schema, is complete enough for correct invocation. The description explains the key output guarantee, pagination, and the optional hydration path. Nothing material is missing for an agent to select and call the tool correctly.

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

  Parameters3/5

  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 and the schema already documents every parameter with examples, defaults, constraints, and per-mode requirements. The main description adds little beyond the schema: it restates batching up to 25 identifiers and Hill notation, both of which already appear in the schema. This consistency is useful but does not meaningfully exceed the schema's parameter documentation.

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

  Purpose5/5

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

  The description identifies a specific resource, PubChem compounds, and a precise action, search, with five enumerated modes: identifier, formula, substructure, superstructure, and similarity. It clarifies the primary output as CIDs and distinguishes itself from the sibling details tool by noting that property hydration avoids a follow-up pubchem_get_compound_details call. This makes the tool's purpose unambiguous and distinct from the other PubChem siblings.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use this tool: when searching for compounds by identifiers, formula, structural containment, or similarity. It also provides one concrete routing cue—hydrate results with properties to avoid a second call to pubchem_get_compound_details. It does not explicitly enumerate exclusions or name all sibling alternatives, but the guidance is sufficient for typical agent selection.

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

• pubchem_get_compound_detailsA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses meaningful behavior: a 100-CID batch limit, paged synonyms/descriptions via offsets, a first-10-CID cap for descriptions and classification, and skippedCids reporting. This gives agents important execution expectations without contradicting the annotations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: purpose first, then return categories, then the batch cap. Every sentence contributes useful information, and detailed parameter behavior is appropriately delegated to the schema.

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

  Completeness5/5

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

  Given the read-only annotations, full parameter documentation, and an output schema, the description supplies the remaining contextual glue: batch limits, optional enrichment features, pagination behavior, and per-CID caps. An agent has enough information to select and invoke this tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the structured schema already fully documents every parameter. The tool description adds no parameter-level semantics beyond those already present in the schema; it only summarizes the available optional features at a high level.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('Get detailed compound information by CID') and enumerates exact return categories: physicochemical properties, textual descriptions, synonyms, drug-likeness, and pharmacological classification. This makes the tool's purpose unambiguous and clearly distinct from sibling tools like image, safety, or bioactivity lookups.

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

  Usage Guidelines4/5

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

  The 'by CID' framing implies use when CIDs are already known, and the cids parameter explicitly routes name/SMILES resolution to pubchem_search_compounds. It does not explicitly state when not to use this tool versus pubchem_get_summary or pubchem_get_safety, so it falls just short of a 5.

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

• pubchem_get_compound_xrefsA
  4.5/5.0
  Behavior5/5

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

  The description transparently discloses pagination behavior: results are paged per type, capped at maxPerType, total counts are reported, and offset advances past the current page. This adds valuable behavioral detail beyond the annotations' readOnly, idempotent, and openWorld hints.

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

  Conciseness5/5

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

  Two sentences communicate the core purpose first and then the essential paging behavior. Every clause adds information, with no repetition of schema content or filler.

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

  Completeness5/5

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

  For a read-only, idempotent tool with a full input schema, an output schema, and clear paging rules in the description, nothing needed for correct invocation is missing. The cid resolution pointer is already present in the schema, and the output schema handles return-value details.

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

  Parameters3/5

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

  The input schema already provides 100% parameter coverage with detailed descriptions for cid, offset, xrefTypes, and maxPerType. The description adds a helpful human-readable gloss of the xref type categories, but most parameter meaning is already carried by the schema, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Get external database cross-references for a compound,' then enumerates the covered reference types (PubMed, patents, genes, registry numbers, taxonomy). This clearly distinguishes it from sibling compound tools like details, image, and safety.

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

  Usage Guidelines4/5

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

  The description clearly establishes this tool's context as fetching external cross-references, which implicitly tells an agent when to select it over sibling tools that handle details, images, or bioactivity. It does not explicitly name alternatives or exclusion conditions, but the resource-specific language gives adequate directional guidance.

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