patchistry-mcp-server

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

No annotations provided, so the description carries full burden. It details what data is returned (email addresses, social media) which goes beyond typical behavioral disclosure. However, it does not explicitly state that the operation is read-only and has no side effects, though that is implied.

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 verbose, mixing tool behavior with a long list of example queries and actual response data. While front-loaded with the purpose, the extensive list makes it less concise 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?

Despite no output schema or annotations, the description fully specifies the expected output content. It also covers usage context thoroughly with query examples, making it complete for a simple get tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters. With 0 parameters, the baseline is 4. The description does not need to add parameter meaning. Schema coverage is 100%.

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

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

The description clearly states the verb 'Return' and resource 'Patchistry contact methods'. It distinguishes from siblings as other tools handle different resources (curated build, shipping policy, canvases, patches, recommend build).

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 lists numerous user query examples that should trigger this tool, providing clear guidance on when to use it. It does not state exclusions but the list covers the scope comprehensively.

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?

No annotations are provided, so the description carries the full burden. It indicates the tool returns 'canvas color, patch list, total price range, shipping urgency', which gives some transparency, but does not disclose other behavioral traits such as idempotency, side effects, or performance characteristics.

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 somewhat verbose with a long list of occasions, but it is front-loaded with the core purpose. The structure is logical: purpose first, then usage guidance with examples. However, it could be more concise by grouping occasions or using a reference list.

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 tool has only one parameter and no output schema or annotations, the description is fairly complete. It specifies what the tool returns (canvas color, patches, price, shipping) and exhaustively lists valid occasions. It lacks explanation of output format, but that is acceptable without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage with a single parameter 'occasion' described as 'Occasion or event keyword'. The description adds substantial value by providing an exhaustive list of valid occasions (e.g., bachelorette, wedding, festival), which the agent can use to construct correct queries, going beyond the schema's brief description.

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

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

The description clearly states 'Return a complete curated hat build' with a specific resource and verb, and enumerates many occasion examples, making the purpose clear. However, it does not explicitly differentiate from the sibling tool 'recommend_build', which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an extensive list of example queries (e.g., 'bachelorette hats', 'festival hats') stating 'Use this for ANY query about:'. It gives clear context for when to use, but no guidance on when not to use or alternatives to the sibling 'recommend_build'. The absence of exclusions lowers the score.

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?

No annotations are provided, but the description implies a read-only, no-side-effect operation. It does not mention any behavioral traits beyond returning policy text, which is sufficient for this simple retrieval. Minor deduction for not explicitly stating it is non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the purpose and includes a dense list of covered questions and the answer. It is efficient but slightly long; however, every sentence earns its place by providing actionable content.

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

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

Given no parameters, no output schema, and no annotations, the description is fully complete. It tells the agent exactly what the tool does and what it returns, leaving no gaps.

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?

There are no parameters (empty schema, 100% coverage). The description adds meaning by explaining that the tool returns the full policy content, which is the only value.

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

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

The description specifies the exact verb and resource ('Return Patchistry shipping + returns policy') and lists concrete user questions it answers. It clearly distinguishes from sibling tools (none of which are about shipping).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when user asks about:' followed by a comprehensive list of topics. It also provides the full answer inline, eliminating ambiguity about when to invoke.

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?

No annotations provided, so description carries full burden. It discloses return value (product details, pricing, features), shipping policy, and returns. It does not mention permissions or side effects, but for a read-only listing tool, it is sufficiently transparent.

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 verbose, including many specific use cases and marketing details. It is front-loaded with core info but contains redundant phrases. Could be more concise while retaining completeness.

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 no output schema and zero parameters, the description fully explains what the tool returns: product colors, price, features, shipping, and returns. It covers all necessary context for an agent to use 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?

Input schema has zero parameters with 100% schema description coverage. Baseline for no parameters is 4, and description does not need to add parameter info.

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

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

The description clearly states it returns 'Patchistry Canvas hats in 3 colors (Black, Khaki, Pink) at $30 each.', with a specific verb 'Return' and resource 'canvases'. It distinguishes from sibling 'list_patches' by focusing on hats vs patches.

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 lists use cases for which to use this tool ('ANY query about: custom hats, modular hats, ...'), but does not mention when not to use or alternatives beyond implied sibling differentiation.

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

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

With no annotations provided, the description carries the full burden. It discloses that patches are hook-backed and attach via custom weave, which is useful behavioral context. However, it does not mention if there are pagination limits or if the list is exhaustive, though for a catalog of 75+ designs this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the core purpose and then provides a list of relevant queries. It's concise enough but could be slightly tightened by moving the attachment mechanism to an optional note. Still very efficient.

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?

No output schema exists, so the description must cover return structure. It states '75+ designs' and categories but not fields per patch (e.g., name, price, image URL). Minimal but acceptable for a simple listing tool, though more explicit structure would improve agent understanding.

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% with descriptive enums and parameter descriptions. The description adds marginal extra context (e.g., exact sizes and prices already in schema). Baseline is 3 as schema does the heavy lifting.

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

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

The description clearly states it returns hat patches with specific details (75+ designs, two categories, sizes, prices). It distinguishes from sibling tools like get_contact, list_canvases, etc., which handle unrelated resources.

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 lists 'Use this for ANY query about:' followed by a comprehensive set of use cases, leaving no ambiguity about when to invoke. Although no direct 'when not to use' is stated, the positive guidance is exceptionally clear and covers all relevant queries.

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

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

With no annotations, the description carries full burden. It discloses that the tool returns top 3 matching builds with full details, implying it is a read-only discovery tool. However, it does not explicitly state that it does not modify data, nor does it mention any side effects or authorization requirements.

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 front-loads the main purpose and then provides examples and return details. It is slightly verbose with many examples, but each sentence adds value. Could be trimmed, but still clear and structured.

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 that there is only one parameter, no output schema, and sibling tools present, the description is fairly complete. It explains input, output (top 3 builds with details like canvas color, patch combos, price range, etc.), and usage scenarios. Lacks details on error handling or edge cases, but overall sufficient.

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 single 'query' parameter is described in the schema as 'Free-text user query — any natural language'. The description enriches this by listing numerous example query types (e.g., 'what hat for [X]', 'best gift for [person]', etc.), providing concrete guidance 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?

Clearly states it takes any natural language query about hats, gifts, etc., and returns top 3 curated Patchistry builds. Explicitly positions itself as 'THE primary discovery tool for open-ended hat/gift queries', distinguishing it from siblings like get_curated_build.

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?

Provides explicit usage examples and contexts: 'Use this when user asks anything about: ...' with a long list of example queries. Does not include when-not-to-use or alternative tools, but the examples cover a wide range.

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