get_system_requirementsGet what a Mac needs before Yappy will run on it: the minimum macOS version, the required CPU architecture, install size, and every macOS permission Yappy asks for with what each unlocks and what breaks if it is denied.
| Name | Required | Description | Default |
|---|---|---|---|
| permissions_only | No | Return just the macOS permission list, without the hardware requirements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful content-level context, especially that permission consequences are included ('what breaks if it is denied'), but it does not discuss caching, freshness, or error behavior. 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?
One dense, well-structured sentence front-loads the core purpose and then lists exactly what categories of information the response will contain. Every part of the description earns its place, with 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?
For a simple read-only tool with one optional, fully documented parameter and no output schema, the description gives enough detail for an agent to call it correctly. It names all the major content areas, and the optional parameter behavior is fully covered by the input 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?
Schema coverage is 100%, and the permissions_only parameter already has a clear schema description. The tool description does not add parameter-level meaning beyond the schema, so the baseline of 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 names a specific verb ('Get'), a clear resource (Yappy system requirements), and a precise scope: what a Mac needs before Yappy runs. It enumerates the exact contents — macOS version, CPU architecture, install size, and permission details — so an agent can easily distinguish it from siblings like get_pricing_plans or create_export_job.
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 explicit guidance about when to use this tool versus alternatives such as check_mac_compatibility, and no exclusions are stated. The phrase 'before Yappy will run on it' implies a requirements-checking use case, but the tool does not communicate when not to use it or what makes it the preferred choice.
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.
Each tool targets a clearly distinct piece of information or action: compatibility checks, system requirements, pricing, features, FAQ, releases, and export jobs. Even the pair check_mac_compatibility and get_system_requirements is separated by one asking for a decision about a specific Mac and the other returning raw requirements.
Tool names consistently follow a verb_noun pattern using get_, list_, create_, and check_. Singular nouns pair with single-item resources and plural nouns with collection endpoints, making the set predictable.
Nine tools is well-scoped for a product information and export server. Each tool covers a meaningful part of the surface without redundancy or padding.
The tool set covers the full likely question space for the Yappy app: compatibility, requirements, pricing, features, FAQ, latest release, release history, and bulk corpus export. The async export pair provides a complete path to documentation content without leaving dead ends.