Identify integer sequences by terms, search the OEIS, read formulas, programs, b-files, cross-refs.
Scored across 6 tools
Each tool targets a distinct operation: full entry retrieval, term listing, cross-references, term-based identification, keyword search, and vocabulary lookup. Potential overlap between oeis_get_sequence (which includes xrefs and data-line terms) and the dedicated cross-refs/terms tools is explicitly clarified by pagination and b-file semantics in the descriptions.
Every tool follows the same oeis_verb_noun snake_case pattern (get_cross_refs, get_sequence, get_terms, identify_sequence, list_reference, search_sequences). No mixing of conventions or vague verbs.
Six tools is well-scoped for a read-only reference database, with each tool covering a clear facet (search, fetch, terms, xrefs, identify, help). Nothing feels redundant or missing at the count level.
The surface covers the natural lifecycle of a read-only database: discovery (search), retrieval (sequence, terms, cross-refs), reverse lookup (identify), and self-documentation (reference). Pagination and section-selection parameters handle large entries, so there are no obvious 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 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, 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. |
| 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. |
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.
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.
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.
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.
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.
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.
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. 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, 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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond those: the page size ('Returns up to 10 summaries per page'), which tells the agent how much each call yields and motivates pagination. Auth/permission and rate-limit behavior remain unstated, so it is not a 5.
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 core action and syntax before the return-size note and sibling routing. The syntax enumeration is dense but each element earns its place; nothing is 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 values need not be explained, and the description covers syntax, pagination size, offset continuation via the schema, and sibling routing. The only gap is the absence of any note on result limits per query or authentication, but the definition is otherwise sufficient for correct invocation.
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, and the schema already documents sort, query examples, and the start offset semantics. The description adds value by enumerating the query operators the schema only points to by reference ('| for OR', leading '-' to exclude) and the full prefix set, giving the agent actionable syntax detail beyond the schema.
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 (Search) and resource (OEIS sequences), then defines that search's syntax surface concretely with plain words, quoted phrases, prefixes, and operators. It explicitly distinguishes itself from the term-matching sibling by naming oeis_identify_sequence as the route for identifying a sequence from its terms.
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?
Gives a clear routing condition: use oeis_identify_sequence when identifying a sequence from its terms, implying this tool is for query-driven discovery. It covers the alternative route but does not address the other siblings (oeis_get_sequence, oeis_get_terms, oeis_get_cross_refs) or explicit when-not-to-use conditions, so it stops short of full 5-level guidance.
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_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.
