Skip to main content
Glama
thenavidm

ScrapeCreators MCP Server

by thenavidm

Profile

truth_social_profile

Fetch a Truth Social user's profile details like followers, following, statuses, and verified status. Requires confirm=true and paid credits; only prominent figures work.

Instructions

Retrieves a Truth Social user's public profile including display_name, username, avatar, header, followers_count, following_count, statuses_count, verified status, website, and created_at. Only prominent public figures (e.g., Trump, Vance) are accessible without authentication; most other accounts will not work. Potentially consumes paid API credits; requires confirm=true. Read-like POST requests do not publish to social platforms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleYesTruth Social username
accountNoNamed private ScrapeCreators account; selects credentials, not a remote account ID.
confirmNoMust be true for the specific approved credit-consuming research call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only give generic hints (readOnlyHint=false, openWorldHint=true). The description adds concrete traits beyond them: credit consumption, the confirm gate, partial authentication scope, and a clarification that the read-like POST does not publish to social platforms, which explains the non-read-only hint rather than contradicting it.

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?

Three sentences, front-loaded with the operation and its return fields, then constraints. The field enumeration is long but earns its place given there is no output schema; no filler sentences.

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 no output schema, the description compensates by listing returned fields, and it covers authentication scope, cost, and the confirm requirement for a 3-parameter tool. It could still say what happens on failure for non-prominent accounts, but nothing essential for a correct call is 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%, so all three parameters (handle, account, confirm) are already documented; the description only restates the credit/confirm behavior. Baseline 3 applies since the schema does the heavy lifting with no added syntax or format detail.

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?

States a specific verb (Retrieves) and resource (Truth Social user's public profile) and enumerates the exact fields returned (display_name, followers_count, verified, etc.), which sharply separates it from truth_social_user_posts and truth_social_post. An agent can identify the operation 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?

Gives an explicit usage boundary: only prominent public figures (Trump, Vance) are accessible unauthenticated, and most accounts will not work, plus the confirm=true prerequisite. It lacks a named alternative (e.g., twitter_profile) for the failing case, so it stops short of full routing guidance.

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