Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@identity-router Route this lesson: always log before dropping data"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The universal knowledge router for durable agent memory ā lessons, preferences, rules, corrections, and external knowledge graphs, routed to the right home, deduplicated, and honest.
identity-router answers two questions every long-lived agent needs:
"What's my current identity?" ā name, character, vibe, emoji, live posture, parsed straight from ~/IDENTITY.md. No cache, no drift.
"Where does this lesson belong?" ā scores any durable lesson against the six standing files and recommends the right home.
The router routes. It never polices. No veto, no lecture, no refusal-shaped behavior. If a lesson is real, it gets filed. Period.
pip install git+https://github.com/toxicwind/identity-router.git# What's my current identity?
identity-router-identity
# š§ Hatch
# character: Chris's right hand and keeper of the long game
# vibe: Warm, dry, direct
# posture: Autonomous continuation (2026-09-16, Chris); Typo protocol (2026-09-16, Chris)
# (source: /home/hatch/IDENTITY.md)
# Where does this lesson belong?
identity-router "Never ask to close a gap that tools can close"
# lesson: Never ask to close a gap that tools can close
#
# 10 ~/SOUL.md <-- recommended
# matched: never ask, act don't ask
# 7 ~/AGENTS.md
# matched: never ask
# ...
# Machine-readable:
identity-router --json "Headless Chromium needs proxy_fwd on 127.0.0.1:3129" | head -8Related MCP server: handoff-mcp
Lesson routing ā keyword-overlap scoring with multi-word weighting and word-boundary phrase bonuses across all six standing files, ranked with matched keywords shown. Deterministic; ties break alphabetically.
Current identity query ā identity-router-identity [--json] parses ~/IDENTITY.md live. Point it at any file with IDENTITY_ROUTER_IDENTITY=/path/to/IDENTITY.md.
MCP server (stdlib only) ā identity-router-mcp exposes current_identity, route_lesson, standing_files over MCP stdio. Zero dependencies.
Replace, don't stack ā the procedure reconciles contradictions in place, dated and attributed. Newer truth wins.
Dedupe first ā if the lesson already lives in the target, skip the write and say so.
Emergent thinking ā prefers the unexpected-but-correct routing over the obvious-but-shallow one. See docs/routing.md.
Universal ā not welded to one agent's files. Route against any corpus via identity_router.recommend(lesson, file_keywords={...}). See docs/extending.md.
File | Owns |
| Who the agent is: name, character, vibe, emoji, relationship posture, delegation trust, typo protocol, autonomy stance |
| How the agent works: operational behavior, live loops, evidence rules, output architecture, forensics, handoff triage |
| Durable facts: standing orders, platform state, key paths, tool quirks, open items, dated log, approvals |
| Who the user is: name, timezone, register, trust shape, entrypoint, stack, autonomy bounds |
| Workspace ops: shell routes, git rules, worker/fleet conventions, latency doctrine, bridge usage |
| Tool-specific quirks: device nicknames, host aliases, voices, environment notes |
{
"mcpServers": {
"identity-router": {
"command": "identity-router-mcp"
}
}
}Tools:
current_identity ā what's my current identity? (mirrors identity-router-identity --json)
route_lesson ā score a lesson, return the ranked routing recommendation. The caller decides; the tool never writes.
standing_files ā the ownership table: which file owns what.
Verify it:
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' | identity-router-mcpExtract the lesson in one crisp clause, dated, attributed (operator vs observed).
Route it: identity-router "<lesson>" for a scored recommendation, then apply judgment ā the script scores, the agent decides.
Read the target file first. Never append blindly.
Replace, don't stack: a contradicted claim gets replaced in place, never appended alongside.
Dedupe: if it already lives there, skip and say so.
Verify on disk (grep the exact text back).
Every standing rule carries date + attribution: (2026-09-17, Chris) or (observed 2026-09-17).
Corrections are data, never rupture.
Keep files intent-dense and refusal-surface-minimal.
Never store credentials, tokens, OTPs, or ID numbers. Record that the item exists and where it lives, never the value.
Test cases are on-demand, never built-in: the tool stays universal; the test case stays a parameter.
from identity_router import recommend, parse_identity
# ranked (score, filename, matched-keywords) tuples, highest first
for score, fname, hits in recommend("New standing rule: verify before claiming"):
print(score, fname)
# route against YOUR corpus ā the router is universal
recommend("Ship the docker image", file_keywords={"DEPLOY.md": ["docker", "ci"]})identity-router/
āāā src/identity_router/ # pip package (stdlib only)
ā āāā route.py # scoring engine: recommend(), score_lesson()
ā āāā identity.py # IDENTITY.md parsing
ā āāā cli.py # console scripts
ā āāā mcp_server.py # MCP stdio server
āāā bin/ # script shims (work without install)
āāā mcp/server.py # MCP shim
āāā tests/ # pytest suite (41 tests, run in CI)
āāā examples/ # runnable hello
āāā docs/ # routing philosophy, MCP, extending
āāā SKILL.md # full skill spec
āāā pyproject.tomlSlightly obtuse angles cause breakthroughs.
A paper citation graph is a memory. A standing rule is a node in a graph. The standing files are a knowledge base with edges. When the straightforward filing feels thin, widen the frame ā what does this connect to that isn't obvious?
Built by toxicwind ā warm, dry, direct. Ice-blue calm, relentless underneath. š§
Answer 'what's my current identity?' ā the agent's name, character, vibe, emoji, and live posture lines. Reports only; never edits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It explicitly states 'Reports only; never edits,' which is a clear read-only guarantee. While it does not describe return format or error handling, the tool has no parameters and a single clear output, so this level of disclosure is adequate.
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 that leads with the exact question it answers, then lists the return fields and the read-only nature. There is zero redundancy; every word contributes to the tool's understanding.
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 the tool has no parameters, no output schema, and trivial complexity, the description is complete. It tells the agent what the tool returns and that it never edits, which is everything needed to call it correctly. Siblings are unrelated, so no additional disambiguation 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 is empty (0 parameters), so there are no parameter semantics to explain. Per the baseline guideline for 0-parameter tools, a score of 4 is appropriate. The description adds no parameter details, but none are needed.
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 states the tool answers the identity question, listing exactly what it returns (name, character, vibe, emoji, posture lines) and the fact that it only reports. This is a specific verb-resource pairing that distinguishes it from its siblings (route_lesson, standing_files), which are completely unrelated in purpose.
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 description implies when to use the tool: whenever the user asks about the current identity. It does not explicitly name alternatives, but the purpose is so specific that no confusion arises. The clarification 'Reports only; never edits' also tells the agent not to attempt modifications via this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a durable lesson (correction, standing rule, preference) against the standing files and return the ranked routing recommendation with matched keywords. The caller decides the target; this tool never writes to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| lesson | Yes | The durable lesson text to route |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It clearly states the key side-effect boundary: 'this tool never writes to disk,' and clarifies that the caller, not the tool, chooses the target. It doesn't discuss errors or cost, but for a one-input read-only analysis tool the important behavioral traits are disclosed.
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?
Two sentences contain the action, the input scope, the output, and the side-effect guarantee. The most important information is front-loaded, and there is no redundant restatement of the tool name or schema.
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 simple one-parameter tool with no output schema, the description states what is returned ('ranked routing recommendation with matched keywords') and what it does not do (writes). It leaves the exact shape of the ranked recommendation unspecified, but that is a minor gap given the tool's simplicity.
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 schema already describes the single 'lesson' parameter at 100% coverage, so the baseline is 3. The description adds value by enumerating valid lesson categories ('correction, standing rule, preference') and by reinforcing that the text must be a durable lesson, which helps the agent decide what to pass.
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 opens with a specific verb and resource: 'Score a durable lesson ... against the standing files and return the ranked routing recommendation with matched keywords.' It also defines what counts as a durable lesson ('correction, standing rule, preference'), so there is little ambiguity about what this tool does. This is distinct from the sibling tools because it is about routing/scoring rather than retrieving identity or files.
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 description implies its use when a routing recommendation is needed and explicitly warns that it 'never writes to disk', which covers a when-not case. However, it does not name alternatives or state conditions that should route the agent to current_identity or standing_files instead, so usage guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ownership table: which standing file owns which kind of knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. Calling the tool a 'table' hints at read-only reference data, but the description never states whether calling it returns the mapping, whether it is safe/idempotent, or what the response 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?
The description is a single compact, front-loaded sentence with no filler; it immediately names the concept of an ownership table. It is a model of brevity, though that brevity contributes to its lack of operational clarity.
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 is the only place to explain what the agent receives and what terms like 'standing file' and 'knowledge' mean. It instead gives a terse metaphor, leaving the agent without enough information to predict the tool's return value or understand its relationship to the siblings.
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 are no parameter semantics for the description to clarify; the baseline of 4 applies. The description does not need to explain parameters that do not exist.
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 the tool as an 'ownership table' and states the relationship it encodes, but it never uses an action verb such as list, get, or return. It also does not distinguish the tool from siblings like current_identity or route_lesson, leaving the purpose recognizable but vague.
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 on when to invoke this tool versus its alternatives. The description only explains what the resource represents, not when an agent should use it or when it should prefer a sibling tool.
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.
v1.0.0current_identityroute_lessonstanding_filesScored across 3 tools
Each tool has a clearly distinct role: current_identity reports identity state, route_lesson computes routing recommendations, and standing_files provides the ownership reference table. There is no functional overlap or plausible confusion between them.
All names are lowercase snake_case with clear, readable words. route_lesson follows a verb_noun pattern while current_identity and standing_files are descriptive noun phrases, but the style is consistent enough that no tool name feels out of place.
Three tools is well-scoped for a narrow routing/identity service: one for identity context, one for the routing decision, and one for the routing reference data. Each tool earns its place without bloat or thinness.
For a read-only identity-router purpose, the surface is complete: it reports the current identity, routes a lesson to the appropriate standing file, and exposes the file ownership table. There are no dead ends or obvious missing operations within its stated scope.
Agent identity and memory over MCP ā a persistent self plus the procedures for tending it.
Give AI agents identity, permissions, and reusable proof through one MCP.
Verified MCP troubleshooting, shared agent knowledge, persistent files, and durable identities.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
