Skip to main content
Glama
apify

actors-mcp-server

Official
by apify

Fetch Actor details

fetch-actor-details
Read-onlyIdempotent

Get detailed information about any Apify Actor by ID or full name, including input schema, README, pricing, stats, and MCP tools. Use output flags to select exactly what you need.

Instructions

Get detailed information about an Actor by its ID or full name (format: "username/name", e.g., "apify/rag-web-browser").

Requires the exact ID or full name — do not construct a plausible-looking name and call this tool with it. If you only have a description, a partial name, or a name you have not seen in this conversation, find it with search-actors first.

Use 'output' parameter with boolean flags to control returned information:

  • Default: All fields true except mcpTools

  • Selective: Set desired fields to true (e.g., output: { inputSchema: true })

  • Common patterns: inputSchema only, description + readme, mcpTools for MCP Actors

The 'readme' field returns the summary when available, full README otherwise. Use when querying Actor details, documentation, input requirements, or MCP tools.

EXAMPLES:

  • What does apify/rag-web-browser do?

  • What is the input schema for apify/web-scraper?

  • What tools does apify/actors-mcp-server provide?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesActor ID or full name in the format "username/name", e.g., "apify/rag-web-browser".
outputNoSpecify which information to include in the response to save tokens.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
readmeNoActor README summary when available, otherwise the full README documentation.
mcpToolsNoMarkdown listing of MCP tools exposed by the Actor (only present when `output.mcpTools` is requested).
actorInfoNo
inputSchemaNoActor input schema.
outputSchemaNoOutput schema inferred from successful runs.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.14.2
    • removedOutput schema / properties / actorInfo / properties / stats / properties / successRate
      Removed value: -{
      -  "description": "Success rate percentage",
      -  "type": "number"
      -}
  2. Changed2 schema fields changedv0.11.5
    • addedOutput schema / properties / actorInfo / properties / pictureUrl
      Added value: +{
      +  "description": "Actor picture URL",
      +  "type": "string"
      +}
    • changedOutput schema / properties / actorInfo / properties / pricing / required
      Previous value: -[
      -  "model",
      -  "userTier"
      -]New value: +[
      +  "model"
      +]
  3. First observedv0.10.13

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful details beyond that: default output fields, readme fallback behavior, and how the output parameter controls response content. No contradictions found.

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?

Well-structured and front-loaded with purpose, then usage constraints, output explanation, and examples. Slightly long but every section serves a clear function; no fluff.

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

Completeness5/5

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

Given the nested output object with many flags, the description covers defaults, common patterns, and usage scenarios comprehensively. The output schema exists, so return values are well-specified. Agent has everything needed to call correctly.

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 100% with detailed parameter descriptions. The description adds extra value by explaining default behavior, common patterns, and examples, which goes beyond the schema's structure.

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?

Description clearly states the tool retrieves detailed Actor information by ID or full name, with a specific format example. It differentiates from siblings like search-actors and call-actor by focusing on detail retrieval rather than searching or execution.

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

Usage Guidelines5/5

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

Explicitly instructs when to use this tool vs. search-actors, warns against constructing plausible names, and provides concrete usage scenarios (docs, input schema, MCP tools). This is exceptionally actionable guidance.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/apify/apify-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server