Skip to main content
Glama
polatbakir

ui-optimizer-mcp

by polatbakir
OverviewSchemaRelated ServersScoreDiscussions
Local

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v0.1.0

  • Disambiguation5/5

    The two tools have clearly distinct inputs and purposes: one scans a live URL and produces a report, the other consumes an existing report to produce a prompt. There is no realistic overlap or ambiguity between them.

    Naming Consistency5/5

    Both tool names follow the same verb_noun pattern with snake_case convention: scan_website_ui and generate_ui_fix_prompt. Naming is perfectly consistent.

    Tool Count3/5

    With only two tools, the server feels quite thin for a 'ui-optimizer' domain. The tools support a narrow scan-and-prompt workflow, but the count is on the low end and could warrant a few more related operations.

    Completeness4/5

    The workflow of scanning a website and generating a fix prompt is functionally complete for the server's stated purpose. Minor gaps exist such as lacking a way to import external reports or apply fixes directly, but the core flow is not broken.

  • Average 3.5/5 across 2 of 2 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 3 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.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • 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.json to 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

  • Behavior3/5

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

    With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the core behavior of generating a prompt summary from a report, but it does not mention any side effects, output format, or limitations. This is adequate but not detailed.

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

    Conciseness5/5

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

    The description is a single, focused sentence with no filler. The key action and input are front-loaded, making it easy to parse quickly.

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

    Completeness2/5

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

    Given the complex nested input schema, no output schema, and no annotations, the description is too sparse to be complete. It does not explain what the generated prompt summary looks like, how the report components map to the output, or how this tool relates to scan_website_ui.

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

    Parameters2/5

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

    Schema description coverage is 0%, so the description must compensate, but it only refers to an 'existing optimization report' without explaining the meaning of url, summary, issues, or nested fields like severity and affectedArea. The agent is left to infer semantics from field names alone.

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

    Purpose4/5

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

    The description states a specific action (generate a concise Claude Code prompt summary) and a clear input source (an existing optimization report). It does not explicitly contrast with the sibling tool scan_website_ui, but the word 'existing' helps distinguish it from a tool that creates the report.

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

    Usage Guidelines3/5

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

    The description implies the tool is meant for use after an optimization report already exists, which gives some usage context. However, it does not explicitly state when to prefer this tool over scan_website_ui, nor does it mention any prerequisites or exclusions.

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

  • Behavior4/5

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

    With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions using Playwright to open the URL and captures screenshots/DOM metadata, which conveys that this is an active browser automation operation with potential side effects like network requests and page execution. It also names the output artifacts, though it does not warn about failure modes or resource intensity.

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

    Conciseness5/5

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

    The description is a single, dense sentence that front-loads the core action ('Open a URL with Playwright') and lists the key steps and outputs. It is concise with no redundant wording, wasting no tokens.

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

    Completeness3/5

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

    The description gives a high-level overview of the process and outputs but omits details about the viewportPresets parameter and the exact structure/format of the optimization report. With no output schema and no annotations, the description is adequate but not complete enough for an agent to fully anticipate the response shape or handle edge cases.

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

    Parameters2/5

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

    Schema description coverage is 0%, so the description must compensate for the parameter meaning. It only mentions 'Open a URL' and 'capture screenshots,' but never explains the viewportPresets parameter or how it relates to the scanning behavior. The parameter names are somewhat self-explanatory (url, viewportPresets), but the description adds no additional semantic detail beyond the schema.

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

    Purpose5/5

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

    The description clearly states the tool's function with specific verbs and resources: opens a URL, captures screenshots and DOM metadata, runs deterministic UI checks, and returns a structured report. The combination of scanning and producing a follow-up prompt distinguishes it from the sibling generate_ui_fix_prompt, which likely only generates a fix prompt.

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

    Usage Guidelines3/5

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

    The description implies the tool is for analyzing a website's UI and getting optimization feedback, but it provides no explicit guidance on when to use this tool versus the sibling generate_ui_fix_prompt. The usage context is inferable but not directly stated, and no exclusions or alternative conditions are given.

    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

ui-optimizer-mcp MCP server

Copy to your README.md:

Score Badge

ui-optimizer-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/polatbakir/ui-optimizer-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server