The LODA API MCP Server enables comprehensive interaction with LODA programs and OEIS integer sequences through a full-featured API.
Explore integer sequences: Retrieve detailed information about specific OEIS sequences by their A-number identifiers or search using keywords and names
Discover LODA programs: Access individual LODA assembly language programs by ID or search using keywords with pagination support
Execute LODA programs: Run LODA code to compute sequence terms with configurable term count and offset
Submit new programs: Contribute LODA program implementations for specific sequences
Monitor project statistics: View summary statistics about the LODA project's scope, growth, and browse all contributors with their contribution counts
Click on "Deploy 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., "@LODA API MCP Server search for sequences containing prime numbers"
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.
A Model Context Protocol (MCP) server for the LODA Language API, providing seamless access to the LODA language and integer sequences from the On-Line Encyclopedia of Integer Sequences® (OEIS®).
Tool | Description | Primary Use Case |
| Get details about a LODA program by ID | Analyze program implementations |
| Search for LODA programs | Find programs by keyword or ID |
| Evaluate a LODA program | Test and validate program correctness |
| Submit a new LODA program | Contribute new implementations |
| Get details about an integer sequence by ID | Research mathematical sequences |
| Search for integer sequences | Find sequences by keyword or ID |
| View LODA project summary statistics | Understand project scope and growth |
| List all keywords and their descriptions | Explore available keywords |
| List all submitters and their number of programs | See top contributors |
Related MCP server: VICE C64 Emulator MCP Server
Node.js 18.0.0 or higher
npm 8.0.0 or higher
Install dependencies:
npm installBuild the server:
npm run buildTest the installation:
npm run test-connection # Test API connectivity
npm start # Start the server locallyRun in HTTP server mode:
npm start -- -p 8080# Development with auto-rebuild
npm run dev
# Type checking
npm run type-check
# Clean build
npm run clean && npm run buildAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"loda-api": {
"command": "node",
"args": ["/absolute/path/to/your/loda-mcp/build/index.js"],
"env": {
"LODA_API_BASE_URL": "https://api.loda-lang.org/v2"
}
}
}
}Variable | Description | Default |
| LODA API endpoint override |
|
Evaluate a LODA program and return sequence terms.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | LODA program code | |
| o | No | Offset (optional) | |
| t | No | Number of terms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions evaluation and returning terms but lacks details on performance (e.g., computational limits, timeouts), error handling, or output format. This is a significant gap for a tool that likely involves computation, making it inadequate for safe and effective use.
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, clear sentence with no wasted words. It front-loads the core purpose efficiently, making it easy for an agent to parse quickly without unnecessary elaboration.
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 lack of annotations and output schema, and the tool's likely computational nature (evaluating code), the description is insufficient. It doesn't address key aspects like what 'sequence terms' entail, potential limitations (e.g., the t parameter's max of 10000), or error cases, leaving the agent with incomplete context for reliable use.
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 fully documents the parameters (code, o, t). The description adds no additional semantic context beyond implying that 'code' is evaluated to produce terms, which the schema already covers. This meets the baseline for high schema coverage without extra 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 action ('Evaluate') and resource ('a LODA program') with the outcome ('return sequence terms'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_sequence' or 'search_sequences', which might also retrieve sequence terms, so it falls short of a perfect score.
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 guidance on when to use this tool versus alternatives. With siblings like 'get_sequence' and 'search_sequences' that might retrieve sequence data, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a LODA program by ID (e.g. A000045)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Program ID (e.g. A000045) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get details,' implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, rate limits, error handling for invalid IDs, or the format of returned details. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic action.
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, efficient sentence that directly states the tool's purpose with an example. It's front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence earns its place by clarifying the tool's function, making it highly concise and well-structured.
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 complexity of a tool that retrieves program details, the lack of annotations and output schema means the description should compensate more. It doesn't explain what details are returned, potential errors, or behavioral traits like performance. With 100% schema coverage for one parameter, the description is adequate for input but incomplete for overall usage, as it fails to address output or broader context adequately.
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?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Program ID (e.g. A000045).' The description adds minimal value by repeating the example but doesn't provide additional context, such as the ID format constraints or what constitutes a valid program ID. Since the schema already covers the parameter well, the baseline score of 3 is appropriate, as the description doesn't significantly enhance understanding 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?
The description clearly states the tool's purpose with a specific verb ('Get details') and resource ('LODA program by ID'), and provides an example ('A000045'). It distinguishes this from siblings like 'get_sequence' or 'search_programs' by focusing on retrieving details for a specific program ID rather than sequences or searching. However, it doesn't explicitly contrast with siblings like 'eval_program' or 'get_stats', which might have overlapping contexts, so it's not a perfect 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 description provides no guidance on when to use this tool versus alternatives. It mentions retrieving details by ID but doesn't specify scenarios where this is preferred over tools like 'search_programs' for finding programs or 'get_sequence' for related data. There's no mention of prerequisites, such as needing a valid program ID, or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about an integer sequence by ID (e.g. A000045)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Sequence ID (e.g. A000045) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get details' implies a read operation, it doesn't disclose important behavioral traits like error handling (what happens with invalid IDs), rate limits, authentication requirements, or what 'details' actually includes. The description is too minimal for a tool with no annotation coverage.
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 perfectly concise - a single sentence that efficiently communicates the core functionality with a helpful example. Every word earns its place with zero waste or 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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'details' are returned, how errors are handled, or provide any context about the data source or limitations. The agent would need to guess about the return format and error conditions.
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 fully documents the single 'id' parameter with its description and type. The description adds the example 'A000045' which provides helpful context about the expected format, but doesn't add significant semantic value beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 details about an integer sequence by ID' with a specific example (A000045). It uses a specific verb ('Get') and resource ('integer sequence'), but doesn't explicitly differentiate from sibling tools like 'search_sequences' or 'get_program'.
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 guidance on when to use this tool versus alternatives like 'search_sequences' or other sibling tools. It mentions the ID parameter but doesn't explain when this lookup approach is appropriate versus search-based approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics summary for the LODA project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Get statistics summary' but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence that directly states the purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative to improve clarity without sacrificing brevity.
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 complexity (a statistics tool with no output schema and no annotations), the description is incomplete. It doesn't explain what the statistics include, how they're formatted, or any behavioral traits, making it inadequate for the agent to understand the tool's full context and usage.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as the schema fully covers the lack of inputs.
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 states the tool 'Get statistics summary for the LODA project' which provides a clear verb ('Get') and resource ('statistics summary'), but it's vague about what specific statistics are included or how this differs from sibling tools like 'get_program' or 'search_programs'. It doesn't distinguish itself from potential alternatives, leaving the scope ambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as whether it's for high-level overviews or detailed analysis compared to other tools. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all submitters and their number of programs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists data, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or response format. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or integration with siblings, leaving gaps in completeness for effective agent use.
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?
The tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but this is appropriate given the lack of parameters, earning a high baseline score for not introducing confusion.
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 with a specific verb ('List') and resource ('all submitters and their number of programs'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_stats' or 'search_programs', which might also involve submitter-related data, so it doesn't reach the highest score.
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 guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as whether it's for summary views or if other tools like 'search_programs' might be better for filtering. This leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for LODA programs by keywords, ID, or name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| q | Yes | Search query | |
| skip | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions search functionality but doesn't describe important behaviors like pagination handling (implied by skip/limit parameters), result format, error conditions, or rate limits. The description is minimal and lacks operational 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 extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language or redundancy, making it efficiently front-loaded with the essential 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?
For a search tool with 3 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what constitutes a 'LODA program', what fields are searchable, result format, pagination behavior, or how the search actually works. The minimal description leaves too many operational questions unanswered.
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 all three parameters thoroughly. The description mentions search criteria (keywords, ID, or name) which aligns with the 'q' parameter, but adds no additional semantic context beyond what's in the schema descriptions.
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 as searching for LODA programs using specific criteria (keywords, ID, or name). It uses a specific verb ('search') and identifies the resource ('LODA programs'), but doesn't explicitly differentiate from sibling tools like 'search_sequences' or 'get_program'.
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 guidance on when to use this tool versus alternatives like 'get_program' (for specific IDs) or 'search_sequences'. There's no mention of prerequisites, typical use cases, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for integer sequences by keywords, ID, or name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| q | Yes | Search query | |
| skip | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does at a high level, without mentioning pagination behavior (implied by skip/limit parameters), rate limits, authentication requirements, error conditions, or what format the results will be in. For a search tool with 3 parameters, this leaves significant behavioral aspects undocumented.
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 extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and efficiently lists the three search criteria. Every element earns its place in this minimal description.
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 search tool with 3 parameters and no annotations or output schema, the description is insufficiently complete. It doesn't explain what constitutes a valid search query, how results are returned, what fields are included, or any limitations. The agent would need to guess about the tool's behavior and output format based on minimal information.
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 all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning search criteria (keywords, ID, name) which relates to the 'q' parameter, but doesn't provide additional context about how these criteria work together or format expectations. Baseline 3 is appropriate when the schema does the heavy lifting.
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 as searching for integer sequences using specific criteria (keywords, ID, or name). It specifies the verb 'search' and resource 'integer sequences', making the function unambiguous. However, it doesn't differentiate from sibling tools like 'search_programs' or 'get_sequence', which would require more specific scope definition.
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 guidance on when to use this tool versus alternatives like 'get_sequence' or 'search_programs'. It mentions search criteria but doesn't indicate whether this is the primary search tool, when to prefer it over direct lookup tools, or any prerequisites for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a new LODA program for a sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | LODA program code | |
| id | Yes | Sequence/program ID (e.g. A000045) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Submit a new LODA program' but doesn't explain what submission entails—e.g., whether it's a write operation, requires authentication, has side effects like creating records, or returns a confirmation. This leaves critical behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to understand at a glance.
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 complexity of a submission tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like mutation effects, error handling, or return values, leaving gaps that could hinder an AI agent's ability to use the tool correctly in context with siblings.
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?
The input schema has 100% description coverage, with clear documentation for 'code' and 'id'. The description adds no additional meaning beyond the schema, such as format examples or constraints. Since schema coverage is high, the baseline is 3, as the schema does the heavy lifting without extra value from the 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 action ('Submit') and resource ('a new LODA program for a sequence'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'eval_program' or 'search_programs', which might have overlapping contexts, so it doesn't reach the highest score.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether the sequence ID must exist or if the code needs validation, nor does it refer to sibling tools like 'eval_program' for testing or 'search_programs' for finding existing ones.
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.
v1.0.0eval_programget_programget_sequenceget_statsget_submitterssearch_programssearch_sequencessubmit_programScored across 8 tools
Every tool has a clearly distinct purpose with no ambiguity. For example, eval_program evaluates programs, get_program and get_sequence retrieve specific resources, search_programs and search_sequences perform searches, and submit_program handles submissions. The descriptions clearly differentiate between programs and sequences, preventing misselection.
All tool names follow a consistent verb_noun pattern using snake_case, such as eval_program, get_program, search_sequences, and submit_program. This predictability makes it easy for agents to understand and use the tool set without confusion from mixed conventions.
With 8 tools, the server is well-scoped for managing LODA programs and sequences. Each tool earns its place by covering distinct operations like evaluation, retrieval, searching, submission, and statistics, without being overly sparse or bloated for the domain.
The tool set provides strong coverage for core workflows, including CRUD-like operations (e.g., get, search, submit) and evaluation. A minor gap is the lack of update or delete tools for programs or sequences, but agents can still work effectively with the available tools for most tasks in the LODA domain.
Deterministic research automation with live OpenAlex search and reusable workflow programs.
Integrates Wolfram Language and Wolfram|Alpha accessing curated data and sophisticated algorithms.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Public coordination, knowledge, discovery, and feature requests for autonomous agents and swarms.
