Browse Raven creative presets for product photoshoots, marketplace cards, UGC ads, TV spots, cinematic reveals, social launch packs, storyboards, and infographics.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search preset name or description. | |
| media_type | No | Filter presets by media type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds contextual value by specifying the scope of presets (product photoshoots, UGC ads, etc.), which helps the agent understand what results to expect. 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?
The description is one concise sentence, front-loaded with the verb 'Browse' and the resource, followed by a specific list of preset categories. No filler or redundant info.
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 list tool with no output schema, the description sufficiently explains the tool's scope and what it returns (creative presets related to various production types). It does not mention pagination or response format, but for a basic listing operation this is acceptable.
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?
Both parameters (search and media_type) are fully described in the schema, so the description adds no additional parameter semantics. Per the rubric, with 100% schema coverage, the baseline is 3.
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 tool lists Raven creative presets and enumerates the specific categories (product photoshoots, marketplace cards, UGC ads, etc.), making the purpose unambiguous. It easily distinguishes from sibling tools like list_design_systems or list_creative_models.
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 conveys the tool is for browsing presets but gives no explicit guidance on when to prefer it over alternatives or when not to use it. The listing of preset types implies applicability, but there's no exclusionary or comparative language.
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.
Most tools have clearly distinct purposes (audit_* vs get_* vs list_* vs generate_* vs score_*), but there is notable overlap among audit_page, audit_layout, score_page, and audit_url (all audit rendered HTML, with audit_page and score_page explicitly sharing checks; audit_screen and audit_ios_screen are aliases). The get_* family (get_pattern vs get_content_pattern vs get_service_pattern, get_principles vs get_brand_principles vs get_content_principles) have overlapping boundaries that may cause misselection.
Names follow a consistent verb_noun pattern (audit_*, get_*, list_*, generate_*, score_*, compose_*, suggest_*, search_*), which is predictable and readable. Minor deviations exist: 'evaluate_design' uses evaluate_ instead of audit_/score_, and 'process' isn't present but 'compose_system' uses compose_ instead of generate_/get_. Overall the convention is strong and consistent.
45 tools is far beyond the typical well-scoped server (3-15 tools) and even beyond the 'heavy' 25+ threshold. The server appears to be an all-in-one design/UX knowledge base and auditing suite, but the sheer count makes discovery and selection overwhelming, and many tools (e.g., multiple audit_* variants for mobile platforms) could be consolidated.
The server covers a wide domain: audits for web/mobile/RN/SwiftUI, design tokens, UX principles, content systems, business strategy, creative scoring, and service design. However, there are gaps: no tool for creating or editing design systems (only get/generate), no update/delete operations anywhere (all read-only or audit-only), and the creative side has list/score but no generation tool. The set feels broad but shallow in lifecycle coverage.
