maltego-mcp

Server Quality Checklist

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

Latest release: v0.4.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.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on July 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

[![maltego-mcp MCP server](https://glama.ai/mcp/servers/lidless-labs/maltego-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lidless-labs/maltego-mcp)

Score Badge

Copy to your README.md:

[![maltego-mcp MCP server](https://glama.ai/mcp/servers/lidless-labs/maltego-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lidless-labs/maltego-mcp)

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