Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

networking_mac_address_generator

Read-only

Generate random IEEE 802 MAC addresses for VMs and lab testing, or analyze and reformat existing ones. Supports unicast/multicast and locally/universally-administered bits.

Instructions

MAC Address Generator And Analyzer. Generate random IEEE 802 MAC addresses and analyze or reformat existing ones. The default generate operation returns count fresh random MACs (output varies every call — not idempotent) with selectable unicast/multicast and locally/universally-administered bits; other operations are deterministic: analyze decodes one MAC into OUI, NIC, cast/admin bits and best-effort vendor, format converts one MAC between notations, use_case emits a single MAC tuned for a scenario, and vendor_oui prefixes random NIC bytes onto a supplied OUI. Use this to fabricate MACs for VMs, lab testing, and network config; use osint_mac_vendor_lookup instead to resolve a real manufacturer from a known MAC. Runs locally via a JS logic bridge: read-only, non-destructive, contacts no external service, rate-limited to 60 requests/min for anonymous callers. Returns a success flag, the echoed operation, and an operation-specific result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYesWhich action to perform. Defaults to generate.generate
countNogenerate only: how many random MACs to return.
macNoanalyze/format only: the MAC to process; 12 hex digits, separators (: - .) ignored.
formatNoOutput notation for generate and format operations.colon
unicastNogenerate only: force the unicast (LSB of first octet = 0) bit.
locallyAdministeredNogenerate only: set the locally-administered bit on generated MACs.
universallyAdministeredNogenerate only: clear the locally-administered bit (ignored if locallyAdministered is true).
useCaseNouse_case only: scenario preset selecting the admin/cast bits.virtual_machine
ouiNovendor_oui only: 6 hex-digit OUI prefix to prepend to random NIC bytes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the operation completed.
operationNoThe operation that was executed.
resultNoOperation-specific payload. generate -> array of { mac, formatted, analysis }; analyze -> an analysis object; format -> { input, output, allFormats }; use_case -> { mac, formatted, useCase, description, analysis }; vendor_oui -> the generated 12-hex-digit MAC string.
errorNoPresent only when success is false; the failure reason.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses behavioral traits beyond annotations: non-idempotency for generate operations, local execution via JS logic bridge, read-only and non-destructive nature, no external service contact, and rate limiting (60 req/min). Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph that front-loads the purpose and systematically covers all operations, constraints, use cases, and alternatives. Every sentence adds necessary information without redundancy.

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 complexity (9 parameters, 5 operations, enum constraints), the description is complete. It explains all operations, parameter dependencies, and provides use-case guidance. The output structure is briefly described, and rate limiting is mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining parameter interactions (e.g., universallyAdministered ignored if locallyAdministered is true) and clarifying operation-specific applicability (e.g., count only for generate). This increments the score to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as generating and analyzing MAC addresses, listing all five operations (generate, analyze, format, use_case, vendor_oui) with specific verbs and resources. It distinguishes itself from the sibling tool osint_mac_vendor_lookup by specifying when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (fabricating MACs for VMs, lab testing, network config) and when to use an alternative (osint_mac_vendor_lookup for real manufacturer resolution). It also explains the different operations and their intended scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Jambozx/onlinecybertools-mcp-server'

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