Skip to main content
Glama
Sign In

CryptoSocials

by net.cryptosocials.api
OverviewDiscussionsAdmin

Describe archive

describe_archive
Read-only

Read stored counts or coverage diagnostics for an explicit UTC period and scope. This describes selected retained evidence, not all of X or a live collection watermark.

Input Schema

NameRequiredDescriptionDefault
textNo
date_toYesExclusive UTC end; required.
metricsNocoverage
asset_idsNoCanonical asset IDs from resolve_assets, not tickers or provider IDs.
chain_idsNoCoin chain IDs, e.g. solana, ethereum, base, robinhood. Includes confirmed stored V1, native and multichain associations; candidates, expired and unknown associations are excluded. Posts qualify through their attached coins.
date_fromYesInclusive UTC start; required. Maximum window 366 days.
has_mediaNo
asset_typeNoKnown asset relationship. With chain_ids, type must match on one of those chains; native and token relationships may coexist across chains. Unknown has no classified relationship.
author_idsNoCanonical author IDs from search_authors, not X handles or user IDs.
multichainNoTrue selects assets with at least two known chains. False means fewer than two KNOWN chains, not proven single-chain.
post_typesNo
evidence_classNoFilter standalone collected evidence versus retained embedded quote evidence; omitted includes both.
exclude_post_typesNoExclude selected types; excluding original also excludes historical unknown labels, while excluding repost keeps ordinary unknown labels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / text / properties / full_text_query / description
      Added value: +"Space-separated AND, spaced OR, quoted phrases and minus exclusions. No stemming: agent and agents differ. Unquoted parentheses unsupported; repeat common terms, e.g. AI agent OR AI agents."
  2. Changed2 schema fields changed
    • addedInput schema / properties / asset_ids / description
      Added value: +"Canonical asset IDs from resolve_assets, not tickers or provider IDs."
    • addedInput schema / properties / author_ids / description
      Added value: +"Canonical author IDs from search_authors, not X handles or user IDs."
  3. Changed1 schema field changed
    • changedInput schema / properties / exclude_post_types / description
      Previous value: -"Exclude only known types; excluding repost keeps unknown types."New value: +"Exclude selected types; excluding original also excludes historical unknown labels, while excluding repost keeps ordinary unknown labels."
  4. Changed1 schema field changed
    • addedInput schema / properties / metrics
      Added value: +{
+  "default": "coverage",
+  "enum": [
+    "counts",
+    "coverage"
+  ]
+}
  5. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly, non-destructive, non-open-world behavior, so the bar is lower. The description adds genuinely non-obvious interpretive context: results reflect selected retained evidence rather than a live collection snapshot, which is important for reading the output correctly. It does not cover cost, latency, or why idempotentHint is false.

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?

Two tight sentences with zero filler, and the core purpose is front-loaded before the scope caveat. It is arguably terse for a 13-parameter tool, but no sentence is wasted.

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

Completeness3/5

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

The description conveys the content categories (counts vs coverage diagnostics) and the retained-evidence scope, which partially offsets the missing output schema. However, for a 13-parameter diagnostic tool with no output schema and 31% undocumented parameters, it does not explain the shape of the returned diagnostics or how metrics interacts with the filters.

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 69%, so the schema carries most parameter meaning (asset_ids, chain_ids, author_ids, evidence_class, multichain, full_text_query are all well documented). The description itself adds no parameter-level guidance at all, so it neither compensates for the undocumented fields (metrics, has_media, post_types) nor enriches the documented ones.

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?

States a specific verb and resource: reading stored counts or coverage diagnostics over an explicit UTC period and scope. The second sentence differentiates it from a whole-dataset or live-watermark tool, though it never names the sibling (measure_evidence/discover_evidence) an agent should compare against.

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?

Usage is implied - diagnostics over a retained/archival period - and the description excludes what it is not ('not all of X or a live collection watermark'). But it never states when to prefer this over measure_evidence, discover_evidence, or read_evidence, leaving the routing decision to inference.

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

All CryptoSocials toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Directories

Listed in ChatGPT · CryptoSocials

Last observed

Resources