scholar-mcp

Get Standard

get_standard

Read-only

Fetches a standard by canonical or fuzzy identifier, resolving inputs like rfc9000 to their canonical form. Optionally downloads and converts the full text, returning a job handle for polling.

Instructions

Retrieve a standard by identifier (canonical or fuzzy).

Resolves fuzzy inputs (such as rfc9000 or 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.

NIST SP and NISTIR publications are catalogued per revision, so an identifier with no revision, such as NIST SP 800-53, can come back not_found even though the publication exists. search_standards lists the revisions that are published.

not_found means the source answered and holds no such standard: stop asking about that identifier. A lookup that never got an answer says so instead, as rate_limited (with retryable) or upstream_error with the status and what went wrong. Both are worth retrying: the standard may well exist.

Full text is returned in pages of at most 20,000 characters. When next_offset is present, call this tool again with that value as text_offset; the cached conversion makes later pages inexpensive. Set max_chars to null only when the client can accept the complete document in one response.

Input Schema

Name	Required	Description
`max_chars`	No	Maximum full-text characters to return, capped at 20,000. Pass ``null`` for the complete text.
`identifier`	Yes	Canonical or fuzzy standard identifier.
`text_offset`	No	Character offset at which the full-text page starts.
`fetch_full_text`	No	If True and docling is configured, download and convert the full text PDF/HTML via docling.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.1.1Nov 5, 2026

addedInput schema / properties / max_chars

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": 20000,
+  "description": "Maximum full-text characters to return, capped at 20,000.\nPass ``null`` for the complete text."
+}

addedInput schema / properties / text_offset

Added value: +{
+  "default": 0,
+  "description": "Character offset at which the full-text page starts.",
+  "type": "integer"
+}

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.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint, openWorldHint and destructiveHint=false; the description goes well beyond them by disclosing that docling conversion takes minutes and returns a pollable job handle, that failures still return the record with full_text_error and full_text_url, and that a missing full_text plus missing error means nothing was on offer. It also explains the per-revision cataloguing quirk that produces spurious not_found results.

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?

Front-loaded with purpose and fuzzy resolution, then layered into conversion behavior, error taxonomy, and pagination — each block carries distinct operational value. It is long, and the fetch_full_text/docling conversion is introduced twice (once as capability, once as latency/job-handle consequence), which costs a point.

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 four-parameter tool with an output schema, this covers everything an agent needs: latency expectations, job-handle indirection, error classification, retry decisions, and multi-call pagination. Nothing about calling it correctly is left to inference.

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%, so the baseline is 3, and the description earns above that by tying parameters to behavior the schema cannot express: fetch_full_text changes the return shape (job handle vs record), text_offset pairs with the returned next_offset, and max_chars=null is only safe for clients that accept a whole document. The 20,000-character cap is restated from the schema, which is the only redundancy.

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 verb and resource ("Retrieve a standard by identifier") and immediately scopes the identifier domain to canonical-or-fuzzy. The mention of search_standards for revision enumeration separates it from the sibling search tool, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit routing rules: use get_job_result when fetch_full_text returns a job handle, use search_standards to find revisions, and use text_offset with next_offset for pagination. It also spells out retry policy per outcome — not_found is terminal, rate_limited and upstream_error are retryable — which is exactly the when/when-not guidance the dimension asks for.

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