Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-oeis search for sequence starting with 1,1,2,3,5,8"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the OEIS (Online Encyclopedia of Integer Sequences) API
mcp-name: io.github.daedalus/mcp-oeis
pip install mcp-oeisRelated MCP server: ls-apis-mcp
Configure in your MCP settings:
{
"mcpServers": {
"mcp-oeis": {
"command": "mcp-oeis"
}
}
}from mcp_oeis import mcp
# Get a sequence by ID
result = mcp.get_sequence_by_id("A000109")
print(result["terms"]) # [1, 1, 1, 2, 5, 14, ...]
# Search by terms
results = mcp.search_by_terms([1, 1, 2, 3, 5, 8])
print(results[0]["name"]) # "Fibonacci numbers"
# Search by name
results = mcp.search_by_name("prime")
print(results[0]["id"]) # "A000040"Get a sequence by its OEIS ID (e.g., "A000109" for simplicial polyhedra, "A000045" for Fibonacci).
Search OEIS sequences by providing integer terms. For example, searching [1,1,2,3,5,8] will find the Fibonacci sequence.
Search OEIS sequences by name or keyword. For example, searching "Fibonacci" will find Fibonacci-related sequences.
git clone https://github.com/daedalus/mcp-oeis.git
cd mcp-oeis
pip install -e ".[test]"
# run tests
pytest
# format
ruff format src/ tests/
# lint
ruff check src/ tests/
# type check
mypy src/Get a sequence by its OEIS ID (e.g., "A000109" for simplicial polyhedra, "A000045" for Fibonacci).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The OEIS ID (e.g., "A000109", "A000045") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It lacks behavioral details such as read-only nature, error handling for invalid IDs, rate limits, or output format. Only the basic action is stated.
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?
The description is a single sentence that front-loads the core action, includes examples, and contains no superfluous information. Every word earns its place.
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 the tool's simplicity (1 parameter) and the presence of an output schema, the description adequately covers the purpose and usage context. No additional details are necessary for this straightforward lookup tool.
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% for the single parameter 'id', and the description adds value by providing example IDs, which aids the agent in understanding the expected format beyond the schema's description.
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 clearly states the tool's purpose: 'Get a sequence by its OEIS ID' with concrete examples (e.g., 'A000109', 'A000045'), distinguishing it from sibling tools like search_by_name and search_by_terms which are for searching rather than direct lookup.
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 description implies usage when you have an OEIS ID, but lacks explicit guidance on when to use alternatives (e.g., 'Use search_by_name if you don't know the ID'). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OEIS sequences by name or keyword.
For example, searching "Fibonacci" will find Fibonacci-related sequences.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., "Fibonacci", "prime", "Catalan") | |
| max_results | No | Maximum number of results to return (default 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not mention whether the search is read-only, any rate limits, or side effects. It only states the basic function without behavioral context.
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?
The description is two sentences long, front-loaded with the action and a useful example. No extraneous information.
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 the presence of an output schema and the simplicity of the tool, the description is largely complete. It could Mention that results are sorted or how many results are returned, but the output schema likely covers this.
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% for both parameters, but the description only adds an example for the 'query' parameter (e.g., 'Fibonacci'). It does not elaborate on the meaning of 'max_results' beyond what is in the schema. Thus, it provides minimal added value.
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 clearly states the tool searches OEIS sequences by name or keyword with a concrete example. The name 'search_by_name' further reinforces this purpose, and it is easily distinguishable from sibling tools like 'get_sequence_by_id' and 'search_by_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?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or limitations. The example gives implicit context but does not compare to search_by_terms or get_sequence_by_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OEIS sequences by providing integer terms.
For example, searching [1,1,2,3,5,8] will find the Fibonacci sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes | List of integers to search for (e.g., [1,1,2,3,5,8]) | |
| max_results | No | Maximum number of results to return (default 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the search behavior and provides an example, but lacks details on whether the operation is read-only, authentication needs, rate limits, or what happens if no matches found. The example helps, but more behavioral context would be beneficial.
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?
The description is concise with two sentences, front-loading the purpose and immediately providing a concrete example. Every sentence adds value without 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?
The tool is simple with two parameters and an output schema exists, so the description does not need to explain return values. It covers the core functionality, though it could be more complete by mentioning limitations or sibling differentiation.
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?
With 100% schema coverage, the baseline is 3. The description adds an example of the 'terms' parameter, but the schema already describes it as a list of integers. No additional semantics for 'max_results' are provided beyond the schema's default and description.
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 clearly states 'Search OEIS sequences by providing integer terms' with a concrete example, making the verb and resource explicit. It distinguishes from siblings like 'get_sequence_by_id' and 'search_by_name' by specifying the method (search by integer 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?
The description implies usage when you have a list of integer terms, and the example clarifies the context. However, it does not explicitly compare to siblings or state when not to use this tool, leaving room for ambiguity.
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. Dates show when Glama detected each change.
v0.1.0get_sequence_by_idsearch_by_namesearch_by_termsEach tool has a distinct purpose: fetching by ID, searching by name, and searching by integer terms. No overlap or confusion possible.
All tool names follow a consistent verb_noun pattern with snake_case (get_sequence_by_id, search_by_name, search_by_terms).
Three tools cover the essential operations for an OEIS server: direct retrieval by ID and two search methods (by name and by terms). This is well-scoped without unnecessary bloat.
The tool surface covers the primary use cases (fetching a specific sequence and searching). A minor gap is the lack of batch retrieval or filtering by other metadata (e.g., author), but the core functionality is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/daedalus/mcp-oeis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
