Skip to main content
Glama

SaSame MCP Observatory + Gold Rush Town

by online.sasame

research_corroborate

Read-only

Injection-quarantined EVIDENCE GRAPH for any research query. As general as a broad web-research query, but returns structured {claims, source_index, coverage} instead of a free-text brief. Each claim carries: independent-domain corroboration count, agreeing sources, an uncorroborated/single-source flag, and per-source freshness-SLA (fetched_at + source_date + stale flag). Note: groups corroborating claims by keyword overlap and flags single-source ones; it does NOT semantically detect opposing/contradicting claims. Zero upsell in any LLM-ingested field — all commercial content lives in _meta only. Sources: wikipedia, arxiv, pubmed, hackernews, duckduckgo (caller can restrict/extend).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesResearch question or claim to investigate
sourcesNoRestrict to a subset of sources: wikipedia, arxiv, pubmed, hackernews, duckduckgo. Default: all five.
intent_tokenNoFresh single-use token returned by register_intent; required for this gated tool.
freshness_daysNoFlag (do not drop) sources older than N days as stale so caller decides what to trust.
min_corroborationNoOnly return claims asserted by >= N independent registrable domains (default 1 = include all). Set 2+ for cross-confirmed-only.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • addedInput schema / properties / intent_token
      Added value: +{
+  "description": "Fresh single-use token returned by register_intent; required for this gated tool.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • removedInput schema / properties / intent_token
      Removed value: -{
-  "description": "One-time token from register_intent (required by some calling contexts)",
-  "type": "string"
-}
  4. Added

TDQS

A3.9/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), the description discloses injection-quarantine, the structured output format, per-claim details (corroboration count, freshness, single-source flag), and explicitly states it does not detect opposing claims. This provides rich 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed and front-loaded with the main purpose, but contains some jargon (e.g., 'Injection-quarantined', 'freshness-SLA') that may reduce clarity. It is appropriately sized for the tool's complexity.

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 output schema, the description adequately describes the return structure (claims, source_index, coverage) and details per-claim fields. However, it could be more precise about the exact output schema or format.

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 input schema has 100% coverage with descriptions for all five parameters. The description reiterates some parameter concepts (sources, freshness, corroboration) but adds no new semantic detail 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 returns a structured evidence graph for a research query, with specific outputs like claims, source index, and coverage. It distinguishes itself from a free-text brief but does not explicitly differentiate from sibling tools like claim_confirm or ecosystem_search.

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 for broad research queries but does not explicitly state when to use this tool over alternatives or provide exclusions. It mentions limitations (no opposing claim detection) but no alternative tool guidance.

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

All SaSame MCP Observatory + Gold Rush Town toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation2/5

With 94 tools spanning overlapping concepts (multiple readiness/audit/grade tools, many status checkers, deprecated aliases like trust_* vs observation_*), agents will frequently struggle to pick the right one. While each tool is individually distinct, the sheer volume and conceptual overlap (e.g., audit_mcp, readiness_report, verify_mcp_ready, lookup_readiness, recommend_mcp, subscribe_grade_changes) create high misselection risk.

Naming Consistency3/5

Most tools use snake_case with underscores, but the pattern is inconsistent: some are verb-first (audit_mcp, verify_mcp_ready, claim_start, check_engagement) while others are noun-first (receipt_issue, meter_open, work_order_open, agent_invoice_status). Deprecated aliases like trust_compare vs observation_compare further break consistency, though the majority remain readable.

Tool Count1/5

94 tools is far beyond any reasonable scope for a single server, even one with broad ambitions like 'observatory + town'. The calibration notes 50+ as extreme mismatch; this server far exceeds that. Many tools are highly specific (e.g., factory_resolve_dead_letter, visit_touch_status, start_here) and could be consolidated or split into separate servers.

Completeness3/5

The server covers a wide range of domains (auditing, claiming, receipts, meters, escrow, work orders, gold rush, town, analytics) and offers many CRUD-like operations, but several lifecycle gaps exist: no cancel/close for work orders (only open/accept/deliver/accept_delivery), escrow (only open/attest/status), or meters (only open/charge/status). Given the massive scope, important operations are missing, though core workflows are present.

Resources