Server Quality Checklist

Tool Scores

• generate-claude-mdB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a file but does not describe where the file is saved, whether it overwrites existing files, what permissions are needed, or the format of the output. For a tool that creates documentation, this lack of operational details is a significant gap.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the main action ('Generate a CLAUDE.md file') and elaborates on its contents. It avoids redundancy and wastes no words, though it could be slightly more structured by separating key components like tech stack and conventions into bullet points for clarity.

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

  Completeness3/5

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

  Given the tool's moderate complexity (generating a structured documentation file) and the absence of annotations and output schema, the description is minimally adequate. It outlines what the tool does but lacks details on behavioral aspects, output format, and integration with sibling tools, leaving gaps for the agent to navigate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents the parameters (appName, appDescription, features). The description adds no additional meaning beyond what the schema provides, such as how these inputs influence the generated content or examples of usage. Baseline 3 is appropriate when the schema handles all parameter documentation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('Generate a CLAUDE.md file') and resources ('project rules for Claude Code'), and distinguishes it from siblings by specifying its unique output (a documentation file with tech stack, architecture rules, code conventions, and MCP tool usage instructions) rather than generating code files or retrieving patterns like other tools.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. It mentions the tool's purpose but does not specify prerequisites, appropriate contexts, or when to choose it over sibling tools like 'setup-new-project' or 'generate-project-files', leaving the agent to infer usage.

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

• get-component-patternsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It describes what content is available (patterns for specific components and technologies) and mentions the compact parameter behavior ('returns rules only without code examples'). However, it doesn't disclose important behavioral aspects like response format, potential size of output, error conditions, or whether this is a read-only operation.

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

  Conciseness4/5

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

  The description is appropriately sized with three sentences. The first sentence establishes purpose, the second provides usage context, and the third adds parameter guidance. Each sentence adds value, though the second sentence could be slightly more concise by removing the colon-separated list of component examples.

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

  Completeness3/5

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

  For a read-oriented tool with 2 parameters and 100% schema coverage but no output schema, the description provides adequate context about what patterns are available and when to use it. However, without annotations or output schema, it should ideally describe the response format or structure to help the agent understand what to expect from the tool's output.

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

  Parameters3/5

  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 adds some value by mentioning 'Use `topic` to get a specific section only' and listing the available topics, which complements the schema's description. However, it doesn't provide additional semantic context beyond what's already in the well-documented schema parameters.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get React Native component patterns' with specific examples (button, card, etc.) and technologies covered (Pressable, expo-image, etc.). It distinguishes from some siblings like 'get-api-patterns' or 'get-styling-patterns' by focusing on components, but doesn't explicitly differentiate from all similar pattern tools like 'get-navigation-patterns'.

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

  Usage Guidelines4/5

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

  Provides clear usage context: 'Call this when creating any component: button, card, list item, image, form input.' This gives specific scenarios for when to use the tool. However, it doesn't mention when NOT to use it or explicitly compare with alternatives among sibling tools.

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

• get-state-patternsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It describes what content the tool provides (Zustand store setup, MMKV persistence adapter, etc.) and mentions the 'compact' parameter's effect on output length. However, it doesn't disclose important behavioral aspects like response format, potential size of output, error conditions, or whether this is a read-only operation (though 'Get' implies it).

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose. The first sentence establishes what the tool does, followed by usage guidance and parameter hints. While efficient, the second sentence could be slightly more concise by combining related concepts.

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

  Completeness3/5

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

  Given 2 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate context for a documentation/pattern retrieval tool. It covers purpose, usage context, and hints at parameter effects. However, for a tool that returns potentially complex pattern information, more detail about output format or content structure would be helpful since there's no output schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions using 'topic' to get specific sections and implies 'compact' affects content length. This meets the baseline 3 for high schema coverage, but doesn't provide significant additional parameter context.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get state management patterns (Zustand + MMKV)' - a specific verb ('Get') and resource ('state management patterns'). It distinguishes from siblings by focusing on state management patterns rather than other topics like components, navigation, or styling. However, it doesn't explicitly contrast with similar tools like 'get-api-patterns' or 'get-component-patterns' beyond the topic difference.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: 'Call this when creating a store or working with global state.' This gives explicit guidance on when to use the tool. However, it doesn't mention when NOT to use it or provide explicit alternatives among sibling tools, though the topic specialization implies alternatives exist.

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

• get-styling-patternsA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It describes what content is covered (NativeWind v4, arbitrary values, etc.) and mentions the 'compact' parameter behavior (returns rules only without code examples). However, it doesn't disclose important behavioral traits like response format, whether it's read-only, potential rate limits, or authentication requirements. The description adds some context but leaves significant gaps.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences. The first sentence states the purpose and scope, while the second provides usage guidance for the topic parameter. There's no wasted text, and information is front-loaded. However, it could be slightly more structured by separating behavioral information from parameter guidance.

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

  Completeness3/5

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

  Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers purpose and basic usage but lacks information about response format, error conditions, or what constitutes 'patterns' in the output. Without annotations or output schema, the description should do more to explain what the tool returns and how to interpret it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions using 'topic' to get specific sections and implies 'compact' makes output 'much shorter.' This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't add significant semantic context beyond what's already in parameter descriptions.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get styling patterns (NativeWind / Tailwind CSS)' with specific technologies mentioned. It distinguishes from some siblings like 'get-api-patterns' or 'get-performance-patterns' by focusing on styling, though it doesn't explicitly differentiate from 'get-component-patterns' which might overlap. The description includes the verb 'Get' and resource 'styling patterns' but could be more specific about what 'patterns' means.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: 'Call this when styling components' which gives practical guidance. It also mentions using the 'topic' parameter to get specific sections, implying an alternative to getting full content. However, it doesn't explicitly state when NOT to use this tool or compare it to potential alternatives like 'get-component-patterns' for component-specific styling advice.

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

• generate-project-filesA
  3.7/5.0
  Behavior2/5

  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 mentions the tool 'Produces actual file contents' but lacks details on behavioral traits like whether it overwrites existing files, requires specific permissions, or has side effects. This is inadequate for a file-generation tool with no 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.

  Conciseness5/5

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

  The description is front-loaded with the main purpose and efficiently lists the generated file types in a single sentence. Every part adds value without redundancy, making it appropriately sized and easy to scan.

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

  Completeness3/5

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

  Given the tool's complexity (file generation with 3 parameters) and lack of annotations and output schema, the description is somewhat complete but has gaps. It specifies what files are generated but not the output format or potential errors. It's adequate but could benefit from more behavioral context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description does not add meaning beyond the schema, such as explaining how 'features' map to generated files or what 'includeCI' entails. Baseline 3 is appropriate when the schema handles parameter documentation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('Generate starter files') and resources ('React Native + Expo Router project'), and it distinguishes from siblings by focusing on file generation rather than pattern retrieval or project setup. It lists the specific file types produced, making the scope explicit.

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

  Usage Guidelines4/5

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

  The description implies usage for a 'NEW' project, providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'setup-new-project', which might have overlapping functionality.

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

• get-memory-optimizationA
  3.8/5.0
  Behavior3/5

  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 mentions the tool returns content about specific topics (e.g., useEffect cleanup, closures) and that the 'compact' parameter affects output length. However, it doesn't disclose behavioral traits like response format, potential errors, rate limits, or whether it's a read-only operation. It adds some context but lacks comprehensive behavioral details.

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

  Conciseness4/5

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

  The description is front-loaded with the main purpose and usage context, followed by examples of topics and a note on parameters. It's relatively concise but could be slightly tighter by integrating the parameter guidance more seamlessly. Most sentences earn their place by providing useful information.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description provides adequate context for a read-oriented tool with well-documented parameters. It covers purpose, usage, and topics, but lacks details on output format, error handling, or integration with sibling tools. It's minimally complete but has gaps in behavioral transparency.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions using 'topic' to get a specific section and implies 'compact' reduces content length. This meets the baseline for high schema coverage without significant enhancement.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get memory optimization patterns.' It specifies the resource (patterns) and context (memory optimization). However, it doesn't explicitly differentiate from sibling tools like 'get-performance-patterns' or 'get-api-patterns' beyond mentioning memory-specific topics.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Call this when debugging memory leaks or performance issues.' It also mentions using the 'topic' parameter to get specific sections, which helps guide parameter usage. The context is clear and actionable.

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

• get-navigation-patternsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what content is covered (file structure, layouts, AuthGuard, typed params, etc.) and that the 'compact' parameter affects output length. However, it doesn't disclose important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what format the output takes (though no output schema exists). The description adds some context but leaves gaps for a tool with no annotations.

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

  Conciseness5/5

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

  The description is efficiently structured in three sentences: purpose statement, usage context, and parameter guidance. Every sentence adds value with zero waste. It's appropriately sized for a tool with 2 parameters and no annotations, front-loading the most important information about what the tool does and when to use it.

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

  Completeness3/5

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

  Given 2 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers purpose, usage guidelines, and parameter semantics reasonably well. However, for a tool with no output schema, it should ideally describe the return format or content structure. The mention of 'rules' and 'code examples' hints at output content but doesn't fully compensate for the lack of structured output documentation.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by listing the available topics ('file-routing, layouts, auth-guard, typed-params, navigation-api, deep-linking, groups') which provides semantic context beyond the schema's generic 'Available: file-routing...' description. It also explains the purpose of the 'compact' parameter ('returns rules only without code examples. Much shorter.') which complements the schema's description.

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

  Purpose4/5

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

  The description clearly states 'Get Expo Router navigation patterns' which specifies the verb ('Get') and resource ('Expo Router navigation patterns'). It distinguishes from siblings by focusing specifically on navigation patterns rather than other aspects like components, styling, or performance. However, it doesn't explicitly contrast with similar-sounding sibling 'get-api-patterns' or 'get-component-patterns' beyond the navigation focus.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: 'Call this when working with routes, navigation, deep links, or auth guards.' This gives explicit guidance on when to use the tool. It also mentions using the 'topic' parameter for specific sections. However, it doesn't explicitly state when NOT to use this tool or provide alternatives among the sibling tools (like when to use get-api-patterns vs get-navigation-patterns).

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

• get-performance-patternsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It describes what content is returned (patterns covering specific technologies) and mentions the 'compact' parameter affects output length, but doesn't disclose format, structure, permissions needed, rate limits, or error behavior. It adds some behavioral context but leaves gaps.

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

  Conciseness4/5

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

  The description is efficiently structured with two sentences: first states purpose and usage context, second explains parameter usage. It's appropriately sized and front-loaded with essential information, though the list of covered technologies is somewhat lengthy.

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

  Completeness3/5

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

  For a 2-parameter tool with no annotations and no output schema, the description provides good purpose and usage context but lacks details about return format, structure, or what 'patterns' actually look like. It's adequate for basic understanding but incomplete for full agent comprehension.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description mentions using 'topic' to get specific sections and implies 'compact' affects content, but adds minimal semantic value beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does the work.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get performance optimization patterns' with specific domains listed (lists, images, bundle size, animations). It distinguishes from some siblings like 'get-api-patterns' or 'get-typescript-patterns' by focusing on performance, but doesn't explicitly differentiate from 'get-memory-optimization' which might overlap.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Call this when optimizing lists, images, bundle size, or animations.' It lists specific optimization contexts and mentions using the 'topic' parameter to get specific sections, giving clear when-to-use instructions without alternatives needed.

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

• get-typescript-patternsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It describes what the tool returns (patterns, rules, code examples) and mentions the 'compact' parameter affects output length. However, it doesn't disclose behavioral aspects like rate limits, authentication needs, or potential side effects.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the main purpose. The second sentence provides usage context, and the third lists coverage areas efficiently. The final sentence directly addresses parameter usage. Some redundancy exists in listing topics that appear in the schema.

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

  Completeness4/5

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

  For a read-only informational tool with 2 parameters and 100% schema coverage, the description is reasonably complete. It explains what the tool provides, when to use it, and gives parameter context. Without an output schema, it could better describe the return format, but the 'compact' parameter hint helps.

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

  Parameters4/5

  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 adds value by explaining the 'topic' parameter provides 'specific section only' and lists all available topics, giving semantic context beyond the schema's enum-like list. It also mentions the 'compact' parameter affects output length ('Much shorter'), adding useful context.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get TypeScript patterns for React Native' and specifies it's for 'writing types or interfaces'. It distinguishes from siblings like 'get-api-patterns' and 'get-component-patterns' by focusing specifically on TypeScript patterns, though it doesn't explicitly contrast them.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: 'Call this when writing types or interfaces' and lists specific topics covered. It doesn't explicitly state when not to use it or name alternatives, but the context implies it's for TypeScript-specific guidance in React Native development.

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

• get-screen-architectureA
  4/5.0
  Behavior3/5

  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 describes what the tool returns (architecture patterns, rules, benefits) and mentions the compact parameter for shorter output. However, it doesn't disclose important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. The description adds some context but leaves significant behavioral gaps.

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

  Conciseness4/5

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

  The description is appropriately sized (3 sentences) and front-loaded with the core purpose. The first sentence states what the tool does, the second provides usage guidance and scope, and the third mentions parameter usage. Each sentence serves a distinct purpose with minimal redundancy.

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

  Completeness3/5

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

  Given no annotations, no output schema, and 2 parameters with full schema coverage, the description provides adequate but incomplete context. It covers purpose and usage well but lacks behavioral transparency details that would be important for an agent to use this tool effectively. The description doesn't explain what format the patterns are returned in or what constitutes 'full content' vs. specific sections.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions 'Use `topic` to get a specific section only' which adds minimal context beyond what's in the schema (which says 'Get a specific section only. Available: core-rule, route-file, screen-ui, rules, benefits. Omit for full content.'). The description doesn't add meaningful semantic information about the compact parameter. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get screen architecture patterns (Logic/UI separation)' - a specific verb+resource combination. It distinguishes from siblings by focusing specifically on screen architecture patterns (vs. get-api-patterns, get-component-patterns, etc.) and mentions the specific scope: 'Covers the Route file + ScreenUI file split, naming conventions, and why it matters for testability and SOLID principles.'

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: 'Call this when creating a new screen or route.' This gives clear context for usage. While it doesn't explicitly mention when NOT to use it or name specific alternatives, the guidance is sufficiently specific for the agent to understand the appropriate context.

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

• setup-new-projectA
  4.2/5.0
  Behavior3/5

  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 describes the output as a 'step-by-step guide' covering various topics, which gives some behavioral context. However, it doesn't disclose details like response format, length, or whether it's interactive, leaving gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose in the first sentence, followed by a concise list of covered topics. Every sentence earns its place by adding specific value about what the guide includes, with no redundant or vague language.

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

  Completeness4/5

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

  Given the tool's complexity (comprehensive project setup guide) and lack of annotations or output schema, the description does well by listing specific topics covered. However, it could be more complete by hinting at the guide's format (e.g., markdown, interactive steps) or depth, which would help set expectations for the agent.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output. This meets the baseline of 4 for zero-parameter tools.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get a step-by-step guide for creating a new Expo Router project from scratch.' It specifies the exact resource (Expo Router project) and action (step-by-step guide creation), and distinguishes itself from siblings by focusing on comprehensive project setup rather than specific patterns or optimizations.

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

  Usage Guidelines4/5

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

  The description implies usage context by listing specific technologies covered (TypeScript, NativeWind, Zustand, etc.), suggesting it's for developers starting a new Expo project with these tools. However, it doesn't explicitly state when to use this tool versus alternatives like 'get-project-structure' or 'generate-project-files,' which could provide overlapping guidance.

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

• get-project-structureA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It describes what the tool returns (folder tree, placement rules, naming conventions, import aliases) and hints at output format (rules with code examples unless compact=true). However, it doesn't disclose behavioral traits like rate limits, authentication needs, or potential side effects.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, followed by specific use case and parameter guidance. Every sentence earns its place: first states what it does, second when to use it, third details coverage, fourth explains parameter usage. No wasted words.

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

  Completeness4/5

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

  Given no annotations and no output schema, the description does well by specifying what information is returned (folder tree, placement rules, etc.) and how parameters affect output. However, it doesn't fully describe the return format (e.g., structured data vs. text), leaving some ambiguity for a tool with rich output.

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

  Parameters4/5

  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 adds value by explaining the 'topic' parameter's purpose ('to get a specific section only') and listing available sections, which clarifies beyond the schema's enum-like description. It also implies the 'compact' parameter affects output length ('Much shorter'), adding useful context.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get project folder structure and file placement guide.' It specifies the exact resource (project structure) and verb (get), and distinguishes from siblings by focusing on folder organization rather than patterns, optimization, or project setup.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Call this when deciding where to place a new file.' It also mentions using the 'topic' parameter to get specific sections, offering clear usage instructions. While it doesn't explicitly name alternatives, the context implies it's for structural guidance rather than code generation or patterns.

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

• get-api-patternsA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by describing what content is covered (Axios client with interceptors, domain-grouped services, custom query/mutation hooks, etc.) and mentions the 'compact' parameter's effect on output length. However, it doesn't disclose potential limitations like response size or format details.

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

  Conciseness5/5

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

  The description is efficiently structured with three sentences that each earn their place: purpose statement, usage guidance, and parameter context. It's front-loaded with the core purpose and contains zero wasted words or redundant information.

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

  Completeness4/5

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

  For a read-only informational tool with 2 optional parameters and 100% schema coverage, the description is quite complete. It covers purpose, usage context, and parameter semantics. The main gap is the lack of output schema, so the agent doesn't know the return format, but the description compensates somewhat by describing content scope.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the schema already documents both parameters well. The description adds value by explaining the 'topic' parameter's purpose ('to get a specific section only') and listing available sections, and mentions the 'compact' parameter's effect ('returns rules only without code examples'). This provides useful context beyond the schema's technical descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get API and data fetching patterns (Axios + TanStack Query)' - a specific verb ('Get') and resource ('API and data fetching patterns') with technology scope. It distinguishes from siblings like 'get-component-patterns' and 'get-typescript-patterns' by focusing specifically on API/data fetching patterns.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Call this when creating API services or data fetching hooks.' This tells the agent exactly when to use this tool versus alternatives. The description also mentions using the 'topic' parameter for specific sections, providing additional usage context.

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