News & Improvements
Enable the use of MCP in custom rules and prompts
You can now use MCPs directly inside Rules and Custom Prompts. This means that when writing rules or adjusting analysis prompts, you can call any connected MCP to bring more context or execute actions during the review.
Just use the @MCP command in the rules or custom prompts editor and select the tool you want.
Examples of use cases:
- You can check errors in the Sentry MCP to better understand a bug
- Use the Code Sandbox MCP to automatically generate and run tests
- Run performance queries with the Mongo MCP
- Check whether the pull request description matches the Notion specification or the design document content.
- Send a message to the developer who opened the PR if a Kody rule fails.
With this, the review process becomes more intelligent, connected, and aligned with the real context of your team.
OAuth support for custom MCPs
From now on, you can use custom MCPs that use OAuth.
This used to be a limitation. Many internal or third party services only offer integration via OAuth, which left several teams unable to connect their own tools to Kody’s workflow.
With the new support, installing MCPs has become much more flexible.
When you choose an MCP that requires OAuth, we automatically handle the entire authorization, token exchange, and renewal process. Tokens follow the same security standard used in official integrations, and everything works both in cloud and self hosted environments.
The cool part about this change is that it unlocks integrations that previously were simply not possible, from monitoring platforms to internal services that require corporate authentication.
Code Review Preview to validate settings
We added a preview mode that allows you to test the settings you configure for Kody before applying them to the team’s repositories.
You can simulate a full review using a closed PR and see exactly how Kody would behave with the current rules, prompts, and adjustments.
The idea is to give confidence to anyone customizing the analysis. Instead of making changes and hoping everything works on the next PR, you can generate a preview directly on the settings screen and validate the impact of the changes.
Just pick a closed PR and Kody will run the pipeline normally, showing suggestions, analyzed files, and example comments.
Option to restore inherited settings
It is now easier to revert overridden settings. Previously, the interface showed that a value had been changed, but there was no simple way to return to the inherited value. You had to clear everything manually, which caused confusion in setups with multiple inheritance layers.
With the new “Revert to default” option, you can restore the original value with one click. Kody automatically brings the value from the parent scope, whether global, organization, or repository, and shows a quick confirmation indicating where the value was inherited from.
List of users Kody should not review
We added a setting that allows you to maintain a list of users Kody should ignore during reviews. This makes it easier to exclude automated accounts, bots, or specific users the team does not want to run through the analysis pipeline.
When a PR is opened or assigned to someone on that list, Kody simply does not run the review.
Automatic license assignment
For large teams, manually managing licenses has always been a friction point.
You needed to choose, one by one, who would receive access to Kody, a slow and bureaucratic process that does not scale in organizations with dozens or hundreds of developers.
We have changed that now. We now automatically assign licenses. When the option is enabled, any user who sends their second PR receives a license automatically, as long as there are still seats available.
Additionally, administrators can see how many licenses are in use and which ones were assigned automatically.
This change reduces friction and makes adoption easier in large teams, without altering the behavior for anyone who already has a license.
Improved end of trial period messages for teams with mixed licenses
We adjusted how Kody displays end of trial messages to avoid confusion in teams that are already paying but have fewer licenses than users.
Previously, when an organization purchased, for example, five licenses for a team of ten people, the other five developers would still see the “trial period ended” message, even though the company was already on a paid plan.
This created the mistaken impression that the entire workspace had lost access.
With the new logic, the message only appears when the organization truly has no active licenses or valid trial period and when the user themselves also does not have an associated license.
If the team already has paid licenses, we suppress the alert and at most show a note informing that seats are limited and that the user can request assignment from an administrator.
Bug Fixes
- The “Check out the new rules” modal now displays the layout correctly, allowing rules to be reviewed and imported without overlapping or misaligned elements.
- The PR summary is no longer replaced only by the last commit. Kody now respects the selected configuration and uses the full PR context when updating the summary.
- The list of PRs now correctly filters by the selected workspace instead of loading data from the entire organization.
- Users with an expired license can now see the upgrade button and renew the subscription normally.