torah-mcp

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the Vilna layout, collapsible Rashi/Tosafot, click-to-translate, and the default behavior of showing the day's daf yomi when no argument is given. This goes beyond the schema and annotations.

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 compact, front-loaded with the core function, and every sentence earns its place: the layout, the interactive features, the default behavior, and the usage trigger with examples. No fluff.

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 read-only viewer with 2 optional parameters and no output schema, the description covers the main behavior, defaults, and usage trigger. It doesn't describe the return format, but since there's no output schema and the tool is a visualizer, the agent can infer the result is a rendered page. Minor gap: no mention of error cases (e.g., invalid ref), but this is acceptable for a read-only 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?

Schema description coverage is 100%, so the schema already documents both parameters (ref and langue) with examples and defaults. The description adds the default daf yomi behavior for ref, which is useful, but doesn't add much beyond the schema. Baseline 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 states a specific verb ('Affiche'), a precise resource (page de Guemara en visualiseur interactif façon Vilna), and the key features (texte au centre, Rachi/Tossafot dépliables, traduction au clic). It also gives concrete example invocations ('montre-moi le daf du jour', 'ouvre Berakhot 2a'), which clearly distinguishes it from siblings like sefaria_text or sefaria_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 description explicitly says 'Utiliser dès que l'utilisateur veut VOIR ou étudier un daf' and provides example user requests. This gives clear when-to-use guidance. It doesn't explicitly name alternatives, but the sibling list is large and the examples make the trigger condition unambiguous.

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

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

The description adds that output includes daily events ('événements du jour (Rosh Hodesh, fêtes, paracha)'), which is not in annotations. It doesn't discuss side effects, but readOnlyHint is true, so no write behavior is expected. It also doesn't contradict annotations.

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?

Two sentences, front-loaded with the primary function and followed by direction-specific instructions. No redundant content.

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 read-only conversion tool with 100% schema coverage, the description covers both directions and output events. However, it lacks explanation of 'apres_coucher' and doesn't describe output format, though these are not critical for a basic conversion.

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 description defines which parameters are relevant for each conversion direction, supplementing the schema's individual descriptions. It clarifies that 'date' is for civil-to-Hebrew and the trio 'annee_h, mois_h, jour_h' for the reverse, but omits 'apres_coucher'.

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 defines the tool as converting civil dates to Hebrew dates and vice versa ('Convertit une date civile en date hébraïque (ou l'inverse)'), including daily events. The verb and resource are specific, but it doesn't explicitly differentiate from sibling calendar tools like sefaria_calendar or zmanim.

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?

It gives explicit instructions for both conversion directions: 'Sens civil→hébreu : passer date (YYYY-MM-DD)' and 'Sens hébreu→civil : passer annee_h, mois_h, jour_h'. This provides clear context on parameter selection, though it doesn't mention alternatives or exclusivity conditions.

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

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

Les annotations fournissent readOnlyHint=true, signalant une opération en lecture seule, ce que la description confirme indirectement en disant que le texte est lu via Sefaria. Cependant, à part cette lecture, la description ne détaille pas le comportement : format exact de sortie, structure de la fiche, ou ce qui se passe si la référence est invalide. Elle ajoute peu au-delà de l'annotation de sécurité, donc score bas.

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?

La description tient en deux phrases, avec l'information clé (fonction, contenu de la fiche, source de texte) placée dès le début. L'ajout 'jamais de citation de mémoire' est un peu verbeux mais souligne la fiabilité. Pas de gaspillage majeur.

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?

Avec une complexité modérée (2 paramètres, schéma complet, annotations de lecture seule et pas de schéma de sortie), la description est minimale mais suffisante pour un usage simple. Cependant, elle manque de détails sur le format de sortie exact et sur l'interaction avec les autres outils (ex : comment obtenir des liens d'étude). Un agent aurait besoin de plus pour gérer des cas d'usage avancés.

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?

Le schéma couvre 100% des paramètres : ref avec un exemple concret et segments avec sa valeur par défaut. La description ne renseigne pas davantage sur le format de ref ou l'effet de segments (par exemple, si segments=0 est autorisé). Le baseline de 3 est approprié, car la description ne compense pas au-delà du schéma.

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?

L'action est claire : composer une fiche source partageable incluant texte hébreu, traduction, référence exacte et liens d'étude. La description précise aussi qu'elle lit via Sefaria, apportant une spécificité utile. Toutefois, elle ne distingue pas explicitement des outils voisins comme sefaria_search ou sefaria_text, et le nom n'est pas évident pour un agent non francophone.

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?

La description indique l'usage (créer une fiche à partager) mais ne précise pas quand utiliser cet outil plutôt que d'autres comme sefaria_text pour lire un texte ou sefaria_search pour trouver des références. Aucune condition d'exclusion ou alternative n'est mentionnée ; l'usage est implicite par le contexte de partage.

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

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

Annotations declare readOnlyHint=true, and the description adds meaningful behavioral details beyond that: it is a local, exact calculation, and niqqud is ignored. This provides context about the tool's execution specifics and limitations.

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?

Two tightly packed sentences: the first states the core function and scope, the second adds method details and an important caveat. No wasted words, every sentence earns its place.

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 one well-documented parameter and a read-only annotation. The description covers the purpose, methods, and a key behavioral caveat. While it does not describe the output format, the description is sufficient for a simple, well-scoped calculation 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 schema already describes the single parameter 'texte' with 100% coverage. The description reinforces that niqqud is ignored, which slightly clarifies behavior but does not add new semantic meaning to the parameter itself. Baseline score is appropriate given high schema coverage.

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 calculates gematria for Hebrew text, word by word and total, listing specific methods. This verb+resource+scope structure distinguishes it from all sibling tools, none of which offer gematria calculations.

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 defines when to use the tool (for gematria calculations) and what it does, but does not explicitly mention alternatives or exclusions. Since no sibling tool overlaps with this functionality, the context is clear enough to guide an agent.

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

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

The readOnlyHint annotation already establishes the safe read-only nature. The description adds context about the guide's structure and the weekly data it uses, but doesn't disclose whether the tool returns a formatted guide, initiates a mode, or provides navigation. No contradiction with annotations, but more behavioral detail would be clearer.

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?

Two sentences efficiently convey the tool's function and usage. The first sentence packs essential details about the guide's components, and the second gives a direct usage instruction. No wasted words or repetition of schema/annotations.

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 zero-parameter, read-only tool with no output schema, the description adequately covers what the tool does and when to use it. It could explicitly state the output format or behavior, but the description is sufficient for the tool's simple nature. The 'data of the week' phrase adds helpful context about automatic date-based input.

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 has zero parameters, so the description doesn't need to explain parameter syntax. The mention of 'les données de la semaine' implies the tool automatically fetches current week data, which is useful context beyond the empty schema. Baseline 4 for a no-parameter tool 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 clearly identifies the tool as loading a structured parasha study guide, enumerating specific components (aliya-by-aliya, questions with commentators, haftara, Shabbat table questions). It distinguishes itself from sibling tools like sefaria_text (raw text) and sefaria_calendar (dates) by focusing on a study method.

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 final sentence explicitly states when to use the tool: whenever the user wants to prepare or study the parasha. It provides clear usage context but does not mention alternatives or exclusions, which is acceptable given the tool's specific niche.

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

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

The description discloses meaningful behavioral detail beyond the readOnlyHint annotation: Claude becomes a study partner, asks questions, defends opposing positions (Rashi vs Tosafot), and withholds direct answers. This explains the mode's interactive design without contradicting the annotation.

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?

Two concise sentences with zero fluff. The purpose is front-loaded, and the usage guidance is tacked as a separate, clearly readable instruction. The parenthetical examples (Rashi vs. Tosafot) are efficient and illustrative.

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 no parameters, no output schema, and only a readOnlyHint annotation, the description is sufficiently complete: it tells an agent what the mode does, how it behaves, and when to activate it. It could touch on whether mode_etude coexists, but that is above the basis.

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?

With zero parameters and 100% schema coverage, the description is not required to explain parameter behavior. There are no parameters, so this dimension scores the baseline 4 as specified.

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 what the tool does: it activates an interactive study mode where Claude becomes an active study partner, asks questions, defends alternative positions, and helps formulate kouchiot. It also distinguishes this from a simple answer-returning mode, but it does not explicitly differentiate from the sibling mode_etude, which is likely a related study mode.

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 explicit when-to-use guidance: 'À charger quand l'utilisateur veut ÉTUDIER un texte, pas juste obtenir une réponse.' This provides a clear yes/no for a relevant situation. However, it does not mention when NOT to use it in favor of a specific alternative sibling like mode_etude, so it's not quite full guidance.

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

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

L'annotation readOnlyHint=true couvre déjà la sécurité, et la description ajoute des comportements essentiels : recherche par lemme, traduction automatique des autres langues, OCR fautif et non vocalisé. Elle prévient que les extraits servent à localiser un passage et non à citer, ce qui évite des attentes erronées.

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?

La description est dense et front-loadée : l'information clé sur la recherche plein texte apparaît dès la première phrase. On note une légère redondance entre « Recherche PLEIN TEXTE » et « Cherche dans le contenu des livres, pas seulement les titres », mais chaque phrase apporte soit un cas d'usage, soit une limitation utile.

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?

Il n'y a pas de schéma de sortie, mais la description décrit précisément ce que renvoie l'outil : passage trouvé, numéro de page, lien vers le fac-similé. Elle couvre les cas d'usage, les langues, la lemmatisation, la traduction et les limites OCR ; un agent dispose de tout le contexte nécessaire pour décider et invoquer correctement l'outil.

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?

Le schéma couvre 100 % des paramètres, donc la baseline est 3. La description ajoute une vraie valeur sur q en expliquant le comportement par lemme et la traduction automatique, ce qui dépasse le simple libellé du schéma. Les paramètres livre, auteur et limit ne sont pas approfondis, mais le schéma les documente déjà correctement.

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?

La description utilise un verbe précis (« Recherche PLEIN TEXTE ») et identifie une ressource spécifique, le corpus océrisé de HebrewBooks.org. Elle distingue clairement la recherche dans le contenu des livres de la recherche par titres et précise ce que renvoie l'outil : passage, page et lien fac-similé. La différenciation avec Sefaria et sefaria_text est explicite.

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?

La description indique explicitement quand utiliser l'outil : ouvrages absents de Sefaria, minhagim locaux, responsa, ouvrages nord-africains et orientaux. Elle donne aussi une exclusion nette : pour un texte à citer, utiliser sefaria_text. Ce niveau de guidage est supérieur au minimum viable.

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

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

With readOnlyHint=true already provided, the description adds substantial behavioral context: it discloses that the skill uses verified primary texts via Sefaria, provides links to hebrewbooks.org for reading, and covers specific Jewish text domains. This goes beyond the annotation by explaining the tool's method and output behavior.

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 two sentences, with the first providing a dense but informative overview of the skill's purpose and the second a clear usage instruction. It is not overly verbose, though the enumeration of text genres makes the first sentence slightly long.

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 no parameters, no output schema, and simple annotations, the description is complete: it explains what the skill does, when to use it, the topics covered, and the sources involved. The agent has enough information to know when to load this skill and what to expect.

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 reflects this, so there is no parameter information needed. The description does not need to explain parameters, and the baseline for zero parameters is 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 clearly states the tool's purpose: 'Charge le skill d'étude des sources juives' (loads the Jewish sources study skill) and specifies the domain of religious questions (halakha, Talmud, Tanakh, responsa, hassidout, moussar). It distinguishes itself from sibling Sefaria tools by being a meta-skill loader, not a direct search or text retrieval tool.

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 explicitly says 'À charger AVANT de répondre à toute question religieuse' (to load before answering any religious question), providing a clear when-to-use trigger. However, it does not explicitly mention when-not-to-use or alternative tools, though it implies this skill should precede the use of Sefaria tools.

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

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

The annotation readOnlyHint=true indicates no data mutation, and the description adds behavioral context by explaining that the tool adjusts response style without affecting source discipline. This goes beyond the annotation by clarifying the scope of the state change, which is useful. It does not elaborate on persistence, but that is minor for a mode setter.

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 relatively long but each sentence is purposeful: it front-loads the primary purpose and then systematically explains each mode. The structure with colons and quotes is clear. It earns its length because the mode explanations are essential for correct invocation, though it could be slightly more terse.

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 a single enumerable parameter and no output schema, the description is complete. It covers what the tool does, when to use it, and what each mode means. The usage trigger is explicit, and the mention of 'without touching source discipline' addresses a potential concern. Nothing critical is missing.

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 covers 100% of parameters and describes 'niveau' as 'Le mode à activer,' but the description adds substantial meaning by explaining each enum value ('debutant', 'classique', 'avance') in detail, including target audience and style. This goes far beyond the basic schema, enabling the agent to select the correct value.

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: it sets the response register based on the reader, and it explicitly details three modes without touching source discipline. This is a specific verb and resource that distinguishes it from sibling tools like 'sefaria_search' or 'guide_paracha', which are content-retrieval tools rather than mode setters.

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 an explicit trigger: 'À charger dès que le niveau de l'utilisateur est connu ou déductible.' This tells the agent when to invoke the tool. It does not provide explicit negative cases or alternatives, but since this is a global mode setter with no obvious alternative, the guidance is adequate.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful behavioral detail: the verse is actually read via Sefaria, the times come from Hebcal, and omitting a city removes the schedule section. This helps the agent understand the tool's conditional behavior and external dependencies.

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 front-loaded with the main action and is information-dense. It is slightly dense as one long sentence with parenthetical additions, but every clause earns its place and no redundant filler is present.

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 does a good job enumerating the returned message components: paracha details, the French verse, lighting/end times, and a study link. It leaves minor uncertainty about exact formatting or unknown-city handling, but those are partly covered by the schema and the stated no-city rule.

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 description only relates parameters to behavior at a high level ('pour la ville donnée', 'Sans ville, le mot est composé sans les horaires'). It does not explain the latitude/longitude/geonameid alternatives, leaving the schema to carry that meaning; with 60% schema coverage, this is a marginal gap rather than a severe one.

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 opens with a specific action and deliverable: 'Compose le petit mot de Chabbat de la semaine, prêt à envoyer sur WhatsApp', then lists the concrete contents (paracha, verset, horaires, lien d'étude). This clearly differentiates it from sibling navigation or study tools such as zmanim, guide_paracha, or sefaria_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?

It provides clear context: this is the weekly Shabbat-message generator for sharing on WhatsApp, and it explicitly states the no-city behavior. It does not name alternative tools or exclusions, but the composite purpose makes the usage situation clear enough.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context: it invokes an external academic service and explicitly states the return behavior ('Renvoie la meilleure vocalisation et les variantes par mot ambigu'). This goes beyond the annotation without contradicting it.

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 compact, front-loaded with the core action, and every sentence earns its place: function, genres/default, and expected output. 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?

With only two parameters, full schema coverage, readOnlyHint set, and no output schema, the description adequately covers what an agent needs: what the tool does, how it behaves, what genres are supported, and what it returns. Nothing essential is missing.

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%, so the baseline is 3. The description restates the genre enum and the default value already present in the schema, but it does not add meaningful new parameter-level detail beyond what the schema provides.

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 states a specific action ('Vocalise'), the exact resource ('texte hébreu non ponctué'), and the underlying service ('le nakdan de Dicta'). It also names the available genres, making the tool's scope immediately clear and distinguishable from the unrelated sibling tools.

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 clearly implies when to use the tool: for unpointed Hebrew text needing vocalisation, with genre selection. It does not explicitly mention exclusions or alternatives, but the context is clear enough and no sibling tool competes with this function.

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

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

Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds the default behavior (without argument returns today) but nothing else. No contradiction.

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 filler. It efficiently conveys the tool's function and default behavior.

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 tool with one optional parameter and read-only annotation, the description covers the essential usage. It lacks details about return format, but given no output schema, that may be acceptable. It lists the types of calendars included.

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 only parameter 'date' is fully described in the schema (YYYY-MM-DD default today). The description repeats the default but adds no additional semantics beyond the schema.

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 purpose: providing daily study calendars with specific examples (parachat hachavoua, haftara, daf yomi, etc.). It is specific and distinct from generic text retrieval, though it does not name sibling alternatives explicitly.

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 only notes the default behavior without an argument. There is no mention of conditions or exclusions.

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

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

With readOnlyHint=true, the bar is lower, and the description adds genuine behavioral context: it returns references (not the text itself) organized by category, which is beyond the annotation. This prevents an agent from expecting full text output. No contradiction with annotations.

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 efficient sentence packs the purpose, examples, return type, and follow-up action with zero waste. The core purpose is front-loaded before the category details.

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 list tool with readOnlyHint=true, the description covers what is returned (refs by category), gives category examples, and routes to sefaria_text for the actual content. With no output schema, the return format is described adequately, though slightly more explicit formatting detail could be added.

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% so both parameters are already documented. The description adds marginal value by listing example categories (Rashi, Tosafot, etc.) that map to the category filter, but doesn't add syntax or format details beyond what the schema provides. Baseline 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 states a specific action (retrieving commentaries and texts linked to a reference) with concrete examples (Rashi, Tosafot, midrashim, halakha, responsa) and clearly differentiates from the sibling sefaria_text by noting the caller must load text separately. An agent can distinguish this from sefaria_text and sefaria_search without opening schemas.

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 provides a clear usage workflow: call this to fetch linked references by category, then load the actual text with sefaria_text. This names the follow-up tool and the sequencing. However, it doesn't explicitly state when NOT to use it or name alternatives like sefaria_search for finding refs, so exclusions are absent.

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

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

Annotations already provide readOnlyHint=true, so the read-only safety profile is covered. The description adds scope and language context but does not disclose result format, pagination, sorting, or failure behavior. Given the annotation coverage, 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 two short sentences: the first states the action and scope, the second gives the practical use case. There is no filler, repetition, or unnecessary detail, and the key purpose is front-loaded.

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 search tool with a readOnlyHint, a fully documented two-parameter schema, and no nested structures, the description plus schema is complete enough for an agent to select and invoke the tool correctly. The absence of an output schema is acceptable here because the tool's behavior and purpose are clear.

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%, with both query and size already described in the input schema. The description reinforces the search intent but adds no parameter-level details beyond what the schema provides, so the baseline of 3 applies.

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 states a specific operation: 'Recherche plein texte dans toute la bibliothèque Sefaria', with a clear resource and language scope. It adds the use case 'retrouver une source dont on connaît les mots mais pas la référence', which makes the purpose concrete. It does not explicitly contrast with sibling tools like sefaria_text or sefaria_links, so it stops short of full sibling differentiation.

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 phrase 'Utile pour retrouver une source dont on connaît les mots mais pas la référence' gives a clear when-to-use context. It does not mention exclusions or explicitly recommend an alternative tool, so it lacks the explicit when-not/alternatives guidance needed for a 5.

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

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

The annotation readOnlyHint already covers the safety profile, and the description adds useful context: output is Hebrew text with an English translation only if available, and the returned text is the authoritative basis for citations. It does not describe failure modes or the exact response structure, but for a read-only lookup this is an acceptable level of 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 two dense sentences covering purpose, examples, and the key quoting rule, with no filler. The purpose is front-loaded, and the examples are compactly listed.

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 one-parameter, read-only retrieval tool with 100% schema coverage, the description adequately covers what to pass, what to expect in the response, and how to use the result. The only minor gap is not describing the response encoding or invalid-reference behavior, but the tool's simplicity makes this non-critical.

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 describes ref as a Sefaria-format English reference, but the description adds five concrete reference examples, including complex ones like 'Mishneh Torah, Laws of Repentance 2:1'. These examples materially help an agent construct a valid argument.

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 opens with 'Texte d'une référence Sefaria' and gives concrete examples like 'Genesis 1:1', 'Berakhot 2a', and 'Shulchan Arukh, Orach Chayim 1:1', which make the resource and scope unambiguous. It lacks an explicit action verb such as 'returns' or 'retrieves', so it stops short of the highest clarity score.

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 instruction 'TOUJOURS citer depuis le texte réellement lu ici, jamais de mémoire' strongly implies this tool is the authoritative source for quoting Sefaria texts. However, it never contrasts this tool with siblings like sefaria_search or sefaria_links, so choosing among them is left mostly to inference.

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

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

With readOnlyHint already covering safety, the description adds useful context: Hebcal is the data source, chabbat=true switches the output mode, and locations can be predefined or coordinates. However, it does not describe output shape, timezone defaults, or behavior on invalid input, so it remains moderate.

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?

Three short sentences front-load the main output, then the mode switch, data source, and location options. There is no filler, no repetition of schema detail, and every sentence contributes to selecting a valid call.

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?

Together with the rich schema, the description gives an agent enough context to call the tool: what date to pass, how to choose a location, and what output to expect. Minor gaps such as output serialization and invalid-location behavior remain, but they are not blocking for a read-only calendar 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 schema already describes 5 of 7 parameters in detail, and the description's 'chabbat=true' and 'coordonnées libres' phrases mostly restate those existing constraints. It adds only a light conceptual link between the mode flag and the returned content, without enriching per-parameter meaning much.

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 resource ('Zmanim du jour') and lists the returned items (alot, netz, sof zman, etc.), then specifies the chabbat=true behavior for Shabbat entry/exit times and paracha. It does not explicitly contrast with sibling tools such as sefaria_calendar or guide_paracha, so it misses the top score.

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 explicit conditional guidance: use chabbat=true for Shabbat times, and choose either predefined villes or free coordinates. It does not name alternative tools or say when not to use this tool, so it stops short of full routing guidance.

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