Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_x_users_item

Retrieve an X user profile from a dataset by username, with or without @; returns stored account details or 404 without a live scrape.

Instructions

Get an X user from the dataset. Returns one X user from the dataset by username, with or without a leading @. The record has name, bio, location, external URL, avatar and banner, followers, following, posts, likes, listed count, blue-verified flag and verified type. An unknown username returns 404; no live scrape runs.

Input Schema

NameRequiredDescriptionDefault
usernameYesX username, with or without a leading @, max 128 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations the description carries the full load, and it delivers two genuinely useful traits: unknown usernames return 404, and 'no live scrape runs' (the data is served from the dataset rather than freshly fetched). Auth/permission requirements are not covered, keeping it short of a 5.

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 tight sentences, front-loaded with the verb and key, then the return shape, then the edge case. The field enumeration is long but earns its place since there is no output schema; slightly verbose but not wasteful.

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, enumerating the record fields is the right compensation, and the 404 behavior plus data-source note cover the important edge cases. Only auth/permission context is missing, which is a minor gap for a read-style lookup.

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 coverage is 100% and the schema description already states 'with or without a leading @, max 128 characters'. The description's '@' note merely repeats the schema, adding no syntax or format detail beyond it, 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?

States a specific verb ('Get') and resource ('an X user from the dataset') and pins the retrieval key ('by `username`'). 'Returns one X user' makes the single-item semantics explicit, which cleanly separates it from the item-vs-search/facets siblings in the datasets_x_users family.

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 'by `username`' phrasing implies this is a direct-lookup tool, but no alternative is named and no when-to-use condition is stated. It never tells the agent to run datasets_x_users_search first to discover a username, nor when this is preferable to the facets tool.

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