Provides tools to run the TinyRex RSS feed scraper, enabling collection of items from RSS feeds via Apify.
Provides tools to run the TinyRex Shopify products scraper, enabling extraction of product data from Shopify stores via Apify.
Provides tools to run the TinyRex WooCommerce products scraper, enabling extraction of product data from WooCommerce stores via Apify.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TinyRex MCP look up the LEI for Siemens AG with gleif-lei-lookup"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Run TinyRex Apify Store actors from any MCP-capable AI agent (Claude Desktop, Cursor, and others) using your own APIFY_TOKEN.
This is a thin stdio Model Context Protocol server: it lists the public TinyRex actors and starts a run, then returns dataset items (capped for MCP hosts).
Actors are pay-per-event (PPE) on Apify. Failed or empty runs are often free under TinyRex pricing — check each actor’s Store page. You pay Apify with your own account; this MCP does not bill separately.
Python 3.11+:
pip install git+https://github.com/emirmrkaljevic/tinyrex-mcp.git
# or clone and:
# pip install -e .Requires an Apify API token in the environment as APIFY_TOKEN.
Related MCP server: web-data-mcp
mcpServers){
"mcpServers": {
"tinyrex": {
"command": "tinyrex-mcp",
"env": {
"APIFY_TOKEN": "YOUR_APIFY_TOKEN"
}
}
}
}If the script is not on PATH, use the module form:
{
"mcpServers": {
"tinyrex": {
"command": "python",
"args": ["-m", "tinyrex_mcp"],
"env": {
"APIFY_TOKEN": "YOUR_APIFY_TOKEN"
}
}
}
}Tool | What it does |
| Lists all 17 public TinyRex actors (name, title, description, Store URL, example input). |
| Runs |
list_actors → find gleif-lei-lookup
run_actor with:
{
"actor": "gleif-lei-lookup",
"input": { "companyNames": ["Siemens AG"], "maxResultsPerName": 1 },
"max_items": 5
}Actor | Store |
tech-stack-detector | |
ats-jobs-scraper | |
shopify-products-scraper | |
workday-jobs-scraper | |
woocommerce-products-scraper | |
ted-tenders-scraper | |
eu-grants-scraper | |
remote-jobs-scraper | |
rss-feed-scraper | |
sitemap-scraper | |
contact-details-extractor | |
us-uk-tenders-scraper | |
tenderned-tenders-scraper | |
seo-on-page-audit | |
broken-link-checker | |
gleif-lei-lookup | |
uk-companies-house-lookup |
Private / ToS-blocked actors are not exposed.
docker build -t tinyrex-mcp .
docker run --rm -i -e APIFY_TOKEN=YOUR_APIFY_TOKEN tinyrex-mcppython -m venv .venv && source .venv/bin/activate
pip install -e .
APIFY_TOKEN=... tinyrex-mcp # stdio MCPSmoke-test helpers (list tools + one cheap run) live in scripts/smoke_test.py.
MIT. Brand: TinyRex. Store username: tinyrex.
List all public TinyRex Apify Store actors this MCP can run.
Returns name, title, short description, Store URL, and an example input for each actor. Private / ToS-blocked actors are not included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The 'List' verb signals a read-only, side-effect-free operation, and it proactively discloses filtering behavior by naming what is excluded (private and ToS-blocked actors) -- a genuinely useful behavioral trait. It does not address auth requirements, result size, or pagination, which keeps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, followed by the return shape and then the exclusion caveat. No sentence is wasted and the most important information comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool, the description covers what is returned and what is deliberately omitted, and an output schema exists to carry the exact return structure. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to clarify beyond confirming the call is argument-free, and the schema reflects that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all public TinyRex Apify Store actors') with scope qualifiers that tie it to run_actor's capability set ('this MCP can run'). An agent immediately understands this is the enumeration/discovery tool, clearly distinct from run_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: it enumerates exactly the actors run_actor can execute, but the description never says 'call this first to discover valid inputs for run_actor' or notes any preconditions. The exclusion clause ('Private / ToS-blocked actors are not included') is helpful context but is not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a TinyRex Apify actor and return dataset items.
Args: actor: Actor name (e.g. "gleif-lei-lookup") or "tinyrex/". input: Actor input object (same fields as on the Apify Store). Use list_actors exampleInput as a starting point. max_items: Max dataset items to return (default 50). Total count is always included. timeout_secs: How long to wait for the run to finish (default 180). memory_mbytes: Optional memory override for the run (Apify default if omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | ||
| input | No | ||
| max_items | No | ||
| timeout_secs | No | ||
| memory_mbytes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits: the run can be waited on ('How long to wait for the run to finish', default 180s), memory can be overridden, and total count is always returned. However it omits what happens on timeout, whether the run is billed/quota-limited, and any auth requirement, which matters for an externally-executed job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line purpose leads, followed by a compact per-argument block. Every entry is substantive and front-loaded; only the restatement of defaults that also live in the schema is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape explanation is rightly omitted, and all parameters are covered. For a networked, long-running execution tool the description stops short of error/timeout behavior and any auth or rate/quota caveats, leaving that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does: it documents all five parameters with meaning, example format for actor ('gleif-lei-lookup' or 'tinyrex/<name>'), the input-object convention ('same fields as on the Apify Store'), and the semantics of max_items (50 default, total count always included). Minor gap: memory_mbytes lacks units/guidance beyond 'Apify default if omitted'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a TinyRex Apify actor') plus the return ('return dataset items'), which distinguishes it from the sibling list_actors. It references list_actors explicitly as a source for input examples, giving partial sibling differentiation, but never says plainly 'use list_actors to discover actors, use this to execute one'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one concrete routing hint ('Use list_actors exampleInput as a starting point'), which implies a read-then-run workflow, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (Apify token/auth) or cost implications of launching a run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_actorsrun_actorScored across 2 tools
The two tools have clearly distinct purposes: list_actors for discovery and run_actor for execution. There is no overlap, and the descriptions explain their relationship through the exampleInput field.
Both names follow a consistent snake_case verb_noun pattern: list_actors and run_actor. The verbs are distinct and the noun is consistent.
Only two tools are provided, which is below the typical 3-15 range and may feel thin for a server that might need run management. However, for the narrow scope of discovering and running actors, it could be sufficient.
The surface covers actor discovery and execution, including example inputs and result retrieval. However, it lacks operations for managing runs (e.g., status, cancellation, or retrieving past runs), which agents might need for long-running or async actors.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
