SiteCheck Agent Intel & Dev

TrustRadius software product summary: product name, vendor

dev_trustradius

Read-only

TrustRadius software product summary: product name, vendor, category, TrustRadius score (out of 10) and rating count, product description, TrustRadius' review digest (overview, top pros and cons, number of reviews it is based on) and the top industries using the product (share of tracked installs). Takes the product slug from trustradius.com/products//reviews. Via a rendering residential proxy. Related tools on this server, for a different need: dev_producthunt when you need Product Hunt launches featured on the homepage feed for one; dev_sherdog when you need Sherdog MMA fighter profile by Sherdog fighter id: name. Price: $0.02 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "product": "<product>"
    },
    "name": "dev_trustradius"
  }
}

Input Schema

Name	Required	Description	Default
`product`	Yes	Product slug as in trustradius.com/products/<slug>/reviews, e.g. slack, salesforce-sales-cloud, jira

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description is not burdened with the safety profile. It still adds real behavioral context beyond the annotations: retrieval goes through a rendering residential proxy, each successful call costs $0.02 in USDC via x402 on Base/Solana/Arc, and failed calls are not charged. It stops short of covering rate limits or latency/retry behavior.

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?

Content is front-loaded with the returned fields, followed by input source, routing, and pricing. It is one long run-on sentence and the field enumeration partly duplicates the output schema, but no sentence is truly filler given the cost and proxy disclosures.

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?

With an output schema present, the description need not restate return values, yet it does list them anyway; the essential gaps (input derivation, cost, payment mechanism, proxy, sibling routing) are all covered. Only retry/rate-limit expectations and behavior on an invalid slug are missing.

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% and the single parameter already documents the slug format with examples. The description repeats the same slug source, adding no syntax or edge-case guidance (e.g., what to do for a missing or ambiguous slug), so the baseline 3 applies.

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 names a specific resource (TrustRadius software product summary) and enumerates exactly what comes back: product name, vendor, category, score out of 10, rating count, description, review digest, and industry share. It explicitly distinguishes itself from the two named siblings (dev_producthunt, dev_sherdog), so an agent can place it without opening the schema.

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?

It states the input source clearly (slug taken from trustradius.com/products/<slug>/reviews) and routes alternative needs to dev_producthunt and dev_sherdog. It does not say when this tool should be avoided (e.g., for non-software products or for review-level granularity), but the usage context is otherwise unambiguous.

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

All SiteCheck Agent Intel & Dev tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?