Tags: Infinibay/ken
Tags
Release 0.11.0: minor bump for the MCP guard + README troubleshooting The 0.10.2 patch release already shipped the guard and the schema fix to PyPI, but it deserved a minor bump rather than another patch: * Anyone still on 0.10.0 from PyPI needs a clear signal that the fix is a non-patch change — the wheel had a wrong pin and a missed migration, so silently re-releasing as a patch would understate it. * Adds a Troubleshooting MCP startup section to the README so users who hit the same failure mode have something to land on when searching.
Release 0.10.2: guard the MCP startup against mcp<2.0
ken-rank 0.10.0 on PyPI shipped with the wrong pin (mcp>=1.0) and code
that only worked with that range. Installations done before the 0.10.1
fix could resolve mcp 1.x and then fail at MCP server import with a raw
ImportError that the host assistant saw as 'MCP failed to start'.
0.10.2 closes that hole three ways:
* src/ken/mcp/server.py now wraps the MCPServer import and writes an
actionable remediation message (uv/pipx/pip reinstall commands) when
the installed mcp is too old, then exits 1 — no more raw traceback.
* pyproject.toml tightens the pin to mcp>=2.0,<3 so a 3.x line can't
quietly break the MCP surface either.
* Resolves a latent schema bug in _register: under
'from __future__ import annotations' every annotation is a string at
runtime, so the JSON schema was generated as '{}' for every param.
ken tools file_symbols --no-include-docstrings used to fail because
argparse didn't see 'boolean' and rejected the --no- flag. The
schema now mirrors what the SDK itself derives.
Release 0.10.1: mcp 2.x compat - fix(mcp): migrate ken mcp server to mcp>=2.0 (c4954cf) - bump: 0.10.0 → 0.10.1 The MCP server in 0.10.0 imported from mcp.server.fastmcp, which 2.0 removed; hosts pinned to mcp 2.x (opencode today) failed to register any ken tools. 0.10.1 ports the server to mcp.server.MCPServer without changing the tool surface.
feat(install): wire ken into OpenCode via MCP OpenCode (https://opencode.ai) has no lifecycle-hook equivalent to Claude Code or Codex CLI — its plugin system is JS/TS-based and runs on Bun/Node. The documented way to expose structured tools to OpenCode is the MCP server block in opencode.json, which speaks the same protocol ken already serves for Claude Code. ken install --opencode . registers ken as a local MCP server in opencode.json (or .jsonc). Auto-detects when the project already has opencode.json or a .opencode/ directory; merges with user-authored config (model, providers, sibling MCP servers) and is idempotent across re-installs. Uninstall strips just the ken block and deletes the file if it empties. The read path tolerates JSONC: comments and trailing commas in the existing file. The stripper is string-aware so URLs and prompts containing '//' or '/* */' survive intact. 26 new tests in tests/test_install_opencode.py; existing test_install_codex.py updated for the new install() signature. Bumps to 0.10.0 — new feature (wiring a third assistant). Tagged v0.10.0 will trigger the publish-to-PyPI workflow.
ken 0.9.1 — migration reclaims disk `ken vectors migrate` moved the vectors out but left the database at its old size, because NULLing a column frees pages inside the file and nothing else. It now VACUUMs and reports the result: 14.2 MB -> 0.5 MB on a test index, 4.10 GB -> 214 MB on a Linux 7.1-rc2 one.
ken 0.9.0 — memory-mapped vector store rank() on a Linux 7.1-rc2 index (101 083 files, 771 563 symbols): 21.3 s -> 1.82 s, with the top-k output unchanged across 12 queries. fuzzy channel 20.4 s -> 0.374 s vectors memory-mapped, not deserialised lexical channel 22.6 s -> 0.126 s name tokens indexed once, not per query ken.db 4.10 GB -> 214 MB SQLite was never the bottleneck: it delivered the vector column at 906 MB/s, within 1.7x of a raw flat-file read, against 0.138 s of actual arithmetic. The cost was materialising 771 563 Python row objects per query. Storage format changes; existing indexes are converted by `ken install` and answer correctly in the meantime.
PreviousNext