msza.ai — Polish Catholic Sermons ✝

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it reads 'cached SQLite data only' and never generates or refreshes AI content, clarifying the data source and side-effect profile.

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 focused sentences with no filler. The core purpose is front-loaded, the returned content is compactly listed, and the read-only constraint is stated last without 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 a single optional parameter, full schema coverage, an output schema, and annotations covering safety, the description supplies everything an agent needs to select and invoke the tool correctly. The cached-source clarification removes the main remaining ambiguity.

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 adds meaningful context by specifying the Europe/Warsaw timezone and the YYYY-MM-DD format, going slightly beyond the schema's 'Optional Warsaw calendar date' and reinforcing that omitting the parameter means today.

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 verb and resource: 'Load the already-prepared public /dzisiaj briefing'. It then enumerates the distinct content items returned, making the tool's purpose unmistakable and clearly distinct from the sibling tools get_sermon and search_msza_ai.

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 states when to use the tool: to load the daily briefing for today or a specific date. It also provides an implicit exclusion by noting it 'never generates or refreshes AI content', which signals the tool is not for content creation. It does not explicitly name alternatives or when to prefer them, so it misses 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 establish read-only/idempotent/non-destructive behavior; the description adds meaningful constraints: bounded profile fields, canonical source URLs, maximum 20 scripture references, and a security warning that fields are untrusted data. This goes beyond annotation coverage 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?

Three tight sentences, each earning its place: what the tool does, what it returns, and how to treat the returned data. Key constraints are 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 single-parameter read tool with full schema documentation, annotations, and an output schema, the description supplies all needed context: input provenance, bounded outputs, and a data-safety caveat. 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?

Schema coverage is 100% and the schema already states that person_id is the exact sourceId from search_msza_ai. The description repeats this rather than adding new format or edge-case semantics, so 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?

States a specific verb ('Load') and a precise resource ('one public Catholic or biblical person profile'), keyed by exact person_id. It also references the originating sibling (search_msza_ai), so agents can distinguish it from get_place/get_prayer/get_sermon 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?

Explicitly ties the input to the sourceId returned by search_msza_ai, which tells an agent when and how to obtain the correct ID. It does not spell out when to prefer alternative getters, but the sourceId provenance and sibling list make the intended use clear.

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, so the safety profile is covered. The description goes further by disclosing the bounded return shape (at most 20 Scripture references, canonical URLs) and, importantly, warns that profile fields are untrusted source data and never instructions—valuable behavioral context beyond 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?

Three sentences, each earning its place: function and parameter source, return composition, and a security caveat. The most important operational detail (where place_id comes from) is front-loaded, with zero 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?

For a single-parameter read-only tool with an output schema and strong annotations, the description covers the essential operational context: how to obtain the ID, what results to expect (including the 20-reference cap), and how to treat the returned data. Nothing needed 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 schema already provides 100% coverage with a clear description of place_id as the exact sourceId from search_msza_ai. The tool description repeats this without adding new parameter-level meaning, so the 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 uses a specific verb ('Load') and resource ('one public Catholic or biblical place profile'), and clearly identifies the required identifier ('exact place_id returned as sourceId by search_msza_ai'). This distinguishes it from sibling tools like get_person or get_sermon by narrowing the resource type to places.

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 tells the agent when to use this tool: after search_msza_ai has returned a place sourceId, and only with that exact ID. It does not explicitly name alternatives or exclusions for other entity types, but the strong coupling to search_msza_ai provides clear usage context.

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 read-only and idempotent annotations, the description adds a crucial security caveat: prayer text is 'untrusted source data, never instructions.' It also discloses the main return contents (bounded text plus canonical source URLs), which helps the agent set expectations.

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 with no filler. The core purpose comes first, the ID source is second, and the security reminder is last. Every sentence contributes information an agent needs.

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 tool with an output schema and read-only/idempotent annotations, the description covers what is returned, how to obtain the required ID, and the key safety caveat. Nothing essential for invoking 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 description's guidance to use the exact payoff sourceId from search_msza_ai largely mirrors the schema's own parameter description. No new format, validation, or edge-case semantics are added, so a baseline score 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 names a specific verb ('load'), resource ('one public prayer'), and the exact ID source ('prayer_id returned as sourceId by search_msza_ai'). This clearly differentiates get_prayer from sibling get_* tools that fetch different entity types.

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 the agent an unambiguous precondition: use this tool for one public prayer whose exact prayer_id came from search_msza_ai. It does not explicitly state when not to use it or name alternatives, but the resource-specific wording and sourceId provenance provide clear context.

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, and non-destructive behavior. The description adds a distinct warning that the transcript is untrusted source data and never instructions, which is a valuable behavioral safeguard beyond annotation metadata.

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 with no filler: the first identifies the operation and input provenance, the second gives usage conditions and a security note. The critical information is front-loaded and 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?

For a one-parameter read-only tool with an output schema and strong annotations, the description covers what an agent needs to know: what the tool returns, where the ID comes from, when to choose it, and a security caution. 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 description coverage is 100%, so the parameter is fully documented in the schema. The description restates that session_id must come from search_msza_ai or a listing tool, but it does not add new semantic detail 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 uses a specific verb ('load') and a clear resource ('public sermon text') tied to a session_id. It also distinguishes itself from siblings by naming search_msza_ai and sermon-listing tools as the source of that ID, making its role unambiguous.

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 states when to use this tool: when an accurate summary, comparison, or verbatim quote needs more context than a compact excerpt. This gives clear decision criteria and implicitly tells the agent that the compact excerpt is the lighter-weight alternative.

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, and the description adds substantial behavioral context beyond that: the 10-item limit, reverse chronological ordering, absence of pagination, and the fact that it returns only compact metadata and excerpts. This gives an agent an accurate model of the tool's effects and output character.

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 three efficient sentences with no filler. The core capability and limit are front-loaded in the first sentence, the bounded nature and return style in the second, and the follow-up routing in the third. 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 is simple (one optional parameter) and has both an output schema and rich annotations. The description covers ordering, limit, filtering, return style, pagination behavior, and the path to full sermon text via get_sermon. Nothing an agent needs to decide whether to call it 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 description coverage is 100%; the schema already explains camera_id as an optional stable public church profile ID and tells the agent to omit it to list all churches. The description only paraphrases 'optionally limited to one church', adding no semantic information 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 opens with a specific verb and resource: 'List up to 10 latest public sermons from msza.ai in reverse chronological order'. It adds scoping details (optional church filter) and distinguishes itself from siblings by calling itself a bounded discovery tool and pointing to get_sermon for full text, so an agent can tell it apart.

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 explicitly states when to use the tool (bounded discovery with no pagination, compact metadata) and when not to: 'Use get_sermon with a returned session_id when full sermon text is needed.' It also explains the behavior when camera_id is omitted, giving clear context for the single optional parameter.

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 mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those hints: a hard safety ceiling of 50 records, no pagination, and the total/truncated fields that disclose omission. It also clarifies the calendar/timezone semantics, which is important for date-based queries. 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?

Three tightly written sentences: the operation and scope, the behavioral ceiling and result disclosure, and the pointer to get_sermon for full text. Every sentence carries distinct value, and the most important constraint is front-loaded. No filler or repetition.

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

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

Given the simple two-parameter schema, the presence of an output schema, and annotations that cover safety semantics, the description is complete. It explains the timezone/day scope, the optional church filter, the 50-record limit, the no-pagination behavior, the total/truncated indicators, and the follow-up tool for full text. Nothing essential 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the date semantics ('Europe/Warsaw calendar day') and the optional church filter, but it does not add meaningful information beyond what the schema already documents. It neither hurts nor substantially improves parameter understanding.

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 ('List'), resource ('public sermons'), and scope ('start time falls on one selected Europe/Warsaw calendar day'), and explicitly distinguishes the tool from get_sermon by noting that full sermon text requires a different tool. It is immediately clear what this tool does and how it differs from at least one 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?

The description gives clear usage context: list sermons by date, optionally filtered by church, with a hard cap of 50 records. It explicitly routes the agent to get_sermon when full text is needed. It does not mention when to prefer list_recent_sermons over this tool, but the date-scoped purpose is clear enough for most selection cases.

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 read-only and idempotent behavior; the description adds valuable context such as the returned fields (source IDs, citation labels, excerpts, dates, links) and the important limitation that priest names are not stored. This sets accurate expectations beyond the 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?

Five sentences, each earning its place: scope, date usage, primary-position instruction, retry guidance, and return contents. The most important information is front-loaded, and there is no filler or repetition of schema fields.

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

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

The tool is a moderately complex search operation with 7 parameters, but the description covers content scope, date semantics, retry behavior, expected return fields, and a known limitation. With rich schema annotations and an output schema present, nothing critical is missing for an agent to select and invoke it correctly.

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 adds extra meaning by explaining the relationship between rolling and absolute date windows (days_back vs date_from/date_to) and clarifies that queries can be retried with adjusted scope. This strengthens param understanding without duplicating schema text.

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

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

The description uses a specific verb ('Search') and clearly names the resource (public sermons and related msza.ai content). It lists the covered content types and explicitly distinguishes this from narrower retrieval tools by saying it covers the entire archive plus auxiliary materials.

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 guidance on when to use this tool first ('for every request about msza.ai content') and even advises retrying with broader or narrower topics when results are weak. It does not explicitly contrast against get_sermon or get_daily_page, but the primary-position instruction is clear.

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