Search published prayer guides
search_prayer_guidesDiscover published Prayer in Hand guides. Results are informational and do not claim spiritual authority.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
search_prayer_guidesDiscover published Prayer in Hand guides. Results are informational and do not claim spiritual authority.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added content is a content disclaimer about spiritual authority, which is not behavioral disclosure — nothing about result ordering, empty-query behavior, pagination, or what the open-world search actually reaches.
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 purpose front-loaded and no padding. The second sentence is a disclaimer that occupies space without helping the agent call the tool, which keeps this from a 5.
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 search tool with two undocumented parameters, no output schema, and no usage routing against its siblings, the description leaves too many open questions (what query matches, result ordering, how many results return). The disclaimer is the only extra content and it is not decision-relevant.
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 0% and the description never mentions the 'query' or 'limit' parameters, so neither the matching semantics of 'query' (full text? keyword? title only?) nor the meaning of the 1-20 'limit' cap is explained anywhere. With zero schema coverage, the description was obligated to compensate and does not.
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 ('Discover published Prayer in Hand guides'), which is clearer than the bare tool name. It implicitly contrasts with get_prayer_guide (retrieve one known guide) versus this bulk-discovery tool, but never names or explicitly marks that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of the sibling tools build_reflection_rhythm or get_prayer_guide, and no conditions under which this search should be preferred over fetching a specific guide. The reader must infer usage entirely from the word 'Discover'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.