3 ways Human37 uses the Talon.One MCP

The Talon.One MCP is a server that connects an AI agent (like Claude) to a live Talon.One environment through the Model Context Protocol. It wraps Talon.One's APIs as a set of read-only tools, so the agent can pull real configuration and customer state like applications, campaigns, rulesets, achievements, coupons, loyalty programs, balances and ledgers, customer profiles, sessions, and events and answer questions about them directly. 

Currently the Talon.One MCP is read-only which means you can’t alter configurations using it. All instructions needed to connect with the MCP can be found here. 

This article shows 3 ways Human37 uses the Talon.One MCP.

The Talon.One MCP is a very strong companion to co-create your build as the MCP has all the knowledge about the ins and outs of Talon.One.

Before starting the build, we ask the MCP how it would approach a particular campaign. This gives us an opportunity to explore different scenarios and approaches upfront. Since Talon.One often offers multiple ways to achieve the same outcome, we can compare different functionalities and mechanics to identify the approach that best fits our way of working. This collaborative exploration also helps ensure consistency across our builds.

The advantage here is that the intrinsic knowledge the MCP has access to is taken into account. The parts that need further exploration are closed immediately and taken into account to determine if a build scenario is viable or not. 

The final build is transformed into a build guide that is picked up by the team for implementation.

Talon.One is a real-time evaluation engine. This implies that, in order to evaluate campaigns over longer periods of time, a longer evaluation period is required as historical data ingestion is not a supported functionality.

In order to circumvent these longer evaluation periods we use the MCP to run functional simulations. What does this mean?

Since we can't provide Talon.One with actual historical data we leverage the AI agent, Claude in our case, to evaluate how Talon.One rules would apply if a user conducted certain behavior over time. 

Here's an example of the test schedules we provide:

This input is taken by Claude and evaluated against the existing configuration of Talon.One via the Talon.One MCP.

We then ask Claude to evaluate all existing rules against the ingested events using a new, standard user profile. This allows us to see which rules are triggered, how many points are awarded, which achievements progress, and what the user's resulting balance is.

It is important to note that you have an expected result to evaluate against. 

This requires us to define the expected outcome in advance: which rules should trigger, how many points should be awarded, and what the user's balance should be after the simulated behavior. These expected results serve as our benchmark, giving us a clear source of truth to compare the simulation against, much like a teacher grading a student's test.

This methodology allows us to rapidly simulate configuration changes and evaluate if and where things break unexpectedly.

At Human37 we have wrapped this in a re-usable skill to ensure consistency.

I like to compare Talon.One to a box of Lego bricks. You can build a castle in more than one way. Therefore it is important to document how exactly your castle was built, so others understand which bricks can be tuned, and which ones will make the castle collapse.

Today we use Talon.One in two ways when it comes to documentation, both are described below:

Every build or change performed ends with documentation.

The AI agent uses the Talon.One MCP to provide all the details of the application, campaigns, rules, achievements, etc., using a structured and easy-to-understand format. This is then transferred into the client’s chosen environment (Confluence, Notion, etc).

We can ask the agent to evaluate the existing configuration and make modifications where needed. This ensures that every build has updated documentation so users can verify configurations, settings and get their bearings in the existing setup.

Coming back to the concept of Lego bricks - we use the AI agent linked to the Talon.One MCP to be able to pin-point where certain things live in the configuration. For example, it might not be easy for someone who just joined the company to understand which achievement to tweak in order to change points attributed by a rule. This is an excellent use case to ask your agent. Since the agent has access to the Talon.One MCP it has complete read access to the entire build configuration and is able to immediately guide the Talon.One user to the right achievement for re-configuration.

This principle can be applied to any Talon.One component.