camoufox-research

by aidvizhhub

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools blur together: web_search vs research (both search, difference is orchestration), fetch_page vs browser_navigate vs batch_fetch (all return page text), and extract_links vs session_links overlap. browser_* vs session_* stateless/stateful boundary is subtle and only made clear by reading paragraphs of Russian text.
Naming Consistency3/5
Consistent snake_case and a strong, predictable session_* family (start/navigate/click/type/scrool/links/text/back/status/end). However, two conventions mix: verb_noun (fetch_page, extract_links, ping) vs noun_verb (browser_navigate, session_start, web_search), and some session_* items name objects (text, links, status) rather than actions.
Tool Count3/5
19 tools sits in the heavy range above the typical 3-15 sweet spot. The count is defensible because stateful browsing genuinely needs ~10 session/browser tools, but combined with the one-shot fetch/search tools it feels heavier than necessary and edges into the 16-25 borderline zone.
Completeness4/5
The full research workflow is well covered: search (web_search, research), fetch (fetch_page, batch_fetch), interact (browser_click/type), stateful session lifecycle (start→navigate/click/type/scroll→end), link extraction, and health check. Minor gaps remain: no schema/structured extraction tool, no status-code/header inspection, and no explicit wait-for-element tool, but all core journeys are unblocked.
Average 3.6/5 across 19 of 19 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 provided, the description carries the full burden of disclosing behavior. It mentions only the output, not side effects like changing the browser's current page, potential wait times, or error behavior. This is a significant gap for a navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than appropriately concise. It lacks essential details about the tool's operation and parameters, making it insufficiently sized for effective use.
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?
Even with an output schema present, the description omits critical contextual information such as side effects, relationship to siblings, and parameter usage. For a navigation tool with many similar siblings, this is inadequate.
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%, and the description does not compensate. While 'first links' hints at the purpose of max_links, it does not explain the parameters or their format. The url parameter is completely undefined in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Page text + first links' gives some indication of what the tool returns, but does not explicitly state that it navigates the browser to a URL. It fails to distinguish from siblings like fetch_page or extract_links, which likely have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 session_navigate or fetch_page. The description offers no context for selecting this tool over others.
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?
The tool has no annotations, and the description says only that it 'collects' links. It does not state whether it dereferences URLs directly, whether it only returns raw HTML, what filtering does at the structure level, or any network side effects. The description is under-specified for safe and low-level behavior on a network; the tool can drag the agent.
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?
One concise sentence, front-loaded with the action, directly follows the resource and parameters. 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 accepts 3 parameters and 1 required; the output schema is present, which helps, but descriptions give no return format or handling. The description is still weak: it fails to note the probable return of a list of URLs, does not cover relative/oblique links, handling of exceptions, or behavior with 'max_links' and limitations. Among sibling drivers, extraction lacks explicit conditions, so the context is incomplete.
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% coverage and no enum values. The description names the url parameter and muddles through the pattern as substring filtering, but it leaves max_links undocumented and gives no format for the pattern or maximum-links semantics. The description fails to compensate for the lack of structured schema data to make a parameter viable.
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 'Collects page links (filter by substring pattern)' clearly identifies a link-extraction verb and resource, and the required 'url' parameter indicates the target page. However, it does not contrast this with sibling tools like web_search or fetch, so some ambiguity about when to choose this over those remains.
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 explicit when-to-use guidance is given, and no alternative tools are mentioned. The filtering behavior is implied but not formalized, leaving it to the agent to infer when link-extraction is preferable to a search, fetch, or browser navigation.
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 bear the full burden of behavioral disclosure. It only mentions the session_start prerequisite, which is a precondition rather than a behavior. It offers no information about read-only status, output format, error conditions, or side effects.
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 with no redundant words or filler. It states the core purpose and a key prerequisite efficiently, achieving high conciseness and front-loading.
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?
Although an output schema exists (so return format is covered), the description is too sparse for a tool with one optional parameter and no annotations. It omits the meaning of max_links and fails to mention any error conditions, edge cases, or how it differs from similar tools. The prerequisite is noted, but the overall context is incomplete.
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 the max_links parameter at all, and the schema provides only type and default with no explanatory text. With 0% schema description coverage, the description completely fails to explain the parameter's meaning or usage, leaving the agent to infer it from the parameter name.
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 identifies the resource (links) and context (current session page) but lacks an explicit verb such as 'get' or 'list', making it slightly less direct. It distinguishes from sibling tools like extract_links by specifying the session context, so the purpose is still unambiguous.
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 mentions 'Requires session_start', which implies it should be used after starting a session, but it does not explicitly contrast with alternatives like extract_links or state when not to use it. This provides some context but no direct usage guidance 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 mentions the session_start prerequisite but does not explain what the tool returns, how far back it goes, whether it mutates navigation state, or what happens at the beginning of history.
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 short and front-loaded, with no wasted words. It earns its place by conveying purpose and a prerequisite, though it could expand slightly on behavior without becoming verbose.
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 single-parameter tool with no annotations and no parameter explanation, this description is insufficient. It correctly identifies the purpose and prerequisite but leaves the tool's behavior and max_chars semantics unexplained, making confident invocation difficult.
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 only parameter, max_chars, has 0% schema description coverage and is not mentioned in the description. The agent cannot infer what max_chars controls, such as output truncation or result size, which is essential for correct invocation.
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 action: navigate backward through the session tab history. It uses a specific verb ('back') with a clear resource ('session tab history') and distinguishes itself from sibling navigation tools like session_navigate or browser_navigate.
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 explicitly states a prerequisite: 'Requires session_start.' This gives useful context about when it can be used, but it does not mention when not to use it or compare it to alternatives such as browser_navigate or session_navigate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says that input is performed and that session_start is required; it does not mention side effects, error conditions, page state requirements, or what happens with the max_chars limit. The behavioral transparency is thin.
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 with no filler. It front-loads the action and then gives the prerequisite. Every sentence contributes useful information, making it appropriately concise.
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 that an output schema exists, return values are covered elsewhere, and the description names the action, selector mechanism, and dependency on session_start. However, there are no annotations and no parameter descriptions, so the agent is left guessing about max_chars, failure modes, and target visibility. The description is minimally viable but not complete.
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 explain the parameters. It does clarify that selector is a CSS selector and implies text is the value being entered, but it does not explain max_chars or provide additional detail for text beyond the schema. This is only partial compensation.
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: entering text into a field on a live session page using a CSS selector. It also names the required prerequisite, session_start. However, it does not explicitly distinguish this from sibling tools like browser_type or session_click, so it falls just 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one usage constraint: 'Requires session_start.' This implies it should be used only within a live session, but it does not explain when to choose this tool over alternatives or provide exclusions. The prerequisite provides some guidance, but no when-not-to-use context.
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 burden. It discloses that a session must be started ('Требует session_start') and clarifies that the tool does not navigate ('без навигации'), which implies a read-only, non-destructive action. However, it does not describe error conditions, return format (though output schema exists), or any side effects. It adds some useful behavioral context beyond the name.
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, compact sentence that front-loads the tool's primary purpose. There is no fluff or redundant wording. It is appropriately sized for a simple tool, though it leaves out optional parameter details. It earns its place but is not overly verbose, so it scores high but not perfect due to missing essential context.
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's simplicity (1 parameter, no annotations) and the existence of an output schema, the description covers the core function and prerequisite. However, it omits any explanation of the max_chars parameter and does not mention what happens if no session is active. While the output schema likely defines the return format, the description is not fully complete for an agent to invoke the tool correctly, especially regarding parameter usage.
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 description coverage is 0%, meaning the description does not explain the parameter max_chars. The parameter name is somewhat self-explanatory, but the description adds no meaning about its purpose, limits, or how it affects the output. With a single parameter and no description, the agent has to guess its semantics, so the description fails to compensate for the lack of schema documentation.
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 returns the text of the current session page, and the phrase 'без навигации' (without navigation) distinguishes it from navigation-related siblings like session_navigate or fetch_page. The verb is implicit ('get') but the resource is specific. It does not explicitly name alternative tools, but 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to retrieve the text of the current session page. It also specifies a prerequisite (requires session_start), which is a usage condition. However, it does not provide guidance on when to use this tool versus alternatives like session_links or fetch_page, nor does it mention exclusions. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior independently. It mentions that navigation occurs in the current tab without opening a new page and specifies the session_start prerequisite, but it does not clarify side effects (e.g., page content replacement), return behavior, or potential errors. Some transparency exists but is incomplete.
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: two short sentences in Russian that immediately state the core functionality and a key prerequisite. No filler or redundant information is present, and critical information is front-loaded.
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?
Although an output schema exists, it is not shown, so the description must stand on its own. The description omits any mention of return values, waiting behavior, or error handling. For a navigation tool within a session, knowing whether it returns page content or just confirmation is essential. Thus, while the tool is simple, the description is not fully complete.
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% – neither parameter (url, max_chars) is explained. The description only hints at the URL parameter implicitly through the tool's purpose, but max_chars is completely unspecified, leaving the agent to guess its meaning (likely character limit for response). This fails to compensate for the low 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 clearly states the tool's purpose: navigating to a URL in the current tab of an existing session, explicitly noting that it does not open a new page. This differentiates it from browser_navigate and aligns with session_* 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 only usage guidance is the prerequisite 'Requires session_start,' which is useful but does not provide explicit comparison with alternative tools like browser_navigate or explain when to prefer this over other navigation methods. No conditions or exclusions are given.
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 transparency burden. It usefully discloses that the tool waits for lazy content to load ('Ждёт догрузку lazy-контента') and requires session_start. However, it does not explain whether scrolling is incremental or absolute, how max_chars affects behavior, or what happens if the session is no longer active.
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 and every sentence earns its place: what the tool does, one behavioral nuance (lazy-content waiting), and a prerequisite. It is front-loaded and has no redundant 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?
An output schema exists, so the return shape may be covered elsewhere. The description adequately captures purpose, prerequisite, and lazy-loading behavior, but the unexplained max_chars parameter and lack of annotations leave a meaningful gap in what an agent needs to invoke the tool confidently.
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 prose description must supply parameter meaning. It adds some value by listing 'bottom/top/down/up', which clarifies the direction parameter. However, max_chars is completely unexplained, and the description does not formally map any of its prose to the schema properties, leaving the agent guessing about a key parameter.
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: 'Скролл на живой странице сессии' (scroll on the live session page) and enumerates the direction values bottom/top/down/up. It distinguishes session_scroll from nearby session_navigate/session_text tools by focusing specifically on scrolling, though it does not explicitly contrast itself with alternative 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 prerequisite: 'Требует session_start' (requires session_start), and scopes the tool to the live session page. It does not state when not to use it or name alternatives, but the context is sufficient for an agent to understand that this tool operates only on an already-started live session.
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 must carry the burden. It includes the core actions (open, input, return) and notes the returned page is updated. Missing details about failure handling, prerequisites, or side effects, but the description is not misleading and basic behavior is disclosed.
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 concise (two sentences) and front-loaded, mentioning the primary action first. It wastes no words but could benefit from slightly turning the purpose claim into a fuller explanation without bloat.
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's simplicity, the description is adequate: it conveys the purpose and primary behavior. The presence of an output schema covers return-format details, so the description reasonably omits those. However, it is thin on potential caveats (e.g., JavaScript dependency, selectors must be visible/animated) that would make it robust.
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 only lists 3 parameters with 0% coverage, forcing the description to clarify meaning. It interprets 'selector' as a CSS selector and 'text' as the input content, but does not describe URL format or specificity. This partial clarification improves on schema but leaves some ambiguity.
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 opens a URL, types text into a CSS-selector field, and returns the updated page. It specifies the use case (search forms) and distinguishes from sibling tools like browser_navigate (navigation only) and browser_click (click only), making the purpose unambiguous.
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 mentions it is for search forms, giving a clear context for use. However, it lacks explicit when-not-to-use guidance or references to alternative tools like session_type. The instruction is functional but does not frame usage in relation to other available options.
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 exist, so the description bears the full transparency burden. It does honestly disclose the key behavioral trait — state persists across commands like a real person's browser tab. However, it omits meaningful behavioral caveats: resource cost/latency of spinning up a live session, what happens if a session already exists, whether only one session can be active, timeout behavior, or any rate limits. The description is accurate but not rich enough for the resource-heavy operation it describes.
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 compact and front-loaded: purpose first, then state semantics, then forward/backward commands, then status. Three short sentences accomplish a lot with no real waste. The only minor ding is that the forward-slashed list of command names, while informative, becomes a bit dense and could have been structured more cleanly.
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 stateful session-management tool, the description explains the lifecycle very well (start → interact → close/status) and intentionally doesn't need to explain return values since an output schema exists. However, it misses critical stateful details such as single-session semantics, re-entry behavior if called twice, or consequences of forgetting session_end. These gaps matter for a stateful, potentially resource-leaking tool, so the description is adequate but incomplete.
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?
With 0% schema coverage, the description had to compensate for the two parameters. It only implicitly covers 'url' via 'opens URL,' and it's completely silent on 'max_chars' (a non-obvious parameter whose default of 6000 is unexplained). It also doesn't clarify why both parameters are optional or what the default behavior is when URL is omitted. The description adds no real meaning for the parameters the schema marks as optional.
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+resource construction — 'Starts a LIVE session: opens URL in persistent tab of serve-worker' — and clearly differentiates itself from sibling tools by emphasizing persistent state across commands (scroll, input, clicks live between commands, 'like a human in one tab'). This distinguishes it from stateless siblings like fetch_page and browser_navigate, and it clearly states the session-scoped resource it manages.
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 explicit workflow context: it names the follow-up commands (session_navigate, session_click, session_type, etc.), the close command (session_end), and the status command (session_status), essentially teaching an agent the usage lifecycle. However, it never explicitly contrasts this with the stateless alternatives (e.g., 'use fetch_page for one-shot reads') or states when NOT to use a session, so it stops short of full when/when-not coverage.
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?
Discloses caching behavior (one-day cache) and that article_only uses Trafilatura with fallback to entire body. With no annotations provided, these details partially cover behavioral traits, though side effects like errors or rate limits are not mentioned.
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?
Two concise sentences convey key information without redundancy. The structure is clear, including a brief parameter explanation, making it efficient and easy to scan.
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?
While the output schema exists (so return format need not be described), the description provides useful operational context like caching and extraction behavior. It omits error handling or edge cases, but overall it is sufficiently complete for a simple fetch 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 description explains the article_only parameter (true yields article text via Trafilatura, fallback to body), but does not clarify url or max_chars. Schema coverage is low, so the added meaning for one parameter adds some value but leaves others 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: extracting page text without HTML junk, targeting articles/docs/README. It also notes caching and the optional article_only mode, making the purpose specific and distinct from sibling browser tools.
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 explicit guidance on when to use this tool versus alternatives like browser_navigate or web_search. The description implies it is for getting clean text content but does not contrast with sibling tools or specify scenarios.
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?
The description discloses a behavioral side effect ('resets state') beyond the name. However, it does not elaborate on consequences such as irreversibility, impact on other sessions, or whether the entire browser closes, and there are no annotations to fill this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, compact sentence that conveys both the primary action and a side effect without any wasted 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 zero-parameter, simple tool with an output schema present, the description covers the essential behavior. It could clarify whether it closes just the current tab or the entire session, but overall it is sufficient.
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?
With zero parameters, the input schema is trivially 100% covered. The description does not need to explain parameter semantics, and the baseline for 0 params is 4.
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 action ('closes') and resource ('session tab'), and additionally notes that it resets state. This distinguishes it from sibling tools like session_back or session_status, which have different purposes.
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 explicit guidance on when to use this tool versus alternatives. It does not mention typical scenarios, prerequisites, or exclusions, so an agent must infer usage from the name alone.
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?
The description discloses that it uses an anti-detect browser and that results are cached for a day, which is useful transparency. However, it does not mention potential rate limits, errors, or that it is a read-only operation. With no annotations, the description carries the burden, and it provides some but not comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a compact format that conveys essential details (search engine, anti-detect, output fields, pagination, snippets, caching) without unnecessary fluff. Every word adds value.
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?
The description gives enough context for a search tool: it indicates the output format (number, title, URL) and caching behavior. It does not specify return schema details but that is not required since the output schema is not provided. Overall, it covers necessary aspects for a basic search operation.
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 description explains pages (pagination for more URLs) and include_snippets (snippet under each URL), adding meaning beyond the bare schema. Query and max_results are self-explanatory. Since schema coverage is 0%, this description compensates well for two of the four 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 clearly states the tool performs a search in DuckDuckGo via an anti-detect browser, which is a specific action on a specific resource. It distinguishes itself from sibling tools like fetch_page and browse by focusing on search rather than page fetching.
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 does not explicitly state when to use this tool over alternatives. It mentions pagination and snippet options but lacks context such as 'use when you need general web search results' or comparisons with other browsing tools. This is a significant gap given the many sibling tools.
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?
The description transparently discloses the core actions (opening URL, clicking, returning the page) and provides an example. However, it fails to explain the behavior associated with the `max_links` parameter or any side effects, which is a gap given the lack of annotations.
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 highly concise, using two short sentences and a clear example. It is front-loaded with the action and leaves out any unnecessary detail, making it 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?
While the main functionality is well described, the presence of the `max_links` parameter and the existence of session-based sibling tools suggest additional context is needed for complete understanding. The description does not address these aspects, leaving some questions about edge cases and tool selection.
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 adds crucial meaning to `selector` and `target_text`, and implies the role of `url` in the example, but it completely ignores `max_links`. Since the schema has 0% coverage (no parameter descriptions), the description only partially compensates for the missing information.
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 it opens a URL and clicks an element using either a CSS selector or link/button text, which precisely defines its purpose. This differentiates it from sibling tools like browser_navigate or session_click by focusing on the specific click action.
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 usage context is implied through the example and description, but there is no explicit guidance on when to use this tool over alternatives like session_click or browser_navigate. It lacks any mention of alternatives or exclusions, so it's only partially helpful for an agent deciding between tools.
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 transparency burden. It discloses the return behavior ('Возвращает текст ПОСЛЕ клика') and the session_start requirement, but does not cover side effects, waiting behavior, or failure modes. It is adequate but not rich.
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 compact, front-loaded with the main action, and every clause adds value: target methods, return behavior, and prerequisite. No wasted 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 simple click tool, the description covers the core essentials: what to click, how to specify the target, what is returned, and the session prerequisite. An output schema exists, so return-value details are not required in the text. It could be stronger with explicit alternatives to browser_click, but remains sufficient.
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?
Schema coverage is 0%, so the description must compensate. It meaningfully explains selector with a concrete CSS example and clarifies target_text as link text. However, max_chars is not mentioned in the description, though its title and default provide some inherent meaning.
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 action: 'Клик на живой странице сессии' (click on a live session page), specifies two targeting modes (CSS selector or link text), and notes it returns text after the click. This separates it from generic browser tools like browser_click by anchoring it to the session context.
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 prerequisite ('Требует session_start') and explains how to choose between selector and target_text. It does not explicitly name alternatives or exclusions, but the session-specific framing and requirement provide enough contextual guidance.
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, the description must carry behavioral context. It indicates a read-only status check (no mutating actions) and lists the data points (URL, title, tab alive). This is adequate for such a simple query, though it doesn't explicitly state it has no side effects or mention failure modes.
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 fully conveys the tool's purpose. It is front-loaded and free of fluff, earning a perfect score.
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 status check with no parameters, the description covers the key output fields (URL, title, tab liveness). It doesn't mention potential edge cases (e.g., what happens if no session exists), but the output schema likely clarifies that. Given the simplicityainer, this is complete enough.
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)Skip. With no parameters to explain, the baseline is 4. The description adds no additional parameter semantics since none exist, which is appropriate. Schema coverage is 100% (vacuously).
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 reports session status including URL, title, and tab liveness. This is specific and distinct from sibling tools like session_navigate (navigation), session_text (page text), or session_links (links).
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 checking session state but does not explicitly mention when to use it instead of other session tools (e.g., session_text for content, session_links for URLs). No exclusion criteria or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 caching (already visited URLs return instantly), rate limiting to avoid captchas, parallelism for batches ≥8, auto-detection of workers, and the return format with separators. It also explains article_only extraction via Trafilatura. This is rich behavioral detail that significantly aids agent decision-making.
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 dense but well-structured: purpose first, then cache, rate limit, parallelism, return format, article_only, and an example. Every sentence adds value, though it could be slightly more concise by integrating the max_chars explanation more explicitly.
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 complex tool with 4 parameters and no annotations, the description covers caching, rate limits, parallelism, output format, and article extraction. It lacks explicit explanation of max_chars and error handling, but overall it is sufficiently complete for an agent to use it effectively, especially with an output schema present.
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 0%, so the description must explain all parameters. It explains article_only and max_parallel explicitly, and urls implicitly, but max_chars is only shown in the example and not defined. This leaves a gap for one of the four parameters, though the example provides some contextual clue.
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 it opens multiple URLs in a single browser for deep research, contrasting with single fetches. It uses a specific verb (opens) and resource (URLs), and distinguishes from siblings like fetch_page by emphasizing batch use for 30-50 sources.
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?
It implies when to use: for deep research on many sources in one call instead of a series of cold starts. It contrasts with single fetch, but does not explicitly name alternatives or exclusions. The context is clear enough that an agent would know to prefer this for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does well: it discloses URL deduplication, snippet returns, parallel article fetching with auto resource allocation and max_parallel limits, and 24-hour caching. It also notes the gpt-researcher quick_search pattern, adding useful behavioral context beyond the schema.
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 compact and front-loaded with the core purpose ('Deep-поиск ОДНИМ вызовом'), followed by parameter explanations and a concrete example. Every sentence adds value, and the structure is easy to scan despite being information-dense.
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 6-parameter tool with no annotations, the description covers the main workflow, caching, deduplication, parallel fetching, and return shape (snippet list). However, it misses semantics for two parameters (max_chars, article_only) and does not mention error cases or edge behavior; the presence of an output schema reduces the need to describe return values.
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 0%, so the description must compensate. It explains queries (multiple formulations, agent plans subqueries), fetch_top (read top-N sources), and max_parallel (explicit limit), but leaves max_chars and article_only semantically unexplained, and max_results_per_query appears only in the example without clarification.
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 the tool performs deep web search in a single call, taking multiple query formulations, deduplicating URLs, returning snippets, and optionally fetching top-N source texts. This clearly distinguishes it from siblings like web_search or fetch_page by emphasizing multi-query planning, deduplication, and integrated fetching.
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 frames this as 'deep search in one call' and says the agent itself plans subqueries, making it clear when to use it for multi-angle research instead of repeated single searches. It provides a concrete example, but does not explicitly state exclusions or name alternative tools for cases where this tool is not appropriate.
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?
No annotations are provided, so the description bears the full burden. It explicitly discloses the observable behavior: it returns 'pong'. It implies a no-side-effect check, though it does not discuss failure modes or latency; for such a simple tool this is adequate.
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 short, front-loaded sentence. Every word contributes, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's trivial complexity, zero parameters, and presence of an output schema, the description fully covers the tool's purpose and behavior. Nothing else is necessary.
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 the baseline is 4. The description adds no parameter details, but none are needed.
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 clear, specific action ('Проверка связи' – connectivity check) and its exact result ('возвращает pong'). This unambiguously identifies the tool and differentiates it from all sibling tools, which perform search, research, fetching, or browser automation.
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 'Проверка связи' provides clear context: this is a connectivity/liveness check. No explicit exclusions or alternatives are stated, but for a zero-parameter health-check tool, this is not a meaningful gap.
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:

[![camoufox-research MCP server](https://glama.ai/mcp/servers/aidvizhhub/camoufox-research/badges/card.svg)](https://glama.ai/mcp/servers/aidvizhhub/camoufox-research)

Score Badge

Copy to your README.md:

[![camoufox-research MCP server](https://glama.ai/mcp/servers/aidvizhhub/camoufox-research/badges/score.svg)](https://glama.ai/mcp/servers/aidvizhhub/camoufox-research)

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/aidvizhhub/camoufox-research'

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