Hebbrix MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

hebbrix_claim_verify

Verify the six-digit code sent by email to finish converting guest memory into a claimed account, preserving saved memories and removing guest limits.

Instructions

Finish claiming a guest memory with the emailed six-digit code.

Only call after hebbrix_claim_start and after the human supplies the code. On success the same memories remain available and guest expiry/caps are replaced by the normal claimed-account tier.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "hebbrix_claim_verify"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.6Aug 19, 2026
- addedInput schema / properties / code / format
```
Added value: +"password"
```
- addedInput schema / properties / code / writeOnly
```
Added value: +true
```
Addedv0.5.1Aug 11, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since the annotations are only false flags, the description defines the actual behavioral effect: same memories remain available, and guest expiry/caps are replaced by a regular claimed-account tier. It doesn't describe failure modes, but the main success state and the state mutation are made clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the operation, the second gives the comparator and postcondition. Everything is front-loaded and every sentence contributes; no unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the description is short, it includes the mandatory predecessor, the user-code precondition, the success state, and the type of security tier change. Since the output schema is provided the description does not need to explain the return value, and it is sufficient for a simple verification step.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema merely defines a required code string with format password, so the description adds crucial semantics by stating the code is 'emailed' and 'six-digit'. This is enough for a single parameter, though it doesn't literally map the parameter name in the prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Finish claiming' and identifies the target resource as 'guest memory with an emailed six-digit code', which makes its purpose clear. It should be executed after hebbrix_claim_start, so it is unambiguous when compared with that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Only call after hebbrix_claim_start and after the human supplies the code', giving a definitive ordering and an exact precondition. This tells the agent exactly when to use the tool and not to use it beforehand.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.