UX Laws MCP
Server Quality Checklist
Latest release: v2.0.0
- Disambiguation5/5
Each tool is clearly distinct, targeting a specific UX law or utility function (e.g., analyze_fitts_law, ux_checklist). The consistent 'analyze_' prefix for law-specific tools and descriptive names for utility tools (e.g., ux_detect_platform) eliminate ambiguity. No tools appear to overlap in purpose, making misselection unlikely.
Naming Consistency5/5Tool names follow a highly consistent pattern: all law analysis tools use 'analyze_' + snake_case law name (e.g., analyze_aesthetic_usability), and all utility tools use 'ux_' + snake_case descriptive term (e.g., ux_list_laws). This uniformity across all 37 tools makes the set predictable and easy to navigate.
Tool Count2/5With 37 tools, the count is excessive for a UX analysis server, especially since many tools (30 for individual laws) could be consolidated into a single configurable analysis tool. This bloats the interface and may overwhelm agents, as the core functionality (analyzing UX laws) is fragmented across many similar tools rather than being efficiently scoped.
Completeness5/5The tool set comprehensively covers the UX analysis domain: it includes individual analysis for 30 specific laws, a full audit tool, law listing/info tools, platform detection/comparison, and checklists. There are no obvious gaps; agents can perform detailed analyses, get contextual information, and handle multi-platform scenarios seamlessly.
Average 2.9/5 across 37 of 37 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description doesn't disclose what the tool actually does behaviorally - does it return a score, recommendations, explanations? What format is the analysis? Does it make API calls or perform local computation? The philosophical preamble about 'flow' doesn't help an agent understand the tool's operational behavior. For a tool with no annotations, this 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured with a philosophical preamble about 'flow' that doesn't help an agent understand the tool's function. The operational part is buried after this irrelevant context. While brief, the first sentence doesn't earn its place for tool selection purposes, making this inefficient rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the analysis produces, how results are formatted, what 'flow' analysis entails operationally, or how this differs from other UX analysis tools. The philosophical context about flow state is irrelevant to tool invocation and doesn't compensate for the missing behavioral information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema - it mentions 'CUALQUIER PLATAFORMA' which aligns with the platform parameter's extensive enum list, but doesn't provide additional context about parameter usage, relationships, or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a philosophical definition of 'flow' that doesn't directly state the tool's function. It then says 'Analiza código o componentes UI según esta ley para CUALQUIER PLATAFORMA' which translates to 'Analyzes code or UI components according to this law for ANY PLATFORM.' This is somewhat tautological with the tool name 'analyze_flow' and doesn't specify what the analysis produces or how it differs from sibling tools like 'analyze_fitts_law' or 'analyze_hicks_law' that presumably analyze different UX principles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'CUALQUIER PLATAFORMA' and lists many platform options in the schema, but provides no guidance on when to use this tool versus the many sibling analysis tools (e.g., analyze_fitts_law, analyze_hicks_law, analyze_cognitive_load). There's no indication of what types of code/components benefit from flow analysis versus other UX principles, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions analyzing code/UI components but doesn't describe what the tool actually does: Does it return recommendations? Identify chunking violations? Score chunking quality? Provide before/after examples? The description is too abstract to guide an agent on what behavior to expect from invoking this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but poorly structured. It starts with a definition of chunking rather than stating the tool's purpose upfront. The second sentence is more useful but still vague. While not verbose, the structure doesn't effectively communicate the tool's function to an AI agent needing to select it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what analysis means in practice, what format results come in, what chunking law entails for UI/code analysis, or how this differs from other UX analysis tools. The agent would struggle to understand what invoking this tool actually accomplishes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions platforms but the schema's platform enum is more detailed. The description doesn't explain relationships between parameters or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a general definition of chunking ("Fragmentación") rather than stating what the tool does. It then says "Analiza código o componentes UI según esta ley" which is somewhat vague - it doesn't specify what kind of analysis it performs or what outputs it produces. The description doesn't clearly distinguish this from sibling tools like analyze_fitts_law or analyze_hicks_law which presumably analyze UI according to different laws.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it works for "CUALQUIER PLATAFORMA" and lists many platforms, but provides no guidance on when to use this specific tool versus other analysis tools in the sibling list. There's no mention of what types of problems chunking analysis addresses, what questions it answers, or when it would be more appropriate than other UX analysis tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions analyzing code/UI for cognitive bias across platforms, but lacks critical behavioral details: what the analysis outputs (e.g., findings, scores, recommendations), whether it's read-only or modifies input, any rate limits, or authentication needs. For a tool with 4 parameters and no output schema, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with two paragraphs, but the first paragraph defines cognitive bias conceptually without directly stating the tool's action, which could be more front-loaded. The second paragraph specifies the analysis scope and platforms. Some redundancy exists (e.g., listing platforms when schema has enum), but overall it's structured adequately without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., analysis results, error handling), behavioral constraints, or how it differs from sibling tools. For a cognitive analysis tool with multiple parameters, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly with descriptions and an enum for 'platform'. The description adds no additional parameter semantics beyond implying platform flexibility ('CUALQUIER PLATAFORMA'), which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law), which provides a general purpose. However, it's vague about what 'esta ley' (this law) specifically refers to (cognitive bias), and it doesn't clearly distinguish from siblings like 'analyze_cognitive_load' or 'analyze_working_memory' that also analyze cognitive aspects. The first paragraph defines cognitive bias but doesn't directly tie it to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it works for 'CUALQUIER PLATAFORMA' (any platform) and lists examples, but provides no guidance on when to use this tool versus alternatives like 'ux_full_audit' or other analysis tools. There's no explicit when/when-not instructions or comparison to siblings, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'analyzes' but doesn't describe what the analysis entails - whether it's a read-only inspection, generates reports, suggests optimizations, or has any side effects. It mentions 'ANY PLATFORM' but doesn't clarify limitations or prerequisites for different platforms. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences, but it's not optimally structured. It starts with an emoji and definition of the Pareto Principle before stating the tool's function. The platform list in the last sentence is somewhat redundant given the detailed platform enum in the schema. While not verbose, the structure could be more front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is an analysis tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis produces, what format results come in, or what insights users can expect. For a tool that presumably performs complex analysis across multiple platforms, the description lacks sufficient context about the tool's capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 four parameters thoroughly with descriptions and enum values for 'platform'. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how parameters interact, provide examples of valid inputs, or clarify the relationship between 'code' and 'component_description' parameters. 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analyzes code or UI components according to the Pareto Principle' which provides a general purpose, but it's vague about what specific analysis it performs. It doesn't specify what output or insights are generated, nor does it clearly distinguish this Pareto analysis from other analysis tools in the sibling list like 'analyze_fitts_law' or 'analyze_hicks_law' beyond mentioning the Pareto Principle itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions analyzing 'code or UI components for ANY PLATFORM' and lists many platform options, but provides no guidance on when to use this tool versus alternatives. It doesn't specify scenarios where Pareto analysis is appropriate (e.g., identifying critical 20% of code causing 80% of issues) or when other sibling tools might be better suited for different analytical needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions analyzing code/components according to a specific UX law, but doesn't disclose behavioral traits like what the analysis outputs, whether it's read-only or has side effects, performance characteristics, or error handling. The description is insufficient for a tool with 4 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with 3 sentences. The first introduces the UX principle, the second explains it briefly, and the third specifies the tool's scope. However, the second sentence about users not reading manuals feels more like background than essential tool information, and the description could be more front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis produces, how results are formatted, or what constitutes a 'good' versus 'bad' analysis according to this principle. For a tool that presumably returns analytical insights, the description should provide more context about the expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly with descriptions and enum values. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how parameters interact or provide usage examples. 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes code or UI components according to the 'Paradox of the Active User' principle for any platform. It specifies the action ('analiza') and scope ('código o componentes UI'), but doesn't clearly distinguish it from sibling tools like 'analyze_aesthetic_usability' or 'analyze_cognitive_load' which also analyze UI/UX principles. The purpose is somewhat vague about what specific analysis it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools analyzing different UX laws/principles (e.g., analyze_fitts_law, analyze_hicks_law), there's no indication of when the 'Paradox of the Active User' analysis is appropriate versus other analytical tools. It mentions it works for 'ANY PLATFORM' but doesn't specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 analyzing based on a 'mental model' law but doesn't disclose behavioral traits such as whether this is a read-only analysis, if it requires specific permissions, what the output format might be, or any rate limits. The description is too high-level to inform the agent about how the tool behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but the first sentence ('Un modelo comprimido...') is somewhat abstract and could be more direct. The second sentence clearly states the action and scope. It's front-loaded with the core purpose, though minor improvements in clarity could enhance efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of analyzing UI components across multiple platforms and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis produces, how results are returned, or any limitations. For a tool with 4 parameters and no structured output information, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 (code, component_description, platform, context) with descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema, such as examples or usage tips. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes code or UI components according to a 'mental model' law for any platform, which gives a general purpose. However, it's vague about what 'analyze' entails (e.g., what outputs or insights are produced) and doesn't clearly differentiate from sibling tools like 'analyze_fitts_law' or 'ux_full_audit', which likely perform similar analyses for different principles or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions it applies to 'ANY PLATFORM', but this doesn't help distinguish it from sibling tools that might also analyze UI components. There's no mention of prerequisites, constraints, or comparison to other analysis tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'analyses' but does not clarify what the analysis outputs (e.g., recommendations, scores, insights), whether it's read-only or modifies data, or any performance considerations. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the Parkinson's Law definition followed by the tool's scope. However, the inclusion of an emoji and all-caps 'ANY PLATFORM' adds minor stylistic flair without essential information, slightly reducing efficiency. Overall, it is well-structured with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of analyzing code/UI across multiple platforms and the lack of annotations and output schema, the description is incomplete. It does not explain what the analysis produces (e.g., insights, metrics, suggestions), leaving users uncertain about the tool's utility and results, which is inadequate for a tool with four parameters and no structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters. The description adds no additional semantic details about parameters beyond what the schema provides, such as examples or usage tips. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes code or UI components according to Parkinson's Law for any platform, which provides a general purpose. However, it lacks specificity about what the analysis entails (e.g., identifying inefficiencies, time-wasting patterns) and does not clearly distinguish it from sibling tools like 'analyze_cognitive_load' or 'ux_full_audit', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description mentions it applies to 'ANY PLATFORM' but does not specify scenarios where Parkinson's Law analysis is particularly relevant (e.g., for bloated code, over-engineered UIs) or when other tools like 'analyze_occams_razor' might be more appropriate, offering minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'analiza' (analyzes) but doesn't describe what the analysis produces, whether it's a report, score, recommendations, or just validation. It doesn't mention if the tool makes changes to code, provides explanations, or has any limitations. The description quotes Postel's Law but doesn't explain how this translates to tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences. The first presents Postel's Law in Spanish, the second states the tool's purpose, and the third specifies platform scope. While efficient, the middle sentence could be more specific about the analysis output. No wasted words, but could be more front-loaded with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter analysis tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the analysis produces, what format results come in, whether there are limitations to the analysis, or what constitutes a successful versus problematic analysis. The tool appears to perform complex UI/code analysis across multiple platforms, but the description provides minimal operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly with descriptions and enum values. The description adds no additional parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples of valid inputs, or clarify how parameters interact. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law), which provides a general purpose. However, it's vague about what specific analysis is performed - it doesn't specify whether it identifies violations, suggests improvements, or provides compliance scores. It mentions 'CUALQUIER PLATAFORMA' (any platform) but doesn't clearly differentiate from sibling tools that also analyze various laws/principles for UI/UX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools analyzing different laws/principles (Fitts' Law, Hick's Law, Jakob's Law, etc.), there's no indication of when Postel's Law analysis is appropriate versus other analytical tools. It doesn't mention prerequisites, typical use cases, or what problems this tool addresses specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. The description explains what the law is ('Las personas percibirán...') and states it analyzes code/components, but it doesn't disclose key behavioral traits: what the analysis outputs (e.g., suggestions, scores, issues), whether it's read-only or mutating, any rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the law definition, then states the tool's action, and ends with platform scope. There's minimal waste, though the law explanation could be seen as slightly verbose for a tool description. It's efficient overall, with clear structure in two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It lacks crucial context: what the analysis returns (no output schema), behavioral details (e.g., is it read-only?), and how to interpret results. The platform scope is helpful, but without annotations or output schema, the description doesn't provide enough information for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters (code, component_description, platform, context) with descriptions. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain how parameters interact, provide examples, or clarify usage. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law), which provides a clear verb ('analiza') and resource ('código o componentes UI'). However, it doesn't specifically differentiate this tool from its many sibling analysis tools (like analyze_fitts_law, analyze_hicks_law, etc.) beyond mentioning the specific law (Prägnanz). The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'CUALQUIER PLATAFORMA' (any platform) and lists examples like Web, iOS, Android, etc., which gives some context about when to use it. However, it provides no explicit guidance on when to choose this tool over the many other analysis tools (e.g., vs. analyze_aesthetic_usability or analyze_cognitive_load), no exclusions, and no prerequisites. The guidance is minimal and implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions analyzing code/components but doesn't disclose what the analysis produces, whether it's a report, score, recommendations, or something else. There's no information about performance characteristics, error conditions, or what happens with invalid input. The description is insufficient for a 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with two sentences that cover the core concept and scope. The first sentence explains the serial position effect concept, and the second states what the tool does and its platform coverage. No wasted words, though the Spanish introduction could be considered slightly extraneous for an English-speaking agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Incomplete for a 4-parameter tool with no annotations and no output schema. The description doesn't explain what the tool returns, what format the analysis takes, or what constitutes a successful versus problematic analysis. For a UX analysis tool with multiple parameters and no output schema, the description should provide more context about the analysis results and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 four parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions analyzing code/components and working for any platform, but the schema already covers this with detailed parameter descriptions and platform enum values. 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes code or UI components according to the serial position effect law for any platform. This provides a general purpose (analyze according to a specific UX law) but is somewhat vague about what specific analysis it performs. It doesn't clearly distinguish from sibling tools like analyze_fitts_law or analyze_hicks_law which also analyze code/components according to different UX laws.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions it works for 'ANY PLATFORM' but doesn't specify when this analysis is appropriate versus other UX analysis tools in the sibling list. There's no mention of prerequisites, typical use cases, or comparison to similar tools like analyze_von_restorff_effect or analyze_working_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 analyzing for any platform but doesn't disclose behavioral traits such as what the analysis output includes (e.g., textual feedback, scores), whether it's a read-only operation, potential rate limits, or authentication needs. This leaves significant gaps for an agent to understand 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: it introduces the law, states the tool's purpose, and specifies platform scope. It's front-loaded with the core purpose, though the first sentence is more explanatory than directly tool-focused, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is incomplete. It doesn't explain what the analysis returns (e.g., insights, errors, or structured data), which is critical for a tool with 4 parameters and complex platform options. This leaves the agent guessing about the tool's output and full utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 well. The description adds no additional meaning about parameters beyond implying platform flexibility, which is already covered by the schema's enum. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes code or UI components according to the Law of Uniform Connectedness, which provides a general purpose. However, it doesn't specify what the analysis produces (e.g., recommendations, scores, or insights) or how it differs from sibling tools like analyze_proximity_law or analyze_similarity_law, making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is for analyzing code or UI components for any platform, but it provides no guidance on when to use this specific law versus other sibling tools (e.g., analyze_common_region_law or analyze_proximity_law). There's no explicit context, exclusions, or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions the tool analyzes code/UI components but doesn't describe what the analysis produces, whether it's a report, score, or recommendations. It doesn't disclose computational requirements, rate limits, or what happens when analysis fails. The description is too vague about the tool's actual behavior beyond the high-level purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences, but the first sentence is more of a definition of the Goal-Gradient Effect rather than a direct description of the tool's function. The structure could be improved by front-loading the tool's purpose more clearly. The emoji adds visual appeal but doesn't contribute functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter analysis tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the analysis produces, what format the results take, or what constitutes a good vs. bad analysis. The mention of 'CUALQUIER PLATAFORMA' (any platform) is helpful context, but overall the description leaves too many behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description mentions analyzing code/UI components for any platform, which aligns with the 'code' and 'platform' parameters but doesn't add meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code or UI components according to the Goal-Gradient Effect law for any platform. It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components), and mentions the psychological principle being applied. However, it doesn't explicitly differentiate from sibling tools that analyze other UX laws.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool - only stating it analyzes according to the Goal-Gradient Effect. It doesn't explain when this analysis would be appropriate versus other sibling tools like analyze_fitts_law or analyze_hicks_law, nor does it mention prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions analyzing code/UI components for the Von Restorff effect but doesn't describe what the tool does behaviorally (e.g., returns insights, scores, suggestions), whether it's read-only or mutative, or any constraints like rate limits or authentication needs. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: an explanation of the Von Restorff effect, the tool's purpose, and platform scope. It's front-loaded with the effect definition, but the second sentence could be more direct. There's minimal waste, though the emoji and capitalization are stylistic but not detrimental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analyzing UI/code for a psychological effect), no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, what output to expect, or how to interpret results. For a tool with 4 parameters and behavioral uncertainty, this lacks sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 (code, component_description, platform, context) with descriptions. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law), which provides a general purpose. However, it's vague about what specific analysis it performs (e.g., detection, evaluation, recommendations) and doesn't clearly distinguish from siblings like 'analyze_similarity_law' or 'analyze_uniform_connectedness', which also analyze UI laws. The title is null, so the description carries the full burden.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it analyzes 'CUALQUIER PLATAFORMA' (ANY PLATFORM) with examples, giving some context. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., vs. 'analyze_similarity_law' for different principles) or provide exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states what the tool does (analysis) but doesn't disclose whether it's read-only, what output format to expect, whether it makes API calls, or any performance characteristics. The description adds the platform scope but lacks critical behavioral context for an analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences. The first states the law definition, the second specifies the tool's function, and the third adds platform scope. While efficient, the law definition could be considered extraneous since sibling tools suggest this is part of a UX law analysis suite where law definitions might be redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an analysis tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the analysis produces, how results are structured, or what constitutes good versus poor proximity. The platform list adds context but doesn't compensate for missing behavioral and output information critical for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no parameter-specific information beyond what's already in the schema descriptions. It mentions platform generality but doesn't elaborate on parameter usage or relationships. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing code or UI components according to the Law of Proximity. It specifies the action ('analiza') and target ('código o componentes UI'), but doesn't explicitly differentiate from sibling tools like analyze_common_region_law or analyze_similarity_law that also analyze design principles. The mention of 'CUALQUIER PLATAFORMA' adds scope but not sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like analyze_common_region_law or analyze_similarity_law, nor does it explain when proximity analysis is appropriate versus other UX laws. The platform list implies broad applicability but offers no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 'analiza' (analyzes), implying a read-only operation, but doesn't clarify output format, potential side effects, error handling, or performance considerations. For a tool with 4 parameters and no output schema, this leaves significant behavioral gaps, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the law's definition and immediately stating the tool's function. The two sentences are efficient, with no redundant information. However, the inclusion of an emoji (🔍) and the law's name in Spanish adds minor stylistic elements that don't enhance clarity, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing UX laws across multiple platforms with 4 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis entails, what results to expect, or how to interpret outputs. For a tool with no structured behavioral hints, this leaves the agent under-informed about its operation and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'code' as UI component code, 'platform' with enum values). The description adds minimal value beyond this, only implying analysis of 'código o componentes UI' which loosely maps to the 'code' and 'component_description' parameters. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing code or UI components according to the Law of Similarity for any platform. It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components), making the action concrete. However, it doesn't explicitly differentiate from sibling tools like 'analyze_proximity_law' or 'analyze_common_region_law', which likely analyze other Gestalt principles, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions applicability to 'CUALQUIER PLATAFORMA' (any platform), but doesn't specify scenarios, prerequisites, or exclusions. With many sibling tools analyzing different UX laws (e.g., 'analyze_fitts_law', 'analyze_hicks_law'), the lack of comparative context leaves the agent without clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'shows how to implement' for comparison, implying a read-only informational output, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data or examples, or if it's a simulation vs. real implementation. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences (including an emoji for visual emphasis). The first sentence establishes the core purpose, and the second elaborates slightly. There's no wasted text, though the structure could be more front-loaded by integrating the comparison aspect into the initial statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 minimally adequate. It explains what the tool does but lacks context on output format, behavioral constraints, or differentiation from siblings. Without annotations or output schema, the agent must guess at the return value and operational details, making this incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 ('law_id' and 'platforms') with descriptions. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain format constraints, provide examples of valid law IDs, or clarify platform naming conventions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Muestra cómo implementar una ley de UX en diferentes plataformas para comparación' (Shows how to implement a UX law on different platforms for comparison). It uses specific verbs ('implementar', 'comparar') and identifies the resource ('ley de UX', 'plataformas'). However, it doesn't explicitly differentiate from sibling tools like 'ux_get_law_info' or 'ux_list_platforms' that might provide related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or how it differs from sibling tools like 'ux_get_law_info' (which might provide law details) or 'ux_list_platforms' (which might list available platforms). The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'detects automatically' but doesn't disclose behavioral traits like accuracy, limitations, whether it's deterministic or probabilistic, what happens with ambiguous code, or if it requires internet access. For a detection tool with zero annotation coverage, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences and an emoji. The first sentence clearly states the purpose, and the second adds context about the input. However, the emoji and formatting slightly reduce efficiency, and the second sentence could be more front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is incomplete for a detection tool. It doesn't explain what the output looks like (e.g., platform name, confidence score), any error conditions, or limitations. For a tool that performs analysis based on code input, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain how 'code' and 'file_extension' interact or provide examples). 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('detecta') and resource ('plataforma'), and indicates it's based on provided code. It distinguishes itself from sibling tools that analyze UX principles rather than detect platforms. However, it doesn't specify what types of platforms it can detect (e.g., web frameworks, mobile platforms).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While sibling tools like 'ux_compare_platforms' and 'ux_list_platforms' exist, the description doesn't explain how this detection tool differs from them or when it's preferred. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 retrieves information with platform-specific code patterns, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or the format of returned information. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly state the tool's purpose and key feature (platform-specific code patterns). It uses an emoji and title-like formatting ('📚 Información de Ley UX por Plataforma'), which is slightly decorative but not wasteful. Every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, 100% schema coverage, no output schema), the description is minimally adequate. It covers the core purpose and hints at output (information with code patterns), but without annotations or an output schema, it lacks details on behavioral traits, return format, or error handling. This leaves room for improvement in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'law_id' (ID of the law with examples) and 'platform' (platform for specific patterns with an enum list). The description adds context by mentioning 'patrones de código específicos para la plataforma elegida' (specific code patterns for the chosen platform), which aligns with the schema but doesn't provide additional semantic details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtiene información detallada sobre una ley de UX, con patrones de código específicos para la plataforma elegida' (Gets detailed information about a UX law, with specific code patterns for the chosen platform). It specifies the verb ('obtiene'), resource ('información de ley UX'), and scope ('por plataforma'), but doesn't explicitly differentiate from sibling tools like 'ux_list_laws' or 'analyze_[law_name]' tools, which appear to analyze rather than retrieve information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'ux_list_laws' (which might list laws) or 'analyze_[law_name]' tools (which might provide analysis rather than platform-specific code patterns), nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It states the tool 'shows' platforms grouped by category, implying a read-only operation, but doesn't disclose whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly state the tool's function. The emoji adds visual context without being distracting. The information is front-loaded with the core purpose stated immediately. However, the second sentence could be more tightly integrated with the first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description is minimally adequate. It covers the basic purpose but lacks important context about output format, authentication requirements, and relationship to sibling tools. Given the complexity is low (single optional parameter), the description meets minimum requirements but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a clear enum parameter, so the baseline is 3. The description mentions 'agrupadas por categoría' which aligns with the optional 'category' parameter, but doesn't add meaningful semantics beyond what the schema already provides about filtering by category. No additional parameter context is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Muestra' - shows/list) and resource ('plataformas soportadas para análisis UX') with specific scope ('agrupadas por categoría'). It distinguishes from siblings like 'ux_detect_platform' or 'ux_compare_platforms' by focusing on listing rather than detection or comparison. However, it doesn't explicitly differentiate from 'ux_list_laws' which is a similar listing function for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use this versus 'ux_detect_platform' (which detects platform from user agent) or 'ux_compare_platforms' (which compares platforms). There's no context about prerequisites, typical use cases, or relationship to other tools in the UX analysis workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'analiza' (analyzes), which suggests a read-only operation, but doesn't clarify whether this is purely analytical or if it might modify anything. It doesn't mention authentication requirements, rate limits, output format, or what kind of analysis results to expect. The description provides only basic functional context without 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences, but has some structural issues. The first sentence is a definition of selective attention rather than a direct tool description. The second sentence contains the actual tool description but includes an overly broad platform claim ('CUALQUIER PLATAFORMA') followed by a list that doesn't match the enum values exactly. The emoji adds visual noise without semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter analytical tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the analysis produces, what format results come in, or what constitutes a successful analysis. Given the complexity of analyzing code/UI against psychological principles across multiple platforms, the description should provide more context about the analytical methodology and expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema - it mentions analyzing 'código o componentes UI' (code or UI components) which aligns with the 'code' and 'component_description' parameters, and mentions 'CUALQUIER PLATAFORMA' which relates to the 'platform' parameter. However, it doesn't provide additional semantic context about how parameters interact or what constitutes good input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (Analyzes code or UI components according to this law). It specifies the resource (code/UI components) and the analytical framework (selective attention law). However, it doesn't explicitly differentiate from sibling tools like 'analyze_cognitive_load' or 'analyze_working_memory' which also analyze UI/code against psychological principles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating it works for 'CUALQUIER PLATAFORMA' (any platform) and listing examples, which implies when this tool is applicable. However, it doesn't explicitly state when to use this specific law versus alternatives like 'analyze_fitts_law' or 'analyze_hicks_law', nor does it provide exclusion criteria or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions the tool analyzes based on 'working memory' law but doesn't disclose behavioral traits like what the analysis outputs (e.g., recommendations, scores, errors), whether it's read-only or mutative, performance characteristics, or error handling. The description adds minimal context beyond the basic purpose, leaving significant gaps for a 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes unnecessary elements: it starts with an emoji and a Spanish translation ('La Memoria de Trabajo') that doesn't add value for tool selection. The core purpose is stated in the second sentence, but the first sentence is redundant fluff. It could be more front-loaded and streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (cognitive analysis tool with 4 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on what the analysis produces, how results are formatted, error conditions, or practical usage examples. For a tool that likely returns structured insights, the description should do more to compensate for the missing structured data, especially with no output schema provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly with descriptions and an enum for 'platform'. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have enhanced understanding of how parameters relate to the analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley para CUALQUIER PLATAFORMA' (Analyzes code or UI components according to this law for ANY PLATFORM). It specifies the action (analyze), target (code/UI components), and scope (working memory law, all platforms). However, it doesn't explicitly differentiate from sibling tools like analyze_millers_law or analyze_cognitive_load, which likely analyze different cognitive principles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it analyzes 'código o componentes UI' (code or UI components) for 'CUALQUIER PLATAFORMA' (ANY PLATFORM), which suggests when this tool is appropriate. However, it doesn't provide explicit guidance on when to use this versus alternatives like analyze_cognitive_load (which might be more general) or ux_full_audit (which might be broader). The platform list in the schema helps but isn't part of the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions what the tool does (analysis based on a specific UX law) but doesn't disclose behavioral traits like whether it's read-only or has side effects, what format the analysis output takes, whether it requires authentication, or any rate limits. For a tool with no annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences. The first introduces the law concept, the second states the tool's action, and the third specifies platform scope. While efficient, the first sentence about the law effect could be considered slightly extraneous if the tool name already implies it, but it provides useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis tool with 4 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis produces, how results are formatted, whether it provides recommendations, or what happens with incomplete inputs. For a tool that presumably returns analysis results, the lack of output information is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions analyzing 'código o componentes UI' which aligns with the 'code' and 'component_description' parameters, but provides no additional semantic context. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing code or UI components according to the Aesthetic-Usability Effect law. It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components), and mentions the specific law being applied. However, it doesn't explicitly differentiate from sibling tools that also analyze different UX laws, though the law name itself provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by stating it analyzes 'CUALQUIER PLATAFORMA' (ANY PLATFORM) and listing examples. However, it doesn't explicitly state when to use this tool versus alternatives like other law-specific analysis tools or broader audit tools (e.g., ux_full_audit). The platform scope is helpful but doesn't address tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool 'analiza' (analyzes), which implies a read-only operation, but doesn't disclose behavioral traits like whether it makes API calls, has rate limits, requires authentication, or what format the analysis output takes. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but has structural issues. The first sentence defines 'Choice Overload' conceptually rather than stating the tool's function upfront. The actual tool purpose ('Analiza código o componentes UI...') comes second. While not wasteful, it could be more front-loaded for immediate clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage but no annotations and no output schema, the description is minimally adequate. It covers what the tool does and for which platforms, but doesn't address behavioral aspects (permissions, side effects) or output format. For an analysis tool with moderate complexity, it should provide more context about the analysis process or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'code' and 'component_description' interact or provide examples of valid 'context' values). 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law). It specifies the resource (code/UI components) and the analytical framework (choice overload law). However, it doesn't explicitly differentiate from sibling tools like 'analyze_hicks_law' or 'analyze_cognitive_load' which also analyze UI principles, though the specific law focus provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating it analyzes 'CUALQUIER PLATAFORMA' (any platform) and listing examples like Web, iOS, Android. However, it doesn't explicitly state when to use this tool versus alternatives like 'analyze_hicks_law' (which deals with decision time) or 'ux_full_audit' (comprehensive analysis). The context is clear but lacks explicit comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states what the tool does (analyze cognitive load) but lacks critical behavioral details: it doesn't specify whether this is a read-only analysis or if it modifies anything, what the output format or structure might be, any rate limits, authentication needs, or error conditions. For a tool with 4 parameters and no output schema, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: it defines cognitive load, states the tool's action, and specifies the scope. It's front-loaded with the key purpose. However, the first sentence is more of a definition than a direct tool description, and the use of emojis and capitalization ('CUALQUIER PLATAFORMA') slightly reduces professionalism without adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks information on what the analysis returns, how results are structured, any behavioral constraints, or error handling. For a tool that performs analysis across multiple platforms, users need more context about the output and limitations to use it effectively. The description alone is insufficient for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no specific parameter semantics beyond implying analysis of 'código o componentes UI' (which loosely relates to the 'code' and 'component_description' parameters) and 'CUALQUIER PLATAFORMA' (relating to the 'platform' parameter). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description provides minimal additional value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley para CUALQUIER PLATAFORMA' (Analyzes code or UI components according to this law for ANY PLATFORM). It specifies the action (analyze), target (code/UI components), and scope (cognitive load law, all platforms). However, it doesn't explicitly differentiate from sibling tools like 'analyze_working_memory' or 'analyze_mental_model' which might also relate to cognitive aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it analyzes 'código o componentes UI' for 'CUALQUIER PLATAFORMA,' suggesting it's for UI/UX analysis across platforms. However, it provides no explicit guidance on when to use this tool versus alternatives like 'ux_full_audit' or other analysis tools, nor does it mention prerequisites or exclusions. The platform enumeration in the schema hints at applicability but isn't part of the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 analyzing according to the Doherty Threshold law and the 400 ms threshold, but doesn't disclose key behavioral traits: what the analysis outputs (e.g., a report, score, or recommendations), whether it's a read-only or mutation operation, any performance implications, or error handling. The description is vague about the actual behavior beyond the high-level concept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the law definition and immediately states the tool's function. The second sentence adds platform scope efficiently. There's minimal waste, though the emoji and law explanation could be seen as slightly extraneous but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis tool with 4 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on what the analysis entails, the output format, any limitations, or how results should be interpreted. Without annotations or output schema, the description should do more to explain the tool's behavior and results, but it remains high-level and conceptual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters with descriptions. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how parameters interact or provide usage examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing code or UI components according to the Doherty Threshold law for any platform. It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components). However, it doesn't explicitly differentiate from sibling tools like 'analyze_fitts_law' or 'analyze_hicks_law' beyond mentioning the specific law name, which is implied but not stated as a distinguishing factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it analyzes 'CUALQUIER PLATAFORMA' (ANY PLATFORM) and listing examples like Web, iOS, Android, etc. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., other analysis tools in the sibling list) or any exclusions. The platform scope is broad but not framed as comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. The description explains what the tool does (analysis based on Fitts's Law) but lacks details on behavioral traits such as what the analysis outputs (e.g., metrics, recommendations), whether it's read-only or has side effects, performance characteristics, or error handling. It mentions platform versatility but doesn't clarify operational limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the law's definition and then stating the tool's function. It uses two sentences efficiently, with no redundant information, though the emoji and law name repetition are minor stylistic elements that don't detract significantly from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a UI analysis tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., analysis results, scores, suggestions), how to interpret outputs, or any limitations (e.g., supported code formats beyond listed platforms). For a tool with 4 parameters and analytical purpose, more contextual detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all four parameters (code, component_description, platform, context). The description adds minimal value beyond the schema, as it doesn't provide additional syntax, format details, or usage examples for the parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law). It specifies the resource (code/UI components) and the analytical framework (Fitts's Law), though it doesn't explicitly distinguish it from sibling tools like analyze_hicks_law or analyze_jakobs_law beyond mentioning the specific law name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by stating it analyzes 'CUALQUIER PLATAFORMA' (any platform) and listing examples like Web, iOS, Android, etc. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., other analysis tools in the sibling list) or mention any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 analysis based on Hick's Law but doesn't disclose behavioral traits such as what the analysis outputs, whether it's read-only or modifies data, performance characteristics, or error handling. The description is too vague about the tool's actual behavior beyond the high-level concept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the law definition and immediately stating the tool's function. It uses two sentences efficiently, with no wasted words, though the platform list could be more streamlined given the schema already enumerates them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of analyzing UI components across platforms with no annotations and no output schema, the description is incomplete. It lacks details on what the analysis entails, output format, error cases, or how it integrates with sibling tools. For a tool with 4 parameters and no structured output information, the description should provide more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear descriptions for all parameters. The description adds minimal value beyond the schema, as it only mentions platform applicability without detailing parameter interactions or usage examples. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law). It specifies the resource (code/UI components) and action (analyze) and mentions applicability to multiple platforms, though it doesn't explicitly differentiate from sibling tools like 'analyze_fitts_law' or 'analyze_cognitive_load' beyond the law name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it analyzes UI components for 'CUALQUIER PLATAFORMA' (any platform) and lists examples, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'ux_full_audit' or 'analyze_choice_overload'. The platform enumeration in the schema suggests broad applicability but lacks comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral disclosure. It doesn't describe what the analysis returns, whether it's read-only or has side effects, performance characteristics, or error handling. The description only states what the tool does conceptually, not how it behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. The first explains Jakob's Law, the second states the tool's purpose, and the third specifies platform scope. Each sentence earns its place, though the first sentence could be considered background rather than direct tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter analysis tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the analysis returns, what format results come in, or what constitutes a successful versus problematic analysis. The conceptual explanation of Jakob's Law doesn't compensate for missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no specific parameter information beyond what's already documented in the schema. It mentions analyzing code/components for any platform, which aligns with the schema parameters but doesn't provide additional semantic context about how parameters interact or their significance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code or UI components according to Jakob's Law for any platform, providing a specific verb ('analiza') and resource ('código o componentes UI'). It distinguishes from siblings by focusing on Jakob's Law specifically, though it doesn't explicitly contrast with other analysis tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it analyzes 'para CUALQUIER PLATAFORMA' and listing examples, but doesn't provide explicit guidance on when to use this tool versus alternatives like ux_full_audit or other analyze_* tools. No when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states what the tool does (analysis) but doesn't describe what the analysis produces, whether it's a report, score, or recommendations. It doesn't mention error conditions, performance characteristics, or what happens with invalid inputs. For a 4-parameter analysis tool with no annotations, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: first explains Miller's Law, second states the tool's function, third specifies platform scope. It's front-loaded with the core purpose. The emoji adds visual emphasis but doesn't detract from clarity. It could be slightly more structured but is generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter analysis tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the analysis produces, what format results come in, or what constitutes a successful analysis. Given the complexity of analyzing code/UI against a cognitive principle across multiple platforms, more context about the output and analysis methodology would be needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 thoroughly. The description adds minimal value beyond the schema - it mentions 'CUALQUIER PLATAFORMA' which aligns with the platform parameter's enum values, but doesn't provide additional context about parameter interactions or usage patterns. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing code or UI components according to Miller's Law for any platform. It specifies the verb ('analiza') and resource ('código o componentes UI'), and distinguishes itself by focusing on Miller's Law specifically. However, it doesn't explicitly differentiate from sibling tools like 'analyze_working_memory' which might cover similar cognitive concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it analyzes 'CUALQUIER PLATAFORMA' and listing examples, providing some context about when it's applicable. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'analyze_cognitive_load' or 'analyze_working_memory', nor does it mention prerequisites or exclusions. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states the tool 'analiza' (analyzes), which implies a read-only operation, but doesn't disclose behavioral traits like whether it modifies input, requires authentication, has rate limits, or what the output format might be. For a tool with 4 parameters and no annotations, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: it introduces Occam's Razor, states the tool's purpose, and specifies platform scope. It's front-loaded with the core purpose. However, the first sentence is a philosophical statement that doesn't directly aid tool selection, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the analysis entails, what criteria are used, what the output looks like, or how results should be interpreted. For a tool performing analysis across multiple platforms, more contextual information is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'código o componentes UI' and 'CUALQUIER PLATAFORMA', which loosely maps to the 'code' and 'platform' parameters but doesn't provide additional syntax, format, or usage details. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (analyzes code or UI components according to this law). It specifies the verb ('analiza') and resource ('código o componentes UI'), and mentions Occam's Razor principle. However, it doesn't explicitly differentiate from sibling tools like 'analyze_fitts_law' or 'analyze_hicks_law' beyond mentioning the specific law name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context: it mentions analyzing code/UI components 'para CUALQUIER PLATAFORMA' (for any platform) and lists examples. However, it doesn't explicitly state when to use this tool versus alternatives like 'ux_full_audit' or 'analyze_cognitive_load', nor does it provide exclusions or prerequisites. The guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions the Peak-End Rule concept but doesn't disclose behavioral traits like what the analysis outputs, whether it's read-only or mutative, if it requires authentication, rate limits, or error handling. The description is purely conceptual without operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: an emoji/rule name, a conceptual explanation, and a usage statement. It's front-loaded with the rule name and concept, but includes some redundancy (e.g., listing platforms after stating 'CUALQUIER PLATAFORMA'). Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is incomplete for a tool with 4 parameters. It explains the UX principle but lacks details on what the analysis returns, how results are structured, or practical usage scenarios. For a tool that presumably produces analysis output, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema, such as examples or constraints. It mentions platforms generally but doesn't elaborate on parameter usage, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code or UI components according to the Peak-End Rule for any platform. It specifies the action ('analiza') and target ('código o componentes UI'), but doesn't explicitly differentiate from sibling tools like 'analyze_aesthetic_usability' or 'analyze_cognitive_load' which likely analyze different UX principles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it analyzes 'CUALQUIER PLATAFORMA' and lists examples, providing some context about when to use it. However, it doesn't explicitly state when to choose this tool over alternatives like 'ux_full_audit' or other analysis tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 describes the analysis action but lacks details on what the tool returns (e.g., a report, score, or recommendations), any rate limits, error conditions, or performance characteristics. The description is functional but insufficient 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: an introduction to Tesler's Law, the core purpose, and platform scope. It's front-loaded with the law definition, but the purpose statement is clear. There's minimal waste, though the law explanation could be slightly trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis tool with 4 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis outputs (e.g., a complexity score, recommendations, or a report), leaving the agent uncertain about the tool's result. For a tool with rich input schema but no output information, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'code' and 'component_description' interact or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza código o componentes UI según esta ley' (Analyzes code or UI components according to this law). It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components). However, it doesn't explicitly differentiate from sibling tools like 'analyze_fitts_law' or 'analyze_hicks_law' beyond mentioning Tesler's Law specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by stating it works for 'CUALQUIER PLATAFORMA' (ANY PLATFORM) and listing examples like Web, iOS, Android, etc. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., other analysis tools in the sibling list) or any exclusions. The guidance is limited to platform compatibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 Zeigarnik Effect definition but doesn't disclose behavioral traits such as what the analysis outputs, whether it's read-only or mutative, performance characteristics, or error handling. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: a definition of the Zeigarnik Effect, the tool's purpose, and platform scope. It's front-loaded with the key purpose, though the first sentence is more educational than directly tool-focused, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is incomplete for a tool with 4 parameters. It lacks details on what the analysis returns, how results are structured, or any behavioral context needed for effective use. The sibling tools suggest this is part of a UX analysis suite, but the description doesn't leverage that context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly with descriptions and an enum for 'platform'. The description adds no additional parameter semantics beyond implying platform flexibility, which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code or UI components according to the Zeigarnik Effect law, with a specific verb ('Analiza') and resource ('código o componentes UI'). It distinguishes itself by focusing on this specific psychological principle, though it doesn't explicitly differentiate from sibling tools that analyze other laws like Fitts Law or Hick's Law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it analyzes 'CUALQUIER PLATAFORMA' and lists examples, suggesting broad applicability across platforms. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'ux_full_audit' or other law-specific analyzers, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions analyzing against 'TODAS las 30 leyes de UX' (all 30 UX laws), which suggests comprehensive evaluation, but doesn't disclose behavioral traits like whether this is a read-only analysis, what format the output takes, computational requirements, or potential limitations. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence (with emoji) states the core purpose, and the second adds important context about platform adaptation. No wasted words, though the emoji could be considered decorative rather than functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, no output schema, and many sibling tools, the description is incomplete. It doesn't explain what the analysis produces, how results are structured, whether it's a simple checklist or detailed report, or how it differs from individual law analysis tools. For a comprehensive analysis tool with complex input options, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions platform adaptation but doesn't explain how parameters like 'focus_areas' or 'component_description' affect the analysis. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza un componente o interfaz contra TODAS las 30 leyes de UX' (analyzes a component or interface against all 30 UX laws). It specifies the verb (analyzes) and resource (component/interface), but doesn't explicitly differentiate from sibling tools like 'ux_checklist' or 'ux_compare_platforms' which might 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'adaptado a la plataforma específica' (adapted to the specific platform) and listing many platform options, but doesn't provide explicit guidance on when to use this tool versus the many sibling analysis tools (e.g., 'analyze_fitts_law', 'analyze_hicks_law'). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 explains what the tool does (analyzes based on the Law of Common Region) but doesn't disclose behavioral traits like whether it's read-only or destructive, what the output format might be, any rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: it names the law, explains the principle, and specifies the tool's scope. It's front-loaded with the law name and purpose, though the second sentence is more explanatory than directive. There's minimal waste, but it could be slightly more focused on tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage but no annotations and no output schema, the description provides adequate context about what the tool does and its platform scope. However, it lacks details on behavioral aspects and output, making it minimally complete but with clear gaps for a tool that performs analysis without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 4 parameters thoroughly. The description mentions analyzing code or UI components for any platform, which aligns with the 'code' and 'platform' parameters but doesn't add meaningful semantics beyond what the schema provides. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code or UI components according to the Law of Common Region for any platform. It specifies the verb 'analiza' (analyzes) and the resource 'código o componentes UI' (code or UI components), but doesn't explicitly differentiate from sibling tools like analyze_proximity_law or analyze_similarity_law, which likely analyze different Gestalt principles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it analyzes 'CUALQUIER PLATAFORMA' (ANY PLATFORM) and lists examples, but doesn't provide explicit guidance on when to use this specific law versus alternatives like analyze_proximity_law or analyze_similarity_law. It gives context about platform applicability but lacks when-not scenarios or clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 checklist but doesn't reveal key traits: whether it's a read-only operation, what the output format is (e.g., list, structured data), if there are rate limits, or if it requires specific permissions. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated in two sentences. The first line ('✅ Checklist de UX por Plataforma') serves as a title-like summary, and the second sentence explains the action. There's no unnecessary information, making it efficient, though the emoji adds minor visual clutter without functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 adequate but incomplete. It covers the purpose and parameters at a high level but lacks details on output behavior, error handling, or integration with sibling tools. Without annotations or output schema, more context on what the generated checklist includes would improve completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions adaptation to 'component type' and 'platform', aligning with the two parameters in the schema. Since schema description coverage is 100%, the schema already documents these parameters well (e.g., 'component_type' with examples, 'platform' with enum values). The description adds minimal semantic value beyond what's in the schema, meeting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Genera un checklist de verificación UX adaptado al tipo de componente Y plataforma específica' (Generates a UX verification checklist adapted to the component type AND specific platform). It specifies the verb 'genera' (generates) and resource 'checklist de verificación UX' (UX verification checklist), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ux_full_audit' or 'ux_compare_platforms', which might offer broader or comparative analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning adaptation to 'component type' and 'platform', suggesting it's for generating platform-specific UX checklists. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'ux_full_audit' for comprehensive audits or 'ux_compare_platforms' for cross-platform analysis). No exclusions or prerequisites are stated, leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it states what the tool does (list laws with optional filtering), it doesn't disclose important behavioral traits like: what format the list returns (array of names? objects with details?), whether there's pagination or limits, if it requires authentication, or any rate limits. For a list operation with no annotation coverage, this 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: an emoji for visual recognition, a clear title in Spanish, and one explanatory sentence that covers the core functionality. Every element earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single optional parameter, list operation) and 100% schema coverage, the description is adequate but has gaps. No output schema exists, so the description should ideally mention what the list returns (e.g., 'returns an array of law names with basic info'). Without annotations, it also misses behavioral context about the operation's safety and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'category' with its description and allowed values. The description adds minimal value beyond the schema by mentioning 'opcionalmente filtradas por categoría' (optionally filtered by category), which reinforces the optional nature. With only one parameter and high schema coverage, baseline 3 would be appropriate, but the description provides slight additional context about the filtering purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Listar' - list) and resource ('Leyes de UX' - UX laws), with the optional filtering capability. It distinguishes from siblings like 'ux_get_law_info' (which gets detailed info about a specific law) and 'analyze_*' tools (which analyze specific UX principles rather than listing them all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: to list all available UX laws with optional category filtering. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context is sufficiently clear given the sibling tools (use 'ux_get_law_info' for detailed info on a specific law, use 'analyze_*' tools for analysis of specific principles).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Agencia-Tecnologica-Multiverse-Limitada/UX-UI-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server