eyepup_todoGet the top friction patterns ranked by impact score. Use BEFORE making any UX edit — the highest-impact pattern is usually a more valuable fix than whatever the user just asked about. Each row carries a paste-ready recommended_action.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Apex-domain scope. | |
| limit | No | Max patterns (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Get' and the phrase 'Each row carries a paste-ready recommended_action' communicate the read-only, output-oriented behavior. It doesn't disclose side effects, but none are expected for a list operation. The description adds context about ranking by impact score, which is beyond the schema.
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?
Three sentences: what it does, when to use it, and what output to expect. Front-loaded with the primary verb. No fluff.
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?
The description explains the output format (rows with paste-ready recommended_action), the ranking criterion (impact score), and the intended use case. With no output schema and no annotations, this is sufficient for a low-complexity read-only tool. It could have explicitly stated its read-only nature, but 'get' and 'list' imply non-mutating behavior.
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 input schema descriptions already cover both parameters ('Apex-domain scope' for site, 'Max patterns (default 5)' for limit) at 100% coverage. The tool description does not add parameter-specific semantics, but given the schema's completeness, this is acceptable per the baseline.
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 opens with 'Get the top friction patterns ranked by impact score,' which is a specific verb+resource with a clear scope (top-ranked pattern list). The title 'List the friction-pattern To-Do queue' further reinforces this. It is clearly distinct from siblings like eyepup_ask and eyepup_log, so the purpose is unambiguous.
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 instructs to 'Use BEFORE making any UX edit' and explains the rationale (highest-impact pattern is more valuable than the user's immediate request). This provides a clear contextual trigger. It doesn't list alternative tools to use instead, but the guidance is explicit enough for this simple tool.
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 has a clearly distinct purpose: ask is for free-text questions, log is for recording shipped changes, todo is for top friction patterns, visitor is for a specific visitor profile, and visitors_hot is for active high-intent visitors. There is minimal overlap, and the descriptions explicitly guide when to use each.
All tool names share the 'eyepup_' prefix, but the second part mixes verbs (ask, log) with nouns (todo, visitor, visitors_hot). This is readable but not a consistent verb_noun convention. A more uniform pattern like 'ask_question', 'log_change', 'get_todo', 'get_visitor', 'list_hot_visitors' would be clearer.
With 5 tools, the server is well-scoped for its purpose of visitor behavior analysis and optimization. Each tool addresses a distinct need without unnecessary bloat or overlap. The count feels right for a focused analytics assistant.
The toolset covers the core workflow: asking questions, identifying friction patterns, viewing hot visitors, drilling into individual visitor profiles, and logging changes for impact analysis. Minor gaps exist, such as no direct tool for listing all visitors or viewing historical trend charts, but the 'ask' tool can likely address many such queries. Overall, the lifecycle is adequately covered for the stated purpose.