Kery MCP server has 26 tools with moderate naming consistency (verb_noun pattern mostly followed) but severe gaps in schema documentation, parameter descriptions, and output documentation. Tool names are generally clear (kery_start, kery_create_project, kery_delete_bug), but parameter documentation is minimal and input schemas are largely undocumented or inferred from limited code samples. Descriptions exist for tools but lack detail about when to use them, what they return, and error recovery. Critical issue: no visible input schema definitions beyond tool names and basic parameter lists, for most tools, schema structure cannot be verified from source code. The server is a STDIO-only implementation with no error handling patterns, no pagination for list tools, and no output schema documentation.
Input schemas are not visible for most tools (15+ tools have schema score 0). Critical tools like kery_start, kery_status, kery_list_projects, kery_list_runs, kery_list_bugs, kery_list_tests, kery_get_memory, kery_get_settings have no documented input schema.
Parameter descriptions are minimal and generic. Tools like kery_set_auth have a parameter 'config' of type 'object' with description 'Auth config', this violates the rule that every parameter needs a description explaining what it controls and what format/values are expected. LLMs cannot infer valid config schemas from 'Auth config'.
Define explicit JSON Schema for all tool inputs, including type, required fields, and enum constraints. Example for kery_set_auth: {"mode": {"type": "string", "enum": ["basic", "oauth2", "api_key"], "description": "Authentication mode..."}, "config": {"type": "object", "properties": {...}, "description": "Mode-specific configuration..."}}
Expand all tool descriptions to 50 - 200 characters with explicit WHAT (what does it do?), WHEN (when should the LLM call it?), and any prerequisites or side effects. Example: 'Create a new test case for the given project and environment. Call this after kery_list_tests to see existing tests. Returns test_id for use in kery_run_test.'
Document output schemas for all tools, specifying returned fields, types, and which IDs/references chain into downstream calls. Publish these as separate 'Output Schema' blocks in tool definitions or in a schema reference document.
Add pagination to all list tools: limit (default 20, max 100), offset (default 0), and total_count in response. Example: kery_list_projects should accept {limit: number, offset: number} and return {projects: [...], total: number, offset: number}.
Add description hints for each parameter explaining format, valid values, and constraints. For 'intent' parameters, clarify whether free-form strings are accepted or if specific intents (e.g., 'login', 'checkout', 'search') are expected. Use enums if the set is fixed.
Implement confirmation flow for destructive operations. Offer a dry-run parameter or a separate preview tool (e.g., kery_preview_delete_project) that returns what will be deleted without executing. Require explicit confirmation in a second call.
Score history
Overall score trend
First recorded score · v2 rubric
41/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
41
2026-07-28+
v2
read onlyauth45/100
Get authentication configuration for an environment
kery_get_memoryread onlyauth35/100
Get agent memory for a project
kery_get_run_detailread onlyauth47/100
Get detailed information about a run
kery_get_settingsread onlyauth37/100
Get Kery settings
kery_list_bugsread onlyauth42/100
List all bugs for a project
kery_list_environmentsread onlyauth48/100
List environments for a project
kery_list_projectsread onlyauth42/100
List all projects
kery_list_runsread onlyauth42/100
List all runs for a project
kery_list_testsread onlyauth42/100
List all tests for a project
kery_run_testwriteauth47/100
Run a test
kery_set_authwriteauth40/100
Set authentication for an environment
kery_setupwriteauth42/100
Set up a new Kery project
kery_startread only40/100
Start Kery (initialize or check health)
kery_statusread only40/100
Get current Kery status and capabilities
kery_stop_runwriteauth47/100
Stop a run
kery_update_bugwriteauth48/100
Update a bug status
kery_update_settingswriteauth43/100
Update Kery settings
kery_update_testwriteauth48/100
Update a test
No output schemas documented. Tool descriptions do not specify what fields are returned, what structure LLMs should expect, or what IDs/references are included for chaining downstream calls. For example, kery_create_project should document that it returns a projectId for use in subsequent calls, but this is absent.
List tools (kery_list_projects, kery_list_environments, kery_list_tests, kery_list_runs, kery_list_bugs) lack pagination parameters and limits. No evidence of limit, offset, or cursor parameters in definitions. This violates the pagination pattern: large result sets blow context windows.
No error handling or recovery guidance. Tool descriptions do not explain what errors might occur, how to recover, or what to do next. For example, kery_delete_project does not warn about cascade deletes or advise checking for active runs first.
Destructive operations (delete_*) lack confirmation or dry-run support. Tools like kery_delete_project and kery_delete_bug offer no way for agents to preview consequences or confirm intent before irreversible changes. Agents make mistakes, a confirmation pattern is essential.
Parameter 'intent' appears in kery_discover_flows, kery_run_test with no description of valid values or expected format. Are these free-form strings? Enums? This ambiguity forces LLMs to guess and causes misuse.
Tool descriptions are too short (25-40 chars typical). Patterns require 10 - 1024 characters with explicit WHAT, WHEN, and any prerequisites. Current descriptions ('Discover flows for a project', 'Set up a new Kery project') lack context for LLM selection and downstream behavior expectations.
kery_setupkery_audit_connectionkery_get_memory
Add error recovery guidance to tool descriptions. Example for kery_delete_project: 'Before deleting, call kery_list_runs(projectId) to check for active runs. Deletion cascades to all environments and tests. If deletion fails, a 409 conflict indicates active runs, stop them first with kery_stop_run.'
For tools with complex object parameters (e.g., kery_set_auth's 'config'), include a structured description with mode-specific examples. Alternatively, split into separate tools (kery_set_basic_auth, kery_set_oauth_auth) so the LLM has explicit choices.
Ensure every parameter has a description. Audit all 26 tools for parameters lacking descriptions (e.g., 'testId', 'runId', 'bugId') and add context: is it a display ID or internal UUID? What tool call generates it?
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to support protocol readiness. Mark kery_list_* and kery_get_* as readOnly; mark kery_delete_* and kery_update_* as destructive; mark kery_create_* with idempotent=false if retries could cause duplicates.