Skip to main content
Glama
Sign In
honesty-mcp

honesty-mcp

by lkopietz3-byte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Score how organic unattributed signals look

assess_anonymous_authenticity

Assess unattributed sentiment signals for organic consensus, diversity, volume, and recency, flagging single-source concentration and near-uniform praise as statistically unusual for human review.

Instructions

Scores how organic a corpus of UNATTRIBUTED, scraped sentiment signals (crawled mentions, imported reviews with no verifiable identity, aggregator feeds) looks, weighing a positive composite of consensus/diversity/volume/recency against a heuristic penalty for two specific, cheap manipulation patterns: evidence concentrated in a single source, and suspiciously uniform sentiment (near-maximal with near-zero variance -- the fingerprint of copy-pasted or purchased praise). This is NOT a fraud or astroturf detector: it cannot show that sentiment is fabricated or that any reviewer is fake, and a campaign that varies its wording/sentiment and spreads across several sources isn't caught by these two checks. Treat a low score as 'looks statistically unusual in a specific way worth a human look', not as a fraud finding. Use this for reviews/mentions/buzz with no identity behind them. For signals from known, identified contributors, use score_trust_identified instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "signals": "<signals>",
      "now": "<now>"
    },
    "name": "assess_anonymous_authenticity"
  }
}

Input Schema

NameRequiredDescriptionDefault
nowYesISO 'now' timestamp recency decay is computed against. Pass a fixed value for determinism.
configNoPartial override merged over the library's illustrative EXAMPLE_ANONYMOUS_CONFIG -- omit to use the example config as-is.
signalsYesThe unattributed signals to assess. May be empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explains the positive composite, the two specific penalty patterns, and the tool's limits (it cannot show fabrication and misses varied, multi-source campaigns). It does not explicitly state side-effect purity or deterministic behavior beyond the schema's now parameter.

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 purpose is front-loaded, and the description is dense but largely earns its length by covering scope, interpretation, and limitations. Some sentences are long, but the complexity of the tool justifies most of the space.

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?

The description gives rich context for a complex scoring tool, including scope, interpretation, and caveats. Because there is no output schema, it would be stronger if it specified the return score's range or shape, but it is still sufficient to call the tool correctly.

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%, so the schema already documents all three parameters and nested config properties thoroughly. The description adds conceptual meaning about consensus/diversity/volume/recency and the two manipulation checks, but no additional parameter-level semantics 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 opens with a specific verb and resource: it scores how organic a corpus of unattributed, scraped sentiment signals looks. It clearly distinguishes itself from the sibling score_trust_identified and explicitly states what kind of signals it handles.

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?

It gives explicit when-to-use guidance (reviews/mentions/buzz with no identity behind them) and names the alternative tool for identified contributors. It also clarifies when not to over-interpret the result, saying a low score is not a fraud finding.

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

Deploy Server

Other Tools