Desert Road Catholic

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the default resolves to today's date in US Eastern time when neither parameter is supplied. It leaves the precedence rule ambiguous if both 'day' and 'date' are passed.

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 with the invocation condition, then inputs, then a worked example; every sentence carries information. Minor redundancy in enumerating return fields when an output schema already exists.

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 lookup with an output schema present, the description covers trigger, input formats, and default resolution. The one real gap is what happens when both 'day' and 'date' are supplied simultaneously.

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, giving a baseline of 3. The description goes beyond that by explaining that the two inputs are alternatives and by documenting the zero-argument default timezone behavior, which is not expressed anywhere in 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?

States a specific verb and resource ('look up ... one of the 90 days'), names the returned fields (date, Exodus reading, stage, opening prayer), and scopes the tool to a single program day so it is distinguishable from get_prayer and list_stages.

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?

'Call this when the user asks about the reading, date or stage for one of the 90 days' gives a concrete trigger condition, and the description covers the no-argument fallback. It stops short of naming alternatives (e.g., list_stages for the stage catalog) or stating exclusion conditions, so it does not reach the top band.

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 read-only, idempotent, closed-world behavior, so the description is free to add the things annotations cannot: that Day 90 and Easter Sunday are computed 'by our count', that days-until is measured in US Eastern time, and that no app store links exist yet. That last point is a real hallucination guard, preventing the agent from fabricating store URLs.

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 when-to-call clause is front-loaded and every clause carries information. However, the return inventory is delivered as one long run-on sentence, and the trailing example largely restates the triggers already listed, so it is slightly denser and more redundant than ideal.

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 zero parameters, an output schema, and full annotation coverage, the description needs only to say when to call and what comes back, and it does both plus the caveats about app availability and date computation. Nothing an agent needs in order to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter guidance is missing because no inputs exist.

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 exactly what the tool returns: the official 2027 start date plus its source page, Day 90 and Easter Sunday by the program's count, days until Day 1 in US Eastern time, follow channels (web live, iOS/Android coming soon), and the signup link. That is concrete enough to separate it from get_day (a specific day's content) and get_program_info (general program material). The name is vague on its own, but the description removes all ambiguity.

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 call triggers: user asks when the 90 days start, how long until Day 1, or whether an app exists, reinforced with a sample query. There are no when-not conditions and no named alternatives (e.g. it never says to use get_program_info instead for broader program questions), so it falls short of 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 annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It adds that the text comes from the site's Armory and lists the categories of prayer available, which helps the agent predict the response. It does not discuss failure behavior when a prayer falls outside the enum, but the output schema and enum largely cover the return shape.

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?

It is three sentences with the trigger first, the content scope second, and a concrete example last. The parenthetical prayer list is long but earns its place by showing the coverage. Nothing is wasted, though the example partially duplicates the trigger sentence.

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 single-enum-parameter read tool with rich annotations and an output schema, so the description needs to cover only when to call it and what content it covers, and it does both. The only gap is the undisclosed relationship to the rosary mystery siblings.

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 enum is self-documenting, so the baseline is 3. The description goes further by grouping enum values into meaningful categories (stage prayers, rosary mysteries by day, prayers in temptation, daily examen), which helps map a natural-language request to the correct enum value. It adds no syntax guidance, but none is needed for a closed enum.

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 and resource: it returns the full text of a named traditional Catholic prayer. It also enumerates the content categories it covers, such as stage prayers and the daily examen. It does not distinguish itself from the sibling tools get_rosary_mysteries or list_rosary_mysteries, even though the enum includes a "rosary" value, which creates overlap.

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 trigger is explicit and front-loaded: "Call this when the user asks for the words of a traditional Catholic prayer," and the Memorare example shows how a user request maps to a call. It gives no when-not guidance, so an agent cannot tell from this description whether the rosary entry here overlaps with the dedicated rosary mystery 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 annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the content envelope (free cost, 2027 dates, six stages, signup link), though it says nothing about the response's shape, freshness, or whether the content is static versus live — minor gaps given a static info tool.

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?

It is three compact sentences, front-loaded with the trigger condition before the payload inventory, which is the right order for an agent scanning for relevance. The trailing example largely restates the trigger sentence, so a small amount of text does not earn extra 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?

For a zero-parameter, read-only overview tool with full annotations and a declared output schema, the description supplies everything an agent needs: the selection condition, the contents it will get back, and a sample user phrasing. No material gap remains that would cause a wrong call.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is trivially complete and the description correctly implies no filtering or scoping arguments are available.

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-and-resource ('get_program_info' framed as 'Call this when the user asks what Desert Road Catholic is') and then enumerates the payload: what it is, cost, 2027 dates, six stages, registration contents, signup link. That inventory clearly separates it from siblings like list_stages or get_day, which each cover a single slice.

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 trigger conditions ('what it costs or how it works') plus a concrete example utterance, so the agent knows when to reach for it. What it lacks is routing guidance away from it — e.g., that list_stages should be used for the full stage list once the user is past the overview — so there is clear context but no stated 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine context beyond that: the timezone used for "today," the full weekday-to-mystery mapping, and the shape of the returned content (five mysteries, fruits, Douay-Rheims scripture, schedule, link). No auth or rate-limit notes, but none appear relevant for a static lookup.

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 with the trigger condition, then inputs, then default, then an example — a sensible order with no filler. The parenthetical weekday mapping duplicates information that the output schema likely already conveys, so one clause is slightly expendable.

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-parameter, zero-required, read-only lookup with an output schema, nothing an agent needs is missing: trigger condition, accepted input forms, default behavior, and the nature of the result are all stated. Return-value detail is technically redundant given the output schema but harmless.

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 would be 3, but the description adds real meaning beyond the schema: the two inputs are alternatives ("Pass a date ... or a weekday") and omitting both silently defaults to today in US Eastern time. That defaulting rule is not derivable from the schema alone.

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 gives a specific verb and resource ("Returns the mysteries for that day") and scopes it to a calendar day, which in practice separates it from the sibling list_rosary_mysteries. It never names that sibling, so the differentiation is implicit rather than stated.

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?

"Call this when the user asks which Rosary mysteries to pray today or on a given day" is an explicit triggering condition, and the fallback rule (today in US Eastern if nothing is passed) removes ambiguity about default behavior. No when-not guidance or named alternative is given, which keeps it below 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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description still adds real value beyond them by enumerating what comes back — four mystery sets with assigned days, twenty mysteries with fruits and Douay-Rheims citations, prayer order, and a downloadable data file — which tells the agent the response is a rich, self-contained reference rather than a pointer.

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 with the invocation trigger, then a single dense enumeration of contents, then an example query — a sensible order with no filler sentences. The contents list is long but each clause corresponds to a distinct returned artifact, so little could be cut without losing 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?

An output schema and full annotation coverage already handle return shape and safety, and the description supplies the invocation trigger, a sample utterance, and a summary of the payload. For a zero-parameter, read-only lookup tool, nothing an agent needs in order to call it correctly is absent.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a single, unfiltered call with no arguments needed.

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?

States a specific verb and resource plus the exact payload: 'the four sets of mysteries (Joyful, Sorrowful, Glorious, Luminous)', all twenty mysteries with fruits and scripture, prayer order, and the guided link. The word 'all' implicitly contrasts with the sibling get_rosary_mysteries, but that sibling is never named, so an agent must infer that get_rosary_mysteries is the narrower, day-specific counterpart.

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?

Gives a clear trigger: 'Call this when the user wants all the Rosary mysteries or how to pray a full Rosary,' reinforced by an example utterance. It stops short of naming when to prefer get_rosary_mysteries or get_prayer instead, so the routing is clear but not exhaustive.

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 the safety profile is covered. The description adds useful behavioral content beyond that: exactly which fields come back (days, start dates, opening prayers, per-day readings), which tells the agent how heavy the response is. It stops short of stating ordering or pagination, but this is a small fixed six-item list, so that matters little.

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?

It is front-loaded with the invocation condition, then the payload, then an example query, which is the right order. The example adds real value for matching user phrasing rather than being filler. Three sentences with no wasted wording.

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 list tool with an output schema present, this covers everything an agent needs: when to call it, what it returns, and what a triggering user question looks like. Nothing required for correct invocation 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly conveys that no filtering or arguments are needed.

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 its scope: it returns 'the six stages of the 90 days' along with days, start dates, opening prayers and daily Exodus readings. That is far more concrete than the title alone. It does not explicitly contrast itself with get_day, though the phrase 'the whole reading plan' implicitly separates it from the single-day sibling.

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 an explicit trigger condition ('when the user asks about the six stages or wants the whole reading plan') and reinforces it with a sample user utterance. It stops short of naming when-not to call it or pointing to get_day for single-day lookups, which would have made this a 5.

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