Chromate MCP

by 69gg

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct browser automation action: tab management, page info, screenshots, clicking, scrolling, typing, key presses, and waiting. There is no overlap or ambiguity in their intended purposes.
Naming Consistency4/5
Most tools follow a verb-first snake_case pattern (list_tabs, select_tab, screenshot, click, scroll, type_text, press_key, wait), but page_info is a noun phrase and slightly breaks the pattern. Overall the naming is predictable and readable.
Tool Count5/5
Nine tools is well within the ideal range for a browser automation server. Each tool covers a necessary action without being redundant or overwhelming.
Completeness4/5
The set covers tab selection, page inspection, screenshots, input actions, and waiting—core browser interactions. The most obvious gap is navigation (e.g., goto_url) and richer page content access, but agents can work around these limitations by relying on existing tabs.
Average 3.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states that it lists tabs. It does not explain what 'available' means (e.g., includes internal tabs), whether it is read-only, or any side effects. The parameter includeInternal hints at a behavior but is not addressed.
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 sentence with no unnecessary words, front-loading the core action and resource. It earns its place and is highly 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?
Despite the tool's simplicity, the description is incomplete. It lacks context on the CDP endpoint, the meaning of includeInternal, and the return format (no output schema). The absence of annotations further reduces completeness, as the agent cannot determine safety or behavioral implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (includeInternal) with 0% description coverage, and the tool description does not mention this parameter at all. The description fails to add any meaning to the parameter, forcing the agent to guess what 'internal' refers to in the context of Chrome tabs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'List' and a distinct resource 'Chrome tabs available through the configured CDP endpoint'. This distinguishes it from sibling tools like select_tab or page_info, which perform different 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 provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or contrast with sibling tools such as select_tab or page_info, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action and coordinate reference, but omits whether the operation is read-only, what the return format is, or any side effects. The phrase 'CSS viewport pixel coordinates' adds some precision but insufficient transparency for a tool with no other behavioral metadata.
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 sentence that is efficiently worded and front-loaded with the core action. Every word adds value; there is 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 two parameters, no output schema, and no annotations, but the description does not explain the return value, parameter behavior, or usage context. It is too sparse to fully support an agent in selecting and invoking the tool correctly, especially without schema-level descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, it never mentions 'overlay' or 'crosshair' or how they relate to the capture. The description fails to add meaning beyond the raw schema, leaving the agent without semantic understanding of the parameters.
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 ('Capture') and identifies the resource ('selected tab viewport') with a technical detail ('using CSS viewport pixel coordinates'). It clearly distinguishes the action from sibling tools like click or scroll, leaving no ambiguity about what the tool does.
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 or how it compares to alternatives. There is no mention of scenarios like visual verification or when a screenshot is preferred over other operations, so the agent receives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure, but it only states the action and target. It does not mention whether scrolling is relative to the viewport, what happens if no tab is selected, or any side effects. The absence of safety or mutation details leaves the agent underinformed.
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 that is concise and to the point. However, it omits parameter details and usage context, making it less complete than ideal for a tool with four 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?
Given the four parameters, no annotations, and no output schema, the description is too minimal to be fully usable. It fails to explain coordinates, delta semantics, or the required context of a selected tab, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining the parameters, but it does not. The schema lists x, y, deltaX, and deltaY without descriptions, and the tool description only mentions 'mouse wheel event' without adding meaning to these fields.
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 dispatches a mouse wheel event in the selected tab, using a specific verb and resource. This distinguishes it from sibling tools like click and press_key, which target different input types.
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 scrolling via mouse wheel events and requires a selected tab, but it does not explicitly state when to use it versus alternatives like click or press_key. No exclusions or alternative guidance is provided, leaving usage to be inferred.
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 transparency burden. It adds useful context by specifying that the tool dispatches a keyDown/keyUp pair (not just a key press) to the selected tab. However, it lacks details about target focus, whether special keys are supported, or any side effects. This is adequate but not fully transparent.
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 is well front-loaded with the action verb 'Dispatch.' Every word contributes meaning, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one parameter and no output schema, so the description does not need to explain return values. It covers the core behavior and target. However, the absence of usage guidelines and parameter semantics leaves gaps, especially given the lack of annotations and schema coverage. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanation, but it does not. The parameter 'key' is named clearly, but the description does not clarify accepted formats (e.g., single character vs. key names like 'Enter'), case sensitivity, or how to specify combinations. The minimal schema only indicates a non-empty string.
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 action: 'Dispatch a keyDown/keyUp pair to the selected tab.' It uses a specific verb and resource, indicating what the tool does. While it doesn't explicitly differentiate from siblings like type_text or click, the task is distinct enough (keyboard key press) to be understood.
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 about when to use this tool versus alternatives like type_text or click. The description does not mention scenarios where a keyDown/keyUp pair is appropriate, nor does it exclude cases where another tool would be better. Usage must be inferred entirely from the tool name and 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 must carry full behavioral disclosure. It mentions two wait conditions but omits timeout behavior, default durations, and what happens if conditions are never met. This is a significant gap for a wait operation that could hang.
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, immediately understandable with no wasted words.
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 lack of annotations and output schema, this simple description is insufficient. It doesn't disclose error handling, return values, or what constitutes page stability. For an automation tool, this missing context could lead to operational failures.
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?
The schema has 0% description coverage, and the description only vaguely alludes to the 'text' parameter via 'visible body text'. The timeoutMs parameter is not mentioned at all, leaving the agent to infer its purpose and requirements.
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 'Wait' and identifies two concrete conditions (page stability, visible body text). This clearly distinguishes it from sibling tools like click, scroll, or screenshot.
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, no prerequisites, and no exclusions. The description states what it does but not the context in which it should be invoked.
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 says 'select the active tab' without detailing side effects (e.g., whether it actually activates the tab in the browser), prerequisites (e.g., where to get tabId), error behavior, or the role of the 'activate' parameter. This is a significant gap for a state-changing tool.
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, direct sentence that gets to the point without filler: 'Select the active tab for subsequent Chromate tools.' It is front-loaded with the action and resource, making it easy to scan.
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 2 parameters, 0% schema description coverage, no annotations, and no output schema. The description only conveys the core purpose but leaves out essential usage details like how to obtain tabId (likely from list_tabs) and what the 'activate' parameter does. The context is too sparse for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention either parameter (tabId or activate), and schema description coverage is 0%. Since there are parameters, the description must compensate, but it provides no meaning beyond the raw schema types. The required parameter tabId and optional activate are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Select the active tab for subsequent Chromate tools.' It uses a specific verb ('Select') and resource ('active tab'), and the phrase 'for subsequent Chromate tools' distinguishes it from sibling tools like list_tabs, page_info, or click, which do different operations.
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 clear context by noting this is for 'subsequent Chromate tools,' implying it should be used before other operations. However, it doesn't explicitly state when not to use it or mention alternatives, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Return information' implies a read-only operation, but it does not explicitly state side effects, safety, or what exactly is returned. No mention of permissions, data types, or potential failure modes. This is insufficient transparency.
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 short sentence that immediately conveys the tool's purpose without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description fails to specify what 'information' is returned (e.g., URL, title, viewport dimensions). This leaves a gap in completeness; an agent would not know the exact shape of the response. It is minimally adequate but not fully complete.
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 is empty, so there are no parameter semantics to document. Baseline for 0 params is 4; the description does not need to add parameter details.
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 a specific action ('Return information') and a specific resource ('currently selected page and viewport'). This distinguishes it from sibling tools like screenshot or click, though it does not explicitly name alternatives. It is sufficiently specific to convey its 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 description implies the tool is used when an agent needs information about the current page and viewport, but provides no explicit guidance on when to use it versus alternatives or any exclusions. This is minimum viable guidance, not strong differentiation.
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 disclosure burden. It adds valuable behavioral context: 'then wait and return an after screenshot' and 'CSS viewport coordinates.' However, it omits potential side effects, permission needs, or details about button variants that could affect behavior.
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 packs essential information: the action, coordinate system, scope, wait behavior, and return value. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and result but is incomplete for a tool with 6 parameters. It fails to address button choice, click count, or configuration options beyond wait and screenshot, leaving some aspects uncovered for an agent needing full operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains x/y as coordinates, wait behavior, and the returnScreenshot concept, but it does not describe the 'button' or 'clickCount' parameters, leaving their semantics to the schema's enum/default values without additional 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 a specific action: 'Click at CSS viewport coordinates in the selected tab.' It distinguishes the tool from siblings like scroll or press_key by specifying coordinates and the selected tab context, and adds the unique behavior of waiting and returning a screenshot.
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 for clicking at a location but does not explicitly contrast with alternatives like press_key, type_text, or scroll. It provides clear context (CSS viewport coordinates, selected tab) but no exclusions or when-not-to-use 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 burden of behavioral disclosure. It does add useful context by specifying the target as 'focused element in the selected tab,' implying the element must be focused beforehand. However, it does not disclose whether the text replaces existing content, appends, or has other side effects, leaving some 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, well-structured sentence that directly states the tool's purpose without extra words. It is front-loaded with the action and delivers the key information efficiently.
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 action tool with one parameter and no output schema, the description covers the core context: what is inserted, where it is inserted, and the condition (focused element). It lacks details about return values or error cases, but these are less critical given the low complexity. The description is sufficient for basic use but could mention prerequisites more explicitly.
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 has only one required parameter 'text' with no description, resulting in 0% schema description coverage. Although the description does not explicitly explain the parameter, the tool's name ('type_text') and the parameter name make its meaning obvious. The description provides no additional details about formatting, valid values, or constraints, but the parameter is simple enough that this is 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 clearly states the function: 'Insert text into the focused element in the selected tab.' It uses a specific verb ('insert') and resource ('text') and specifies the location (focused element in selected tab), which effectively distinguishes it from sibling tools that perform other actions like clicking, scrolling, or pressing keys.
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. The description does not mention prerequisites (e.g., needing to focus the element first) or clarify differences from press_key or click. There is no explicit when-to-use or when-not-to-use information.
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:

[![chromate MCP server](https://glama.ai/mcp/servers/69gg/chromate/badges/card.svg)](https://glama.ai/mcp/servers/69gg/chromate)

Score Badge

Copy to your README.md:

[![chromate MCP server](https://glama.ai/mcp/servers/69gg/chromate/badges/score.svg)](https://glama.ai/mcp/servers/69gg/chromate)

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/69gg/chromate'

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