Skip to main content
Glama

pull_content

Pull licensed creator content from a specific pocket by ID. Use this tool when an AI agent needs to retrieve verified, provenance-tracked content for generation, RAG, and inference use. Training use requires a separate training license — see training_use in the agreement terms. Do NOT use for browsing or discovery — use search_pockets or list_pockets instead. Requires a valid Bearer token for authentication; unauthenticated requests return HTTP 402. Successful pulls trigger a metered charge at the pocket's own price (quoted as owner_price on the receipt; $0.0025 platform default only when a pocket sets none) and the transaction is logged for creator royalty distribution. The pocket_id parameter is a 24-character hex string identifying the specific content pocket to pull from. Returns the full content payload with provenance metadata including creator attribution and license terms. Every call returns a receipt of the same shape (receipt_id, outcome, reason, amount_paid, terms, content_hash, and agent_count / agent_work_count: how many times this agent has accessed the owner's account and this work, this call included) with a public verify_url: on success under 'receipt' in the result (outcome 'delivered'), on an HTTP 402 refusal under 'receipt' in the error body (outcome 'refused', reason 'registration_required' when no valid API key is presented, 'payment_required' when the wallet balance is too low or the card charge fails). A pocket whose rights holder has closed its catalog is refused for every caller, with or without a key, as a normal result (not a 402) with reason 'catalog_closed', owner_price null and the receipt under 'receipt'; nothing is delivered or charged. A listing-only pocket (delivery 'listing' in search results) has no file: its pull is charged the owner's per-pull price like any other and returns delivery 'listing' with 'content' set to the listing object {title, isrc, owner, terms, link} and no download URL. content_hash is the sha256 hex of the delivered 'content' field only: a string is hashed as its UTF-8 bytes, an object as UTF-8 JSON with sorted keys and no whitespace.

Input Schema

NameRequiredDescriptionDefault
queryNoOptional natural language focus query used to narrow or contextualize the returned content within the selected pocket.
pocket_idYesThe 24-character hex identifier of the content pocket to pull from. Obtain this from search_pockets or list_pockets results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

No annotations exist, and the description carries the full burden: Bearer token auth with HTTP 402 on failure, metered per-pull charging with owner_price vs platform default, royalty logging, the full receipt taxonomy including refused/catalog_closed outcomes, and listing-only pocket behavior. This is exactly the behavioral context an agent needs before incurring a charge.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage are correctly front-loaded, but the second half is a dense wall of run-on sentences packing receipt shapes, error outcome enums, and the content_hash algorithm into unstructured prose. The content is substantive, but the delivery is hard to parse and would improve as a short structured list.

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?

With no output schema, the description fully documents return values: provenance metadata, receipt fields, verify_url placement on success vs 402 error bodies, and the content_hash computation. For a paid, auth-gated tool, nothing an agent needs to call or interpret results 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 coverage is 100%, so the baseline is 3. The description restates pocket_id as a 24-character hex string (already in the schema) and never mentions the optional 'query' parameter, so it adds little semantic value beyond structured fields.

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+resource+scope: 'Pull licensed creator content from a specific pocket by ID.' It also names the sibling tools it is not ('Do NOT use for browsing or discovery — use search_pockets or list_pockets instead'), so an agent can route correctly without comparing schemas.

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 states the use case (retrieval of verified, provenance-tracked content for generation, RAG, inference), the exclusion (browsing/discovery), the named alternatives, and the licensing boundary (training requires a separate license).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources