Web malware techniques, kits and EtherHiding contracts from Ohey's website scans. No sign-in.
Scored across 6 tools
Tools are mostly distinct: get_threat (single technique stats) vs list_threats (all techniques) and get_etherhiding_contract (one contract) vs search_etherhiding_contracts (query across contracts) are clear singular/plural and verb distinctions. Minor conceptual proximity between threat-listing and contract-lookup, but descriptions help an agent choose correctly.
All six tools follow a strict verb_noun camel-free snake_case pattern (get_*, list_*, search_*). The singular vs plural naming on get/list and get/search pairs is used intentionally and consistently.
Six tools is well-scoped for a niche threat-research server, covering threats, articles, contracts, and feed stats without redundancy. Each tool earns its place with no filler.
Covers the core lifecycle: list/summarize threats, read article listings, inspect contracts, and check feed health. Minor gap: there is no tool to fetch a single research article's full body or to search threats by keyword, only listing operations.
One contract's destinations over time, the contracts or endpoints it names next, and when Ohey first and last read it.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The contract address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context by spelling out the returned payload (destinations over time, linked contracts/endpoints, first and last read timestamps) — valuable since no output schema exists. It omits failure behavior for a missing address and any sense of result volume or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with no filler, and the scope qualifier is front-loaded. A couple of phrases are elliptical ('the contracts or endpoints it names next', the unexplained 'Ohey'), which costs a little immediate readability without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, single-parameter lookup with no output schema, the description does the heavy lifting by describing the returned fields. Remaining gaps are minor: not-found behavior and whether the time-series data is truncated or paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter and schema description coverage is 100%, with the address pattern and type fully documented in the schema. The description adds nothing about the address beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates what a caller gets back for a single contract: its destinations over time, the contracts or endpoints it names next, and first/last observation timestamps. That makes the resource and scope ('one contract's') clear, and the singular framing implicitly contrasts with search_etherhiding_contracts. It stops short of naming that sibling or using an explicit retrieval verb, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'One contract's...' signals a single-record lookup rather than a bulk/search operation, which is the natural split against search_etherhiding_contracts. There is no explicit when-to-use, no when-not-to-use, and no mention of what happens for an unknown or unobserved address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The size of the Ohey feed, hosts added, accepted, removed and denied over the last seven days, and the size of Ohey's capture archive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond that: it enumerates exactly what is aggregated and fixes the reporting period at the last seven days, implying a rolling window rather than a queryable range. It does not describe the shape of the response or whether metrics are aggregates versus lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the most important element (feed size) is front-loaded. The nested 'over the last seven days' clause spans a long list, but it is grammatical and adds no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only stats tool with annotations covering safety and no output schema, the description supplies the essential missing piece: what the returned numbers actually are. A brief note on response format or aggregation granularity would make it fully complete, but nothing critical for correct invocation is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies the tool is parameterless by framing everything as fixed-scope output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource — feed size plus hosts added, accepted, removed and denied over seven days, and the capture archive size — which is far more concrete than the title alone and clearly distinct from siblings like get_threat or search_etherhiding_contracts. It lacks an explicit verb ('returns'/'retrieves'), so it reads as a noun phrase rather than a stated action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives, and no indication of how these metrics should be interpreted or combined with the sibling threat/contract tools. The seven-day window is the only framing hint, and it is presented as part of the output content rather than as usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A technique or kit page's statistics: sites matched by month, how many sites were still infected when rescanned, WordPress and Joomla shares, common plugins and core versions, kits seen together on the same sites, its EtherHiding contracts and the articles about it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | A slug from list_threats, such as clickfix, etherhiding or socgholish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint false, and destructiveHint false, so the safety profile is covered. The description adds useful output-content context by listing the categories of statistics returned, but it does not disclose response shape, data freshness, pagination, or error behavior for invalid slugs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with dense, relevant content and no filler. Every listed statistic contributes to understanding what the tool returns, though the sentence is long and could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter with annotations and a fully described input schema, the description supplies useful output-content context in the absence of an output schema. However, it does not clarify usage sequencing with list_threats or disambiguate the included EtherHiding contracts and articles from the dedicated sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single slug parameter with 100% schema description coverage, including its pattern and examples such as clickfix and etherhiding. The description adds no meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a technique or kit page's statistics and enumerates the data returned, such as monthly matched sites, rescan infections, CMS shares, and related contracts/articles. It is clear what is retrieved, though it uses a noun phrase rather than a verb and does not explicitly contrast itself with list_threats or the EtherHiding/article sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. The schema does note that the slug comes from list_threats, but the description itself does not route the agent, and it leaves the overlap with get_etherhiding_contract and list_research_articles unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ohey research articles, newest first: incident write-ups with timelines, code analysis and indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| threat | No | Only articles about this technique or kit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the ordering guarantee (newest first) and the article content types, which is genuine extra context, but it says nothing about pagination, result caps, or what happens when no articles exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the ordering and content description front-loaded and no filler. The leading typo ("Ohey") and the missing verb slightly reduce immediate parseability but do not waste length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only listing tool with full schema coverage and annotations, the description is close to sufficient. It still leaves the agent guessing about result set size and pagination behavior, which matters for a list operation's planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional 'threat' parameter is documented in the schema with its pattern. The description never mentions the filter, so it adds no meaning beyond the schema, which lands at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (research articles) and describes their content precisely: incident write-ups with timelines, code analysis and indicators, plus the ordering (newest first). The verb is garbled by a likely typo ("Ohey"), and it does not distinguish itself from siblings like list_threats or get_feed_stats, keeping it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when to prefer this over sibling tools such as list_threats or get_feed_stats, and no indication of expected result volume. The only implied usage comes from the content description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every technique Ohey publishes, with its page, a summary, site counts and its kits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds what the response contains (page references, summaries, site counts, kits), but says nothing about result size, ordering, or pagination despite promising 'every' technique — a real gap for an unbounded listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the scope and then enumerates the returned fields; nothing is padding. The trailing field list ('its page, a summary, site counts and its kits') is slightly awkward in construction but still efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list tool with annotations covering safety and no output schema, the description supplies broadly the right picture of the return payload. The missing pieces — result volume and whether the full catalogue is dumped in one call — are moderate rather than fatal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter detail is missing because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource and scope clearly: every technique Ohey publishes, along with the fields returned (page, summary, site counts, kits). It lacks an explicit verb and never distinguishes itself from the sibling get_threat or search_etherhiding_contracts, and the switch from 'threats' in the tool name to 'techniques' here (and in the title) adds a small terminological wrinkle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Every' implies an unfiltered enumeration, which weakly signals that this is the bulk-listing counterpart to a filtered or single-item sibling. There is no explicit when-to-use statement, no when-not-to-use, and no alternative tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Smart contracts that compromised websites read their next stage from, as the EtherHiding contract tracker lists them: chain, kit, current destinations and when Ohey last read each one. Set destination to find the contracts that point, or pointed, at a host.
| Name | Required | Description | Default |
|---|---|---|---|
| kit | No | A kit slug, such as clearshort. | |
| chain | No | A chain name, such as Polygon or BNB Smart Chain. | |
| limit | No | ||
| destination | No | A host or URL, fanged or defanged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, closed-world behavior, so the description only needs to add context — which it does by disclosing the returned fields (chain, kit, current destinations, last-read timestamp) in the absence of an output schema. The phrase 'point, or pointed, at' usefully reveals that historical destinations are included, not just live ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the filter behavior is front-loaded within the second sentence. The opening clause is syntactically heavy and leads with a data definition rather than the action, which slows the agent slightly but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing what each record contains, and all filters except limit are semantically covered. It is nearly complete for a read-only lookup tool; default ordering, pagination, and behavior when no filters are given remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and documents kit, chain and destination, so the baseline is already adequate. The description still adds real meaning by clarifying that destination matching covers past as well as present pointers, which the schema's 'host or URL, fanged or defanged' wording does not convey; only limit is unexplained in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (EtherHiding-tracked smart contracts used as next-stage pointers by compromised sites) and enumerates the record fields. The retrieval action is only implied by the closing 'Set destination to find...' sentence, and the distinction from the singular sibling get_etherhiding_contract is left to the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
One concrete usage path is spelled out: set destination to find contracts pointing at a host. Filtering by chain and kit is only hinted at through the field list, and there is no guidance on when to prefer this over get_etherhiding_contract for a single record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_etherhiding_contractget_feed_statsget_threatlist_research_articleslist_threatssearch_etherhiding_contractsLook up hosts in the Ohey web malware feed, read CVEs and scan URLs with Ohey's scanner.
IOCs (URLs, domains, IPs, hashes) shared by the infosec community on X/Twitter. No auth, CC0.
Domain exposures: breaches, infostealers, ULP heap, cookies. Counts and samples, free.
Unit 42 malware analysis & threat research. $0.01/query. Register in-session — free testnet funds.
Add one secure layer between your agents and this server.
