FireKey MCP Server

by partnerhbhl

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct resource-action pair: groups, proxies, browser execution, and profile management are clearly separated. Even closely related tools like profile_delete and profile_delete_cache are unambiguous from their names.
Naming Consistency4/5
Tool names consistently use a resource_action pattern in snake_case (group_create, proxy_list, browser_start, profile_update). Minor deviations like profile_cookies and browser_active are not actions, but they are still predictable and readable.
Tool Count5/5
15 tools is within the well-scoped range and each tool addresses a concrete need for browser profile management, proxy management, group organization, and runtime browser control. There are no redundant or trivial tools.
Completeness3/5
Profile and browser management are well covered, but auxiliary resources have notable lifecycle gaps: proxies cannot be updated or deleted, and groups cannot be deleted. This leaves no way to remove stale proxy configurations or groups, which agents may need to do.
Average 3.3/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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

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 merely states that it creates a configuration, implying a write operation, but does not disclose whether it requires authentication, if it can overwrite existing configurations, what side effects occur, or how errors are handled. For a tool that creates a resource, this is a significant gap—the agent has no insight into the operational impact.
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 sentence with no verbosity, so it is concise. However, it is under-specified; it lacks structure or elaboration that would help the agent. While it avoids fluff, it also earns its place only minimally—it could be considered too thin to be genuinely useful, but it is not a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters (3 required) and no output schema or annotations. The description does nothing to explain how to construct a valid request, what the expected behavior is, or what the result looks like. For a create operation with multiple enum-based parameters, this is completely inadequate. An agent would have to rely solely on the schema, missing critical context like considerations for proxy_url or ipchecker.
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 describes all 8 parameters with clear descriptions (100% coverage). The tool description adds no additional meaning beyond the schema; it doesn't explain how parameters relate or any special constraints. Per the calibration rule, when schema coverage is high, the baseline is 3, and since the description offers no supplementary parameter insight, this score 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 the verb 'create' and the resource 'proxy configuration', which clearly identifies the tool's purpose. It distinguishes from siblings like proxy_list and proxy_create is unique among the list, so there is no ambiguity about what it does. However, it could be more specific about what constitutes a proxy configuration (e.g., including host, port, type), but the core purpose is clear.
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. While there is no sibling that performs the same creation operation, the description does not mention prerequisites (e.g., that a proxy type must be chosen from the enum) or suggest when to use proxy_create vs listing or managing proxies. No context for tool selection is provided.
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 behavioral disclosure burden. It mentions the return value but omits that starting a browser launches a process, has side effects, and likely needs to be paired with browser_stop; it also does not disclose failure modes or lifecycle 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences with no filler, and the action and primary output are front-loaded. It sacrifices some behavioral context for brevity, but the structure itself is clean and direct.
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 8 parameters, no output schema, and no annotations, the description is too thin to make the tool fully actionable. It does not explain the shape of the returned WebSocket endpoints, what happens if both profile_id and profile_no are supplied, or that a profile must already exist before starting it.
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 100%, so the schema already explains all 8 parameters, their enums, and defaults. The description adds no extra semantics beyond the return value, but the baseline of 3 is appropriate because the schema handles parameter meaning well.
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 ('Start') and a clear resource ('a browser profile'), and it states the key return value (WebSocket endpoints for Puppeteer/Selenium). It distinguishes the tool from obvious siblings like browser_stop and browser_active, though it does not explicitly name a sibling to differentiate from.
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 given on when to use this tool versus alternatives such as profile_create, browser_active, or browser_stop. The description does not mention prerequisites like an existing profile or that browser_stop is needed for cleanup.
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 responsibility for behavioral disclosure. It only states that an existing group is updated, which implies mutation and existence, but it does not explain error behavior for a missing group, whether it is a partial or full update, permission requirements, or what the tool returns after success.
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 sentence with no filler or redundant phrases, and it is front-loaded with the core action. However, it is so terse that it borders on merely restating the tool name, slightly reducing its structural value.
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?
This is a mutating operation with no annotations and no output schema, and the description provides only the bare action. It does not help the agent decide between this and group_create, does not indicate which fields are updatable, and does not explain what happens after an update, leaving significant gaps for correct invocation.
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 provides 100% parameter coverage with descriptions for group_id, group_name, and remark, so the description does not need to add much. Since the description adds no additional semantic detail beyond what the schema already provides, the baseline of 3 applies.
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 verb 'update' and the resource 'group', and the word 'existing' distinguishes it from the sibling tool group_create. However, it does not mention what aspects of the group can be updated or any scope limits, so it stops short of a fully rich purpose statement.
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 instead of group_create, group_list, or other group operations. It does not state that the group must already exist, how this relates to group_create, or any prerequisites or conditions 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 must carry the behavioral disclosure burden. It discloses only that a profile is created, not side effects, required inputs, failure modes, response behavior, or implied constraints such as needing a valid group_id. For a mutating create operation, this is a significant transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clean, front-loaded sentence with no filler. It is efficiently written, though it is a simple statement rather than a structured explanation that leverages the richness of the tool's 30 parameters.
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?
There is no output schema and no annotations, so the description alone must make the tool safely invocable. It omits the required group_id dependency, proxy method interaction (none/saved/your), defaults, and expected result. For a 30-parameter creation tool, this is incomplete.
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 100%, and the schema already documents all 30 parameters, their enums, defaults, and conditional meanings. The description adds no parameter-level meaning beyond the schema, so the baseline 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 verb ('Create') and a specific resource ('browser profile'), and the mention of fingerprint and proxy settings gives clear scope. It is clearly distinct from profile_update, profile_delete, and proxy_create by its wording. However, it does not explicitly contrast with sibling tools, so it stops short of a 5.
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 guidance on when to use this tool versus alternatives such as profile_update, profile_delete, or proxy_create. It only declares what the tool does, with no conditions, prerequisites, or 'use this when...' direction.
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 must disclose behavioral traits, but it only restates that the tool updates a profile. It does not mention whether updates are partial or full replacements, whether the profile must be stopped, authentication needs, side effects, or what happens to fields not supplied.
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 clear, front-loaded sentence with no redundant wording. It is concise, though it could have included more useful detail without much extra length.
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?
This is a mutation tool with no annotations, no output schema, and moderately complex nested parameters. The one-sentence description is too sparse to fully inform an agent about update semantics, return values, error cases, or operational constraints.
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 100%, so the baseline is 3. The description adds no parameter-level meaning, but the schema already documents profile_id, name, remark, user_proxy_config, and fingerprint_config, so the missing explanation is acceptable.
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 ('Update') and a clear resource ('existing browser profile'). It is unambiguous and reasonably distinguishes from sibling tools like profile_create and profile_delete, though it does not explicitly name any alternatives.
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 profile_create, profile_delete, or other related profile tools. The word 'existing' weakly implies it is for already-created profiles, but the description provides no explicit context, 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. 'List' implies a read-only operation, but no further behavioral traits are disclosed, such as pagination behavior, filter semantics, or return format.
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 efficient sentence that front-loads the action and resource without unnecessary words. It is appropriately concise for a simple listing operation.
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?
With no required parameters and fully documented optional parameters in the schema, the description is sufficient for basic invocation. However, the lack of an output schema and annotations leaves the return shape and detailed behavior unspecified, so it is not fully complete.
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 100%, with clear descriptions for page, limit, and proxy_id parameters. The description itself adds no parameter-level information, so the baseline of 3 applies.
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 'List saved proxy configurations' uses a specific verb and resource, clearly identifying the tool's function. It is distinct from proxy_create and other sibling list tools, though it does not explicitly name or contrast alternatives.
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 proxy_create or other listing tools. The description only states the action, leaving usage context to be inferred.
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 behavioral disclosure. It only states that a new group is created, omitting important behavior such as duplicate name handling, permissions required, side effects on existing profiles, or what the response contains.
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 efficient sentence with no filler. The action and resource are front-loaded, making it appropriately sized for such a simple tool.
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 two-parameter create tool, the schema and description are sufficient for basic invocation. However, the lack of output schema and behavioral details leaves gaps, such as what happens on duplicate group names and what data is returned after creation.
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 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter meaning beyond the schema, but no compensation is needed given full schema coverage.
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 'Create a new profile group' uses a specific verb and resource, making the tool's purpose immediately clear. It naturally differentiates from sibling tools like group_list and group_update, which cover listing and updating groups.
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 such as profile_create or group_update. There are no prerequisites, exclusions, or conditions stated, so the agent must infer usage entirely from the name and minimal description.
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. 'Move' implies mutation and reassignment, but the description does not state whether profiles are removed from their current group, whether the operation is reversible or idempotent, or what happens if a profile is already in the target group. These are meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler words. Every word earns its place, and the core action is immediately visible.
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 simple two-parameter tool, the description plus fully documented schema is nearly sufficient, but the absence of annotations and behavioral side-effect disclosure makes it only minimally complete. An agent can invoke it correctly, but may not fully understand the consequences of moving profiles.
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 100%, with both profile_id and group_id clearly described in the input schema. The description itself adds no parameter-level meaning beyond the schema, so the baseline 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 uses a specific verb and resource: 'Move profiles to a different group.' It clearly states the tool's core action. However, it does not explicitly differentiate itself from sibling tools like profile_update or group_update, so it falls short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when profiles need to be reassigned to another group, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. There is no mention of prerequisites such as the target group needing to exist or whether this is preferred over profile_update for group changes.
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 merely restates the action implied by the name and gives no information about side effects, idempotency, error conditions, or what happens to the profile's state after stopping.
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 with no wasted words. It states the action and the target resource directly, which is appropriately concise for a simple stop operation.
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 no annotations, no output schema, and all parameters optional in the schema, the description is too thin. It does not clarify that a profile identifier is likely required, what happens if the profile is not running, or what response is expected. An agent could attempt to call the tool with no arguments.
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 100%, and both parameters have clear descriptions ('Profile public ID' and 'Profile serial number'). However, the tool description adds no extra meaning about how these parameters should be used, such as whether one is preferred or whether both are acceptable.
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 uses a specific verb and resource: 'Stop a running browser profile.' It clearly distinguishes the tool from siblings like browser_start and browser_active, leaving no ambiguity about its core purpose.
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 'Stop a running browser profile' implies the tool should be used when a browser profile is active, but it provides no explicit guidance on prerequisites, when not to use it, or alternatives. The usage context is clear only by inference from the action word 'stop.'
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 behavioral disclosure burden. It discloses that deletion is a soft delete to trash, indicating recoverability, but it does not mention effects on running profiles, permission requirements, or failure handling.
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?
A single concise sentence conveys the core action and the critical qualifier in parentheses without any wasted words. The information is front-loaded and easy to parse.
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?
Adequate for a simple one-parameter delete operation; the soft-delete note addresses the main safety concern. However, with no annotations or output schema, details about side effects on active browsers and success/failure behavior are missing, though the simplicity of the tool keeps the gap modest.
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 description already fully documents profile_id as an array of profile IDs with max 100 items. The tool description adds no parameter-specific meaning, so the baseline 3 applies due to high schema coverage.
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 ('Delete browser profiles') and adds a key behavioral qualifier ('soft delete to trash'). This clearly distinguishes it from siblings like profile_delete_cache and makes the operation unambiguous.
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 given on when to use this tool versus alternatives such as profile_delete_cache. The action is self-evident, but the description does not state prerequisites, exclusions, or conditions for selecting this tool over 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 bears the full burden. It only states the action and search option, but does not disclose pagination behavior, search matching semantics (exact vs. substring), sorting, or response format. The read-only nature is implied by 'List' but never stated.
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 one compact sentence with no filler. The core operation is front-loaded and every word contributes meaning.
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 simple listing tool with fully documented optional parameters, the description is mostly complete. The only gap is that without an output schema, the returned group object structure and pagination response are not described, but this is minor given the tool's simplicity.
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 100%, so the schema fully documents page, page_size, and group_name. The description adds little beyond confirming group_name is an optional search field, which the schema already implies. Baseline 3 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 uses a specific verb ('List') and resource ('profile groups') and mentions an optional name search. This clearly distinguishes it from siblings like group_create, group_update, and profile_list, which operate on different resources or actions.
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 purpose implies when to use it: when you need to browse or search profile groups. However, there is no explicit guidance about when not to use it or which alternative to prefer, such as profile_list for profiles or group_create for creating groups.
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. Saying 'List' conveys a non-destructive read operation, which is useful, but it does not disclose return format, result limits beyond pagination, or any constraints such as whether deleted/hidden profiles are excluded.
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 with no filler. It names the verb, resource, and two key capabilities without redundancy.
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 simple list tool the description is functionally adequate, but it omits any statement about return values, which matters because no output schema is provided. It also does not contrast with sibling list tools, leaving the agent to infer context.
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 has 100% description coverage and documents all seven optional parameters, so the baseline is met. The description adds only a generic mention of pagination and filtering, providing no parameter-specific 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 begins with the specific verb 'List' and identifies the resource as 'browser profiles', making the operation unambiguous. It is clearly distinct from sibling tools such as profile_create, profile_update, and proxy_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving profiles and supports pagination/filtering, but it does not state when to prefer it over alternatives or when not to use it. Usage must be inferred from the tool name and the straightforward verb.
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 behavioral burden. It usefully discloses that cookies may come from a running browser via CDP or from local files, which is beyond the schema. However, it does not mention whether the operation is read-only, what happens if the profile is not running or files are unavailable, or any permission/state requirements.
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, well-structured sentence with no filler. The main action is front-loaded, and the clarifying parenthetical about sources adds valuable information without bloat.
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 simple one-parameter getter with no output schema, the description is largely complete: it names the action, the target, and both access methods. It omits details about return format and failure behavior, but these are less critical given the simplicity of the tool and the fully documented schema.
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 description covers 100% of the parameters, so the baseline is 3. The description adds context that profile_id refers to 'a browser profile' and explains the source modes, but it does not add significant new semantics beyond what the schema already states.
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 uses the specific verb 'Get' with the resource 'cookies from a browser profile', making the tool's function unmistakable. It also details two distinct data sources (running browser via CDP, or local files), which clearly separates it from all sibling tools focused on groups, proxies, browsers, and profile management.
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 retrieving cookies and mentions the two possible sources, but it does not explicitly state when to use this tool over alternatives or any exclusions. For a tool with no cookie-related sibling, the usage context is somewhat inferred rather than explicitly defined.
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 behavioral burden. It clearly discloses the destructive nature of the operation and names data categories that get destroyed, but it does not mention permanence, side effects like forced logout, or any required conditions.
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 with no filler. It communicates the action, resource, and scope efficiently while the examples remain useful.
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 two-parameter tool with a fully documented schema, the description plus schema are sufficient for an agent to construct a valid call. Information about return values or side effects is absent but not necessary for correct invocation.
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 100%, so the schema already documents both profile_id and type with enum values. The description repeats some enum items ('cookies', 'history', 'localStorage') but adds no additional semantic value 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 uses a specific verb ('Delete') and resource ('cached data for browser profiles') with concrete examples. It clearly distinguishes this from siblings like profile_delete (deleting entire profiles) and profile_cookies (cookie-related operations).
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 that the tool is used when cache data must be cleared, but it does not explicitly state when to use it versus alternatives such as profile_delete or profile_update. No exclusions or prerequisites like stopping the browser are mentioned.
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 clearly indicates a read-only listing operation and reveals that WebSocket endpoints are part of the output, which adds value beyond the tool name.
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?
A single, front-loaded sentence conveys the core behavior and output key detail without any wasted words. Every part of the description earns its place.
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 simple list tool with one optional parameter and no output schema, the description adequately explains what the tool does and what the result includes. It could be slightly more explicit about how this relates to sibling tools like profile_list, but nothing essential is missing.
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 already fully documents the only parameter, profile_id, with a clear description ('Filter by specific profile ID'). The tool description itself adds no additional parameter semantics, but schema coverage is 100%, so the baseline of 3 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 uses a specific verb ('List') and resource ('currently running browser profiles') and adds a distinguishing detail ('WebSocket endpoints') that separates it from sibling tools like profile_list. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently running' provides clear context for when to use this tool, distinguishing it from tools that list all profiles or manage browser state. However, it does not explicitly name alternatives or state 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.

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

FireKey MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![FireKey MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/partnerhbhl/firekey-mcp/badges/card.svg)](https://glama.ai/mcp/servers/partnerhbhl/firekey-mcp)

Score Badge

Copy to your README.md:

[![FireKey MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/partnerhbhl/firekey-mcp/badges/score.svg)](https://glama.ai/mcp/servers/partnerhbhl/firekey-mcp)