style-agent

by jtrslar

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct with clear roles: find vs wait, click vs hover, styles vs inspect. However, style_status and style_tabs both list tabs, and style_styles vs style_inspect overlap in reading computed styles, creating minor confusion.
Naming Consistency4/5
All tools share the 'style_' prefix and are lowercase snake_case, forming a recognizable pattern. Some use verbs (find, click, wait) while others use nouns (tabs, dialogs, styles), deviating from a strict verb_noun convention but remaining predictable.
Tool Count5/5
With 12 tools, the set is well-scoped for a style/UI inspection purpose. Each tool covers a needed action without redundancy, fitting comfortably within the ideal 3-15 range.
Completeness4/5
The toolset covers the core lifecycle: health check, locating elements, reading styles, spacing, interactions, waiting, dialog listing, and spec-based inspection. Minor gaps such as missing screenshot or scroll capabilities are workarounds, but the surface is robust for style verification.
Average 3.4/5 across 12 of 12 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only states the core action. It does not clarify what 'spacing' measures, how elements are selected in tabs, or what the return value looks like. No contradictions with annotations exist, but the minimal detail leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is positive. However, it is under-specified to the point of losing clarity, so the brevity does not fully serve its purpose.
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 tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It fails to explain return values, tab selection behavior, or the exact meaning of spacing, leaving agents without enough information to invoke it correctly in varied contexts.
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 coverage is 60% with descriptions for optional parameters, but the required uidA/uidB parameters have no descriptions and the tool description adds no parameter context. The description does not compensate for the coverage gap, leaving the semantics of the required parameters implicit.
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 '两 uid 元素间距' clearly indicates the tool's function: retrieving spacing between two UID-identified elements. It is specific enough to distinguish from sibling tools like style_click or style_hover, though the term 'spacing' is somewhat ambiguous (margin, distance, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, or how it relates to sibling tools like style_status or style_tabs. The description gives no context about prerequisites or typical use cases.
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, the description carries the full burden of explaining behavior. It merely says 'list dialogs/aria-modal' but does not explain what 'list' returns (elements? text?), how tab filtering works, or whether there are any side effects. The brevity leaves the agent without enough behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no filler words, front-loading the core action. Although it may be too sparse for full understanding, that issue is more about completeness than verbosity, so conciseness itself is strong.
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?
The tool has 3 parameters, 11 sibling tools, no annotations, and no output schema, yet the description is a single fragment. It lacks information about return format, filtering behavior, relationship to style_tabs, and how to interpret results, making it inadequate for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with useful descriptions (tab index, URL substring, title substring), giving 100% coverage. Since the description adds no additional parameter meaning, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('列出' = list) and a clear resource ('dialog / aria-modal'), which is semantically distinct enough. However, it does not differentiate from siblings like style_find or style_inspect, which could also involve locating elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as style_find or style_tabs. The description only gives a terse one-line action, with no mention of appropriate scenarios, 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 only notes that the menu expands on hover, which is a UI behavior, but does not reveal what the tool does after hovering (e.g., whether it waits, scrolls, or returns a result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. There is no fluff, but the extreme brevity results in missing details.
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?
With five parameters, no annotations, and no output schema, the one-line description is insufficient for an agent to confidently invoke the tool, especially considering optional parameters and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (index, urlIncludes, titleIncludes have descriptions). The description adds meaning only to 'uid' by indicating it is the hover target, but offers no extra semantics for 'scroll' or the selector parameters.
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 the specific action '悬停' (hover) and the target 'uid', with a parenthetical clarifying that this is for menus that expand on hover. This distinguishes it from sibling tools like style_click or style_wait, though the meaning of 'uid' is not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as style_click or style_tabs. The description offers no scenarios, 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?
With no annotations, the description is the sole source of behavioral details. It discloses that by default it returns at most 3 results and suggests css preference, but it omits critical behavior such as timeout/error handling (despite timeoutMs/intervalMs params), what happens if no element appears, and the exact return format. This is insufficient for a wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core purpose, but the brevity leaves out important details, making it slightly under-specified rather than ideally concise.
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 10 parameters, no output schema, and no annotations, the description is inadequate for a complex wait tool. It does not explain timeout semantics, how multiple selectors interact, what the returned items represent, or the tab-filtering behavior. The tool appears sophisticated, yet the description covers only a small fraction of its functionality.
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 coverage is only 40%, leaving 6 parameters (css, role, text, testId, timeoutMs, intervalMs) without schema descriptions. The description adds semantics by naming css/text/testId/role as selector types, but does not compensate for the timing parameters or clarify how index, urlIncludes, and titleIncludes relate to tab selection. It provides only partial value beyond the schema.
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 clearly states the tool waits for an element to appear and lists supported selector types (css/text/testId/role). The verb '等待' (wait) and resource '元素' (element) clearly identify the action, and the selector list helps distinguish it from immediate-find tools like style_find, though it does not explicitly differentiate from siblings.
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 guidance to '优先用 css' (prefer using css) is a usage tip, and the phrase '等待元素出现' implies this is for waiting when elements may not be immediately present. However, it does not explicitly state when to use this tool over siblings, nor provide exclusion criteria or alternative tool references.
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 carry the full burden of behavioral disclosure. It merely states 'highlight uid (confirm positioning)' without explaining side effects, permanence, visibility requirements, or interaction with the page. This leaves significant behavioral ambiguity.
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, front-loaded sentence that states the core action and intent without any wasted words. This is appropriately concise for the tool's apparent simplicity.
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 no annotations, no output schema, and four parameters, the description is too sparse to be fully contextual. It does not explain how highlight behaves (e.g., temporary visual cue, scroll-to-element), what happens if no element matches the uid, or how the optional selectors refine the target. This could lead to misuse in complex UI scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% with documented optional parameters (index, urlIncludes, titleIncludes) and an undocumented uid. The description adds that uid is the element to highlight, but does not elaborate on how the optional selectors work together. Baseline 3 is appropriate since the schema already carries most parameter meaning.
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 uses a specific verb 'highlight' with a resource 'uid' and adds the purpose 'confirm positioning', which clarifies the tool's function. It does not explicitly distinguish from sibling tools like style_find or style_status, but the action is clear enough to infer its role.
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 usage context: use when you need to confirm the location of a uid. However, it offers no explicit guidance on when not to use it or which sibling tool to choose instead, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the key behavioral difference between a uid click (opens dropdown/overlay) and a selector click (Playwright real click). However, it fails to mention side effects, return behavior, errors, or timing, leaving behavioral ambiguity.
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 extremely concise, with two short sentences that front-load the primary purpose and a secondary mode. Every word adds value, with no redundancy or filler.
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?
The tool has seven optional parameters, no output schema, and no annotations, so the description is the only guide. It covers only two modes (uid/selector) but leaves key details unexplained, such as how uid interacts with index/urlIncludes/titleIncludes, what scroll/timeout do, and what the tool returns or does on failure. This is insufficient for an agent to confidently invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, and the description adds meaning by explaining that uid opens dropdowns/overlays, which the schema doesn't describe. It also reiterates that selector uses real Playwright click, but the schema already says 'CSS; 有则优先真实点击'. Other parameters like index, scroll, timeout, urlIncludes, and titleIncludes receive no added semantic context.
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 clicks a uid to open drop-downs/overlays, and also supports a selector for real Playwright clicks. It provides a specific verb and resource, and distinguishes from siblings like style_hover by focusing on click actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use style_click versus sibling tools such as style_hover or style_tabs. It does hint at two parameter modes (uid vs selector) but doesn't explain selection criteria or context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates a read-only lookup operation that returns a uid, but it does not disclose behavior for multiple matches, the effect of the limit parameter, or error handling. The mention of the uid's purpose adds some context, but key behavioral details are missing.
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 concise sentence that front-loads the action and output. It contains no redundant information and is well-structured for quick parsing.
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?
With 8 parameters and no output schema, the description is under-specified. It does not state whether the function returns a single uid or an array, how criteria are combined (AND/OR), what happens when no match is found, or the meaning of the limit parameter. This is a significant gap given the lack of structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the locator parameters (text, css, testId, role) to the Chinese translation '文案/CSS/testid/role', adding meaning beyond the schema. However, it does not explain the 'limit' parameter or how criteria combine, and schema coverage is only 38%. The description partially compensates but not fully.
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 clearly states the tool finds elements by text/CSS/testid/role and returns a uid for use with style_styles/style_click. It effectively distinguishes itself from action-oriented siblings by positioning itself as the lookup step, though it doesn't explicitly differentiate from style_inspect or style_status.
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 phrase '供 style_styles / style_click' implies this tool should be used before styling or clicking to obtain a uid. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like style_inspect.
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 disclose behavioral traits. It only states 'list page tabs' with no information about return format, side effects, or required state. This leaves significant ambiguity about what the tool actually returns or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without any extra fluff. It is front-loaded and appropriately sized for a zero-parameter tool.
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?
Despite its simplicity, the description is incomplete because it lacks information about the output or expected behavior. There is no output schema to compensate, and the description does not clarify what 'tabs' means in this context or what a user should expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers this fully. The description adds no parameter semantics, but with no parameters to describe, the baseline of 4 is appropriate.
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 a specific action ('列出' / list) and resource ('调试 Chrome 中的页面标签' / page tabs in debugging Chrome). This distinguishes it from sibling tools, none of which mention tabs, so it uniquely identifies 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/5
Does 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 simply states what the tool does without mentioning context, prerequisites, or exclusions. Sibling tools exist but no comparison is given.
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 merely warns that the tool is '高级' (advanced) but does not disclose potential side effects, hazards of executing arbitrary JS, return value characteristics, error handling, or any interaction with the page's state. This is a significant gap for a tool that executes code.
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 that conveys the purpose and a usage warning without any fluff. It is front-loaded and every word earns its place.
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?
For a potentially destructive tool like JS execution, the description is starkly incomplete. It does not mention return value, side effects, error behavior, or tab selection mechanics (though some are in the schema). The sibling tools list suggests a rich context, but this description does not integrate with it beyond the 'prefer other tools' caution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%: index, urlIncludes, and titleIncludes have descriptions, but the required 'expression' parameter is left undocumented. The tool description's '执行 JS 表达式' partially clarifies the expression param's role, but does not go beyond the parameter name's obvious meaning. Thus the description adds minimal semantic value over the schema, and the most critical parameter lacks explicit guidance.
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 states a specific verb and resource: '执行 JS 表达式' (execute JS expression) within the page. It also distinguishes itself from siblings by labeling itself as '高级' (advanced) and directing preference to other tools, which clearly sets it apart from the more common interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '优先其它工具' (prefer other tools) explicitly communicates that this tool should be used only when other tools are not suitable. This gives clear context on when to avoid it, though it doesn't name specific alternatives or list exclusions beyond that general guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only status operation ('检查 CDP 是否连通、列出标签'), but does not describe behavior on failure, return format, or side effects. For a simple status check this is minimally adequate but lacks richer detail.
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, compact sentence that front-loads the primary purpose and usage. Every word carries meaning, with no redundancy or filler.
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?
Given the tool has no parameters, no output schema, and no annotations, the description covers the basic function and invocation time. However, it does not specify what the tool returns or how CDP connectivity is indicated, which could leave the agent uncertain about interpreting the result. For a simple status tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any. The baseline of 4 applies since there is nothing to document.
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 clearly states the tool checks CDP connectivity and lists tabs, with the specific verbs '检查' (check) and '列出' (list). It also adds usage context by saying it should be called first at the beginning of the closed loop. While it doesn't explicitly distinguish from sibling 'style_tabs', the CDP connectivity check sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-to-use instruction: '闭环开始时先调' (call it first at the beginning of the closed loop). This gives clear context for when to invoke the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses one key behavior: '默认只返回失败项' ('only returns failures by default'), which is useful. However, it does not mention other behaviors like error handling, side effects, or return format, leaving a moderate transparency level.
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 three short sentences, each earning its place: the first states the purpose, the second describes default behavior, and the third gives usage guidance. It is front-loaded, efficient, and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six optional parameters and no output schema, this description provides the essential context: what it does, the default output behavior, and when to prefer it. It does not explain the selector parameters or the setup/nodes/relations structure, but the schema covers the parameters. It is reasonably complete for a read-only inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, so the baseline is 3. The description adds no new parameter-level meaning; the 'failures only' default is already documented in the failuresOnly parameter. Thus, the schema does the heavy lifting and the description does not enhance it.
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 identifies the tool as running style/layout checks based on a JSON spec, with a parenthetical defining the scope (setup+nodes+relations). It distinguishes from sibling tools by emphasizing spec-driven inspection and explicitly recommending it when acceptance criteria exist, which sets it apart from status, tab, and find tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use signal: '有验收标准时优先用' ('prefer when acceptance criteria exist'). This provides context for choosing this tool over alternatives, but it does not mention specific sibling names or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 uses the verb '读取' (read) implying a read-only operation, which is helpful, but does not explain any side effects, prerequisites (e.g., module must be rendered), performance implications, or what the returned subtree structure looks like. It provides some context via '探索/对稿时用' but leaves key behavioral details unstated.
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 two short sentences, front-loaded with the core action and selection method, followed by usage context and alternative. Every word earns its place; no fluff or repetition of schema field descriptions.
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?
For a tool with 7 parameters, no output schema, and no annotations, the description gives a high-level purpose and usage context but omits important details like the meaning of depth or maxNodes, how the returned subtree is structured, and any constraints or prerequisites. It is minimally viable but leaves gaps in fully guiding the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (43%), so the description must compensate for undocumented parameters. It does clarify that the module can be selected by 'uid 或 css', covering the two main selector parameters. However, it does not explain the depth or maxNodes parameters, which remain undocumented in both schema and description. It partially compensates but not fully.
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 action: '读取模块 computed style 子树（uid 或 css）' (read the computed style subtree of a module, by uid or css). It names the resource (computed style subtree) and the selection mechanism, and explicitly distinguishes from sibling style_inspect by saying '有 spec 优先 style_inspect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: '探索/对稿时用' (use during exploration/design comparison). It also names an alternative tool and when to prefer it: '有 spec 优先 style_inspect' (if a spec exists, prefer style_inspect). This is clear when-to-use and alternative guidance.
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:

[![style-agent MCP server](https://glama.ai/mcp/servers/jtrslar/style-agent/badges/card.svg)](https://glama.ai/mcp/servers/jtrslar/style-agent)

Score Badge

Copy to your README.md:

[![style-agent MCP server](https://glama.ai/mcp/servers/jtrslar/style-agent/badges/score.svg)](https://glama.ai/mcp/servers/jtrslar/style-agent)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jtrslar/style-agent'

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