Skip to main content
Glama

Get passage

get_passage
Read-onlyIdempotent

Return the verbatim text of a Bible passage (up to 200 verses) in one public-domain translation, with a citation link. Examples: "John 3:16", "Psalm 23", "Genesis 1:1-2:3", "Esther 4", "Tobit 12", "1 Enoch 1:9".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "get_passage"
  }
}

Input Schema

NameRequiredDescriptionDefault
referenceYesBook chapter[:verse[-verse]] reference.
translationNoTranslation code. Default lxx2012 (Septuagint in American English).
psalmNumberingNoHow to read Psalm numbers in the reference. "mt" (default) = Masoretic/KJV numbering, converted for Septuagint translations. "native" = the translation's own numbering.

Output Schema

NameRequiredDescriptionDefault
bookYes
notesNo
versesYes
citationYes
referenceYes
requestedNo
translationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "book": {
      +      "type": "string"
      +    },
      +    "citation": {
      +      "properties": {
      +        "licence": {
      +          "type": "string"
      +        },
      +        "publisher": {
      +          "type": "string"
      +        },
      +        "translation": {
      +          "type": "string"
      +        },
      +        "url": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "url"
      +      ],
      +      "type": "object"
      +    },
      +    "notes": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "reference": {
      +      "type": "string"
      +    },
      +    "requested": {
      +      "type": "string"
      +    },
      +    "translation": {
      +      "properties": {
      +        "code": {
      +          "type": "string"
      +        },
      +        "licenceLabel": {
      +          "type": "string"
      +        },
      +        "name": {
      +          "type": "string"
      +        },
      +        "shortName": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "code",
      +        "name",
      +        "shortName"
      +      ],
      +      "type": "object"
      +    },
      +    "verses": {
      +      "items": {
      +        "properties": {
      +          "chapter": {
      +            "type": "integer"
      +          },
      +          "text": {
      +            "type": "string"
      +          },
      +          "verse": {
      +            "type": "integer"
      +          }
      +        },
      +        "required": [
      +          "chapter",
      +          "verse",
      +          "text"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "reference",
      +    "book",
      +    "translation",
      +    "verses",
      +    "citation"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two pieces of real value — the 200-verse cap and the returned citation link — but says nothing about error behavior for invalid references, which translations apply to which books, or ordering/format details beyond the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and constraints, then a compact set of examples that each demonstrate a distinct reference form. No filler or repetition of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, a full output schema, and 100% parameter coverage, the description only needs to supply the extras it does: the verse cap, translation constraint and citation. The only gap is behavior on failed lookups or on references spanning books, which is minor for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, and the examples genuinely add syntax the schema omits: cross-chapter ranges ('Genesis 1:1-2:3'), whole single-chapter books ('Esther 4', 'Tobit 12'), and non-canonical books ('1 Enoch 1:9'). It does not discuss the translation or psalmNumbering parameters, but the schema already documents those with defaults and enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Return the verbatim text of a Bible passage') plus concrete bounds (up to 200 verses, one public-domain translation, citation link). It does not name a sibling to contrast with, so the agent must infer that compare_translations or search_scripture serve the multi-translation / search cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use, when-not-to-use, or alternative routing is given. The phrase 'in one public-domain translation' weakly implies this is for single-translation retrieval rather than comparison, but the definition never says so or points to compare_translations or search_scripture.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources