Skip to main content
Glama
pulpminercom

PulpMiner

Official
by pulpminercom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Save a page-to-JSON config as a reusable API

pulpminer_save_as_api

Save a webpage URL and desired JSON format as a PulpMiner API endpoint, then call it with an API key; add {{ variable }} placeholders for dynamic queries.

Instructions

Save a URL + JSON format as a PulpMiner API (POST /external/ai/json/save). Afterwards the data is available at {baseUrl}/external/{apiId} with the apikey header (see pulpminer_fetch_api_data). For a dynamic API, pass dynamicUrl with {{ variable }} placeholders, e.g. https://site.com/search?q={{ query }}; callers then supply those variables. Saving itself is free; each later fetch costs 0.4 credits (+0.1 with renderJs). Needs only the PulpMiner API key (PULPMINER_API_KEY locally, or Authorization: Bearer <key> on the hosted server).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
llmNoLLM used to convert HTML to JSON. llm_2 = OpenAI GPT (default), llm_1 = Google Gemini, llm_3 = Groq (only if enabled for the account; otherwise the API returns 'bad request').llm_2
urlYesPage URL the API scrapes (for dynamic APIs: an example URL with real values).
cacheNoCache results: serve cached JSON (24h TTL) and refresh in the background when older than 15 min.
scraperNoScraper backend. scraper_1 (default, supports useSession) or scraper_2. Try the other one if a site blocks scraping.scraper_1
renderJsNoRender JavaScript in a headless browser before extracting (default true; adds 0.1 credits).
selectorNoCSS selector to limit extraction to part of the page, e.g. "main" or "#results". Default: whole body.
dynamicUrlNoOptional URL template with {{ variable }} placeholders. When set the API becomes dynamic and must be called with variables.
jsonFormatYesRequired. The JSON shape the API should return, usually the output of pulpminer_generate_json (values can be left as examples).
useSessionNoUse a persistent scraping session (scraper_1 only; ignored for lifetime-plan accounts).
extraLLMInfoNoExtra natural-language instructions for the LLM, e.g. 'only the first 10 products, prices as numbers'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Adds behavior well beyond the annotations: the resulting access URL shape and required `apikey` header, the credit model (saving free, 0.4 per fetch, +0.1 with renderJs), and the two auth paths (PULPMINER_API_KEY locally, Authorization Bearer on the hosted server). This is exactly the mutation/cost/auth context an agent needs and annotations do not supply.

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?

Purpose is front-loaded in the first clause and each subsequent sentence covers a distinct concern (dynamic templating, cost, auth) with no filler. It is denser than necessary for a single paragraph and could be split, but nothing is wasted.

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?

For a 10-parameter mutation tool with no output schema, the description covers the returned identifier (apiId used in the fetch URL), authentication, cost implications, and the dynamic-variable workflow, while the schema documents every parameter. An agent has everything needed to call it 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 description coverage is 100%, so the baseline is 3; the description adds a concrete dynamicUrl template example and explains that callers must then supply the placeholders, which slightly exceeds what the schema states. It does not otherwise elaborate on the other eight parameters, so it is an incremental rather than decisive gain.

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 and resource: 'Save a URL + JSON format as a PulpMiner API', and names the concrete endpoint (POST /external/ai/json/save). It also positions itself against siblings by implying the jsonFormat comes from pulpminer_generate_json and the result is read back with pulpminer_fetch_api_data.

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 clear context for when this tool applies (after producing a JSON format; when a page should be exposed as a reusable/dynamic API) and points to pulpminer_fetch_api_data for consuming the result. It stops short of explicit when-not-to-use or a direct sibling comparison (e.g. vs pulpminer_list_saved_apis), so it is strong but not exhaustive.

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