Access Sefaria's library of Jewish texts, commentaries, and learning schedules via MCP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 9 of 9 tools scored.
Each tool targets a distinct aspect of the library: schedules, text metadata, links, structure, content, TOC, topics, versions, and search. There is no meaningful overlap that would cause an agent to select the wrong tool.
All tools follow a consistent verb_noun snake_case pattern, with 'get_' for retrieval operations and 'search_texts' for the search operation. The naming style is uniform and predictable.
With 9 tools, the server is well-scoped for a read-only library API. Each tool earns its place, covering the core retrieval needs without overwhelming the agent with excessive options.
The set comprehensively covers the library domain: searching, retrieving text, versions, structure, links, calendars, topics, and the full table of contents. For a read-only library, there are no obvious missing operations or dead ends.
get_calendarsAInspectReturns daily learning schedules (Parashat Hashavua, Daf Yomi, etc.) for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| custom | No | Customization (1 for diaspora, 0 for Israel parasha scheme) | |
| timezone | No | Timezone name (e.g., 'America/New_York', 'Asia/Jerusalem') | America/New_York |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly says 'Returns', indicating a read-only operation, and specifies that it is date-specific. However, it omits details like default date behavior or timezone handling, which the schema partially covers. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential purpose and examples without any unnecessary words. It is well-structured and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with fully documented parameters and no output schema, the description is sufficiently complete. It states what is returned and gives examples, though it could elaborate on return structure or edge cases. This is above average but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already documents, so the score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning daily learning schedules for a specific date, with concrete examples (Parashat Hashavua, Daf Yomi). This distinct verb-resource pair differentiates it from sibling tools that handle indexes, texts, or topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear from the description: retrieve schedules for a given date. No explicit exclusions or alternative tools are mentioned, but the specificity makes the context unambiguous, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indexBInspectReturns metadata for a specific text, such as section names and categories
| Name | Required | Description | Default |
|---|---|---|---|
| v2 | No | Use v2 index for more detailed records | |
| title | Yes | The title of the text (e.g., 'Genesis') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the full burden of behavioral disclosure. It only states the output type and does not mention error handling, side effects, authorization requirements, or runtime behavior, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. It includes useful examples without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides only illustrative examples of the metadata. It lacks information about return structure, error conditions, or how to choose this tool over its siblings, leaving noticeable gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both parameters (title and v2). The tool description does not add any additional meaning or usage details for the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Returns') and resource ('metadata for a specific text') with concrete examples like 'section names and categories'. However, it does not explicitly differentiate from sibling tools such as get_toc or get_topics, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling get_* tools. It only states what the tool does, with no exclusions, alternatives, or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_linksAInspectReturns a list of known connections (commentary, citations, etc.) for a specific text segment
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The text reference to find links for | |
| with_text | No | Include the text of the linked source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states a return value and examples of connection types, but does not disclose error behavior, permission requirements, or the effect of the with_text parameter. It is a read operation by implication but lacks explicit safety statements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence with no filler. The description is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature with complete schema, but no output schema exists. The description gives a high-level return type (list of known connections) but lacks detail on the list's structure, edge cases, or how with_text alters the response. It is adequate for basic use but leaves open questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal meaning by framing 'ref' as 'specific text segment,' but it does not elaborate on the with_text parameter or any parameter-specific nuances beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of known connections (e.g., commentary, citations) for a text segment. This verb+resource structure distinguishes it from sibling tools like get_text or get_toc, which operate on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific text segment (requires a ref) but provides no explicit guidance on when to use this tool over siblings like search_texts or get_text. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shapeAInspectReturns the structure and section counts for a specific text reference
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The text reference (e.g., 'Genesis') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states what is returned (structure and section counts) but reveals nothing about potential errors, formatting, or any side effects. This is adequate for a simple read operation but leaves some unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's output. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description sufficiently captures the core behavior. It could be more detailed about what 'structure' entails, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'ref' parameter with an example. The description only repeats 'specific text reference' without adding extra semantic value, so it meets the baseline but doesn't go beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Returns') and the resource ('structure and section counts') for a specific text reference. It is specific enough to distinguish from siblings like get_text or get_toc, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs structural information about a text reference, but it provides no explicit guidance on when to choose this tool over siblings like get_toc or get_index, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_textBInspectRetrieve the text and metadata for a specific reference (e.g., 'Genesis.1.1' or 'Berakhot 2a')
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The citation reference | |
| context | No | 0 to return just the specific text, 1 to include surrounding context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the primary action and examples, but doesn't mention whether the operation is read-only, what 'metadata' includes, or how errors are handled. This is insufficient for an agent to anticipate side effects or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that instantly conveys the tool's purpose with examples. No wasted words, front-loaded verb, and the formatting is clean. It earns the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and 100% schema coverage, the description is adequate but leaves gaps. There's no output schema, so the return format is not specified. Also lacks usage guidance and behavioral details, but the examples compensate partially. Overall, it's a minimally viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters fully, so baseline is 3. The description adds value by providing concrete examples of valid ref formats ('Genesis.1.1', 'Berakhot 2a') and mentioning that the tool returns metadata, which is not in the schema. This extra context raises the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and identifies the resource as 'text and metadata for a specific reference,' with concrete examples. This clearly states what the tool does, though it doesn't explicitly distinguish from sibling tools like get_links or get_toc. The resource type is fairly distinct, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over search_texts or how it differs from get_index. There's no explicit exclusion or alternative, so it lacks usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tocAInspectReturns the table of contents for all texts in the library, grouped by category
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it returns a TOC, but does not explicitly mention read-only nature, potential for large response, pagination, or any performance considerations. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that immediately states the action and object, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple 0-param tool, but it does not describe the exact output structure beyond 'grouped by category,' nor does it mention any alternatives or exclusions. Given the lack of an output schema, a slightly more detailed description (e.g., categories with items or nested structure) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows no properties. The description adds no parameter information because none is needed; the baseline of 4 applies due to the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and the specific resource ('table of contents for all texts in the library'), with the additional detail 'grouped by category.' This distinguishes it from sibling tools like get_text (which likely retrieves a specific text) and get_index (which might be an index of texts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (when you need a library-wide TOC grouped by category) but does not explicitly compare with alternatives or state when not to use it. No exclusions or references to sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topicsBInspectReturns a list of JSON objects containing metadata for topics in the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the return type. It does not disclose behaviors such as pagination, potential rate limits, authentication requirements, or whether the list is exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the action ('Returns') and is free of redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple retrieval tool but lacks detail about the structure of the returned metadata or any limitations. Since there is no output schema, more specificity about the JSON object fields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description adds context by specifying that the output is JSON metadata for topics, which is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of JSON objects containing metadata for topics, with a specific verb and resource. It is distinct from sibling tools by naming 'topics' as the resource, but it doesn't explicitly contrast alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_texts or other get_* tools. There is no context about prerequisites, filtering, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_versionsAInspectReturns available text versions for a specific reference
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The text reference (e.g., 'Genesis.1.1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states what is returned, offering no details on side effects, permissions, error cases, pagination, or other behavioral traits. This is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core function without any redundant words or filler. It is front-loaded with the verb and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no output schema), the description adequately conveys the tool's purpose. However, it lacks detail about the structure of 'available text versions' and any edge cases, which slightly lowers completeness. For a simple read tool, it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since 'ref' is fully described as 'The text reference (e.g., 'Genesis.1.1')'. The description's phrase 'for a specific reference' adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Returns' with a specific resource 'available text versions' scoped to 'a specific reference', making it clearly distinct from sibling tools like get_calendars or get_text. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when text versions are needed for a reference, but it provides no explicit guidance on when to choose this over alternatives. No exclusions or comparisons to sibling tools are mentioned, leaving the selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_textsBInspectSearch the Sefaria library for a query string.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of results to return | |
| type | No | Type of documents to search | text |
| query | Yes | The search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool searches for a query string, without explaining search semantics (e.g., fuzzy vs exact), result format, pagination, or any side effects. This adds minimal value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core action and target resource efficiently, making it exemplary from a conciseness standpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is relatively simple, it has no output schema, so the description must help the agent understand what to expect. It fails to mention that the search can target texts or sheets (via the 'type' parameter), how results are sized (via 'size'), or any limitations of the search. This leaves a significant gap for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (query, type, size) with 100% coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, merely echoing 'query string' without elaborating on the type or size parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and names the resource ('Sefaria library'), making the tool's purpose immediately clear. This also distinguishes it from the sibling get_* tools, which retrieve specific items rather than performing a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'search' implies the tool is for query-based lookup, which contrasts with the sibling get_* tools for known references. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or contextual cues beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
