What can you do with this server?

The maltego-mcp server enables LLM agents to author Maltego .mtgx graph files and perform primitive OSINT lookups, bridging agent-based reasoning with Maltego's graph visualization for threat intelligence investigations. Graph Authoring * Create new empty graphs in memory (graphId returned for further operations) * Add typed entities/nodes (e.g., Domain, IPv4Address, Hash, EmailAddress) with optional properties * Add directed, labeled links between entities * Save graphs to .mtgx files on disk * Load existing .mtgx files into memory Primitive OSINT Lookups * WHOIS — registrar, nameservers, and registration dates for a domain * DNS — A, AAAA, MX, NS, and TXT records for a domain * ASN — ASN, netblock, country, and organization for an IP via Team Cymru * Certificate Transparency — search crt.sh for a domain Convenience Graph Expanders * Expand IP — builds a .mtgx graph around an IP including ASN and netblock * Expand domain — builds a .mtgx graph including WHOIS, DNS records, and ASN per A record * Expand hash — builds a .mtgx graph with a hash entity (md5, sha1, sha256, sha512) * IOC investigation graph — combines one IOC with enrichment summaries from MISP events, TheHive cases, Cortex reports, and MITRE ATT&CK techniques into a single .mtgx file Additional Features * Compatible with Claude Desktop, Claude Code, OpenClaw, Hermes Agent, and Codex CLI * Includes a read-only CLI tool (maltegoctl) for lookups and graph inspection * Optional Phase B transforms for right-click pivots to MISP, TheHive, Cortex, and MITRE ATT&CK inside Maltego Desktop

How do I use maltego-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@maltego-mcp Expand domain google.com with whois and DNS" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

maltego-mcp

by lidless-labs

Overview Schema Related Servers Score Discussions

TypeScript

Local

maltego-mcp is a Model Context Protocol (MCP) server that lets an LLM author Maltego .mtgx graph files and run primitive OSINT lookups (whois, DNS, ASN, crt.sh) from inside an agent session. It exists because graph-driven OSINT investigation in Maltego Desktop is normally point-and-click work, and an agent that can already reason over indicators should be able to produce the graph directly instead of dictating clicks to a human. It differs from a Maltego transform pack by living in the agent layer first: the graph is built and saved to disk by tool calls, then opened in Maltego, so it works even on the Basic plan and without paid connectors. A second optional layer (Phase B) does add native right-click transforms inside Maltego Desktop for teams that want that too.

What it does

maltego-mcp is an MCP server for Maltego Desktop OSINT that gives an LLM agent a small, typed toolset for building Maltego graphs and enriching indicators of compromise. An agent calls these tools to create a graph, add entities and links, run whois / DNS / ASN / certificate-transparency lookups, expand an IP or domain into a pivot map, and write the result to a .mtgx file you open in Maltego Graph Desktop. Keywords: Maltego, MCP server, OSINT, threat intelligence, graph, whois, DNS, ASN, crt.sh, indicators of compromise.

It ships as two cooperating layers:

Phase A (TypeScript MCP server): lets an LLM author Maltego .mtgx graph files and run primitive OSINT lookups (whois / DNS / ASN / crt.sh). Graphs land on disk and you open them in Maltego Desktop.
Phase B (Python TRX transforms in a .mtz): adds right-click pivots into MISP, TheHive, Cortex, and the bundled MITRE ATT&CK dataset directly inside Maltego Desktop. See transforms/README.md.

The two phases share the repo, nothing else. Either layer can be uninstalled without breaking the other.

Related MCP server: MITRE ATT&CK MCP Server

Install

npm install -g maltego-mcp

Or from source (required for Phase B transforms):

git clone https://github.com/lidless-labs/maltego-mcp.git
cd maltego-mcp
npm install
npm run build

Quickstart

Install globally and register it with an MCP client:

npm install -g maltego-mcp

Add it to your MCP client config (Claude Desktop shown; the same command works in any stdio MCP client):

{
  "mcpServers": {
    "maltego": {
      "command": "maltego-mcp"
    }
  }
}

Restart the client and the maltego_* tools appear. From a source checkout, point the client at the built entrypoint instead:

{
  "mcpServers": {
    "maltego": {
      "command": "node",
      "args": ["/absolute/path/to/maltego-mcp/dist/mcp-server.js"]
    }
  }
}

Status: v0.4.3 is published on npm and GitHub. Phase B transforms require a source checkout. See Install for all client recipes.

Tools (Phase A)

maltego-mcp registers 13 MCP tools, verified against src/tools/index.ts:

Graph authoring

maltego_create_graph(name) — returns graphId
maltego_add_entity(graphId, type, value, properties?) — returns entityId
maltego_add_link(graphId, from, to, label?, properties?) — returns linkId
maltego_save_graph(graphId, path, overwrite?) — writes .mtgx
maltego_load_graph(path) — parses an existing .mtgx into a new handle

Primitive lookups

maltego_whois(domain) — registrar, nameservers, dates
maltego_dns(domain) — A/AAAA/MX/NS/TXT
maltego_asn(ip) — Team Cymru ASN, prefix, country, org
maltego_crtsh(domain) — certificate transparency entries

Convenience expanders

maltego_expand_ip(ip, outputPath, overwrite?) — IP + ASN + netblock, saved as .mtgx
maltego_expand_domain(domain, outputPath, overwrite?) — domain + whois + DNS + ASN per A record
maltego_expand_hash(hash, outputPath, algorithm?, overwrite?) — hash entity (extend in later versions)
maltego_build_ioc_graph(ioc, outputPath, ...) — one IOC plus enrichment summaries from other MCPs, saved as .mtgx

Entity types

Standard Maltego ontology: IPv4Address, IPv6Address, Domain, URL, Hash, EmailAddress, Netblock, AS, Website, Company, Person. For concepts without a standard type, use Phrase with a category prefix ([T1566] Phishing, [TheHive] Case #42).

Composing with other MCPs

maltego-mcp does not embed third-party threat-intel clients. For MISP events, ATT&CK techniques, Cortex reports, etc., call the dedicated MCPs (misp-mcp, mitre-mcp, cortex-mcp, etc.) and pipe results into maltego_add_entity / maltego_add_link. Or, for in-Maltego pivots, install Phase B (below).

For the common "one IOC, many enrichments" case, use maltego_build_ioc_graph: call misp-mcp, thehive-mcp, cortex-mcp, and mitre-mcp first, summarize their results into the tool's mispEvents, thehiveCases, cortexReports, and attackTechniques arrays, then save one combined .mtgx. The tool keeps service calls out of this package while still making the graph bridge a single MCP call.

Configuration

Both env vars are optional.

Variable	Default	Description
`MALTEGO_MCP_OUTPUT_DIR`	`~/MaltegoGraphs`	Default output directory for `.mtgx` files
`MALTEGO_MCP_LOOKUP_TIMEOUT_MS`	`30000`	Per-lookup timeout in ms (currently applied to `crt.sh` only; `whois`, `dns`, `asn` use library defaults)

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "maltego": {
      "command": "maltego-mcp"
    }
  }
}

Or, when running from a source checkout instead of the global npm install:

{
  "mcpServers": {
    "maltego": {
      "command": "node",
      "args": ["/absolute/path/to/maltego-mcp/dist/mcp-server.js"]
    }
  }
}

Restart Claude Desktop. The maltego_* tools should appear.

Claude Code

claude mcp add maltego -- maltego-mcp

Or from a source checkout:

claude mcp add maltego -- node /absolute/path/to/maltego-mcp/dist/mcp-server.js

Add --scope user to make it available from any directory instead of only the current project.

OpenClaw

Recommended: install as an OpenClaw plugin via ClawHub.

openclaw plugins install clawhub:maltego
openclaw plugins list   # confirm "maltego" is registered

This installs the same package as a native OpenClaw plugin — tool calls go through the plugin SDK directly instead of spawning a separate stdio MCP process. Configure outputDir and lookupTimeoutMs in OpenClaw's plugin config UI or via the JSON config file. Restart the OpenClaw gateway after installing so the plugin is picked up.

Or, register as a stdio MCP server (manual):

openclaw mcp set maltego '{
  "command": "maltego-mcp"
}'

Or, when running from a source checkout:

openclaw mcp set maltego '{
  "command": "node",
  "args": ["/absolute/path/to/maltego-mcp/dist/mcp-server.js"]
}'

Then restart the OpenClaw gateway so the new server is picked up and confirm registration with openclaw mcp list.

Hermes Agent

Hermes Agent reads MCP config from ~/.hermes/config.yaml under the mcp_servers key. Add an entry:

mcp_servers:
  maltego:
    command: "maltego-mcp"

Or, when running from a source checkout:

mcp_servers:
  maltego:
    command: "node"
    args: ["/absolute/path/to/maltego-mcp/dist/mcp-server.js"]

Then reload MCP from inside a Hermes session:

/reload-mcp

Codex CLI

Codex CLI registers MCP servers via codex mcp add:

codex mcp add maltego -- maltego-mcp

Or from a source checkout:

codex mcp add maltego -- node /absolute/path/to/maltego-mcp/dist/mcp-server.js

Codex writes the entry to ~/.codex/config.toml under [mcp_servers.maltego]. Verify with codex mcp list.

Requirements

Node.js 20+
Maltego Graph Desktop (Basic, Pro, or Enterprise) for either layer to be useful
Phase B only: Python 3.11+ on the Maltego host

Maltego Basic compatibility

The default workflow is Basic-friendly: generate .mtgx files with Phase A, then open or import them in Maltego Graph Desktop. The included demo graph is kept under 24 entities so it stays useful on the Basic plan's per-transform result limit. Local TRX transforms are supported on Basic, but their live results are still subject to your Maltego plan and connector limits. See Maltego's current products and plans and Basic data access notes.

CLI

The same package ships a read-only control CLI, maltegoctl, for shells, cron, and CI. It shares the lookup and graph-reading tools with the MCP server and reads the same env config. It exposes only the read/inspect surface: the OSINT lookups (whois, DNS, ASN, crt.sh) and a .mtgx inspector. Graph authoring, saving, and the .mtgx expanders stay in the MCP/plugin surface, because their primary effect is writing a file to disk.

npx maltego-mcp@latest whois example.com
# or, installed globally:
maltegoctl whois example.com
maltegoctl dns example.com
maltegoctl asn 192.0.2.10
maltegoctl crtsh example.com
maltegoctl inspect graph.mtgx        # parse an existing .mtgx, list entities + links
maltegoctl dns example.com --json    # raw JSON for piping

Run maltegoctl help for the full command and flag list. --json emits raw JSON instead of the concise human-readable summary. inspect reads from inside MALTEGO_MCP_OUTPUT_DIR only and never writes; the lookup tools make outbound queries but mutate nothing. Exit codes: 0 success, 1 runtime error (a lookup failed, the host was unreachable, or the .mtgx could not be read), 2 usage error (unknown command/flag or a missing argument).

Environment:

Variable	Default	Description
`MALTEGO_MCP_OUTPUT_DIR`	`~/MaltegoGraphs`	Base directory `inspect` paths are confined to
`MALTEGO_MCP_LOOKUP_TIMEOUT_MS`	`30000`	Per-lookup timeout in ms (applied to `crtsh` only)

Starting the MCP server

maltegoctl mcp (or the back-compat maltego-mcp bin) starts the stdio MCP server. If a launcher referenced the file path dist/mcp-server.js directly, it keeps working; new launchers can point at dist/mcp-bin.js (or dist/cli.js mcp). Launchers that use the maltego-mcp bin name need no change.

Basic-friendly demo graph

Generate a no-network .mtgx demo that shows how an IOC can connect to MISP, TheHive, Cortex, MITRE ATT&CK, and a triage playbook without requiring API keys or paid Maltego connectors:

npm run demo:basic

Output defaults to dist/maltego-mcp-basic-soc-demo.mtgx. Open that file in Maltego Graph Desktop. To choose a different path:

npm run demo:basic -- --output ~/MaltegoGraphs/basic-soc-demo.mtgx

The demo uses documentation-safe indicators such as 203.0.113.42 and example.invalid; it is meant to prove the graph format and visual workflow, not to perform live enrichment.

Phase B: in-Maltego transforms (.mtz)

A separate Python transform layer ships right-click pivots into MISP, TheHive, Cortex, and ATT&CK directly inside Maltego Desktop. See transforms/README.md for full setup.

Quick start (from a source checkout, on the Maltego host):

npm run setup:transforms     # creates transforms/.venv with maltego-trx pinned
npm run build:mtz            # writes dist/maltego-mcp-transforms.mtz
# Then in Maltego: Import -> Configuration -> dist/maltego-mcp-transforms.mtz

The build bakes the absolute path of transforms/.venv into the manifest, so the .mtz is tied to the host that built it. Re-run npm run build:mtz if the repo moves.

Example prompts

Build me a Maltego graph for the domain example.com with whois, DNS, and ASN expansion.

Calls maltego_expand_domain and returns the path to the saved .mtgx.

Pivot from this IP — give me ASN + netblock as a Maltego graph.

Calls maltego_expand_ip.

Look up the cert transparency log for example.com.

Calls maltego_crtsh and returns matching certificates.

Build a Maltego graph for this hash using the MISP events, TheHive cases, Cortex reports, and ATT&CK techniques we already gathered.

Calls maltego_build_ioc_graph with an input shaped like:

{
  "ioc": {
    "type": "Hash",
    "value": "d41d8cd98f00b204e9800998ecf8427e",
    "properties": { "algorithm": "md5" }
  },
  "outputPath": "hash-investigation.mtgx",
  "mispEvents": [{ "id": 1001, "info": "demo phishing cluster" }],
  "thehiveCases": [{ "id": 42, "title": "Phishing triage", "severity": "high" }],
  "cortexReports": [{ "analyzer": "HashLookup", "verdict": "suspicious" }],
  "attackTechniques": [{ "id": "T1566", "name": "Phishing", "tactic": "Initial Access" }]
}

Why not a Maltego transform pack alone?

Native Maltego transforms are great once an investigation is already open in the Desktop client, but they assume a human is driving the canvas and, for live remote data, often a paid plan or connector. maltego-mcp puts graph authoring in the agent layer so an LLM can build and save a .mtgx from indicators it is already reasoning about, with no canvas clicks and no connector requirement. If you also want in-Maltego right-click pivots, Phase B ships them as a .mtz you import. You are not forced to choose: run the MCP server, the transforms, or both.

Why not just hand the LLM raw whois/DNS tooling?

You can, but then the model has to remember the Maltego .mtgx XML format, entity ontology, and link wiring on every call. maltego-mcp encodes that once: the lookups return normalized fields, and the graph tools emit a valid .mtgx that opens cleanly in Maltego Desktop. The expanders bundle the common pivots (IP to ASN to netblock, domain to whois to DNS to ASN) into one call so the agent does not re-derive them each time.

What maltego-mcp is not

Not a Maltego replacement. It produces .mtgx files; you still open and drive them in Maltego Graph Desktop.
Not a threat-intel platform. It does not embed MISP, TheHive, Cortex, or VirusTotal clients. It composes with the dedicated MCPs for those.
Not a paid-connector bypass. Live transform results are still bound by your Maltego plan and connector limits.
Not a bulk scanner. The lookups are primitive, single-target enrichments meant to build a graph, not a high-volume reconnaissance engine.

Development

npm test                # Phase A unit tests (vitest)
npm run test:integration
npm run test:all
npm run typecheck
npm run test:transforms # Phase B pytest suite

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md for what lands easily, SECURITY.md for how to report a vulnerability privately, and CODE_OF_CONDUCT.md.

License

MIT

Available Tools

13 tools

maltego_add_entityA

Add an entity (node) to a graph. Returns entityId for use with maltego_add_link.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Entity type, e.g. Domain, IPv4Address, Hash, Phrase. Auto-prefixes with maltego. if needed.
`value`	Yes
`graphId`	Yes
`properties`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It notes that the type parameter auto-prefixes with 'maltego.' if needed, which is helpful. However, it does not describe side effects (e.g., graph mutation), permissions, or error conditions.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys the core action and key return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions the return value (entityId) despite no output schema, which is good. However, it lacks details on parameter formats, the 'properties' object, and error states. Adequate for a simple tool but incomplete for rich context.

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

Parameters2/5

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

Schema description coverage is only 25% (only 'type' has a description). The description adds one behavioral detail for 'type' but provides no additional meaning for 'value', 'graphId', or 'properties'. Given low coverage, the description should compensate more.

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

Purpose5/5

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

The description clearly states the action ('Add an entity (node) to a graph'), specifies the returned value ('entityId'), and distinguishes from sibling tools like maltego_add_link. It uses a specific verb and resource, making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description mentions that the returned entityId is used with maltego_add_link, implying a workflow. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it discuss alternatives beyond the linking step.

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

maltego_add_linkC

Add a directed link between two entities. Returns linkId.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Target entityId.
`from`	Yes	Source entityId.
`label`	No
`graphId`	Yes
`properties`	No

TDQS

C2.9/5.0

Behavior2/5

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

The description states it adds a directed link and returns a linkId, but it does not disclose behavioral traits such as whether it overwrites existing links, requires specific graph state, or has any side effects. With no annotations to fill the gap, the description is insufficient.

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

Conciseness3/5

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

The description is concise at two sentences with no extraneous information, but it could provide more context without sacrificing brevity. It is front-loaded with the core purpose, which is good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters (3 required), no output schema, and no annotations, the description is too minimal. It does not explain what 'graphId' refers to, how properties are used, or the effect of adding a link. Agents need more context to use this correctly.

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

Parameters2/5

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

Schema description coverage is 40%, but the tool description adds no parameter-level information. It does not explain the meaning of 'label' or 'properties', leaving the agent to rely solely on the schema, which has missing descriptions for 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 the action ('Add a directed link'), the resources involved ('between two entities'), and the return value ('Returns linkId'). This distinguishes it from sibling tools like maltego_add_entity, which adds an entity rather than a link.

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 like maltego_add_entity or other link-related tools. There is no mention of prerequisites or conditions, leaving the agent to infer usage from the name alone.

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

maltego_asnA

Look up ASN, netblock, country, and org for an IP via Team Cymru.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

The description mentions the data source 'Team Cymru', which adds some transparency about external dependency. However, no annotations are provided, and the description does not disclose potential behaviors such as rate limits, error handling, or whether the tool is read-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/5

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

The description is a single sentence with no wasted words, conveying the essential purpose and data source efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the core purpose and data source. It could be improved by mentioning what happens on invalid input or data freshness, but it is largely 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?

The description adds minimal meaning over the schema: it specifies that the IP is used for the lookup and mentions the data source. It does not clarify the format (IPv4/IPv6, public vs. private) or any constraints, and schema coverage is 0%, so the description should compensate more.

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

Purpose5/5

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

The description clearly states the action (look up) and the specific data returned (ASN, netblock, country, org for an IP) using a specific data source (Team Cymru). This distinguishes it from sibling tools like whois or DNS lookups.

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

Usage Guidelines3/5

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

The description implies the tool is for looking up ASN information for an IP address, but it does not provide explicit guidance on when to use this tool over alternatives (e.g., when you need routing info vs. organizational details) or any exclusions.

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

maltego_build_ioc_graphB

Build a .mtgx investigation graph from one IOC plus enrichment summaries gathered from MISP, TheHive, Cortex, MITRE, or other MCPs. This tool does not call those services itself.

ParametersJSON Schema

Name	Required	Description
`ioc`	Yes
`notes`	No
`title`	No
`overwrite`	No
`mispEvents`	No
`outputPath`	Yes	Output path. Resolved relative to outputDir; absolute paths must be inside outputDir.
`thehiveCases`	No
`cortexReports`	No
`attackTechniques`	No
`maxItemsPerSection`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must bear all behavioral disclosure. It mentions that the tool does not call external services, but omits other critical behaviors: file overwrite behavior (though an 'overwrite' param exists), output path resolution relative to outputDir, error handling, or side effects on existing files. Minimal transparency beyond the basic function.

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

Conciseness5/5

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

The description is two sentences: one for purpose, one for a clarifying limitation ('does not call those services itself'). No unnecessary words. Every sentence adds value and the critical constraint is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, nested objects, no output schema), the description is severely incomplete. It does not explain the expected structure of enrichment summaries, how parameters like 'attackTechniques' or 'cortexReports' map to graph elements, or what the tool returns (likely a file path or success status). Many required behaviors (e.g., overwrite handling) are left to the agent to infer from the param name alone. This is inadequate for confident invocation.

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

Parameters2/5

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

Schema description coverage is only 10%, meaning most parameters lack schema-level explanations. The tool description adds no parameter-specific meaning beyond the generic 'enrichment summaries'. For example, 'notes', 'title', 'mispEvents', 'thehiveCases', etc., remain undefined. The description does not compensate for the sparse schema, leaving the agent to infer parameter formats and relationships.

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 builds a .mtgx investigation graph from one IOC and enrichment summaries, specifying sources like MISP, TheHive, Cortex, MITRE. The verb 'Build' and resource '.mtgx investigation graph' are specific, and the sibling context (e.g., maltego_create_graph, maltego_add_entity) helps distinguish this as a batch graph construction tool.

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: provide an IOC plus enrichment summaries. However, it does not explicitly state when to use this tool versus siblings (e.g., maltego_add_entity for incremental additions, maltego_create_graph for blank graphs). It also lacks prerequisites, such as the need to have already gathered enrichment data from other MCPs. No when-not guidance.

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

maltego_create_graphA

Create a new empty Maltego graph in memory. Returns graphId for use with maltego_add_entity / maltego_add_link / maltego_save_graph.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Display name for the graph.

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries the burden of behavioral disclosure. It correctly states the tool creates an empty graph in memory and returns a graphId. However, it lacks details on error conditions (e.g., duplicate names) or side effects.

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

Conciseness5/5

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

The description is extremely concise with two sentences, front-loading the core action and then adding return/usage context. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation tool with one parameter and no output schema, the description covers the essential purpose, return value, and workflow integration. Minor missing details like naming constraints or persistence behavior are acceptable given the simplicity.

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

Parameters3/5

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

The single parameter 'name' is already fully described in the input schema (100% coverage). The description does not add extra meaning or constraints beyond what the schema provides.

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

Purpose5/5

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

The description uses specific verb 'Create' and resource 'new empty Maltego graph', distinguishing it from sibling tools by explicitly naming related tools (maltego_add_entity, maltego_add_link, maltego_save_graph) and mentioning the return of graphId for further use.

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 clearly indicates when to use this tool (to create a new empty graph) and implicitly guides the agent to use sibling tools (add_entity, add_link, save_graph) after creation, providing a logical workflow.

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

maltego_crtshC

Certificate Transparency search via crt.sh. Honors lookupTimeoutMs.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

The description mentions that the tool honors lookupTimeoutMs, indicating it respects a timeout setting. However, with no annotations provided, the description fails to disclose whether the tool is read-only, destructive, or its authentication requirements. Minimal behavioral context beyond the timeout 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/5

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

The description is very concise with two short sentences. It front-loads the purpose and adds one behavioral detail. No unnecessary words. However, it could be slightly more structured or include a brief usage hint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It states the purpose and one behavioral trait. But it lacks information about output format, typical use cases, or limitations, which would help an agent fully understand the tool's capabilities.

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

Parameters1/5

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

The only parameter is 'domain' with no schema description (0% coverage). The description does not add any additional meaning, such as format, validation, or examples. It simply restates the parameter name without elaboration.

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

Purpose4/5

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

The description 'Certificate Transparency search via crt.sh' clearly indicates the tool's purpose: searching certificate transparency logs for a domain using crt.sh. While it doesn't explicitly state a verb like 'search', the noun phrase sufficiently conveys the action. It distinguishes from sibling tools like dns or whois searches.

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 about when to use this tool versus alternatives such as maltego_dns, maltego_whois, or maltego_expand_domain. The only hint is 'Honors lookupTimeoutMs', which does not help an agent decide between tools.

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

maltego_dnsB

Run a DNS lookup (A / AAAA / MX / NS / TXT) for a domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only states the action without disclosing behavioral traits like read-only nature, side effects, or return format. Fails to add value beyond the name.

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

Conciseness4/5

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

Single sentence, direct and front-loaded. No wasted words, but slightly underspecified given the context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Basic information covers purpose and record types but lacks details on output, errors, or prerequisites. Adequate for a simple tool, but gaps remain.

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?

Only parameter 'domain' has no schema description; description adds minimal value by just restating 'for a domain'. No format or validation details provided.

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 clearly states the action (run DNS lookup), resource (domain), and specifies record types (A/AAAA/MX/NS/TXT). Distinguishes from siblings like whois or crtsh.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives like whois or expand_domain. Usage is implied by the description but not clarified.

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

maltego_expand_domainB

Build a .mtgx graph around a domain (whois + DNS + ASN per A record).

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes
`overwrite`	No
`outputPath`	Yes

TDQS

B3.2/5.0

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 'builds a .mtgx graph' but does not disclose side effects (e.g., file overwriting), authentication requirements, or what the graph contains beyond the listed data types. The 'per A record' hint is vague.

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

Conciseness4/5

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

The description is a single sentence, very concise. However, it could be slightly expanded to cover some of the missing parameter details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too minimal given the tool has 3 parameters with 0% schema coverage, no output schema, and no annotations. It fails to explain the return value or graph structure, leaving agents with insufficient context.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions 'domain' and 'output path' implicitly but does not explain the 'overwrite' parameter or provide format/constraint details. The 3 parameters are inadequately described.

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 builds a .mtgx graph around a domain and specifies the types of data included (whois, DNS, ASN per A record). This distinguishes it from sibling tools like maltego_whois, maltego_dns, and maltego_asn, which focus on individual data types.

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

Usage Guidelines3/5

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

The description implies this tool is for comprehensive domain investigation but does not explicitly state when to use it versus alternatives like maltego_whois or maltego_dns. No when-not or alternative guidance is provided.

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

maltego_expand_hashC

Build a .mtgx graph with a Hash entity (extend in later versions).

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes
`algorithm`	No
`overwrite`	No
`outputPath`	Yes

TDQS

C2.1/5.0

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 mentions building a graph but does not disclose whether it modifies an existing graph, permissions required, or side effects. The note 'extend in later versions' hints at incompleteness.

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

Conciseness3/5

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

The description is short (one sentence) but includes an irrelevant future promise ('extend in later versions') which wastes space. Lacks structure for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and 13 sibling tools, the description is vastly incomplete. It does not explain the tool's core action or how it differs from similar expand tools.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no information about any of the 4 parameters (hash, algorithm, overwrite, outputPath). The description fails to explain their purpose or format.

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

Purpose3/5

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

The description states the verb 'build' and resource '.mtgx graph with a Hash entity', but is vague about what 'expand' means. No distinction from sibling tools like maltego_expand_domain or maltego_expand_ip.

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 versus alternatives. No mention of prerequisites or typical use cases.

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

maltego_expand_ipC

Build a .mtgx graph around an IP (ASN + netblock).

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes
`overwrite`	No
`outputPath`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose behavioral traits such as file creation, overwriting behavior, or required permissions. It only states the action without 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.

Conciseness3/5

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

The description is a single sentence, which is concise but overly terse. It lacks structure and could be improved with more detail without losing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters and no output schema or annotations, the description is severely incomplete. It does not explain the graph's contents, parameter usage, or any prerequisites.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention any parameter details such as format for ip, path for outputPath, or the effect of overwrite. The description adds no value beyond the schema.

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

Purpose4/5

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

The description clearly states the tool builds a .mtgx graph around an IP and mentions ASN and netblock, which are specific to IP expansion. However, it lacks differentiation from similar expand tools beyond the IP type.

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 versus alternatives like maltego_expand_domain or maltego_expand_hash. The description does not provide any contextual cues for usage.

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

maltego_load_graphB

Load an existing .mtgx into a new graph handle. Returns the new graphId.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to a .mtgx file inside outputDir.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states it loads a file and returns a graphId. No disclosure of error handling, file existence requirements, or side effects on existing graphs. Minimal behavioral 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?

Two sentences, front-loaded with the verb and resource, no redundant information. Efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple load operation, the description covers the core purpose and return value. However, it omits potential issues like file not found or permission errors, and given no output schema, the return value is only mentioned but not detailed.

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

Parameters3/5

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

Schema description coverage is 100% for the single parameter 'path', which already has a clear description. The tool description adds no extra parameter semantics beyond implying the file type.

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

Purpose4/5

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

The description clearly states the action ('Load') and resource ('.mtgx file into a new graph handle'), and implies the result (returns graphId). It is specific and distinguishes from sibling tools like 'create' or 'save', though it does not explicitly differentiate.

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 (e.g., create_graph, save_graph). There is no mention of prerequisites or context in which loading is appropriate.

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

maltego_save_graphA

Save a graph to a .mtgx file inside the configured outputDir. Refuses to overwrite unless overwrite=true.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Output path. Resolved relative to outputDir; absolute paths must be inside outputDir.
`graphId`	Yes
`overwrite`	No

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses overwrite behavior but omits other aspects like side effects, success/failure responses, or permission requirements.

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

Conciseness5/5

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

Two concise, front-loaded sentences with no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and only 3 parameters, description covers the core purpose, constraints, and critical behavior. Minor gaps in return value and error handling.

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

Parameters3/5

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

Schema coverage is 33%. Description adds useful detail for path (relative to outputDir, absolute path constraint) but provides no extra info for graphId or overwrite 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?

Clearly states the action (save), resource (graph), format (.mtgx), and location (inside outputDir). Distinguishes from sibling tool maltego_load_graph.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. Doesn't mention prerequisites or when not to use (e.g., to export to other formats).

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

maltego_whoisB

Run a whois lookup for a domain. Returns registrar, nameservers, dates.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description accurately states the operation (read-only lookup) and lists returned fields. However, it omits details like rate limits, authentication requirements, or domain registration prerequisites. It adds some transparency but leaves significant gaps.

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

Conciseness4/5

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

The description is a single concise sentence that front-loads the action and outputs. It has no wasted words, but slight expansion by including a usage example or note about whois privacy could improve completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one parameter and no output schema, the description is adequate: it states the action and key return fields. However, it lacks examples, constraints, or edge-case behavior (e.g., unregistered domains), making it moderately complete.

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

Parameters2/5

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

The single parameter 'domain' has 0% schema description coverage, and the description only repeats 'domain' without specifying format (e.g., 'example.com') or valid inputs. The description adds minimal value beyond the parameter name, failing to compensate for the low schema coverage.

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

Purpose5/5

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

The description specifies the verb 'Run a whois lookup' and the resource 'domain', clearly distinguishing it from siblings like maltego_dns (DNS lookups) and maltego_expand_domain (domain expansion). The purpose is immediately understandable.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use whois over alternatives such as maltego_dns or maltego_expand_domain. No when-to-use or when-not-to-use context is given, leaving the agent to infer usage without comparative information.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.4.0Jul 1, 2026
- First observedmaltego_add_entity
- First observedmaltego_add_link
- First observedmaltego_asn
- First observedmaltego_build_ioc_graph
- First observedmaltego_create_graph
- First observedmaltego_crtsh
- First observedmaltego_dns
- First observedmaltego_expand_domain
- First observedmaltego_expand_hash
- First observedmaltego_expand_ip
- First observedmaltego_load_graph
- First observedmaltego_save_graph
- First observedmaltego_whois

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have distinct purposes (graph manipulation vs lookups vs expansions), but expand_domain overlaps with individual lookup tools (whois, dns, asn). This could cause an agent to pick the wrong tool for a specific lookup, though descriptions help differentiate.

Naming Consistency3/5

Tool names mix verb_noun (add_entity, create_graph) and bare nouns (asn, dns, whois). While all start with 'maltego_', the pattern is inconsistent. The use of 'expand_' vs 'build_' also adds minor inconsistency.

Tool Count5/5

13 tools is well-scoped for a Maltego integration covering graph creation/editing, lookups, and automated expansion. Each tool serves a clear purpose without bloat.

Completeness4/5

Core Maltego operations (create, add entity/link, save, load) are present, along with key lookups. Missing update/delete operations for graph elements, and some common lookups (e.g., reverse IP) are absent. Build_ioc_graph depends on external MCPs, limiting standalone completeness.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1
Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
hyperion
com.thetempleofdoom.hyperion
Hyperion — MCP tool marketplace for AI agents: web, OSINT, security, research via one key.
Browser Automation Penetration Testing Research & Data
1
oracle42-intelligence
io.github.mintmas
AI-powered threat intelligence, smart contract auditing, and cybersecurity OSINT.
Security Blockchain Penetration Testing
2

Related MCP Servers

bhe_mcp
Penetration Testing Security Databases
err0n-0x2A
A
license
A
quality
D
maintenance
Connects LLMs to BloodHound Enterprise for natural language attack path analysis, Cypher queries, and exploration of Active Directory, Azure/Entra ID, and OpenGraph environments.
Updated 4 months ago (2026-05-15 01:33 UTC)
20
GPL 3.0
MITRE ATT&CK MCP Server
Security Open Data Research & Data
imouiche
A
license
A
quality
D
maintenance
Enables AI-native access to the MITRE ATT\&CK framework, allowing LLMs and agents to query techniques, threat groups, software, and generate ATT\&CK Navigator layers for threat intelligence and security workflows.
Updated 8 months ago (2025-12-22 01:21 UTC)
65
76
5
Apache 2.0
Ontolocy MCP Serverofficial
Databases Knowledge & Memory Search
ontolocy
A
license
Not graded
quality
D
maintenance
Augments an LLM with Ontolocy cyber graph capabilities, enabling natural language queries against a Neo4j graph database populated with MITRE ATT\&CK data.
Updated a year ago (2025-06-17 15:46 UTC)
1
MIT
maltego-mcp
Open Data Data Visualization Search
SulimanAbdulrazzaq
A
license
A
quality
B
maintenance
Turns an LLM into a Maltego CE investigation copilot, enabling AI-assisted OSINT investigations by building, analyzing, and exporting Maltego graph files.
Updated 3 months ago (2026-06-15 19:17 UTC)
52
MIT

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/lidless-labs/maltego-mcp'

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

What it does

Install

Quickstart

Tools (Phase A)

Entity types

Composing with other MCPs

Configuration

Claude Desktop

Claude Code

OpenClaw

Hermes Agent

Codex CLI

Requirements

Maltego Basic compatibility

CLI

Starting the MCP server

Basic-friendly demo graph

Phase B: in-Maltego transforms (.mtz)

Example prompts

Why not a Maltego transform pack alone?

Why not just hand the LLM raw whois/DNS tooling?

What maltego-mcp is not

Development

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Ontolocy MCP Serverofficial

Latest Blog Posts

MCP directory API