nab

by MikkoParkkola

Overview Schema Related Servers Score Discussions

Rust

Local

Server Quality Checklist

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

Latest release: v0.12.0
Disambiguation5/5
Each tool has a clearly distinct purpose: auth_lookup for credential lookup, benchmark for timing, fetch for single URL conversion, fetch_batch for parallel fetching, fingerprint for browser profiles, login for automated authentication, submit for form submission, and validate for testing. No two tools serve the same function, and descriptions provide ample detail to differentiate.
Naming Consistency4/5
Tool names use snake_case and are generally descriptive, but there is inconsistency between verb-based names (fetch, fetch_batch, submit, validate) and noun-based names (auth_lookup, benchmark, fingerprint, login). However, the naming is still predictable and readable, with fetch_batch clearly extending fetch.
Tool Count5/5
With 8 tools, the server covers all core web interaction tasks without being overwhelming. The count is appropriate for the domain of web scraping, automation, and testing, and each tool adds clear value.
Completeness4/5
The tool set covers a wide range of web interactions: fetching, batch processing, form submission, authentication, benchmarking, and validation. Minor gaps exist, such as explicit session management or cookie manipulation, but the core workflow is well-served, and agents can accomplish most tasks without missing critical operations.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 83 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly (no mutation) and openWorld (external dependencies). The description adds context about measuring min/avg/max response times and returning results. However, it does not disclose network behavior, potential timeouts, or data volume implications, but annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loading the core purpose. It avoids unnecessary detail, but the first and last sentences are somewhat redundant. Still, it is efficiently structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters with no schema descriptions and a list of similar sibling tools, the description lacks detail on parameter formats and selection guidance. While it has an output schema, the description does not fully leverage it to explain the return structure. The tool's interface is not fully clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; parameters have no descriptions. The description mentions 'URLs' and 'iterations' only broadly, without specifying format, constraints, or defaults. This is insufficient to guide correct use given the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: benchmarking URL fetching with timing statistics. It distinguishes from siblings like 'fetch' and 'fetch_batch' by specifying that this tool measures performance rather than just retrieving content. The action and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While 'benchmark' implies performance testing, the description does not compare it to 'fetch', 'fetch_batch', or other siblings, nor does it state prerequisites 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds context about output contents but no additional behavioral traits like rate limits or side effects. The description aligns with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences front-loading purpose, listing included features, and describing returns. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple fingerprint generation task, output schema exists for return format, and annotations cover safety, the description provides enough context. It could mention any networking dependencies, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description mentions browser types ('Chrome, Firefox, Safari') hinting at the browser parameter but does not link it explicitly. The count parameter is not explained, and return wording implies multiple profiles but is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates realistic browser fingerprints, listing specific browsers and included headers. The purpose is unambiguous and distinguishes it from sibling tools like fetch or login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The description only defines what it does, without mentioning context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation, detailing concurrency, HTTP/2 multiplexing, connection pooling, and timing in results. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences front-loading the main action and key details. Slightly longer than necessary but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and existence of an output schema, the description covers the basic purpose and concurrent behavior but lacks details on limits, error handling, or authentication, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not add any parameter-specific guidance (e.g., max URLs, format) beyond what the schema already provides, leaving the agent with minimal additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches multiple URLs in parallel with HTTP/2 multiplexing, distinguishing it from the sibling 'fetch' tool which likely handles single URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch fetching but does not explicitly specify when to use this tool over alternatives (e.g., 'fetch' for single URLs) or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the behavioral flow: detecting login form, retrieving credentials, filling and submitting, handling MFA/2FA, and returning page content. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true) by explaining the side effects (credential retrieval, cookie storage via session parameter). However, it does not mention potential failure modes or fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the main purpose front-loaded. It uses bullet points for requirements and return value, making it easy to scan. Every sentence adds value without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (login with MFA, credential management) and the presence of an output schema, the description adequately covers the process, requirements, and return type. It could be more complete by addressing error handling or the scope of login form detection, but it provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 33% (only session is described in the schema), the description fails to compensate for the missing parameter details. The url parameter is implied but not explicitly described, and the cookies parameter is not mentioned at all. This leaves ambiguity for the agent about the format and purpose of these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Auto-login to a website using 1Password credentials,' specifying the verb (auto-login), resource (website), and scope (using 1Password). This distinguishes it from sibling tools like fetch (simple retrieval) and submit (form submission), as it handles the entire authentication flow including credential retrieval and MFA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by outlining the prerequisites (1Password CLI installed and authenticated) and the process (detect form, fill, submit, handle MFA). It implicitly differentiates from alternatives by focusing on login with 1Password, though it could explicitly state when to use this tool over fetch or auth_lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses the full workflow (fetching, parsing, extraction, merging, POST submission) and the return format (markdown-converted response body). Annotations already indicate non-read-only (readOnlyHint=false) and open-world behavior, so the description adds detail on what modifications occur (POST submission) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences), front-loads the core purpose, and uses a bullet-list style for uses and returns. Every sentence adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step form handling, state mutation), the description covers purpose, behavior, use cases, and return format. The presence of an output schema reduces the need to detail return structure. It could mention potential errors or prerequisites (e.g., page must be accessible), but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema description coverage, the narrative must compensate. It explains that 'fields' holds user-provided fields and that 'csrf_selector' is used for CSRF token extraction, but does not detail 'cookies', 'session', or the exact syntax of fields array. The description provides moderate additional meaning beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair ('Submit a web form with smart field extraction'), clearly distinguishing it from sibling tools like fetch (fetching only) or login (authentication-specific). It details the multi-step process (fetch, parse, extract, merge, submit), making the tool's exact purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use cases are explicitly listed ('login forms, search forms, API interactions behind HTML pages'), providing clear context. However, it does not advise when not to use this tool (e.g., when a simpler fetch or dedicated login tool would suffice), nor does it mention potential overlap with the 'login' sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint annotation: it explains that passwords are not exposed and that credential info is returned if found. This helps set expectations without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states purpose, second explains behavior, third indicates return value. It is front-loaded, concise, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, readOnlyHint annotation, and existence of an output schema), the description fully covers purpose, behavior, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that the url parameter should be a URL or domain for credential lookup. This adds semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up' and the resource 'credentials in 1Password' for a URL. It specifies the returned items (username, TOTP availability) and notes no password exposure. This distinguishes the tool from siblings like login or fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving credentials for a URL. However, it does not explicitly state when to use this tool versus alternatives like login or fetch, nor does it provide 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?
Annotations declare readOnlyHint true, so description adds value by detailing tests and return format. No contradictions, but no further disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: action, list, return. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no params, good annotations, and existing output schema, description covers the tool's purpose and outputs fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4 applies as description need not compensate for missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it runs validation tests against real websites, listing specific tests (HTTP/2, HTTP/3, compression, fingerprinting, TLS 1.3, 1Password), distinguishing it from siblings like fetch or fingerprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for running listed validation checks, but no explicit when-to-use or when-not-to-use vs. siblings like benchmark (similar performance focus) or fingerprint.
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?
Annotations (readOnlyHint: true) are consistent with read operation. Description adds extensive behavioral context: automatic content conversion per Content-Type, network features, diff mode caching, token budget truncation. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for content conversion, network features, modes. Every sentence adds value; no redundancy. Appropriate length given tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all major aspects: input, modes, return values (with output schema hinted). Handles complexity of 8 params and varied behaviors. Complete for an information retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but description compensates by explaining all parameters in detail: diff caching, focus BM25 scoring, max_tokens priority, session persistence, and implied url/headers/body behavior. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Fetch a URL and convert to clean markdown for LLM consumption.' It clearly identifies the verb (fetch) and resource (URL), and distinguishes from siblings like fetch_batch and submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit guidance via sibling tools (fetch_batch for multiple URLs, login for auth). Describes when to use diff and focus modes. Lacks explicit 'when not to use' but sufficient for most agents.
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:

[![nab MCP server](https://glama.ai/mcp/servers/MikkoParkkola/nab/badges/card.svg)](https://glama.ai/mcp/servers/MikkoParkkola/nab)

Score Badge

Copy to your README.md:

[![nab MCP server](https://glama.ai/mcp/servers/MikkoParkkola/nab/badges/score.svg)](https://glama.ai/mcp/servers/MikkoParkkola/nab)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MikkoParkkola/nab'

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