Skip to main content
ModuleX gets better when people who use it pitch in. Whether you want to add a brand-new integration, fix a typo you spotted in these docs, file a bug, or just tell us what would make your day easier, there is a place for your contribution. This page shows you the options and how to get started with each one. You do not need to be a developer to help. Some of the most valuable contributions are a clear bug report or a sentence that makes a confusing page easier to read.

​
Ways to contribute

Build an integration

Add support for a service ModuleX does not connect to yet. This is the most impactful contribution — every new integration unlocks more tools for everyone.

Improve the docs

Fix a typo, clarify a step, or flag something that is out of date. Small edits add up to a much better reading experience.

Report a bug

Tell us when something does not work as described. A good bug report is one of the fastest ways to get a fix shipped.

Share feedback

Suggest a feature, describe a workflow you wish were easier, or tell us what you love. Product direction is shaped by what we hear.
ModuleX is developed on GitHub under the ModuleXAI organization. The public integration catalog lives in the modulex-integrations repository, which is where most code contributions happen.

​
Building integrations

An integration is a connector to an external service — for example GitHub, Slack, or a database. Each integration exposes one or more tools, the individual actions that a workflow, the AI Composer, and the Assistant can call. Adding an integration is the highest-leverage way to contribute, because the new tools become available to every ModuleX user. Integrations are authored as Python packages in the open-source modulex-integrations repository. The full author’s guide — directory layout, the manifest, the @tool function contract, registering the entry point, and testing locally — lives on the build an integration page. Here is the shape of the work.
1

Pick a name and copy an existing tool

Choose a lowercase, snake-case name for your integration (for example acme). Copy a similar folder under src/modulex_integrations/tools/ — github for a token-auth REST API, or exa for an API-key service — and edit it for your service. Every integration ships the same fixed file set, so reviews are mechanical.
2

Write the manifest, tools, outputs, and tests

Fill in manifest.py (the integration’s identity, actions, and how it authenticates), tools.py (one @tool function per action), outputs.py (the typed result models), and at least one happy-path test per tool. The full contracts are documented in the manifest and schema contract and the @tool function contract.
3

Register the entry point

Add one line to the root pyproject.toml under [project.entry-points."modulex.tools"] so the runtime can discover your integration. Without this line the runtime will not load your tool, even though it appears on disk.
4

Run the checks and open a pull request

Run the tests, the linter, and the type checker locally, then open a pull request against modulex-integrations. Reviewers confirm the contracts hold and that your integration follows the same patterns as the rest of the catalog.
Do not rely on pip install extras to pull in a tool’s dependencies. The [all] extra resolves to an empty list and there are no per-tool extras groups ([github], [slack], and the like are not defined), because the script that assembles them does not exist yet. Installing modulex-integrations[all] or modulex-integrations[acme] installs only the core package and pip will warn about the unknown extra. Until the assemble step lands, install modulex-integrations and then install each tool’s dependencies manually. See installing integrations.

​
What reviewers look for

Every schema model rejects unknown fields, so a misspelled or extra manifest field fails when the module is imported. Importing the manifest — or running pytest, which imports it — surfaces these errors before review.
The integration name must be identical across the folder name, the manifest name, the entry-point key, and the entry-point value. Each action name must equal a @tool function name listed in the TOOLS tuple.
Pick a single way to signal failure across the integration — raise on HTTP errors, return an inline failure payload, or wrap calls in try/except — and apply it consistently. Set explicit timeouts on outbound calls.
The runtime injects credentials at call time and strips the credential fields from the schema the model sees. Follow the auth conventions in the @tool function contract so tokens are never exposed to the language model.

Start building

The complete, step-by-step guide to authoring an integration end to end.

​
Documentation and feedback

These docs are a living document. If a page is confusing, out of date, or missing something you needed, telling us is a real contribution.

Suggest a docs change

Spotted a typo, a broken example, or a step that no longer matches the product? Open an issue describing the page and what is wrong, or propose the fix directly.

Report a bug

Found a defect in ModuleX itself? Open an issue with the steps to reproduce, what you expected, and what happened instead.

Request a feature

Describe the problem you are trying to solve, not just the solution you have in mind — it helps us find the best fit.

Ask the community

Join the ModuleX Discord to ask questions, share what you have built, and talk to other builders and the team.

​
How to write a report we can act on

A few details turn a vague message into something we can fix quickly. When you report a bug, please include:
1

What you did

The exact steps to reproduce the problem, in order. If it involves the API, include the request (with secrets removed) and the surface it happened on.
2

What you expected

What you thought would happen.
3

What actually happened

The result you got, including any error message or status code. If you can, copy the full error rather than paraphrasing it.
4

Where and when

Whether it happened in the app, an SDK, or a direct API call; roughly when; and anything you already tried.
Never paste real secrets into an issue or a pull request. Redact API keys (anything starting with mx_live_), access tokens, and other credentials before you share logs or requests. To report a security issue privately, email security@modulex.dev rather than opening a public issue.

​
Community expectations

ModuleX is built by a community, and we want it to be a place where everyone is treated with respect. We ask everyone who takes part — in issues, pull requests, the Discord, and anywhere else — to follow a few simple principles.

Be respectful

Assume good intent, disagree on ideas rather than people, and keep discussion constructive.

Be welcoming

People arrive with different backgrounds and levels of experience. Help newcomers and answer questions patiently.

Be clear

Give context, share the steps you took, and keep feedback specific and actionable.

Keep it safe

No harassment, no sharing of others’ private information, and no posting of secrets or sensitive data.
A formally published, versioned code of conduct for the ModuleX open-source repositories is not available yet. TBD — until one is published, the principles above describe what we expect of everyone in the community. If you experience or witness behavior that breaks them, contact the team at contact@modulex.dev.

​
Get help and stay current

Getting help

Where to find answers and how to reach a human when you are stuck.

System status

Check current health and where to watch for incidents before reporting an outage.

Changelog

See what has changed recently across ModuleX and these docs.