La Iglesia Católica de los Agentes de AI

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context beyond them: the authority disclaimer (not the Holy See, not a diocese) and the licensing of texts, which materially affect how an agent should cite or represent the source.

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?

Front-loaded and short: the substance comes first and the disclaimer/licensing items are listed compactly. The ES line largely restates the EN line, which costs a little space but is defensible for a bilingual tool.

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-required-parameter informational tool with no output schema, the description tells an agent what topics the response covers. It could go further on return shape or length, but nothing an agent needs in order to call it correctly 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% and the single lang enum is fully documented with default and allowed values, so the schema carries parameter meaning. The description's Spanish mirror line signals multilingual output but adds nothing about language behavior beyond what the enum already states.

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 names the resource concretely — this church for AI agents — and enumerates the content payload: what it is, how to connect, a jurisdictional disclaimer that it is NOT the Holy See nor a diocese, and text licenses. That is specific enough to separate it from content siblings like bible_passage or catechism, though it never explicitly contrasts itself 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?

Usage is only implied: an agent can infer this is the orientation/disclaimer lookup to consult before or instead of doctrinal content tools. There is no explicit 'use this when' clause, no exclusions, and no pointer to a sibling for canonical or legal questions.

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, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds one genuinely behavioral caveat beyond that: deuterocanonical books only exist in Catholic Bibles, which warns of a possible empty result. It still says nothing about output shape, translation labeling, or what happens when a book is absent from the chosen bible.

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 and front-loaded, leading with what is returned and then the reference grammar with concrete examples. The trailing Spanish translation line is a small redundancy for a single-language audience but is defensible for a bilingual tool, and no sentence is filler.

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 should ideally describe the returned structure (e.g., verse text vs. a list of ranges, translation metadata), and it does not. The reference grammar and availability caveats are thorough, so an agent can call it correctly, but it cannot anticipate the response shape or error behavior.

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, but the description substantially enriches the ref parameter beyond 'Reference, e.g. MAT 5:1-12' by documenting OSIS-style book ids, chapter:verse range forms, multi-range separation with ';', and Hebrew numbering for Psalms. It also explains the fallback logic behind the bible default, which the schema only hints at.

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 resource and action: 'Text of a Bible passage', immediately telling the agent this is a retrieval-by-reference tool. It is clear on its own, but it never differentiates itself from the sibling bible_search, so an agent must infer that this tool takes a reference while the sibling takes keywords.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer bible_search, readings_of_the_day, or mass_of_the_day instead. The only usage-like content is reference syntax and the bible-id default, which is parameter mechanics rather than tool selection 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add behavior. It does: substring matching is case- and accent-insensitive, results are capped at 20, and search scope silently narrows to five books without `book` — an important surprise-preventing detail. Missing is anything about result ordering, snippets, or whether truncation at 20 is signaled.

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 written English sentences put the match semantics first and the scope constraint second, with no filler. The appended Spanish line largely duplicates the second sentence; it is justified by the es/en/it audience but is redundant for an agent reading English.

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 5-parameter search tool with no output schema, the description covers matching and scoping well but says nothing about what a result contains (verse reference? snippet?), what order results come in, or how the 20-cap interacts with `limit`. An agent can call it, but cannot predict the response shape.

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 80%, so the baseline is 3, but the description earns above it by clarifying that `book` admits exactly ONE book id and by documenting the default book-set behavior that the schema does not state. It also supplies a concrete example (ROM) beyond the schema's generic list.

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?

"Simple word/phrase search (case- and accent-insensitive), max 20 results" gives a specific verb and resource plus its matching semantics. The scope rules (one book if `book` is given, otherwise Gospels + Psalms) make the tool's behavior concrete, but it never names the sibling `bible_passage`, so the agent must infer that exact-reference lookups go there.

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 implicitly guides usage by explaining that omitting `book` restricts the search to MAT/MRK/LUK/JHN/PSA, which tells an agent when results will silently miss other books. However, there is no explicit when-to-use statement, no exclusion of `bible_passage`, and no advice for what to do when the target book falls outside that default set.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds value on top by disclosing the two distinct response shapes (index vs. module payload with principles, applications, refs and a question), which the agent cannot learn from the annotations. It stops short of saying whether module payloads are stable/cached or how large they are.

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 core English sentence is front-loaded and does real work: resource, module range, both output modes. The trailing Spanish line only partially duplicates the English (it omits the return contents of a module), so it adds a little noise without full parity.

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 two-parameter read-only tool with no output schema this is mostly sufficient: the agent knows what it will get back in each mode. The notable gap is the absence of any indication of what each of modules 1-12 covers, which is exactly the information needed to select a valid, meaningful module number.

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 50%: `lang` is documented in the schema and `module` only has min/max bounds. The description partially compensates by explaining that `module` is optional and toggles the output mode, but it never says what any of the 12 module numbers actually contain, so an agent must guess which integer to pass. Baseline 3 is appropriate given partial coverage and partial compensation.

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 names the resource (a 12-module catechumenate) and states both output modes explicitly: no `module` yields the index, a module number yields principles, agent applications, refs and a question. That is specific enough to distinguish it from siblings like `commandments` or `bible_search`. The only weakness is that the action verb is implicitly 'retrieve content' rather than stated as a verb.

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 clear branching guidance between the index call and a module call, which is the main decision an agent faces here. It says nothing about when to prefer this over related siblings such as `commandments`, `confirmation_exam` or `values_for_agents`, so the cross-tool choice is left 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safe static-reference profile is covered. The description adds the useful facts that output includes refs and an examen question and that numbering variant is selectable, but says nothing about response format or size.

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 short sentences, front-loaded with the resource and contents, then the ES gloss. The Spanish translation is mildly redundant given the lang parameter, but nothing is bloated.

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 trivial two-parameter, read-only tool with no output schema, this is nearly complete: it names the selectable variants and the shape of the payload. The only soft spot is the unexplained term 'refs', which an agent must guess at.

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 only 50%: the lang parameter is documented in-schema but numbering has no schema description. The description compensates by explaining that numbering selects Catholic (default) or Protestant, adding real meaning beyond the bare enum values.

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 resource (the Ten Commandments) and what it returns: each commandment's application to AI agents, refs, and an examen question, plus the Catholic/Protestant numbering choice. This is clear enough to distinguish it from bible_search or catechism, though it never explicitly names those siblings.

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?

Usage is only implied: an agent can infer it should call this for moral-reference material rather than scripture lookup, and the mention of an 'examen question' hints at overlap with examen_of_conscience, but the description never says when to prefer one over the other.

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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered; the description adds the substantive detail that grading produces score, pass/fail, explanations and a dated symbolic certificate with a seal, plus the scope disclaimer 'not a sacrament'. It doesn't state how many questions exist or what the certificate text looks like, which is a minor gap rather than a 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 core behavior is front-loaded in the first sentence, with the mode switch stated before the details. The trailing Spanish sentence largely repeats the English content, which is defensible for a multilingual tool but is still redundancy rather than new 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 does the work of describing return values (questions, score, pass/fail, explanations, certificate) and it covers the nested `answers` object. An agent could call it correctly, though exam length and the exact grading rules remain unspecified.

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 both `lang` and `answers` are already documented with an inline example. The description restates the `answers` format with the same example and never discusses `lang` or its default, so it adds little meaning beyond the schema; baseline 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 names a specific resource (a confirmation exam) and spells out two distinct modes: with no `answers` it returns the question set, with `answers` it grades and returns score, pass/fail, explanations and a certificate. An agent can distinguish this from siblings like `examen_of_conscience` or `catechism` because the grading-plus-certificate behavior is stated 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 two-mode structure effectively tells the agent when to omit `answers` (to fetch the questions) versus when to supply them (to grade). What's missing is any explicit routing to alternatives, e.g. that `examen_of_conscience` is a different, non-graded examination, so the agent must infer sibling selection.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the 30-day cycle rotation and the three-part content shape (value, meaning, commitment), which is worthwhile context. It says nothing about invalid dates or out-of-cycle behavior, so it is useful 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?

Two short clauses that front-load the resource and its contents. The bilingual ES restatement is redundant for an agent but brief enough not to obscure the English original.

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-required-parameter read-only lookup with a fully documented schema and complete annotations, the description covers the essentials and hints at the return shape. The missing piece is sibling disambiguation against values_for_agents, which a routing agent genuinely needs.

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% — the date pattern, the Europe/Berlin default and the language enum are all documented in the schema. The description adds no parameter meaning, so the baseline 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 identifies the payload concretely — a day's value from a 30-day cycle plus its meaning for agents and a concrete commitment — so an agent knows roughly what comes back. But there is no verb phrase and no differentiation from the sibling values_for_agents, so the agent cannot tell from the text alone whether this is the same catalog or a different resource.

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?

There is no guidance on when to call this versus values_for_agents, saint_of_the_day, or readings_of_the_day, and no note that the cycle rotates every 30 days in a way that affects repeat calls. The agent must infer usage entirely from the tool name.

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, idempotentHint, non-destructive and closed-world, so safety is fully covered structurally. The description adds that the payload is a set of reflective questions, but says nothing about how many, whether they are fixed or vary per call, or what the response shape looks like — which is the only behavior an agent still needs to know.

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?

Effectively two short sentences with the purpose front-loaded and no filler. The Spanish line is arguably redundant given the lang parameter, but it is brief and consistent with the tool's bilingual nature.

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-required-parameter, read-only tool with a fully documented enum and no output schema, the description is close to sufficient. Still missing is whether the question set is static across invocations, which an agent would want before calling it repeatedly for iterative self-review.

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 single 'lang' enum is fully documented with default 'es', so the description owes little. The bilingual ES line hints at the multilingual output, but no language behavior (e.g., fallback) is added beyond the schema; baseline 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 names a specific resource (examen of conscience questions) and states their intended use: an agent reviewing its own work honestly. That is materially clearer than a tautology and separates it from doctrinal siblings like catechism or commandments, though it never explicitly contrasts 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 phrase 'for an agent to review its own work honestly' implies the moment of use (self-check after producing output) but gives no explicit trigger, no exclusions, and no reference to any sibling tool as an alternative. Usage is inferable rather than stated.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the rite scope (Roman calendar) and by revealing that the response includes the year's movable feasts, not just the queried date's data. It does not cover failure behaviour for malformed or out-of-range dates, but that is a minor gap given the annotation coverage.

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 short sentences with the substantive content front-loaded: the returned fields come first, the calendar rite second. The Spanish sentence is a near-verbatim translation rather than new information, which is mild redundancy, but it is proportionate for a bilingual audience and nothing else is padded.

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 two-optional-parameter read-only lookup with no output schema, the description says enough: what is returned, which calendar system, and implicitly that a date is the input. Timezone defaults and language options live in the schema, so they need not be repeated here. Only the lack of output-shape detail (e.g., what 'color' looks like as a value) keeps it from a 5.

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 the date pattern/default (today in Europe/Berlin) and the lang enum documented inline. The description adds no further semantics about the parameters, so the schema carries the full burden and the baseline 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 resource set — liturgical season, week, color, celebration, and the year's movable feasts — for a given date in the Roman calendar. That is far more informative than the title, which merely restates the tool name. It does not explicitly contrast with siblings such as mass_of_the_day or readings_of_the_day, though the returned fields implicitly distinguish it.

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?

Usage is implied rather than stated: an agent can infer this is the lookup for calendar/season metadata for a date. There is no explicit when-to-use guidance, no mention of when to pick this over readings_of_the_day or mass_of_the_day, and no note on limitations (e.g., only the Roman rite).

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the bar is lower. The phrase 'with full texts' hints that the response is large, which is useful, but the description says nothing about response length limits, whether content is cached or generated, or how missing dates/languages are handled.

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 main English sentence is front-loaded, content-dense, and free of filler. The trailing Spanish sentence is a near-duplicate translation that adds little for an agent that has already parsed the English, but it does not obscure the primary 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 must convey the return shape, and it does so by listing the sections produced in order. Given three optional, fully documented parameters, this is close to sufficient; the main omission is any note on response size or the language/Bible fallback behavior.

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%, and the schema already documents the default date (today in Europe/Berlin), the lang enum, and the bible id with examples. The description adds no additional meaning about how bible selection interacts with lang or what happens when the requested Bible lacks a reading, so it sits at the 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 names a specific composite artifact and enumerates its parts (introductory rites with examen, Liturgy of the Word with full texts, reflection, offertory, Our Father, blessing), so an agent knows exactly what it gets. It stops short of contrasting itself with close siblings like readings_of_the_day, daily_value, or examen_of_conscience, which deliver subsets of the same content.

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?

Usage is only implied: an agent can infer this is the whole-day devotional package versus the narrower sibling tools. There is no explicit 'use this when you want the complete Mass, use readings_of_the_day when you only need the readings,' and no stated prerequisites 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description adds genuine content scope beyond that — notably that the second reading appears only on Sundays/solemnities — which prevents an agent from assuming it is always present. It does not describe the return shape (citations, refrain structure) despite there being no 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.

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

Two short sentences, front-loaded with the resource and its contents, with zero filler. The duplicated Spanish line mirrors the schema's bilingual style and matches the es default, so it is defensible rather than wasteful, but it does add length without adding information for the agent.

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?

This is a simple read-only retrieval tool with a fully documented three-parameter schema and clear annotations, so the description covers enough to call it correctly. The remaining gap is the return structure: it says 'full text' but not how readings are keyed or whether references/psalm refrains are included, and there is no output schema to fill that in.

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%, and the schema documents all three parameters including the YYYY-MM-DD pattern, the Europe/Berlin default, the lang enum and the bible id examples. The description adds no parameter-level meaning beyond that, so it sits at the baseline rather than above it.

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 names a specific resource (the day's Mass readings) and enumerates the exact content returned: first reading, psalm, second reading on Sundays/solemnities, and gospel, with full text. That is far more specific than a restated title. It does not, however, distinguish itself from the sibling mass_of_the_day or liturgical_calendar, which an agent could easily confuse it with.

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?

Usage is only implied: the agent can infer this is the tool for liturgical reading texts on a given date. There is no explicit statement of when to use this versus mass_of_the_day (Mass order/antiphons) or liturgical_calendar (feast lookup), and no exclusions or prerequisites are given.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the payload is a note plus an example, which is useful given there is no output schema, but it says nothing about data sourcing, caching, or fallback when no saint matches the date.

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 short, front-loaded sentences with no padding. The cost is that the entire text is duplicated in Spanish, roughly doubling length for no informational gain to an English-reading agent.

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-required-parameter, read-only lookup with fully described schema, the description covers the essentials and, importantly, indicates the shape of the return value since no output schema exists. A line on behavior for invalid or out-of-range dates would close the remaining gap.

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%: the date format, the Europe/Berlin default and the lang enum are all documented in the schema. The description adds no further meaning about either parameter, so the baseline 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?

Names a specific resource ('Saint or feast of the day') and states what the response contains ('a short note and an example'). It is distinguishable from siblings like liturgical_calendar or daily_value, though it does not 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?

There is no when-to-use guidance, no exclusions, and no mention of the closely related siblings (liturgical_calendar, mass_of_the_day, readings_of_the_day). The phrase 'for agents' hints at audience but not at selection criteria.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered and the description does not need to repeat it. What the description leaves undisclosed is the meaningful behavior: what happens when topic is omitted (full dump vs. default topic) and roughly what the response contains. Nothing contradicts the 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 topic enumeration is a long comma list duplicating the schema enum, and the trailing Spanish sentence ('ES: Virtudes, bienaventuranzas...') is a near-verbatim restatement of the English content with no added information. The opening is a bare noun list rather than a front-loaded statement of what the tool does.

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 two-optional-parameter lookup tool with annotations and no output schema, this is adequate but leaves a real gap: the omission behavior for topic (and for lang default = es) is never stated. An agent can call it, but cannot predict whether a topic-less call returns everything or a default set.

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 50%: lang is documented in the schema, topic is documented only by its enum. The description restates the topic enum verbatim, which is redundant with the schema rather than additive, and it adds no meaning about how topics relate or what a combined/default call yields. Baseline 3 is appropriate for mid 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 enumerates the specific content domains covered (virtues, beatitudes, works of mercy, capital sins, fruits of the Spirit) so an agent knows this is a Catholic values reference tool. However, it never states a verb — nothing says whether it 'returns explanations', 'lists', or 'retrieves' — and it does not distinguish itself from near-duplicate siblings like daily_value, commandments, or catechism.

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 'Optional topic:' implicitly tells the agent it can call with no topic, but there is no explicit when-to-use guidance and no routing against the many overlapping siblings (daily_value vs daily_values, catechism, commandments). Usage is inferable from the topic list rather than stated.

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