Loading ToolBench

Reading the current corpus…

kairos_codex_mcp_server MCP server · D · ToolBench

kairos_codex_mcp_server

github.com/batson-j/kairos_codex_mcp_server

Bible API MCP server that provides access to Bible translations, books, chapters, and verses with language filtering and verse search capabilities

<=2025-11-25STREAMABLE_HTTP5 tools

58/100

Definition Quality75

Protocol Readiness69

Supportability23

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

No deprecated protocol patterns detected

Summary

Server defines 5 Bible query tools with consistent naming (all verb_noun: get_*, search_*). All tools have descriptions and input schemas with types. However, descriptions are formulaic and lack actionable context. Output schemas are not explicitly documented. Error handling is present but generic. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Parameter descriptions are minimal. The server reads from a public Bible API and has no write operations, but this read-only nature is not formally declared.

Tools (5)

get_booksread onlysource verified73/100

Get list of books available in a specific Bible translation. The user will see the response of this tool call.

get_chapterread onlysource verified75/100

Get the full text of a Bible chapter with verse numbers and formatting preserved. The user will see the response of this tool call.

get_translationsread onlysource verified73/100

Get list of available Bible translations. The user will see the response of this tool call.

get_verseread only50/100

Get a specific verse or verse range from the Bible. The user will see the response of this tool call.

search_versesread only50/100

Search for verses containing specific words or phrases across a translation. The user will see the response of this tool call.

Issues (7)

HIGHtool ↗

Output schemas not documented. Tools accept structured inputs but do not declare what they return (field names, types, structure). LLMs cannot plan downstream tool chains or extract required data.

get_translationsget_booksget_chapterget_versesearch_verses

HIGHtool-description ↗

Descriptions are generic and repetitive ('The user will see the response of this tool call'). They do not explain WHEN to call each tool, WHY one differs from another (get_chapter vs get_verse), or what the response structure is. Descriptions should be 50-200 chars and LLM-optimized.

get_translationsget_booksget_chapterget_versesearch_verses

MEDIUMtool ↗

No tool annotations. All tools are read-only but lack readOnlyHint annotation. This prevents clients from inferring safe retry behavior or displaying read-only badges.

get_translationsget_booksget_chapterget_versesearch_verses

Recommendations

Document explicit output schemas for all 5 tools. E.g., get_translations returns [ { id: string, name: string, language: string, numberOfBooks: int, ... } ]. Include this in tool descriptions and, if possible, as a 'returns' field.
Rewrite tool descriptions to be LLM-optimized (50-150 chars) and explain the tool's unique role. Example for get_chapter: 'Retrieve the full text of a Bible chapter (all verses). Use get_verse() for specific verses or ranges. Returns chapter text with verse numbers preserved.'
Add tool annotations: set readOnlyHint=true for all 5 tools to signal safe retry behavior.
Expand parameter descriptions to 15-30 words each. Include format, constraints, discovery method, and dependency notes. Example: 'translation_id: The ID of the Bible translation (string, case-sensitive). Call get_translations() first to discover valid IDs. E.g., "web", "kjv".'
Add error recovery hints. When translation_id is invalid, catch and return: 'Translation ID not found. Available translations: [list]. Try get_translations() to see all options.'
For search_verses, document the 'limit' default: 'Maximum number of results (default: 20, max: 100). Large limits may timeout.'
Add optional 'pretty' or 'format' parameter to get_chapter and get_verse to control output verbosity (full text vs verse numbers only). This enables agents to optimize token usage.
Consider adding a get_translation_metadata tool that returns full info about a translation (language, version, copyright, URL), currently mixed into get_translations response.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)

Score history

Overall score trend

First recorded score · v2 rubric

58/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	58	<=2025-11-25	v2