The server exposes only 1 tool (get_passage) with a minimal definition. The tool has a valid name starting with 'get_' verb, a brief description, and a single string parameter with a description. However, the parameter lacks type information in the visible schema, the description is very short (62 chars, below the optimal 10-1024 range), and there is no documented output schema. The implementation is a transparent proxy to a remote server, so tool definitions are not explicitly registered in the index.js file, they come from the remote endpoint. The definition quality is further hampered by the absence of error handling guidance, no pagination support documented, and no output schema documentation visible in the source.

• Document the exact output schema for get_passage. Example: 'Returns {passage_id, osis, book, chapter, verse, text, metadata}'.
• Expand the tool description to 100-200 characters explaining WHEN to call this tool (e.g., 'Use this to retrieve the full text of a Bible passage given its OSIS identifier. Returns the passage text and metadata.').
• Replace the example value in the 'osis' parameter description with a regex pattern or format constraint: 'OSIS identifier (format: Book.Chapter.Verse or Book.Chapter.Verse-Verse, e.g., John.3 or John.3.16-17)'.
• Add error handling guidance to the parameter description: 'Invalid or non-existent OSIS identifiers will return an error. Ensure the identifier follows standard OSIS format.'
• If the server supports pagination or filtering (e.g., returning a passage range), document pagination parameters and limits in the tool schema.

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained