eklavya weekly downloads statistics

Eklavya

Eklavya teaches the concepts behind agent-written code and keeps local project memory. This package includes the Claude Code plugin, installer, CLI and MCP server.

Install in Claude Code

With Claude Code and Node.js 22+ with npm:

The installer uses the defaults without settings questions and keeps saved choices. It registers the plugin, installs the managed runtime and chat/artifact skills, and prepares local storage. New installs have the quiz side panel, memory and prompt feedback on. Memory summaries and prompt feedback use claude-sonnet-5 through your Claude Code login, so captured session evidence goes to that model. Memory explains what is captured and how to use local summaries instead. If Claude Mem is installed, it keeps recording and Eklavya memory stays off until you switch recorders.

Allow Eklavya's ten tools in auto mode, then restart Claude Code. /eklavya:setup is an optional installation check.

Read the installation guide for verification and updates and removal for maintenance. Uninstall preserves learner data unless you explicitly use --purge.

Standalone MCP connection

An MCP client can connect directly:

This exposes tools. Automatic capture, checkpoints and session instructions depend on host integration; an MCP connection alone does not provide Claude Code's learning loop.

Available tools

| Purpose | Tools |

| Learner state and concepts | get_learner_profile, log_session_concepts, upsert_concepts, get_concept_graph | | Questions and assessment | get_session_quiz_plan, record_attempt, get_gate_status | | Quiz side panel (experimental) | present_question for the model; panel_sync and panel_answer, called only by the panel mod, never by the model; its header stacks the mark above the topic in a pane under 60 cells wide | | Settings | get_config, set_config | | Find and read memory (memory_status includes a health verdict with reasons) | memory_search, memory_get, memory_timeline, memory_file_history, memory_status | | Maintain memory | memory_write, memory_correct, memory_delete, memory_collections | | Inspect code | code_outline, code_find_symbol |

log_session_concepts and upsert_concepts take a concept name of 1 to 3 words, a description of up to 400 characters and up to 5 tags. A new concept that resembles existing ones is not created: the response lists it under needs_decision with candidates, and you reuse a candidate's slug or repeat the slug with new: true. log_session_concepts creates a new concept with the domain and tier you pass, or domain general and tier 2 when you pass none. Pass prerequisites (up to 5 slugs, existing or in the same call) and each becomes a prerequisite_of edge; a slug it cannot find is reported under prerequisites_not_found, and the response lists the created concepts that still have no edge under unlinked. upsert_concepts sets the domain and tier of a model-created concept that still has domain general, adds tags to any concept, fills in or refines the description of a model-created concept, and adds edges. It never rewrites the description or domain of a concept from the seed or a pack, or of one that already has a domain (the one it was logged with, or its first tag). Its response lists the concepts it changed under updated. get_concept_graph returns each concept's tags.

memory_collections applies a saved filter the same way with or without a query, and its members are live entries only: a member deleted or corrected after the last rebuild drops out of show, and its replacement joins at the next rebuild if the filter matches it.

record_attempt returns the attempt_id of the row it wrote. For a multiple-choice question, also pass correct (the right option's label, verbatim), which lets the learner correct a missed answer from its explainer page in the dashboard, where the server grades the new pick, and option_notes (the note under each option, in order), which that page shows under each option. A correct that is not one of the options, or notes of the wrong length, is stored as nothing and reported back (correct_mismatch, option_notes_mismatch); the answer is still kept. An outcome of invalid means the question itself was at fault (it assumed context the learner never saw, or two options both answered it): it is stored in invalid_questions, grades nothing, returns no attempt_id, and changes no mastery, level, review date or gate; only the repeat check reads it. Each time the option-length check returns a question for a rewrite, option_checks (migration 028) keeps the session, concept, surface (panel or card) and outcome (sent_back, then rewritten or unchanged), never the options; no score, level or gate reads it, and npm run eval -- history reports it. An outcome of declined or dont_know with a grade of 3 or more is contradictory: it returns error: "outcome_grade_conflict" and records nothing, so that call can never update mastery, clear a gate or count toward a level.…