veilbrowser
Server Quality Checklist
Latest release: v1.5.0
- Disambiguation5/5
Each tool targets a specific browser automation action with minimal overlap. For example, 'veil_fill' is for clicking a field and typing, while 'veil_type' is for typing into the focused element, and descriptions clearly distinguish them.
Naming Consistency5/5All tools follow a consistent 'veil_' prefix with a verb or verb_noun pattern, such as 'veil_goto', 'veil_set_viewport', 'veil_wait_for_selector', making the naming predictable and intuitive.
Tool Count4/5With 33 tools, the server covers a broad range of browser automation needs (navigation, interaction, extraction, resource control, etc.), which is appropriate for its comprehensive scope, though slightly on the higher side.
Completeness4/5The tool set covers most essential browser automation operations, including navigation, interaction, data extraction, resource blocking, fingerprinting, and screenshots. Missing features like dialog handling are minor and do not hinder typical workflows.
Average 4/5 across 33 of 33 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 84 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description omits behavioral traits: what happens if no element is focused, whether it clears existing text, how special characters are handled, or if it is blocking/asynchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is incomplete: lacks usage context, behavioral notes, and parameter semantics. It serves only as a minimal header.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only mentions 'text' without explaining format, allowed characters, or behavior. It adds no value beyond the schema's type 'string'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text into the currently focused element' clearly identifies the verb (type) and resource (focused element). It distinguishes from siblings like veil_click and veil_fill, but does not clarify its difference from veil_text, which is a near-sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., veil_fill for form fields, veil_press for keys), nor any prerequisites or context requirements specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. 'Human cadence' suggests simulated typing delays, but it does not disclose whether the field is cleared first, how errors are handled, or if it waits for the field to be ready. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 13 words. It front-loads the main action ('Click a field by ref and type text into it') and added the qualifier 'human cadence' efficiently. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 required parameters, no output schema, and no annotations, the description is too minimal. It lacks information about return values, error cases, and the meaning of 'ref'. Compared to sibling tools, it does not fully explain when this combination is beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description adds no parameter-specific details beyond the property names 'ref' and 'text'. It does not explain what 'ref' is (e.g., CSS selector, XPath, index) or the expected format of 'text'. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks a field and types text, effectively distinguishing it from sibling tools like veil_click (just click) and veil_type (type into focused element). However, the term 'human cadence' is somewhat vague but still conveys basic behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 implies use for filling form fields but does not contrast with using veil_click then veil_type separately. No when-not-to-use or prerequisite information.
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?
Lacks behavioral details beyond 'human-like mouse path'. No disclosure of error handling, waiting behavior, scrolling into view, or side effects. Annotations are absent, so description carries full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter, the description is minimal. It omits typical click behavior (waiting, scrolling, return value) that an agent would need for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'ref' has no schema description (0% coverage). Description mentions 'snapshot ref' but does not explain what a snapshot ref is, how to obtain it, or its format. Should provide more context for such a critical parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('click'), target ('element by its snapshot ref'), and a behavioral nuance ('human-like mouse path'). It distinguishes from siblings like veil_click_at which uses coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like veil_click_at, veil_fill, or prerequisites such as needing a prior snapshot. Sibling tools include other click-like actions but no explicit 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?
No annotations are provided, so the description carries the full burden. It states the tool is for reading (non-destructive), but lacks details on failure cases, required element visibility, or behavior when ref is invalid. Minimal behavioral disclosure beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately sized and front-loads the core action. Could be slightly improved by adding a brief note on return value, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description covers the basic function and use context. However, it lacks parameter details and potential error scenarios, which are important for a tool with only one required parameter. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'ref' is described as a 'snapshot ref' in the description, adding context beyond the schema's type-only definition. However, it does not specify the format or valid range of the ref number, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an element's rendered text by snapshot ref, with examples of use cases (price, status, result cell). It distinguishes itself from dumping the whole page, suggesting a focused read operation. However, it does not explicitly mention the output type despite no output schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without dumping the whole page' implies when to use over veil_snapshot, but no explicit when-not-to-use or alternative tools are mentioned. Usage is implied rather than explicitly guided.
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?
Lacks disclosure of important behavioral traits such as security implications (arbitrary JS execution), potential side effects, or return format. With no annotations, the description carries full burden but only provides basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core purpose without waste. Front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate. However, given the potential power of JS evaluation, additional context about return value handling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'expression' is described merely as a JS expression to evaluate, adding minimal meaning beyond the schema. No details on syntax, scope, or expectations for return value structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a JS expression in the page and returns the value, with a specific verb and resource. It is easily distinguishable from sibling tools like veil_click or veil_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like veil_text or veil_attribute. No exclusions or context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists supported keys and mentions pressing on the focused element. But it omits details like behavior when no element is focused, whether it waits, or side effects like form submission (only implied). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first states purpose, second provides usage example and supported keys. No redundant information; efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one parameter and no output schema or annotations, the description covers the basic action and supported keys. However, it lacks info on prerequisites (element must be focused), return value, or error handling. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It repeats the enum list from the schema (Enter, Tab, etc.) but adds no extra semantics like case sensitivity or special usage. Minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('press a single named key') and the target ('focused element'). It is specific and distinguishable from sibling tools like veil_type (typing strings) and veil_click (clicking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: 'Use Enter to submit a search box or form (fill a field, then veil_press Enter).' This gives clear context. However, it does not explicitly state when not to use this tool or compare to alternatives like veil_type for text entry.
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 minimally discloses the waitUntil option but does not mention potential destructive effects (e.g., losing form state) or behavior beyond reloading. Lacks depth for a mutation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded and no waste. Could benefit from slight structural improvement (e.g., separating parameter explanation) but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reload action with one parameter, description is fairly complete. Lacks only behavioral context about potential hanging with networkidle, but overall adequate given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with enum is fully explained: both 'load' and 'networkidle' values are listed, and default is identified. Since schema coverage is 0%, description compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Reload the current page' with a specific verb and resource, distinguishing from sibling navigation tools like veil_goto, veil_back, and veil_forward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for reloading, but no explicit context on when to use vs alternatives like veil_goto (which navigates to a URL) or wait conditions. Missing 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description adds meaningful behavioral context: it explains that the tool keeps Sec-CH-UA client hints aligned with the new UA to avoid fingerprinting. This goes beyond a simple 'set' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and then adds a crucial behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is reasonably complete. It explains the purpose and an important side effect. Minor gaps: no error conditions or restrictions mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, userAgent, is self-explanatory from its name and type, but the description does not specify the expected format or provide examples. With 0% schema coverage, the description compensates partially by explaining the purpose but not the syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool overrides the User-Agent at runtime, which is a specific verb and resource. It distinguishes itself from all sibling tools, none of which deal with user-agent settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it specify a context or exclusions.
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 provided, so description carries full burden. It states the action but does not disclose side effects like session termination or unsaved data loss, which is adequate for a simple command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero unnecessary words. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but adequate for a parameterless tool. Lacks context on whether it closes the current instance or all, and any confirmation, but sufficient for a basic close action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% (empty object). Baseline of 4 applies as there is nothing to explain beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description is explicit: 'Close the browser.' It clearly states the verb and resource, distinguishing it from all sibling tools (e.g., veil_reload, veil_snapshot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives, but usage is straightforward. Implied by action, yet no when-not-to or prerequisites mentioned.
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 mentions the tool returns an image for vision but omits details like resource usage, permissions, or side effects. The behavioral transparency is insufficient for a screenshot 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the core purpose and then lists alternatives concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main capture modes but lacks details about the return format (e.g., base64 vs URL), synchronous behavior, or potential size limits. Without annotations or output schema, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by clarifying the relationship between parameters and the default behavior. It explains how each parameter (ref, clip, fullPage) modifies the capture region, which is not fully detailed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it captures a PNG screenshot returned as an image for vision. It lists the default viewport and alternative capture modes (ref, clip, fullPage), making it distinct from sibling tools like veil_pdf or veil_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains that the default is the current viewport and alternatives are for specific elements, rectangles, or full page. However, it does not explicitly state when not to use this tool or mention alternative 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 must disclose behavior. It mentions that calls accumulate and coexists with the private-network guard. However, it does not describe what happens if an invalid type or URL is provided, whether the tool is idempotent, or how blocking affects page rendering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the purpose. Every sentence adds value: first sentence states action and parameters, second sentence adds behavior (accumulation, coexistence) and reversal. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional params, no output schema, no nested objects), the description is largely complete. It covers purpose, parameters, behavioral notes, and reversal. Minor missing detail: what occurs when both urls and types are specified (logical AND? OR?), but this is not critical for a blocking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with examples (URL substrings, resource types). The description adds that they can be used together ('by type and/or by URL substring'), but does not meaningfully extend beyond what the schema provides. Schema coverage is 100%, so baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (block resource loads), the purpose (speed up scraping, reduce footprint), and the resources affected (by type and/or URL substring). It also names the sibling tool 'veil_unblock_resources' for reversal, differentiating the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to speed up scraping, reduce footprint) and mentions accumulation and coexistence with a private-network guard. It also provides the counter-tool. However, it does not explicitly state when not to use it or alternatives beyond the sibling.
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 provided, so the description must compensate. It discloses the return format (JSON with fields) and symmetric behavior with injection, but lacks info on permissions, side effects, or whether it reads cookies for all domains or current context only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with the main action and return format. No irrelevant words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields and explains the optional parameter. It lacks detail on default behavior (which cookies are returned) and edge cases like empty result, but is otherwise adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter. The description adds limited value by saying 'optionally' and 'specific origins', but mostly repeats the schema description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the browser's current cookies as JSON, listing specific fields. It distinguishes from sibling tools (no other cookie-related tool in siblings) and mentions symmetry with cookie injection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use the optional `urls` parameter to scope the read. It doesn't explicitly state alternatives or when not to use, but the context of sibling tools suggests no other cookie retrieval tool exists, making guidance clear enough.
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 implies a read-only operation (returning a list) from the accessibility tree, but no annotations are provided. It does not explicitly state safety, prerequisites, or potential side effects, so it's adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence defines the action, the second provides immediate usage guidance. Effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description adequately explains the return format (numbered list of interactive elements) and how to use the output. Could be improved by mentioning that the page must be loaded or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter details; baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a numbered list of interactive elements from the accessibility tree, and references veil_click/veil_fill for usage, distinguishing it from sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use the [ref] numbers with veil_click/veil_fill and that no CSS selectors are needed, providing clear context. However, it does not specify when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear full burden. The term 'trusted' is used without explanation of what trust entails (e.g., bypassing security checks). Basic behavior (clicking at coordinates) is implied but not elaborated on side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence describes the action, the second gives use cases. Slightly more detail could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool with no output schema or nested objects, the description covers the core purpose, usage context, and parameter semantics partially. Missing details about 'trusted' and prerequisites, but sufficient for straightforward invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. It clarifies that coordinates are 'viewport' coordinates, but doesn't specify units, range, or coordinate origin. This adds moderate value beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Trusted click at absolute viewport coordinates (x, y)', specifying the verb 'click' and the resource 'absolute viewport coordinates'. It distinguishes from siblings like 'veil_click' by noting it targets when there is no snapshot ref, e.g., canvas or map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use when there is no snapshot ref to target — a canvas, map, or custom widget.' This tells the agent when to choose this tool over others (e.g., veil_click for element references).
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 provided, so description must cover behavior. Mentions lazy loading but does not disclose return value, failure handling, or side effects like file overwrite. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose and usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention return values or success indicators. For a mutation tool, this is a gap. Also missing behavioral details like wait behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; description adds meaning to undefined parameters (triggerRef) and clarifies paths and timeout default. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Attach files through a control that opens a file picker' and specifies the use case for SPAs with lazy input creation. It distinguishes from siblings by naming the specific mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'SPAs like Gemini that create the <input> lazily on click' and what to pass ('snapshot ref of the trigger element and absolute file paths'). Lacks explicit when-not-to-use but is specific enough.
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 provided, but description conveys polling behavior, return on match, timeout error, and visibility condition. Lacks detail on polling interval or side effects, but sufficient for a read-type wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, no redundancy, front-loads key purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return value is implied but not specified ('then return' lacks detail). Polling behavior is partially described. For a simple wait tool, missing return description reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; description adds context for visible parameter but not for selector. Timeout explanation is partially overlapped. Baseline 3 due to partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it polls until a CSS selector matches, then returns. It differentiates from sibling veil_wait_for as a 'selector-shaped convenience', providing specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions when to use (wait for CSS selector), optional visible:true flag for visibility checks, and error on timeout. Implicitly considers veil_wait_for as alternative but lacks explicit 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool simulates real mouse events (mousedown->mousemove->mouseup) rather than HTML5 drag events, and explains parameter choices (ref vs fromX/Y). It does not mention timing, error behavior, or response, but covers core behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main action and key distinction. The last sentence is slightly wordy but packs parameter guidance. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 2 required, no output schema, and no annotations, the description covers purpose, usage, and parameter mapping. However, it lacks return value/behavior, error cases (e.g., conflicting ref and coordinates), and assumes domain knowledge (snapshot ref). It is adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the meaning of ref (snapshot ref), fromX/fromY (alternative source coordinates), and toX/toY (destination from screenshot). It adds context missing from schema, though assumes knowledge of 'snapshot ref'. Overall, it provides significant value beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drags from one point to another using real mouse events (mousedown, mousemove, mouseup), distinguishing it from HTML5 drag events and plain click. It provides concrete use cases (site/page builders, Kanban boards, sortable lists) and specifies parameter logic. This makes the purpose highly specific and distinct from siblings like veil_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: for drag interactions in UIs where drop targets don't respond to click. It gives examples but does not explicitly list when not to use or name alternative tools beyond implied click. The guidance is clear but could be more explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses error behavior for empty history and waitUntil defaults ('load' or 'networkidle'), providing useful context. No annotations exist, so description carries full burden; it partially covers the behavioral profile, but could mention return values 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with critical info front-loaded. Every word serves a purpose—action, condition, parameters—with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior (forward navigation, error, waitUntil) adequately for a simple action tool with no output schema. Minor gaps: no mention of return values or interaction with frames, but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond the enum-only schema by stating default ('load') and the purpose of the parameter (waiting condition). For a single parameter with 0% schema description coverage, this elevates understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Go forward one entry in session history' with a specific verb and resource, and expertly distinguishes from sibling tools like veil_back. The error condition 'errors if there's nothing later' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the waitUntil parameter options and default, and implies when-to-use by warning about empty history. However, lacks explicit guidance on when not to use this tool (e.g., preferring veil_goto for direct navigation) and no comparison to alternatives.
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 discloses key behaviors: browser launch on first call and the two waitUntil options with their implications. It lacks details on error handling or security restrictions, but covers the main behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core purpose, the second provides critical parameter context. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a navigation tool with 2 parameters and no output schema, the description covers usage, param options, and a notable side effect. Lacks mention of return value or typical errors, but is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the waitUntil enum values with behavior, but does not clarify the url parameter beyond 'URL'. Since schema description coverage is 0%, the description partially compensates (50% of parameters explained), but could add more detail on expected URL format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action: 'Navigate the browser to a URL'. It distinguishes this from sibling navigation tools (veil_reload, veil_back, veil_forward) by focusing on loading a new URL, and mentions the browser launch side effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use each waitUntil option ('better for SPAs that fetch after load'), but does not explicitly contrast with sibling tools or state conditions when not to use this tool.
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 exist, so description bears full burden. It discloses that scrolling uses a real mouse-wheel event (simulates user interaction) and reveals off-screen content. No mention of destructive behavior or rate limits, but sufficient for a scroll action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Key information is front-loaded (what it does, directionality), and the post-action instruction is clear. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains effect (reveals content) and suggests next step (re-run snapshot). For a scroll tool, this is thorough and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both dx and dy. The description adds directionality (positive dy down, positive dx right) but doesn't significantly extend beyond schema; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scroll', resource 'page', and mechanism 'real mouse-wheel event'. It distinguishes from sibling tools like veil_goto and veil_reload by specifying it scrolls by pixel delta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Reveals lazy-loaded / off-screen content; re-run veil_snapshot after.' This tells when to use and what to do next, but doesn't explicitly state when not to use or alternative 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 provided, so description carries full burden. It discloses absolute path requirement and hidden input support, but does not mention potential side effects, error conditions, or dependencies (e.g., page must be loaded). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first conveys core purpose, second adds practical details. No unnecessary words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file upload action with two parameters and no output schema, the description is nearly complete. It misses return value/status info, but that is common for similar tools. Sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, but description adds valuable context: paths must be absolute, selector defaults. This enriches understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (attach local files), target (file input element), and key feature (bypass OS file picker, even hidden inputs). Uses specific verbs and distinguishes from the sibling veil_upload_via_picker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for use (paths must be absolute, selector defaults to first input[type=file]) and hints at when to customize selector. Lacks explicit when-not-to-use or direct comparison to alternative, but sibling name implies picker-based variant.
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?
Describes behavior as read-only (no mutation), returns raw string or null if attribute absent. No annotations provided, so description carries full burden. Does not mention error handling for invalid ref, but explicitly covers the main 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information. Front-loads verb and resource. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, description covers purpose, parameters, and return value. No gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: 'snapshot ref' indicates ref is from a snapshot, name examples given. Schema coverage is 0%, so description compensates well but could be more precise about ref format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads an attribute of an element by snapshot ref, provides examples (href, value, aria-label, data-*), and distinguishes from siblings like veil_text which reads text content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (reading a single attribute from a snapshot) but does not explicitly say when to use this vs alternatives like veil_text or when not to use it. No guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the error condition (nothing earlier) and the waitUntil behavior (load/networkidle). However, it does not mention side effects like triggering navigation or reloading the page, which might be important for an agent to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence covers the primary purpose and error behavior, while the second adds critical parameter detail. No redundant information, and it is front-loaded with the most important action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and no output schema. The description covers the action, error behavior, and parameter options. It implicitly assumes the agent knows about browser session history, which is reasonable. A brief mention of prerequisites (e.g., must have prior navigation) would improve completeness, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with enum values but no description. The tool description adds significant value by explaining the default ('load') and the two options ('load' or 'networkidle'), which is essential for correct usage. Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('go back one entry in session history') and the specific resource (session history). It also mentions error behavior when no history, which distinguishes it from siblings like veil_forward (go forward) and veil_goto (navigate to URL).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the `waitUntil` parameter with its default and alternatives, providing guidance on how to use the tool. However, it does not explicitly state when to use this tool vs. alternatives, though the context of going back in history is clear from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that it 'arms' FedCM interception, which implies setting up some state, but does not explain what exactly happens (e.g., whether it modifies global settings, whether it is reversible, or what the side effects are). For a tool with no parameters, the description is adequate but lacks deeper behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the first sentence is somewhat long. It front-loads the purpose and provides additional context in the second sentence. Every sentence adds value, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the essential context: what the tool does, when to use it (before certain sites), and how it relates to sibling tools. It explains the sequence and exceptions. It is complete enough for its simplicity, though it does not mention return values (acceptable since no output schema exists and the action likely returns nothing).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Per the rubric, 0 parameters earns a baseline score of 4. The description does not need to add parameter details since there are none. It appropriately focuses on the tool's action and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Arm FedCM interception BEFORE navigating to a site that shows a Google/federated 'one-tap' sign-in on load.' It uses a specific verb ('arm') and resource ('FedCM interception'), and distinguishes from the sibling tool 'veil_fedcm_signin' by specifying the different use case (active button vs. automatic sign-in).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a recommended order: 'veil_fedcm_enable -> veil_goto the sign-in page -> veil_fedcm_signin'. It also tells when to skip this tool: 'Skip this for an active 'Sign in with Google' button; veil_fedcm_signin arms itself when you pass a triggerRef.' This gives clear 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 provided, the description carries the full burden. It explains that the tool affects window.innerWidth/Height, screen size, and devicePixelRatio, and mentions optional parameters. This gives the agent a good understanding of what changes will occur, exceeding a simple 'set viewport' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary function, and includes a practical use case. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the tool's effect on the page, the parameters, and use cases. It could mention that mobile emulation might affect touch events or device orientation, but overall it is thorough enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema: it explains that width/height affect the page's view of innerWidth/Height and screen size. For optional parameters, the schema already provides descriptions, but the description clarifies their role in the context of viewport emulation. Required parameters (width, height) are not described in the schema but their purpose is made clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set the viewport size (and optional deviceScaleFactor / mobile emulation).' It also explains the effect on the page ('window.innerWidth/Height, screen size, and devicePixelRatio'). This distinguishes it from sibling tools like veil_set_user_agent or navigation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Emulate a phone or force a fixed desktop size for reproducible screenshots.' This indicates when to use the tool. However, it does not explicitly state when not to use it or compare with alternatives, but the context is clear.
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 carries full burden. It discloses that Chrome prints PDF only in headless mode and returns the saved path. It mentions default behavior for path omission. Could be improved by noting error conditions if headless mode is not set, but overall 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. First sentence covers purpose and key behavioral constraint. Second sentence lists options efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description provides a solid overview. It explains the return value (saved path) and a critical prerequisite (headless mode). Could mention error handling or that the file is written to disk, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (2 of 5 parameters have descriptions). The description adds meaning to all parameters: explains path defaults, landscape, printBackground (default true), scale, and pageRanges. This supplements the schema significantly, compensating for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool renders the current page to a PDF and saves it to disk. The verb 'render' and resource 'current page to PDF' are specific, and it distinguishes from sibling tools like veil_screenshot (image capture) by focusing on PDF generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (to save PDF) and a key requirement (headless mode via VEIL_HEADLESS=1). It also explains default behavior (temp file if no path). However, it does not explicitly state when not to use or compare to alternatives like veil_screenshot.
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 discloses key behaviors: it fires input+change events and matches the value against the option's value attribute, then its visible text. It does not cover failure cases or return values, but adds meaningful behavioral insight 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers purpose, parameters, and key behavior. It could mention prerequisites (e.g., existing snapshot) or error handling, but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description fully explains both parameters: 'ref' is a snapshot reference, 'value' is the value to set, with matching logic detailed (matches option value, then label). This adds significant meaning beyond the type-only schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a native <select> dropdown to a value and fires input+change events. It distinguishes itself from click+type, which cannot reliably drive a native <select>.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool as the reliable way to handle native <select> elements, contrasting it with click+type. It does not discuss alternative sibling tools or when not to use it, but provides clear context for its use.
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 that only resource blocking set by veil_block_resources is lifted, and the private-network guard is unaffected. No annotations exist, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters and no output schema. Description fully explains what the tool does and its effect relative to sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no param info, but none is needed. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lifts all resource blocking set by its sibling veil_block_resources. Uses specific verb 'lift' and resource 'resource blocking', distinguishing it from the blocking tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly indicates it is the inverse of veil_block_resources. Mentions it leaves the private-network guard untouched, providing context on what it does not affect.
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?
Describes blocking behavior (waits for chooser, selects account, returns it). Mentions default accountIndex. But does not specify timeout or error handling if no account appears. Still, adequate for a straightforward interactive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, well-structured. Front-loaded with main purpose, then details on parameters and variations. No redundant or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only 2 optional parameters, the description covers purpose, usage, parameters, and behavioral aspects. Lacks potential error scenarios or return format, but still largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Explains triggerRef as referencing an active sign-in button and accountIndex defaulting to 0. Lacks detail on triggerRef type (e.g., how to obtain it), but adds meaningful usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated: completes a federated login (FedCM), waits for account chooser, selects an account, returns it. Differentiates from sibling veil_fedcm_enable by mentioning its role in passive flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to pass triggerRef (active button click) vs omit it (one-tap/passive flows). Also directs to call veil_fedcm_enable before navigating for passive flows, providing clear alternative guidance.
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 fully carries the burden. It clearly states that the tool polls repeatedly, returns when the condition holds, and errors on timeout. This discloses the core behavioral traits without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word earns its place. It is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, behavior, and main parameter with an example. It is mostly complete but could mention what the function returns (implicitly true or the result). Still, given the simplicity and presence of sibling tools, it is adequately comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (poll and timeout described). The description adds meaning by explaining the 'expression' parameter with an example, compensating for the missing schema description. It does not add new info for already-described parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool polls a JS expression until it is truthy, providing a specific verb and resource. It distinguishes from a fixed sleep and, by implication, from sibling tool 'veil_wait_for_selector' which uses a CSS selector instead of an arbitrary expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'a fixed sleep', giving a clear context for when to use this tool instead. However, it does not mention when not to use it or directly compare with the selector-based wait tool among siblings.
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, but description clearly states it lists cross-origin iframes and implies read-only behavior. Could explicitly state it has no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, limitation (only cross-origin), and example context. Sufficient for a parameterless tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds no parameter details but provides context on when to call, which is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists cross-origin child iframes, distinguishes from veil_snapshot by specifying that same-origin iframes are handled there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call (after veil_goto when page returns no interactive elements) and when not needed (same-origin iframes). Includes example use case.
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 carries full burden for behavioral disclosure. It reveals that switching invalidates existing references and requires re-snapshotting. This is valuable context, though it could mention if there are any side effects or error conditions. Still, it adds significant value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, then detailed consequences. Every word serves a purpose with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully covers essential context: which tools are affected, how to switch back, and the need to re-snapshot. It is complete for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'index' is described as the child iframe index from veil_frames, with null meaning main page. Schema description coverage is 0%, so the description compensates by providing clear meaning and usage, which is necessary for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to point subsequent veil_* calls at a child iframe instead of the main page. It specifies the affected sibling tools (veil_snapshot, veil_click, etc.) and distinguishes itself by focusing on frame targeting, setting it apart from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use: after obtaining frame indices from veil_frames, and how to switch back to main page by omitting or passing null. Also notes that existing refs are invalidated on switch, requiring a fresh veil_snapshot call, providing clear when-not and post-conditions.
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 fully discloses behavior: when injected values take effect (next navigation), which overrides are immediate, and a caveat ('not a magic bullet'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences pack a lot of information without redundancy. The key verb 'Apply' and resource 'COHERENT fingerprint' are front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameter types, nested object, no output schema), the description covers purpose, usage, timing, and limitations comprehensively, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema's property descriptions, explaining the purpose of each parameter (preset, random, seed, fingerprint) and emphasizing internal consistency requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a coherent fingerprint/profile, listing all components (UA, client hints, screen, timezone, etc.), and distinguishes from siblings by emphasizing 'coherent identity control' and timing relative to veil_goto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call before veil_goto for full effect and notes that some overrides apply immediately. Does not mention when not to use or alternative tools, but provides clear context for when to use.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/acunningham-ship-it/veilbrowser'
If you have feedback or need assistance with the MCP directory API, please join our Discord server