Universal Poison Armor

Overview Schema Source Related Servers Discussions Admin

Verify Article Consensus

verify_article_consensus

Audit search results and news articles to defend against consensus poisoning and Sybil attacks by validating domain authorities and detecting coordinated duplicate content via semantic similarity.

Instructions

Verify web search results or news articles to defend against Consensus Poisoning and Sybil attacks.

Audits domain Top-Level Domains (validating trusted authorities like .gov, .edu) and calculates pairwise semantic cosine similarities to detect coordinated flooding campaigns where multiple untrusted sources syndicate near-identical (similarity > 0.95) fake consensus.

Usage Guidelines:

WHEN TO USE: Use whenever 2 or more web search results, news articles, or online references are retrieved for a breaking topic, controversial issue, or factual query to verify that apparent consensus is not an artificial Sybil campaign.
WHEN NOT TO USE: Do NOT use for individual document text sanitization (use sanitize_document instead) or unsupervised corpus outlier detection (use scan_dataset_for_anomalies instead).

Behavior & Side Effects:

Audits domain provenance against verified authoritative TLDs (.gov, .edu, .mil, .int).
Computes pairwise cosine similarity matrix across article embeddings.
Appends timestamped alerts to security_audit.json if a coordinated Sybil attack is detected.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`articles`	Yes	A list of article objects. Each object must be a dictionary containing: - 'url' (str): The origin URL of the article. - 'text' (str): The body or extracted content of the article. - 'title' (str, optional): The headline/title of the article.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses algorithmic behavior (auditing trusted TLDs, computing pairwise cosine similarity, threshold >0.95) and the side effect of appending timestamped alerts to security_audit.json only when an attack is detected. This is transparent about both computation and potential writes.

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 well-structured with separate Usage Guidelines and Behavior & Side Effects sections. Each sentence earns its place: the purpose is front-loaded, and the WHEN NOT TO USE section clearly names alternatives without fluff. It is detailed but not redundant.

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

Completeness5/5

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

Given the single fully documented parameter, an output schema, explicit usage boundaries, and disclosed side effects, the description is complete for an agent to select and invoke the tool correctly. It even names sibling tools for alternative cases, so no critical information is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by framing the 'articles' parameter as untrusted sources involved in possible coordinated flooding, and it clarifies the similarity threshold. However, it does not add new parameter-level details such as examples or additional constraints beyond the schema.

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

Purpose5/5

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

The description states a specific verb and resource: 'Verify web search results or news articles to defend against Consensus Poisoning and Sybil attacks.' It also explains the distinctive mechanism (TLD audit + pairwise semantic cosine similarity) and explicitly distinguishes itself from sibling tools in the WHEN NOT TO USE section by naming sanitize_document and scan_dataset_for_anomalies.

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

Usage Guidelines5/5

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

Provides explicit WHEN TO USE instructions for scenarios with 2+ sources on breaking, controversial, or factual queries, and explicit WHEN NOT TO USE with named alternatives. An agent can determine tool selection unambiguously without additional inference.

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

Deploy Server