Loading ToolBench
MCP server for gkill, a life-log and personal knowledge management system. Provides tools to search, read, and write life-log entries (kyou), manage tasks (Mi), handle GPS logs, access plugins, and manage repository metadata.
The gkill MCP server has 8 read-only tools with generally well-written descriptions (mostly 200-400 chars, well above baseline average of 194). Tool names follow verb_noun convention (gkill_get_*, gkill_update_*, gkill_delete_*, gkill_add_*) and clearly indicate action. However, critical gaps exist: (1) Input schemas are severely incomplete or missing for most tools, gkill_get_kyous (tool 3) shows empty properties {} in the schema provided, gkill_get_mcp_help (tool 2) has an empty enum [], and several tools lack visible parameter type definitions; (2) Parameter descriptions are present but inconsistent in detail, some like gkill_get_all_tag_names (tool 5) provide good guidance (limit 1-100, substring filtering), while others omit constraints; (3) Output schemas are NOT documented in any tool definition shown, the descriptions reference response fields (e.g., 'Response fields: gps_logs[], total_count, returned_count') but no formal output schema is provided; (4) Error handling and recovery guidance is absent from all descriptions; (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. The descriptions themselves are strong, they explain WHAT each tool does, WHEN to use it, and reference dependencies (e.g., gkill_get_kyous directing users to gkill_get_mcp_help for details). But the schemas are the critical failure, tools 3, 4, 7 appear to accept parameters (cursor, locale_name, start_date/end_date) that are not reflected in the provided input JSON schemas.
Get repository names configured in gkill. Use this to discover rep names for filtering in gkill_get_kyous via query.reps. Deployments can hold hundreds of repositories, so narrow with contains when you only need to confirm one name exists. Response fields: rep_names[], total_count (before limit), returned_count, truncated. Only repositories that supply kyou appear here — a plugin that emits no kyou (for example a GPS-only plugin) is absent by design, and its manifest rep_name is not a query.reps value. For canonical rep_types values, per-repository index freshness and where attached data lives, call gkill_get_rep_infos instead.
Get tag names defined in gkill. Use this to discover available tags for filtering in gkill_get_kyous via query.tags or query.timeis_tags. Accounts accumulate hundreds of tags, so narrow with contains when you only need to confirm one exists, or to list one family such as the autolog tags. Response fields: tag_names[], total_count (before limit), returned_count, truncated. Only tags whose target still exists are listed.
Get GPS log points in a date range (deduplicated, newest first). Supports cursor pagination and aggregation: use count_only to size a range, group_by:"day" for daily coverage buckets, and limit/cursor to page through points. Response fields: gps_logs[], total_count (cursor-less responses), returned_count, remaining_count, has_more, next_cursor, buckets (group_by only). Read-only.
Search life-log entries (kyou) and return them newest first with tags, texts, notifications and the type-specific payload inline. Start with query.calendar_start_date / calendar_end_date, query.words, query.tags, limit and data_types; tasks need query.for_mi plus include_create_mi (see gkill_get_mcp_help topic:mi). ALWAYS inspect warnings[] even when partial is false: a repository may have failed to load, so its records are absent — do not put a repository named by that warning back into query.reps. Unknown filter values and ids that match nothing are reported there too. limit / max_size_mb cap what is RETURNED, not what is SEARCHED — narrow the calendar range, data_types or reps to make a query faster. Page by passing next_cursor back as cursor; cursor pages omit total_count, so read remaining_count. count_only / group_by give counts and histograms without payloads. Every entry carries id and rep_name; pass include_attached_ids:true when you need tag_entities[] / text_entities[] (the annotation ids that gkill_update_text / gkill_delete_kyou need). Details: gkill_get_mcp_help topics search (response fields, query semantics, payload shapes), pagination, mi, data_types, plugin, idf, deleted.
Critical: gkill_get_kyous has empty input schema (properties: {}). The description references query parameters (calendar_start_date, calendar_end_date, words, tags, limit, data_types, for_mi, reps, rep_types, include_attached_ids, count_only, group_by, cursor, max_size_mb) but none appear in the schema. LLMs cannot pass required parameters.
Critical: gkill_get_mcp_help has 'topic' enum set to empty [] in input schema. Description says 'Omit topic (or pass "index")' suggesting valid values exist, but enum is empty. LLM cannot determine valid options.
High: No output schemas documented for any tool. Descriptions reference response fields inline (e.g., 'Response fields: gps_logs[], total_count, returned_count, buckets') but no formal return type schema is provided. LLMs cannot plan downstream tool calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
Return the detailed guide for one topic of this MCP server. The tool descriptions in this list are summaries; read the relevant topic before a first search (search / pagination / mi / data_types), before reading files (idf) or plugin bodies (plugin), before writing KFTL text (kftl), when looking for deleted entries (deleted) or repository names (rep), before interpreting the settings trees and the user's description notes on them (config), and whenever a response carries warnings you do not understand. Omit topic (or pass "index") for the list of topics. Static text — no round trip to gkill.
Get the Mi (task) board names that are actually IN USE. Boards are like Kanban columns that organize tasks. These are the distinct board_name values of live (latest, not deleted) Mi and MiReKyou records — not a configured list, so an account with no tasks returns [] and a board whose last task was deleted disappears. The default board (ApplicationConfig.mi_default_board, usually "Inbox") is NOT included unless a task actually sits there, and the web UI's "all boards" entry is a client-side pseudo-board that never appears here. Use this to discover existing board names for Mi queries (query.mi_board_name), and call it before gkill_add_mi / gkill_update_mi. Any string can be used as board_name — non-existent names create new boards. Response fields: boards[] (array of board name strings).
List the gkill plugins installed for the current user. Plugins are external programs that feed their own data into gkill — for example Claude Code / Claude.ai / ChatGPT conversation logs, Fitbit daily metrics, Google location history. IMPORTANT — plugins do not all play the same role, and emits_kyou tells you which one you are looking at. When emits_kyou is true the plugin supplies kyou: filter gkill_get_kyous with query.reps using an entry of rep_names[] (ALWAYS present: the rep names its kyou actually carry — a plugin that wraps several repositories, such as Git repositories archived as zip, lists each repository there, and rep_names is [] until its index is built) — rep_name itself is the plugin's manifest label and is NOT a query.reps value unless it also appears in rep_names — or the top-level data_types (its data_type), and pass include_plugin_content:true to get their bodies in the same call. query.rep_types does NOT work for plugins — they are not in the canonical rep-type vocabulary (a plugin whose provides names a typed kind such as kc or git_commit_log is the exception: its records also answer to that rep_types value). When emits_kyou is false the plugin supplies no kyou at all, and its data_type / rep_name are NOT query values: passing them matches nothing. Read that plugin's data through the route matching provides — today provides:["gpslog"] means gkill_get_gps_log. provides lists what the plugin supplies beyond kyou metadata (kmemo, kc, urlog, nlog, lantana, timeis, mi, git_commit_log, tag, text, notification, gpslog); an absent provides means it supplies plain kyou only. Response fields: plugins[] with name, version, description, data_type, rep_name (manifest label), rep_names (the query.reps values; always present for kyou-emitting plugins), emits_kyou, provides, is_alive (responds to a ping), process_running (started; read without side effects), has_last_error, typed_index, and gps_index. has_last_error is true when the plugin process wrote something to stderr — that is the signal to look at when is_alive is true but no records come back. The text itself is deliberately NOT returned: it is the plugin's raw stderr and carries the directory layout of the user's own machine. When it is true and the text is needed, ask the person running gkill to read it from the server console, and never copy it into documents or commit messages. typed_index is the KYOU index and is present only for plugins that declare a non-gpslog provides; it carries state ("ok" / "failed" / "never_built"), record_count (unique kyou ids), oldest / newest (how far the plugin has actually ingested), truncated, built_at, and — when a build failed — has_last_build_error and last_attempt_at (the failure text is withheld for the same reason as last_error). Index build failures never reach has_last_error: they happen inside gkill (timeouts, a busy plugin, malformed JSON), so has_last_build_error is the one to read for those. last_attempt_at matters because rebuilds back off after a failure and then produce no error at all. gps_index is separate (GPS points are not kyou) and appears for gpslog plugins once their points have been loaded: point_count, oldest / newest, fetched_at. It covers ONLY the points this plugin supplied, counted before deduplication — gkill_get_gps_log spans every GPS repository (including native ones) and dedupes, so the two numbers are expected to differ, sometimes by an order of magnitude. Do not read a stale newest here as proof that GPS recording stopped. Its absence means nothing has requested GPS logs yet, not that the plugin is broken — call gkill_get_gps_log with count_only:true to size the real total.
Report what this MCP server is: server_kind (read / write / readwrite), the gkill account it is connected to (account.user_id / account.device), the gkill build (gkill.version / commit_hash / build_time), transport (stdio / http), started_at / uptime_seconds, tool_count and schema_revision. schema_revision identifies the generation of the tool list a client holds. This description ends with the revision of the list you were given; if the response's schema_revision differs, your client fetched the tools before the server changed them (tool lists are fetched once per client session) — reconnect the MCP client before trusting any argument name or description in this list. Call it first when a search or write behaves unexpectedly: a different account or a stale tool list explains most of them. Takes no arguments.
High: No error handling guidance in any tool description. Tools reference warnings[], partial flags, and error conditions (e.g., 'a repository may have failed to load'), but descriptions never explain how the LLM should respond to these error states or how to recover.
High: Parameter constraints missing or incomplete. gkill_get_all_tag_names accepts 'limit' but description does not specify valid range (baseline pattern expects explicit min/max). gkill_get_gps_log requires start_date/end_date but format description is vague ('ISO DateTime or Date Only format').
Medium: No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema definitions. All tools appear read-only (stated in Risk field), but no formal annotation in the schema itself. Makes tool safety guarantees implicit rather than machine-readable.
Medium: gkill_get_kyous description is exceptionally long (900+ chars) and dense. While detailed, it exhausts token budget and buries key guidance. Could be split: brief summary + reference to gkill_get_mcp_help topic:search for detailed semantics.
Medium: gkill_get_plugin_list description is extremely long (1200+ chars) with nested details about index states, error handling, and plugin metadata. While comprehensive, it requires the LLM to parse and reason through dense text rather than structured schema.