Skip to main content
Glama

Extract keywords

extract_keywords
Idempotent

Exposes POST /keywords. Returns the 5–15 terms and phrases that best represent the page, ordered by relevance — ranked by a language model, not by raw frequency. 15 credits.

As with summarize_page: if you are going to reason over the result yourself, fetch_markdown costs 1 credit and gives you everything.

Input Schema

NameRequiredDescriptionDefault
urlYesThe page to fetch. Must be a public http(s) URL.
syncNoWait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
labelsNoYour own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
max_ageNoHow fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
report_toNoAsync only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
project_idYesWhich project this request belongs to. From list_projects.
residentialNoFetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
auth_profileNoLoad the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles
page_optionsNoWhat to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them.
idempotency_keyNoMakes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / auth_profile
      Added value: +{
      +  "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / page_options / description
      Previous value: -"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too."New value: +"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them."
    • addedInput schema / properties / page_options / properties / scroll_to_bottom
      Added value: +{
      +  "description": "Scroll down the page before reading it, for as long as scrolling loads more (up to 25s). For listings and feeds that load their content as they are scrolled.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / page_options / properties / block_popups
      Added value: +{
      +  "description": "Remove newsletter, app-install and promotional popups laid over the page.",
      +  "type": "boolean"
      +}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "anyOf": [
      +    {
      +      "properties": {
      +        "keywords": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "keywords"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "properties": {
      +        "labels": {
      +          "type": "object"
      +        },
      +        "status": {
      +          "const": "accepted",
      +          "type": "string"
      +        },
      +        "token": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "token",
      +        "status"
      +      ],
      +      "type": "object"
      +    }
      +  ],
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare openWorldHint, non-readOnly and idempotent, so the bar is lower, but the description still adds genuinely useful behaviour: a fixed 15-credit price, the LLM-based ranking semantics of the output, and the cheaper sibling's cost for comparison. It does not restate anything the annotations cover and creates no contradiction with readOnlyHint=false given the credit charge. Async vs sync mechanics are left to the schema.

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?

Four short sentences, front-loaded with purpose and ranking semantics before cost and the alternative. 'Exposes POST /keywords' is the only near-dead weight, restating a transport detail most agents will not act on. Nothing else could be cut without losing routing value.

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?

For a 10-parameter tool with a nested object and an output schema, the description covers what the tool produces, its cost, and when to prefer the cheap alternative — the remaining gaps (async collection, caching, webhooks) are fully documented in the schema. Only the boundary against the other extraction tools is unstated.

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 description coverage is 100%, including nested page_options, sync/async, max_age caching and idempotency_key, so the schema carries the parameter burden entirely. The description adds no parameter-level meaning of its own. Baseline 3 is correct when the schema is this complete.

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 ('Returns the 5–15 terms and phrases that best represent the page') and pins down the ranking method ('ranked by a language model, not by raw frequency'), which is exactly the differentiator an agent needs against extract_metadata or scrape_url. It also routes to fetch_markdown for the case where the agent will do its own reasoning, which distinguishes it from siblings without opening their schemas.

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 an explicit when-to-use-something-else rule: if the agent intends to reason over the result itself, fetch_markdown at 1 credit is the better call than 15 credits here. That is concrete, cost-anchored guidance. It stops short of exclusions against other extraction siblings (extract_metadata, extract_data, summarize_page) where the boundary is left implicit via the 'As with summarize_page' analogy.

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