Skip to main content
Glama
leo-guinan

Community Archive Connector

by leo-guinan

Likes and follows

ca_account_relations
Read-only

Retrieve archived likes, followers, or following for a Twitter/X account with cursor pagination, returning up to 500 records per page and optional multi-page traversal.

Instructions

Archive-derived likes, followers, or following for an account. Cursor-paged, up to 500 per page.

Input Schema

NameRequiredDescriptionDefault
kindYes
limitNo
cursorNonext_cursor from a previous call.
accountYesUsername (e.g. exgenesis) or numeric account ID. Prefix a numeric username with @.
max_pagesNoPages to follow in one call (default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior: results are archive-derived (i.e. a historical snapshot, not live data) and pagination is cursor-based at up to 500 per page. It stops short of disclosing that max_pages lets a single call span up to 10 pages, or what happens when the account exceeds the archive window.

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?

Two short sentences: the resource first, then the paging behavior. Nothing is redundant with the title, and every clause carries information.

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?

With no output schema, the description leaves the shape of a relation record undefined (does a follower entry include handle, ID, timestamp?). The default of one page per call is only visible in the `max_pages` schema text, so a caller could under-fetch. Adequate for a simple list tool but not fully self-sufficient.

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 coverage is 60%; the two gaps are `kind` (enum with no description) and `limit` (bounds only). The description compensates for both by enumerating the three relation types and stating the 500-per-page cap, so it adds real meaning on top of 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?

States a concrete resource (likes, followers, or following for an account) and its provenance (archive-derived), which an agent can map to the `kind` enum without opening the schema. It does not distinguish itself from nearby siblings such as ca_relation_overlap or ca_find_people, which is the only thing keeping it from a 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no named alternative. An agent cannot tell from the description when to pick this over ca_relation_overlap or ca_find_people, nor any prerequisite (e.g. that the account must exist in the archive).

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