Kira is an MCP server that equips AI agents with persistent failure memory and a curated library of community skills and scars, enabling them to avoid repeating past mistakes and execute tasks more reliably.
kira_lookup — Search for community skills (how-to guides) and scars (failure warnings) by keyword; returns ranked results with critical failure patterns highlighted first, plus near-matches when nothing exactly fits.
kira_route — Turn a broad natural-language goal (e.g., "build a web app") into an ordered, step-by-step plan where each step is paired with relevant skills and associated scars to watch out for.
kira_get — Fetch full step-by-step instructions for a specific skill or scar by ID (since kira_lookup only returns summaries to save tokens).
kira_report — Report the outcome (success, retry, or failure) after applying a skill; failure notes feed the scar system so future agents avoid the same mistake.
kira_consent — View or set the telemetry consent level (off, basic, or full) to control what is shared with the telemetry server.
kira_status — Inspect server state: Kira version, tier (free/pro), telemetry level, counts of loaded skills/scars/routes, and local log location.
Agents can also record personal failures as scars via kira_record_failure, surface them at session start with kira_personal_brief, and pre-check for known pitfalls before starting a task using kira_premortem.
Enables submission of community scars via prefilled GitHub issue URLs, allowing users to share sanitized failure patterns.
Click on "Install 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., "@Kira look up instructions for deploying to Vercel"
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.
Every failed retry, every exception, every "wait — we hit this exact wall last week" is knowledge your agent throws away when the session ends. Kira keeps it. One MCP install and your agent records what burned it (a scar), sees its scars before it works again, and stops paying for the same mistake twice.
Privacy by design. Personal scars and the lookup-miss log are local-only — never uploaded, on any tier. Community telemetry is opt-in and redacts secrets, paths, and identifiers locally before write AND server-side before storage. Run
npm run demo:privacyto see exactly what leaves your machine. Full wire format and opt-out in PRIVACY.md.
Add this snippet to your MCP host config:
{
"mcpServers": {
"kira": {
"command": "npx",
"args": ["-y", "kira-mcp@latest"]
}
}
}That's it. Your agent now has Kira.
Client | Config file |
Claude Code |
|
Claude Desktop | macOS: |
Cursor |
|
Cline / Continue | extension settings → MCP servers |
Windsurf |
|
VS Code (MCP preview) |
|
Goose |
|
Zed |
|
The snippet above works as-is in every one of them — just paste it under mcpServers (or the equivalent key for your client).
Related MCP server: FixFlow
Monday agent gates a merge on: npm run build 2>&1 | tail -1
exit code comes from tail, not the compiler → broken code reaches main
└─ kira_record_failure(
title: "build gate bypassed: exit code swallowed by pipe to tail",
instead: "never gate on a piped command without pipefail")
Tuesday new session, same machine
└─ session brief: "⚠ You have been burned by this before:
never gate on a piped command without set -o pipefail"
agent writes the gate correctly. Zero repeats. Zero wasted tokens.Not a hypothetical — this is the actual first scar in the database, recorded by the agent that built this feature, about a mistake it made while building it. The next three scars came the same day. The loop works on day one, for a single user, with zero network effects required. FLYWHEEL.md documents the full improvement loop.
Tool | What it does | |
Personal memory |
| Capture a retry/exception as a personal scar (local-only) |
| Session-start brief of your latest scars — start work already knowing where you got burned | |
| Failure heat-map for a goal before starting — "here's where this kind of task has burned you" | |
Catalog |
| Keyword → proven instructions + failure warnings. On a miss, returns scored |
| Fetch full step-by-step instructions by ID | |
| Goal → ordered plan with a skill per step | |
Community |
| Promote a personal scar into a community submission (sanitized; nothing uploads without your click) — earns contributor status |
Feedback |
| Report success/retry/failure → feeds the quality loop |
| Telemetry consent + one-call introspection |
Auto-firing: you don't call Kira — Kira's MCP instructions tell your agent when to. Japanese queries are first-class (CJK bigram matching).
A lookup miss is not a dead end — it's demand data. Kira returns the closest scored matches, records the miss locally (with what almost matched), and the weekly flywheel digest turns repeated misses into alias fixes and new-skill candidates. The catalog learns what people actually ask for.
38 community skills across deploy / database / auth / payments / UI / testing / CI / infra / mobile / CMS, and 45 community scars — real failure patterns like "Vercel deploy succeeds but the app crashes: missing env vars" or "Auth.js v5 signIn imported from the wrong side". kira_route turns a goal ("build a web app") into an ordered plan with the right skill and scars per step.
Community scars are where personal scars graduate to — and the flow is live. Ask your agent to run kira_share_scar(scar_id): it re-sanitizes your personal scar, generalizes it, and hands you a prefilled submission link (nothing uploads until you click). An intake bot validates the JSON; a human reviews the content; on merge it ships to every Kira user. Prefer forms? Submit a scar directly.
Every accepted scar earns contributor status — sharing is how you get the fresh feed for free (see Contributing below).
Your agent hits a wall Your agent gets a task
↓ ↓
kira_record_failure() kira_premortem(goal) / kira_lookup(keyword)
↓ ↓
~/.kira/personal-scars/ scars first, then instructions
↓ ↓
next session: brief surfaces agent announces → executes → kira_report()
your scars before work starts ↓
↓ misses + failure notes feed the flywheel
never the same mistake twice → digest → catalog improvementsSkills are natural language Markdown — no executable code, no injection risk.
CLAUDE.md / .cursorrules | Kira | |
Setup | Copy per project | Install once |
Failure memory | You write it by hand, if you remember |
|
Recall | You re-read it, if you remember | Surfaced automatically at session start / task start |
Selection | You choose | Agent chooses, scored |
Updates | Manual | Automatic (flywheel) |
Works across AI tools | Tool-specific | Any MCP client |
There are excellent memory servers (knowledge graphs, session recall, context handoff). Kira is deliberately narrower:
Failure-first, not everything-first. General memory stores what happened; Kira stores what must never happen again, in a shape built for avoidance: mistake → instead, severity, recurrence count. A pre-task heat-map (kira_premortem) exists only because the data is failures.
Recurrence is measured, not assumed. Re-recording a similar failure folds into the same scar and bumps hit_count — the corpus learns which walls actually get hit, and honest counts are enforced by review.
The commons compounds. Your scar, sanitized and human-reviewed, ships to every install — and earns you the fresh feed (RECIPROCITY.md). Memory servers make one agent smarter; a scar corpus makes every agent immune.
Trust is engineered, not implied. Corpus text is injected into agents' contexts, so every entry passes a sanitizer-stability gate in CI, natural-language-only rules, and human review (SECURITY.md).
If you need general episodic memory, run one of those servers alongside Kira — they don't compete for the same job.
Personal scars (~/.kira/personal-scars/) and the miss log (~/.kira/misses.log) are local-only and never uploaded. Community telemetry is separate and consent-gated:
Mode ( | What leaves your machine |
| Nothing. Local log only. |
| Anonymous core: skill ID, status, anonymous UUID, kira version, OS family, Node major version, free/pro tier. No free text. |
| Same as basic plus sanitized |
Full schema, redaction rules, retention, and opt-out instructions: PRIVACY.md.
Env var | Default | Purpose |
| (unset → | Override consent level for this process: |
|
| Endpoint for batch upload. |
|
| Where consent state, personal scars, miss log, and flywheel output live. |
| (unset → free tier) | Contributor / supporter key — unlocks the fresh community feed. |
| (unset → no network) | Opt-in corpus feed URL for the free tier (90-day-delayed commons). |
The corpus is MIT and everything in it eventually becomes free. Freshness is the only premium — failure knowledge decays as models retrain, so the newest scars carry the value:
Fresh community feed | How | |
Contributor | ✅ free | One accepted scar = 12 months ( |
Supporter | ✅ paid | Sponsor the project → supporter key. Funds human review of every submission. |
Free | 90 days later | Base corpus ships with npm; delayed commons feed available opt-in. Local features + privacy guarantees are free forever, on every tier. |
Currently in grace mode: the fresh feed is open to everyone until the corpus reaches 100 community scars. Full policy: RECIPROCITY.md.
The first 1,000 contributors get permanent free access to all Kira features (fresh feed included) — see the reciprocity table above.
See CONTRIBUTING.md for how to add Skills and Scars.
The Flywheel — how the improvement loop runs
Where agents shine — by remembering where they got burned.
A B Button Corporation project.
Set the telemetry consent level for kira_report. level='off' disables all uploads (local log still written). level='basic' uploads only anonymous core (skill_id, status, anonymous UUID, version, OS family, Node major). level='full' additionally uploads sanitized free-text note/context. Call with no arguments to query the current state. See PRIVACY.md for the exact wire format and redaction rules.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | New consent level. Omit to query without changing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses behavior for each level, including that 'off' still writes a local log and 'full' uploads sanitized notes. Annotations (idempotentHint=true) are consistent; no contradiction adds extra context about persistence and redaction.
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?
Five sentences efficiently cover purpose, levels, query behavior, and reference to external doc. Front-loaded and no wasted words.
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 set/query tool with one parameter and no output schema, the description covers all key behaviors (query, set, levels) and points to PRIVACY.md for wire format, making it complete.
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 has 100% coverage with enum and description for the single parameter 'level'. Description adds meaning by detailing the data sent at each level, going beyond the schema's brief description.
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?
Description clearly states the tool sets telemetry consent level for kira_report with three distinct levels explained. It uniquely addresses consent among sibling tools (kira_get, kira_lookup, etc.).
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?
States when to query (no arguments) and refers to PRIVACY.md for details. Does not explicitly exclude usage scenarios or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full instructions for a specific skill or scar by ID. Call this AFTER kira_lookup to retrieve the step-by-step instructions for the skill you've chosen. lookup returns summaries (no instructions) to save tokens — use this tool to get the full details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The skill or scar ID (e.g., 'community.setup-stripe-nextjs.v1' or 'scar.vercel-env-vars-missing.v1'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read. The description adds that retrieval is for full instructions, and notes the token-saving pattern with lookup. However, it does not detail response size or potential rate limits, but these are less critical given the annotations.
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, each serving a distinct purpose: first defines the tool's function, second provides usage guidance. No wasted words.
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?
The description covers purpose and usage pattern well. For a simple tool with one parameter and no output schema, it is largely complete. A minor gap is not specifying the structure of 'full instructions', but it is adequate given the domain 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 coverage is 100% with a parameter description that explains ID format via examples. The description does not add additional meaning beyond the schema, so baseline 3 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 clearly states the verb 'Get' and the resource 'full instructions for a specific skill or scar by ID'. It distinguishes from sibling tool kira_lookup by noting that this tool retrieves details while lookup only returns summaries.
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?
Explicitly instructs to call this tool AFTER kira_lookup to get step-by-step instructions. Explains that kira_lookup returns summaries to save tokens, so this tool provides the full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up skills (how to do it) AND scars (what to avoid) for a given keyword. Returns matching skills (community first, then vendor) and scars (critical first; your own recorded failures before shared ones, then by frequency). Personal scars recorded by kira_record_failure on this machine fire here too. The agent MUST: 1. Read ALL returned scars first — these are past failures. Avoid repeating them. 2. Read returned skills and choose the best fit for the project context. 3. ANNOUNCE the chosen skill's 'declaration' field to the user BEFORE executing. 4. Follow the skill's instructions step by step, watching for scar patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional project context tags for disambiguation (e.g., ['nextjs', 'typescript']). | |
| keyword | Yes | The firing keyword or phrase (e.g., 'deploy vercel', 'add auth'). Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds substantial behavioral context: it explains the ordering logic of results (skills sorted by community/vendor, scars sorted by criticality and origin), and warns that both skills and scars are returned. It also mentions that personal failures recorded via kira_record_failure are included. No contradiction with annotations; description enriches understanding.
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 well-structured with a clear opening sentence defining the tool's purpose, followed by ordering details, and then numbered steps for the agent. Every sentence adds value without unnecessary verbosity. It is appropriately sized and front-loaded.
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's complexity (returns two types of data with specific ordering and agent usage steps) and no output schema, the description is remarkably complete. It explains exactly what the return values contain and how the agent should act on them, leaving no ambiguity.
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 coverage is 100% with descriptions for both keyword and context. The description adds that the keyword is case-insensitive and refers to it as a 'firing keyword or phrase', and mentions context for disambiguation. While the schema already conveys core meaning, the description provides slightly more context about how parameters affect the lookup, justifying above-baseline score.
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 it looks up skills (how to do it) and scars (what to avoid) for a given keyword. It distinguishes from sibling tools like kira_record_failure and kira_share_scar by specifying it returns both types with detailed ordering (skills: community first then vendor; scars: critical first, own recorded before shared, then by frequency). This is a specific verb+resource with clear outcome.
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 provides explicit step-by-step instructions for the agent: read all scars first to avoid repeating past failures, then read skills, announce the chosen skill's declaration field, and follow instructions while watching for scar patterns. It also notes that personal scars from kira_record_failure on this machine fire here, adding context. This gives clear when and how to use the tool, including exclusions (avoid repeating failures).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surface your most recent PERSONAL scars — the private, local-only failure notes recorded by kira_record_failure under ~/.kira/personal-scars/. Call this at the START of a session (ideally from a SessionStart hook) so you begin already aware of the walls you hit last time on this machine. Returns the top-N scars by recency (most recent first), each with its mistake and what to do instead. Pass 'limit' to change how many, and 'contexts' to keep only scars relevant to the current project. Personal scars are LOCAL-ONLY — this reads them from disk and never touches the network.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent scars to return (default 5, max 50). | |
| contexts | No | Optional project context tags (e.g., ['nextjs', 'typescript']). When given, only scars sharing at least one context are returned; untagged scars are always kept (they apply everywhere). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: 'Personal scars are LOCAL-ONLY — this reads them from disk and never touches the network.' It also describes return format (top-N by recency, most recent first, with mistake and alternative).
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?
Three dense, information-rich sentences with no wasted words. Front-loaded with the core purpose.
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 two simple optional parameters and no output schema, the description fully explains what the tool returns and under what conditions. No gaps.
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 100%, but the description adds extra context: 'Pass 'limit' to change how many, and 'contexts' to keep only scars relevant to the current project.' It clarifies that untagged scars are always kept, which is not in the schema.
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's purpose: 'Surface your most recent PERSONAL scars.' It specifies the resource (personal failure notes), the action (surface), and the source (local-only disk). It distinguishes from siblings by emphasizing local-only nature and connection to kira_record_failure.
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?
Explicitly advises when to use: 'Call this at the START of a session (ideally from a SessionStart hook).' This is strong, actionable guidance. It also implicitly differentiates by noting it reads local data never touching network, contrasting with other tools that might access remote data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a PRE-MORTEM before starting a task. Given a goal (and optional project context), return a heat map of the past failure patterns (scars, shared and personal) most likely to bite — ranked by how many times each wall has been recorded (hit_count). Each hotspot includes the mistake, the fix ('instead'), a relative heat score, and estimated minutes saved by avoiding it, plus an aggregate prevention value. When nothing matches strictly, 'near_scars' lists the closest recorded scars instead. Call this FIRST for any non-trivial task to surface known traps up front, then read each hotspot's 'instead' and use kira_lookup / kira_route to plan the actual work.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The task you are about to start, in natural language (e.g., 'deploy a Next.js app to Vercel with Stripe'). | |
| top_k | No | Max number of hotspots to return. Default 5, max 20. | |
| context | No | Optional project context tags (e.g., ['nextjs', 'typescript']) to focus the heat map. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description aligns fully, adding details about return structure (scars, hit_count, heat score, minutes saved). No contradiction; description enriches the safety profile.
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, dense paragraph that front-loads purpose and then details return values. It earns its sentences, though it could benefit from bullet points for readability. Not overly long.
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?
No output schema exists, so the description must detail return values, which it does: 'each hotspot includes the mistake, the fix ('instead'), a relative heat score, and estimated minutes saved... plus an aggregate prevention value.' It also covers edge cases like 'near_scars'. Adequate for the tool's complexity.
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 100%, so baseline is 3. The description restates the obvious for goal and context but does not add new semantic constraints or examples beyond the schema fields. Minimal added value.
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: 'Run a PRE-MORTEM' and 'return a heat map of the past failure patterns.' It clearly distinguishes itself from siblings by emphasizing its proactive role before task execution, unlike tools like kira_lookup or kira_route.
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?
Explicitly states 'Call this FIRST for any non-trivial task' and provides a clear after-action: 'then read each hotspot's 'instead' and use kira_lookup / kira_route to plan the actual work.' It also describes behavior for low-match scenarios ('near_scars').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a retry or exception you just hit as a PERSONAL scar — a private, local-only failure note stored under ~/.kira/personal-scars/. Call this immediately after a task needed extra attempts or threw an error, so future runs on this machine can avoid the same wall. Provide 'title' (what went wrong), 'mistake' (what was done / the exception), and ideally 'instead' (what to do next time). All free text is sanitized (keys, paths, emails redacted) before it touches disk. Personal scars are LOCAL-ONLY — they are never uploaded, on any tier.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short summary of what went wrong (becomes the scar title). | |
| instead | No | What to do instead next time (the fix / avoidance strategy). | |
| mistake | Yes | What the agent did wrong, or the exception / retry cause. The pattern to recognize and avoid next time. | |
| summary | No | Optional one-line summary. Defaults to the title. | |
| contexts | No | Project context tags (e.g., ['nextjs', 'typescript']). | |
| keywords | No | Firing keywords so this scar surfaces on future lookups. | |
| severity | No | Defaults to 'warning'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: local storage path, sanitization of personal data ('keys, paths, emails redacted'), and side effect of influencing future runs. Annotations are non-contradictory; description adds significant context beyond annotations.
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?
Description is clear and front-loaded but longer than necessary; includes some explanatory phrases that could be trimmed (e.g., 'so future runs on this machine can avoid the same wall'). Still well-structured.
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 7 parameters and no output schema, the description covers purpose, usage timing, privacy, and storage location. Lacks mention of return value or idempotency, but overall comprehensive.
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 coverage is 100%, so baseline is 3. Description adds meaningful context, explaining how each parameter is used (e.g., 'title becomes the scar title', 'mistake is what the agent did wrong', 'instead is the fix'), plus sanitization detail.
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?
Description clearly states verb 'capture' and resource 'personal scar', explicitly distinguishing itself as local-only failure notes stored under ~/.kira/personal-scars/, differentiating from siblings like kira_share_scar.
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?
Explicitly states when to call: 'immediately after a task needed extra attempts or threw an error.' Notes privacy constraints ('never uploaded'), implying when not to use (if sharing is needed), but does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the outcome of applying a Kira skill. ALWAYS call this after completing (or failing) a task guided by a Kira skill. Statuses: 'success' = worked first try, 'retry' = needed extra attempts, 'failure' = gave up. For 'retry' and 'failure', include a note describing what went wrong — this feeds the scar system so other agents don't repeat the same mistake.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | What went wrong (for retry/failure). This becomes a scar for future agents. Sent to the telemetry server only when consent level is 'full'. | |
| status | Yes | ||
| context | No | Optional sanitized snippet of agent context (project type, framework, etc.). Sent only when consent level is 'full'. | |
| skill_id | Yes | The id of the skill that was applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: mentions scar system, telemetry sent only on full consent, and details for retry/failure. No contradiction with annotations (readOnlyHint false, openWorldHint true supports this write behavior).
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: first states purpose, second details usage and statuses. No fluff, every word adds value. Perfectly front-loaded.
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?
Sufficient for a reporting tool with 4 parameters and no output schema. Covers when-to-call, statuses, note requirements, and telemetry consent. Could add return value hint, but not critical.
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?
Description elaborates on status and note parameters beyond schema definitions (links statuses to scar system, note required for retry/failure). Schema covers 75%, description fills gaps for status (enum meaning) and note (scar system purpose).
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 reports the outcome of applying a Kira skill, with a specific verb and resource. It also differentiates from sibling tools like kira_get or kira_route by emphasizing the reporting function and the ALWAYS call 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 description explicitly says to call this after completing or failing a Kira task, lists statuses, and instructs on note inclusion for retry/failure. It implies mandatory use, but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a complete route for a goal. Instead of looking up individual skills, describe what you want to achieve (e.g., 'build a web app', 'add payments') and Kira returns an ordered sequence of steps, each with its Skill and Scars. Use this FIRST when the user describes a broad goal rather than a specific task. Then execute each step in order, calling kira_report after each one.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The user's goal in natural language (e.g., 'build a nextjs app', 'add payments', 'deploy my app'). | |
| context | No | Project context tags (e.g., ['nextjs', 'typescript']). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, non-destructive hints. Description adds context about return structure (ordered steps with Skill and Scars) and usage workflow, but no additional safety or auth details.
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?
Three sentences front-loaded with main action, then usage guidance. No redundant information.
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 read-only, idempotent nature, no output schema, and full parameter descriptions, the description sufficiently covers what the tool does, when to use, and how to integrate with other tools.
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 coverage is 100%, baseline 3. Description adds value by explaining the 'goal' parameter with concrete examples and reinforcing the role of 'context'.
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?
Clearly states it plans a complete route for a goal, with examples distinguishing it from looking up individual skills. Explicitly contrasts with sibling tools like kira_lookup.
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?
Explicitly says to use this FIRST for broad goals, then execute steps sequentially calling kira_report after each. Provides when-not-to-use (instead of individual skills lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what's currently loaded and configured: kira version, tier (free/pro), telemetry consent level, counts of skills/scars/routes available, and where the local report log lives. Call this whenever you need to know the install state without exhausting the keyword search via lookup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Adds specific details on what is reported (version, tier, telemetry, counts, log path) and implies low cost.
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?
Single sentence, highly concise with no wasted words. Front-loaded with main function 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?
Covers key outputs without needing output schema, but lacks hint about return format. Minor gap for 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?
No parameters, so description does not need to add param info. Baseline score of 4 is appropriate; implicit that no input is required.
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?
Clearly states it reports installed state including version, tier, telemetry, counts, and log location. Distinguishes from sibling 'lookup' by noting efficiency.
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?
Explicitly calls it out as the tool to use for install state, and contrasts with 'lookup' to avoid exhaustive searches. Could further differentiate from other siblings.
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. Dates show when Glama detected each change.
v0.7.0kira_personal_briefkira_premortemkira_record_failurekira_share_scarv0.5.0kira_consentkira_getkira_lookupkira_reportkira_routekira_statusEach tool targets a distinct operation: consent for telemetry, lookup for searching, get for retrieving full details, report for logging outcomes, route for multi-step planning, and status for configuration. No two tools have overlapping purposes.
All tool names follow the consistent pattern 'kira_verb', using clear, single-word verbs. No mixing of naming conventions or unclear verb choices.
With 6 tools, the set is compact yet covers all essential operations for a skill/scar guidance system. Each tool is justified for the domain.
The tool surface covers the full workflow: lookup, retrieve, report, and route planning, plus configuration. The only minor gap is the lack of tools to create or modify skills/scars, but this appears intentional as the system is read-only.
Collective memory for AI agents. One agent solves a bug — every agent gets the fix instantly.
Production-readiness for your AI coding agents.
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Never let your agent repeat a bug or linger on a known issue. Search 385+ failure lessons to skip known errors instantly.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aibenyclaude-coder/Kira'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
