scholar-mcp

Get Standard

get_standard

Read-only

Resolve fuzzy or canonical standard identifiers to retrieve authoritative records, optionally downloading full text via docling for in-depth access.

Instructions

Retrieve a standard by identifier (canonical or fuzzy).

Resolves fuzzy inputs (e.g. "rfc9000", "nist 800-53") to their canonical form before fetching. With fetch_full_text=True and docling configured, downloads and converts the full text.

With fetch_full_text=True the docling conversion takes minutes, so such a call returns a job handle to poll with get_job_result rather than the record itself. Without it, and on a cache hit, the record comes back directly.

A conversion that fails still returns the record, with the reason in full_text_error; full_text_url is there to fetch by hand. No full_text and no full_text_error means none was on offer, or docling is not configured — neither is worth retrying.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`identifier`	Yes	Canonical or fuzzy standard identifier.
`fetch_full_text`	No	If True and docling is configured, download and convert the full text PDF/HTML via docling.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.10.0Sep 8, 2026
- addedOutput schema / additionalProperties
```
Added value: +true
```
- removedOutput schema / properties
```
Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}
```
- removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
- removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```
First observedv1.9.0Aug 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint annotation by explaining the async behavior (job handle), the failure mode (full_text_error), and the meaning of absent full_text/full_text_error. This covers side effects and edge cases clearly.

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

Conciseness4/5

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

The description is well-structured in short paragraphs and each sentence adds value. It is slightly verbose but not redundant, earning a high score for its efficient use of words.

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?

The description fully covers the conditional return behavior (job handle vs. record), error states, and configuration prerequisites. Given the output schema exists and no nested objects are mentioned, this is sufficiently complete for an agent to call correctly.

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

Parameters4/5

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

Schema coverage is 100% for both parameters, but the description adds operational meaning (e.g., 'if True and docling is configured' and the distinction between canonical and fuzzy identifiers), enriching the schema beyond the baseline.

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 the verb 'Retrieve' and the resource 'standard' clearly, and distinguishes from siblings like search_standards and resolve_standard_identifier by emphasizing retrieval by identifier (canonical or fuzzy).

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 conditional guidance for fetch_full_text (returns a job handle when true, with docling configured) and mentions polling via get_job_result. Does not explicitly name alternative tools for when not to use this tool, but the conditions are reasonably explicit.

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