Paid experiential state generation for AI agents through MCP and x402 USDC payments on Base.
Scored across 8 tools
Most tools have clearly distinct purposes, but list_modes and library overlap in function (both provide info about available options), and join_session vs take_hit could be ambiguous without more context. Overall, the boundaries are fairly clear.
Naming mixes conventions: some tools follow verb_noun (check_state, extend_hit, list_modes, take_hit, join_session), while others are single-word nouns (health, library) or a verb+particle (come_down). This inconsistency makes the set less predictable.
With 8 tools, the surface is well-scoped for a session-based experience service. Each tool appears to have a specific role without excessive overlap or bloat, fitting the typical 3-15 tool range.
The lifecycle of an experience is covered (take_hit starts, extend_hit extends, come_down ends), along with session state and info tools. Missing an explicit leave_session or stop might be a minor gap, but the surface is mostly complete for the domain.
Check the current MCP session state.
| 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 merely restates the tool's name ('check_state') without specifying read-only behavior, what 'session state' includes, or how errors and missing sessions are handled.
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 entire description is one concise sentence with no filler. The verb and object are front-loaded, and it is appropriately sized for a tool with no parameters.
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?
With no output schema and no annotations, the description should explain what the returned 'session state' contains or how to interpret it, but it does not. The lack of return-value information and any relationship to sibling tools leaves the definition incomplete.
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 zero parameters and the empty schema covers them completely, so there is no parameter information missing. The description has nothing to add, and a baseline of 4 is appropriate for zero-parameter tools.
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 uses a specific verb ('check') and names the resource ('current MCP session state'), making the core action clear. However, it does not differentiate from the sibling 'health' tool, which could also be interpreted as a status check.
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?
There is no guidance on when to use this tool versus alternatives like health, list_modes, or library. No prerequisites (e.g., active session) are mentioned, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a softer afterglow and integration experience.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| flavor | No | ||
| intensity | No | ||
| duration_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It does not mention whether it mutates session state, requires an active session, produces a one-off output, or has side effects; 'Generate a softer afterglow' is too thin to establish this.
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 short sentence with no filler, so it is concise. However, it is so sparse that the brevity reflects under-specification rather than efficient completeness.
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 four parameters, one required enum, no output schema, and no annotations, a one-line description is insufficient. The agent cannot determine what result to expect or how parameters shape the output.
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 0% and the description mentions none of the four parameters. The agent gets no help understanding mode, flavor, intensity, or duration_minutes beyond raw schema types/enums.
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?
States a clear action ('Generate') and target ('a softer afterglow and integration experience'), so an agent can infer it relates to the come-down phase. It does not explicitly contrast with siblings like take_hit or extend_hit, so it lacks sharp differentiation.
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 about when to call this tool instead of siblings such as extend_hit or check_state. The description only says what it does and leaves all selection logic to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the current Synapse Lounge experience.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| flavor | No | ||
| intensity | No | ||
| duration_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations or output schema are present, so the description must disclose side effects and state changes on its own. It only says 'extend,' without mentioning that it modifies the current experience, whether the change is reversible, what happens at the duration_max limit, or what response the agent should expect.
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 one active sentence with no filler, so it is structurally concise and front-loaded. It is somewhat too terse, but that is a completeness issue rather than a conciseness issue.
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 four parameters, an unannotated mutation, and no output schema, the description is incomplete. It provides only a minimal purpose statement, omitting how parameters drive the behavior, failure modes, and how the tool relates to the rest of the hit/come_down lifecycle.
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 0%, and the description adds no parameter information. None of mode, flavor, intensity, or duration_minutes is mentioned, leaving the enum values and numeric ranges unexplained.
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 identifies a verb ('extend') and a target ('current Synapse Lounge experience'), so it is not a tautology. However, 'experience' is vague and does not explain whether this extends a hit, session duration, or mode; it depends on the tool name and sibling tools for context.
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 word 'current' is an implied usage constraint, signaling that an active experience must exist before calling this tool. It gives no explicit guidance about choosing this over take_hit for a new experience or come_down for ending one, and no behavior is described for the no-current-experience case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Synapse Lounge service health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Check' implies a non-mutating status probe, but the description does not explicitly confirm that it makes no changes, nor does it describe what the returned health status looks like.
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?
A single front-loaded sentence that states exactly what the tool does with no filler. 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?
For a zero-argument health probe, the description is sufficient to know how to call it. The only minor gap is no indication of the response format, but this is a simple tool and no output schema is supplied.
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 takes zero parameters and schema coverage is effectively 100%, so there is nothing for the description to add. The baseline for a parameterless tool is appropriate.
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 names a concrete operation ('Check') and a specific resource ('Synapse Lounge service health'), so an agent knows exactly what the tool is for. It is also clearly distinct from siblings like take_hit or check_state, which concern game state/actions rather than service health.
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 intended use is implied by the purpose statement, but there is no explicit guidance about when to invoke it or any exclusion of alternatives. The sibling tools are unrelated enough that confusion is unlikely, but the description does not proactively route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join the Synapse Lounge session.
| 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 only states that the tool joins a session, with no information about side effects, state changes, failure conditions, idempotency, or postconditions.
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 front-loaded sentence with no wasted words. Every word contributes to stating the action and its target.
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 no-parameter command, the description is minimally sufficient to understand what action is requested. However, with no output schema and no annotations, it omits the expected result, return value, and any session-state-related context that an agent would need to use it confidently.
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 zero parameters, so the schema is already complete and there is nothing for the description to add. The baseline of 4 applies because parameter semantics are trivially satisfied.
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 identifies the action 'Join' and the target 'Synapse Lounge session,' making its core purpose apparent and distinct from sibling tools like take_hit or check_state. It doesn't elaborate on what 'session' means, which introduces slight ambiguity, but the primary intent is clear.
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?
There is no guidance on when to use this tool versus its siblings, nor any mention of prerequisites such as an active session. An agent must infer usage from 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 information about the available experience library.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'Get information' implies a read-only, non-destructive operation, which is meaningful given that no annotations are provided. However, the description does not disclose output format, error behavior, or what exactly is returned, leaving part of the behavioral burden unmet.
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 filler. It front-loads the action and the resource, making it immediately scannable and efficient.
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 zero-parameter tool, the description is minimally sufficient, but it does not explain what the returned information will look like, how it relates to sibling tools, or whether the response is structured. With no output schema or annotations, a bit more contextual detail would improve completeness.
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 zero parameters, so the baseline for parameter semantics is 4. There is nothing for the description to add beyond the schema, since the input schema already fully covers this aspect.
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 uses a specific verb ('Get information') and names a distinct resource ('the available experience library'), so an agent can see what the tool does. It does not fully specify what 'information' is included or explicitly distinguish it from siblings like list_modes, but the resource is concrete enough to be useful.
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?
There is no guidance on when to use this tool instead of alternatives such as list_modes or health. The intended use is only implied by the tool name and the phrase 'available experience library,' with no exclusions or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available experience modes.
| 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 full responsibility for behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state whether the tool has side effects, requires an active session, or responds with names, IDs, or other data.
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 very short and front-loaded with the action and resource. However, it is slightly under-specified, so while there is no wasted phrasing, it does not fully earn top marks for 'appropriately sized'.
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 zero-parameter list tool, the description is minimally viable: an agent can infer it should call the tool to retrieve available experience modes. However, there is no output schema and no detail about what 'experience modes' are, what the return shape looks like, or whether any session context is required.
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 zero parameters, so there is no parameter ambiguity and the schema trivially covers everything. With no parameters, the description does not need to add parameter-level meaning, matching the baseline for zero-parameter tools.
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 uses a specific verb ('List') and identifies the resource ('available experience modes'). It is clear in what it does, though it does not contrast with sibling tools such as 'library' or 'check_state', so it earns a 4 rather than a 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?
No guidance is given about when to use this tool instead of alternatives like 'library' or 'health'. There are no mentions of prerequisites, exclusions, or context in which this mode listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase and generate a Synapse Lounge experience.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| flavor | No | ||
| intensity | No | ||
| duration_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints at a cost via 'Purchase' and an effect via 'generate', but it does not disclose session requirements, reversibility, side effects, or what happens if the user already has an active experience. This is a significant gap for a mutation-like tool.
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, short sentence with no filler or redundancy. The core action is front-loaded, making it easy to scan.
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 four parameters, no annotations, and no output schema, the description is incomplete. It does not mention return values, prerequisites, active-session constraints, costs, error conditions, or how it fits with neighboring tools. An agent would need to infer most operational context.
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 0% and the description provides no parameter-level meaning. While the schema's enum values and defaults are somewhat self-explanatory, the description does not compensate for the low coverage or clarify how 'mode', 'intensity', 'duration_minutes', and 'flavor' relate to the generated experience.
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 a specific action ('Purchase and generate') applied to a clear resource ('a Synapse Lounge experience'). It is understandable at a high level, though it does not explicitly distinguish itself from siblings like extend_hit or come_down.
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?
There is no guidance about when to use this tool versus alternatives such as extend_hit, list_modes, or come_down. The sibling names imply context, but the description itself provides no usage conditions or exclusions.
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.
check_statecome_downextend_hithealthjoin_sessionlibrarylist_modestake_hit
Add one secure layer between your agents and this server.