oeis-mcp-server

Get OEIS Sequence Terms

oeis_get_terms

Read-onlyIdempotent

List terms a(n) of a sequence with their indices n. Reads the entry's b-file when it has one — often thousands of terms beyond the data line — and otherwise the data line itself. Values are exact decimal strings of any size. A slice stops at limit terms, at about 100,000 bytes, or at the end of one 1 MiB part of a larger b-file, whichever comes first; nextFromIndex continues it.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of terms to return, 1–1000 (default 100). A slice stops sooner at about 100,000 bytes of large terms or at the end of one 1 MiB part of a larger b-file; continue with nextFromIndex.
`aNumber`	Yes	OEIS A-number, e.g. "A000045"; oeis_identify_sequence and oeis_search_sequences return them. Also accepts "a000045", "A45", "45", and an oeis.org sequence URL; all normalize to the zero-padded form. Legacy M/N book numbers (e.g. "M1459") are not A-numbers: find them with oeis_search_sequences.
`fromIndex`	No	First index n to return; defaults to the first available index. Pass nextFromIndex from the previous call to continue.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The limit that was applied.
`url`	No	Sequence page on oeis.org; cite it wherever the terms are reused.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Terms in this slice.
`terms`	No	Terms in index order, from the first index at or after fromIndex (or the first available index).
`notice`	No	Guidance: where the next slice starts and whether the byte budget ended this one, why no terms came back (past the last index, or not yet reached in a large b-file), that a b-file line too long to read was skipped, that only the first 1 MiB of the b-file could be read, or that the terms are data-line only.
`source`	No	bfile: read from the entry's b-file of extended terms. data: the entry has no b-file, so these are its data-line terms.
`aNumber`	No	A-number, e.g. "A000045".
`bFileCut`	No	True while the b-file goes on past lastAvailableIndex. Its later terms are at bFileUrl; nextFromIndex or a larger fromIndex reaches them unless the notice says only the first 1 MiB was read.
`bFileUrl`	No	URL of the b-file the terms came from; absent when source is data.
`truncated`	No	True when nextFromIndex is set.
`nextFromIndex`	No	Pass as fromIndex for the next slice. Absent when no slice follows this one: the terms ended, or the notice says how to reach the rest.
`bFileSizeInBytes`	No	Full size of the b-file as OEIS reported it; absent when not reported.
`lastAvailableIndex`	No	Highest index n read so far for this entry; when bFileCut is true the b-file goes on past it. Absent when no terms were read.
`firstAvailableIndex`	No	Lowest index n read for this entry; absent when no terms were read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already mark this read-only/idempotent, yet the description goes further and discloses the real mechanics: it prefers the entry's b-file over the data line, may return thousands of terms, returns exact arbitrary-precision decimal strings, and truncates at limit terms / ~100,000 bytes / one 1 MiB b-file part with nextFromIndex for continuation. That is exactly the beyond-annotation detail an agent needs to page correctly.

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?

Four dense sentences, front-loaded with the primary action and then the b-file/limit mechanics; each sentence carries real information. The final sentence is long but justifies its length by packing three distinct stop conditions plus the continuation hint.

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?

With an output schema present, return values need not be explained, yet the description still clarifies value format (exact decimal strings) and paging semantics. Combined with fully-covered parameters and clear annotations, an agent has everything needed to call and paginate 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 schema already documents limit, aNumber, and fromIndex (including the default range and nextFromIndex continuation). The description adds little parameter detail beyond restating the slicing cap; note it says 'nextFromIndex' where the actual parameter is 'fromIndex', relying on the schema to make the link.

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

Purpose4/5

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

States a specific verb+resource: 'List terms a(n) of a sequence with their indices n', which is clearly distinct from fetching entry metadata. However, it never names a sibling tool (e.g. oeis_get_sequence vs oeis_get_terms), so differentiation from siblings must be inferred; sibling routing only appears in the schema's aNumber description.

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?

Usage is implied — fetch the terms of a known A-number — and the description explains the continuation pattern (nextFromIndex) for paged reading. But it gives no explicit when-to-use vs. when-not, and does not point to oeis_get_sequence for non-term data or to oeis_search_sequences when the A-number is unknown.

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

All oeis-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.