Identify integer sequences by terms, search the OEIS, read formulas, programs, b-files, cross-refs.
Scored across 6 tools
The six tools target distinct entry points: search, identify, fetch-entry, fetch-terms, cross-refs, and vocabulary lookup, and descriptions explicitly steer users (e.g. identify vs search). There is mild overlap since oeis_get_sequence returns cross-reference data-line terms that oeis_get_cross_refs and oeis_get_terms surface in richer, paged form, but boundaries are explained.
Every tool follows the same oeis_<verb>_<noun> pattern (get_cross_refs, get_sequence, get_terms, identify_sequence, list_reference, search_sequences). Consistent snake_case with a uniform server prefix and clear verb-noun pairing throughout.
Six tools is well-scoped for a read-only reference database: search, identify, entry lookup, terms, cross-refs, and vocabulary. Each tool earns its place with no redundant or filler operations.
The surface covers the full OEIS lifecycle: discovering sequences (search), identifying from terms (identify), retrieving entries (get_sequence), pulling term values (get_terms), exploring relations (get_cross_refs), and resolving vocabulary (list_reference). Since OEIS is inherently read-only, no write operations are missing, so there are no dead ends.
List sequences related to an OEIS entry. direction outgoing returns the A-numbers named in the entry's cross-reference (Cf.) lines, with any parenthetical note beside each; direction incoming returns entries that mention this A-number anywhere. Each row carries the related sequence's name and first terms. 10 rows per page.
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | Row offset: 0, 10, … 100 (at most 110 rows are reachable per entry and direction). Pass nextStart from the previous page. | |
| 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. | |
| direction | No | outgoing (default): the A-numbers this entry cross-references. incoming: the entries that mention this A-number. | outgoing |
| Name | Required | Description |
|---|---|---|
| cap | No | Page size: 10, fixed by OEIS. |
| error | No | Present when the call failed. Absent on success. |
| lines | No | Outgoing only: the entry's cross-reference lines verbatim, written by OEIS contributors; lineIndex points into this list. |
| shown | No | Rows on this page. |
| start | No | The row offset of this page. For incoming, as OEIS served it: below the requested start when that start was past the last entry (OEIS then serves the last page). |
| notice | No | Guidance: why nothing matched, how to narrow the query, or how to reach the next page. |
| aNumber | No | The entry whose relations are listed, e.g. "A000045". |
| related | No | Related sequences on this page: outgoing in order of first mention, incoming in OEIS relevance order. |
| direction | No | The direction listed. |
| nextStart | No | Pass as start for the next page; absent on the last reachable page. |
| truncated | No | True when more rows exist than this page shows. |
| totalCount | No | Total rows: the match count OEIS reported, or for outgoing cross-references the number of distinct A-numbers the entry names. |
| effectiveQuery | No | The query as OEIS parsed it (lowercased upstream), e.g. seq:1,2,5,14,42. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, yet the description still adds real behavior: page size ('10 rows per page'), what each row contains, and what the outgoing mode includes (parenthetical notes). It does not mention rate limits or auth, but for a read-only lookup tool that is a minor omission.
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?
Four short sentences, zero filler, and the core capability is front-loaded before the mode semantics. The pagination fact is included economically rather than as its own paragraph.
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?
With an output schema present the description need not explain return values, and it nonetheless sketches the row shape. Combined with the direction semantics and page-size note, an agent has enough to call this correctly; only sibling disambiguation is absent.
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 100% and the schema itself already documents start, aNumber normalization, and the direction enum, so baseline is 3. The description adds only marginal detail beyond that, mainly the parenthetical-note behavior for outgoing, which the schema does not state.
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 ('List sequences related to an OEIS entry') and splits the behavior into two clearly defined modes, so an agent can tell it apart from oeis_get_sequence or oeis_get_terms. It never names a sibling tool to sharpen the boundary, which keeps it short of a 5.
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?
The direction semantics ('outgoing returns the A-numbers named in the Cf. lines' vs 'incoming returns entries that mention this A-number anywhere') give clear context for choosing the right mode. It offers no guidance about when to prefer this tool over sibling tools such as oeis_list_reference or oeis_search_sequences, and states no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one OEIS entry by A-number. Returns the name, data-line terms, offset, keywords, author, dates, and the sections: comments, formulas (recurrences and generating functions), examples, programs (Maple, Mathematica, PARI, Python, …), references, links, cross-references, and extensions. When the sections together exceed 24,000 characters of serialized JSON, the core fields come back with a section outline instead; call again with sections to pick what to read. A selection past 100,000 bytes comes back in parts cut between items: pass nextFromItem as fromItem, with the same sections, for the next part.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| fromItem | No | Where to resume a cut selection: the previous response's nextFromItem, passed unchanged with the same sections. The selected sections before fromItem.section are left out. Omit to start at the beginning. | |
| sections | No | Sections to return with the core fields, e.g. ["formulas", "programs"]. A selection past the 100,000-byte response budget is cut between items; fromItem continues it. Omit (or pass []) for the full entry, or the core fields plus an outline when the entry is large. |
| Name | Required | Description |
|---|---|---|
| url | No | Sequence page on oeis.org; cite it wherever the entry is reused. |
| kind | No | full: every section, or the selected ones (a selection past the 100,000-byte response budget is cut between items, and nextFromItem continues it). outline: the entry is too large, so sections lists the sections to request by name. |
| name | No | Sequence name, written by OEIS contributors. |
| error | No | Present when the call failed. Absent on success. |
| links | No | Link lines. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| terms | No | Data-line terms as exact decimal strings, signs kept; the first is a(firstIndex). |
| author | No | Author line as OEIS records it; absent when the entry has none. |
| notice | No | Guidance: the entry is withdrawn (dead) or its A-number reserved or recycled; where a cut selection stopped and the call that continues it; or that fromItem lies past the end of its section. |
| offset | No | Offset "i,p": i is the index n of the first term, p the 1-based position of the first term with |a(n)| > 1. Absent on a reserved or recycled A-number (keyword allocated or recycled). |
| aNumber | No | A-number, e.g. "A000045". |
| created | No | When the entry was created, ISO 8601 with offset. |
| bFileUrl | No | URL of the entry's b-file of extended terms; oeis_get_terms reads it. |
| comments | No | Comment lines, one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| examples | No | Example lines; whitespace matters for triangles and tables, one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| formulas | No | Formula lines: recurrences, generating functions, closed forms, one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| keywords | No | Keyword flags such as nonn, core, tabl; oeis_list_reference topic keywords decodes them. |
| modified | No | When the entry was last edited, ISO 8601 with offset. |
| programs | No | Programs that compute the terms. Present on a full entry or when selected; a cut selection carries only this part's blocks. |
| revision | No | Revision number of the entry. |
| sections | No | Outline only: the sections of the entry, largest first. |
| legacyIds | No | Legacy book numbers, e.g. ["M0692", "N0256"]; absent on entries that have none. |
| extensions | No | Extension lines: who added terms or corrections, and when, one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| firstIndex | No | The index n of the first term (the first number of offset); absent with offset. |
| references | No | Reference lines (books and papers), one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
| nextFromItem | No | Present when the selection was cut at the 100,000-byte response budget: the first item left out. Pass it unchanged as fromItem, with the same sections, to continue. |
| outlineNotice | No | Outline only: how to request sections, and how a large selection continues. |
| referenceCount | No | How many OEIS entries mention this A-number, the entry itself included. |
| crossReferences | No | Cross-reference lines naming related A-numbers, one element per upstream line, written by OEIS contributors. Present on a full entry or when selected; a cut selection carries only this part's lines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly/idempotent/openWorld), and the description goes well beyond them by disclosing two non-obvious behaviors: the 24,000-character threshold that degrades the response to core fields plus a section outline, and the 100,000-byte budget that cuts responses between items requiring nextFromItem to resume. This is exactly the operational context annotations cannot provide.
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?
Three front-loaded sentences: identification, payload contents, then the two truncation/pagination rules. Efficient, though the section/outline behavior is stated once in the description and again across the schema, producing mild redundancy.
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?
For a read tool with an output schema, the description covers everything an agent needs to call it correctly and to handle the truncation/pagination loop, which is the only real complexity. No return-value explanation is needed since the output schema exists.
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 description coverage is 100% and already documents aNumber normalization, sections, and fromItem, so the baseline is 3. The description adds real interaction semantics not in the schema: the outline fallback tied to omitting sections, and the requirement to pass nextFromItem 'with the same sections' when continuing a cut response.
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 ('Fetch one OEIS entry by A-number') and enumerates exactly what the entry contains. An agent can distinguish it from siblings like oeis_get_terms (terms only) or oeis_get_cross_refs (cross-references only) without opening the schema.
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?
Usage is implied rather than stated: the schema note points to oeis_identify_sequence and oeis_search_sequences as sources of A-numbers, and to oeis_search_sequences for legacy M/N numbers, but the description never says when to prefer this tool over the other lookup siblings or what preconditions exist. Guidance is present but indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 most 1000 per call), 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of terms to return (default 100). One call returns at most 1000, so a larger limit is served as 1000. 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied: limit, or 1000 when limit is larger. |
| 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, how many lines of the b-file part this slice comes from are not n a(n) pairs and were 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, the description discloses real operational traits: b-file vs data-line sourcing, exact decimal strings of arbitrary size, three distinct slice-stop conditions (limit, ~100,000 bytes, end of a 1 MiB b-file part), and the nextFromIndex continuation mechanism. This is exactly the kind of behavior 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all load-bearing, with the core purpose front-loaded before the sourcing and slicing details. Nothing is redundant padding.
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?
With an output schema present, return shape need not be explained; the description still covers sourcing, value format, truncation behavior, and continuation, which is everything an agent needs to call and page this tool correctly.
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 description coverage is 100%, so the schema already documents aNumber, limit, and fromIndex in detail. The description restates the 1000-term cap and the byte/part stop conditions but adds no syntax or format detail the schema lacks, so the baseline 3 applies.
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?
The description opens with a specific verb and resource: 'List terms a(n) of a sequence with their indices n.' That is distinguishable from oeis_get_sequence (entry metadata) and oeis_search_sequences (finding sequences) without opening any schema.
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?
Usage is implied rather than stated: the description explains that it reads the b-file when present and the data line otherwise, which hints at when the tool is useful. However, it never explicitly names oeis_get_sequence or any sibling as the alternative for metadata or for finding sequences, and gives no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify integer sequences that contain a run of consecutive terms, e.g. "1, 2, 5, 14, 42". Returns up to 10 matches per page in OEIS relevance order, each with the index n at which the supplied run begins. For the best hit rate supply about 6 terms and leave off the first one or two, since sources disagree on where a sequence starts. OEIS matches only the first terms of each entry (its data line, at most about 270 characters), not its b-file, so a run from far into a sequence is not found. Takes up to 60 terms, each an integer of at most 200 digits or the wildcard _ for one unknown term.
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | Result offset: 0, 10, … 100 (OEIS shows at most 110 results per query). Pass nextStart from the previous page. | |
| terms | Yes | Up to 60 consecutive terms separated by commas or spaces, e.g. "1, 2, 5, 14, 42" (a bracketed list or a trailing ... is accepted). Each term is an integer of at most 200 digits, or _ for a single unknown term. | |
| matchSigns | No | false (default) matches ignoring signs, so a sign-convention difference does not hide the sequence; true requires the signs to match. |
| Name | Required | Description |
|---|---|---|
| cap | No | Page size: 10, fixed by OEIS. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Rows on this page. |
| start | No | The result offset of this page as OEIS served it; below the requested start when that start was past the last result (OEIS then serves the last page). |
| notice | No | Guidance: why nothing matched, how to narrow the query, or how to reach the next page. |
| results | No | Candidate sequences on this page, in OEIS relevance order. |
| nextStart | No | Pass as start for the next page; absent on the last reachable page. |
| truncated | No | True when more rows exist than this page shows. |
| totalCount | No | Total rows: the match count OEIS reported, or for outgoing cross-references the number of distinct A-numbers the entry names. |
| effectiveQuery | No | The query as OEIS parsed it (lowercased upstream), e.g. seq:1,2,5,14,42. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint/idempotentHint already covering the safety profile, the description adds real behavioral context: up to 10 matches per page in relevance order, each with the index n, and the key limitation that only the data line (~270 chars) is matched, not the b-file. It omits return-shape and rate-limit details, but the matching limitations are the substantive disclosure.
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?
Front-loads the core purpose in the first clause, then layers example, pagination, tuning tip, and the data-line caveat. Dense but every sentence carries information; sizing is appropriate for a matching tool with subtle failure modes.
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?
Given an output schema exists, return values need not be explained, yet the description still covers ordering, page size, and the index-n field. Combined with the matching-limitation warning and input constraints, an agent has everything needed to call this correctly.
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 100%, so the baseline is 3, but the description adds non-obvious semantics: supplying terms from deep inside a sequence will not match because only the leading data line is searched, and the wildcard _ covers one unknown term. That tuning insight goes beyond the raw field documentation.
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: 'Identify integer sequences that contain a run of consecutive terms', with a concrete example. The function and input shape are unambiguous, though it never names the sibling tools (search_sequences, get_sequence) to draw the contrast explicitly.
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?
Provides actionable tuning guidance ('supply about 6 terms and leave off the first one or two') that materially improves results. It stops short of saying when to prefer this over search_sequences or get_sequence, so it gives clear context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up OEIS vocabulary used by the other tools: keyword flags (nonn, core, tabl, cons, …), search syntax (prefixes, operators, wildcards, sort orders, paging window), and identifier conventions (A-numbers, legacy M/N numbers, offsets, b-files).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | keywords: keyword flags such as nonn, core, tabl. search_syntax: prefixes, operators, wildcards, sort orders, and paging. identifiers: A-numbers, legacy M/N numbers, offsets, and b-files. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notes | No | Usage notes that apply across the topic. |
| topic | No | The topic listed. |
| entries | No | Vocabulary entries for the topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the agent knows this is a safe, repeatable, closed lookup. The description adds only that the content is a static vocabulary list, which mildly reinforces the read-only nature but discloses nothing about the form or depth of the returned reference material.
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?
A single front-loaded sentence with a precise colon-delimited inventory; no filler, no restatement of the title, and the three categories align directly with the enum values.
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?
An output schema exists, so return values need no explanation, and the single enum parameter is fully documented. It is complete for its scope, though one clause pointing at the sequence-oriented siblings would make the routing unambiguous.
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 description coverage is 100% and the enum's own description enumerates keywords, search_syntax, and identifiers in the same terms the description uses. The description therefore restates schema content rather than adding new semantics, so the baseline 3 applies.
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 (look up) and resource (OEIS vocabulary/reference material) and immediately scopes it to what 'the other tools' consume, which separates it from sequence-retrieval siblings like oeis_get_sequence and oeis_search_sequences. It does not name a sibling explicitly, so it falls just short of a 5.
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?
The phrase 'used by the other tools' implies this is a supporting reference to consult when interpreting keywords or search syntax from those tools, but it never states when to call it versus those siblings or any prerequisite/exclusion. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the OEIS using its query syntax: plain words, "quoted phrases", comma-separated terms, prefixes (keyword:, author:, name:, comment:, formula:, program:, xref:, id:), | for OR, and a leading - to exclude. Returns up to 10 summaries per page. For identifying a sequence from its terms, oeis_identify_sequence is the direct route.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result order: relevance (default), number (ascending A-number), created (newest entry first), or modified (most recently edited first). | relevance |
| query | Yes | OEIS query, sent as written. Examples: keyword:core fibonacci; author:Sloane; "Catalan numbers" (a quoted phrase); 1,2,5,14,42 (separate terms with commas: with spaces alone, a negative term after the first starts a new run and fewer than three numbers are not joined). oeis_list_reference topic search_syntax lists the prefixes and operators. | |
| start | No | Result offset: 0, 10, … 100 (OEIS shows at most 110 results per query). Pass nextStart from the previous page. |
| Name | Required | Description |
|---|---|---|
| cap | No | Page size: 10, fixed by OEIS. |
| sort | No | The result order applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Rows on this page. |
| start | No | The result offset of this page as OEIS served it; below the requested start when that start was past the last result (OEIS then serves the last page). |
| notice | No | Guidance: why nothing matched; that OEIS split the numbers into separate searches, and how to join them with commas into one run; how to narrow the query; or how to reach the next page. |
| results | No | Matching sequences on this page, in the applied order. |
| nextStart | No | Pass as start for the next page; absent on the last reachable page. |
| truncated | No | True when more rows exist than this page shows. |
| totalCount | No | Total rows: the match count OEIS reported, or for outgoing cross-references the number of distinct A-numbers the entry names. |
| effectiveQuery | No | The query as OEIS parsed it (lowercased upstream), e.g. seq:1,2,5,14,42. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds behavioral context beyond them: result volume ("up to 10 summaries per page") and the shape of the query language, which helps an agent predict output. Auth requirements and rate limits are not mentioned.
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, front-loaded with the syntax spec and closing with the sibling routing rule. The prefix enumeration is dense but directly actionable; no sentence is filler.
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?
Covers query syntax, result volume, and alternative routing, while an output schema exists to carry return-value details and the input schema documents sort/start/pagination. Nothing an agent needs to call this correctly is missing.
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 description coverage is 100%, so the baseline is 3. The description earns extra credit by enumerating the concrete prefixes (keyword:, author:, name:, comment:, formula:, program:, xref:, id:) that the schema defers to an external reference topic, giving the agent usable syntax without a second lookup. It says nothing extra about sort or start.
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 ("Search the OEIS using its query syntax") and immediately differentiates itself from oeis_identify_sequence as the identification route. An agent can distinguish this from all siblings without opening a schema.
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?
Explicitly routes term-based identification to oeis_identify_sequence, which is the primary ambiguity for this family. It does not mention the other siblings (oeis_get_sequence, oeis_list_reference) or state when-not to use plain search, so guidance is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
oeis_get_terms6 fields changedInput schema / properties / limit / descriptionPrevious value: -"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."New value: +"Maximum number of terms to return (default 100). One call returns at most 1000, so a larger limit is served as 1000. 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."Input schema / properties / limit / maximumPrevious value: -1000New value: +9007199254740991Output schema / properties / cap / descriptionPrevious value: -"The limit that was applied."New value: +"The limit that was applied: limit, or 1000 when limit is larger."Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `sequence_not_found`: No OEIS entry exists for the requested A-number. `pacer_shed`: The oeis.org request queue would exceed its wait budget. `upstream_rate_limited`: oeis.org answered HTTP 429 Too Many Requests on the b-file or the record and retries within the call did not clear it. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `sequence_not_found`: No OEIS entry exists for the requested A-number. `pacer_shed`: The oeis.org request queue would exceed its wait budget. `upstream_rate_limited`: oeis.org answered HTTP 429 Too Many Requests on the b-file or the record and retries within the call did not clear it. `upstream_unparseable`: oeis.org answered with a body that is not a b-file or a sequence record (an HTML maintenance page, a b-file with no n a(n) line, or a record in an unknown shape) and retries within the call did not clear it. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "sequence_not_found",
- "pacer_shed",
- "upstream_rate_limited"
-]New value: +[
+ "sequence_not_found",
+ "pacer_shed",
+ "upstream_rate_limited",
+ "upstream_unparseable"
+]Output schema / properties / notice / descriptionPrevious value: -"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."New value: +"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, how many lines of the b-file part this slice comes from are not n a(n) pairs and were skipped, that only the first 1 MiB of the b-file could be read, or that the terms are data-line only."oeis_search_sequences2 fields changedInput schema / properties / query / descriptionPrevious value: -"OEIS query, sent as written. Examples: keyword:core fibonacci; author:Sloane; \"Catalan numbers\" (a quoted phrase); 1,2,5,14,42. oeis_list_reference topic search_syntax lists the prefixes and operators."New value: +"OEIS query, sent as written. Examples: keyword:core fibonacci; author:Sloane; \"Catalan numbers\" (a quoted phrase); 1,2,5,14,42 (separate terms with commas: with spaces alone, a negative term after the first starts a new run and fewer than three numbers are not joined). oeis_list_reference topic search_syntax lists the prefixes and operators."Output schema / properties / notice / descriptionPrevious value: -"Guidance: why nothing matched, how to narrow the query, or how to reach the next page."New value: +"Guidance: why nothing matched; that OEIS split the numbers into separate searches, and how to join them with commas into one run; how to narrow the query; or how to reach the next page."oeis_get_cross_refsoeis_get_sequenceoeis_get_termsoeis_identify_sequenceoeis_list_referenceoeis_search_sequencesSearch INSPIRE-HEP papers, authors, experiments, HEPData records; get citation metrics and BibTeX.
Find IANA ports, MIME types, HTTP codes/fields, URI schemes, PENs, BCP 47 tags, RFCs, any registry.
Integrates Wolfram Language and Wolfram|Alpha accessing curated data and sophisticated algorithms.
Search Wikipedia, read summaries and full text, target sections, find nearby pages, list languages.
Add one secure layer between your agents and this server.
