Skip to main content
Glama

free_sample

Read-only

FREE (when enabled): try a service without paying. Either one keyword-metrics lookup for ONE keyword (send keyword), or one call of any service up to 0.05 USDC (send service and input, the same arguments as the paid tool). Returns the same JSON as the paid tool plus sample: true (no result_token). One sample per service per day per client, a shared daily total, and at most 3 failed samples per client and day; returns an error (sample_used, sample_exhausted or sample_failures) when a limit is hit. Packages such as local_market_check and services above 0.05 USDC have no sample: call list_services and check free_sample per service.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "free_sample"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputNoArguments for that service, same as the paid tool.
keywordNoLegacy keyword-metrics sample: one keyword, up to 60 characters.
serviceNoService id for a per-service sample, e.g. google-serp (see list_services, field free_sample).
language_codeNoLanguage code such as en or de.
location_codeNoCountry code, default 2840 (United States).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / input
      Added value: +{
      +  "description": "Arguments for that service, same as the paid tool.",
      +  "type": "object"
      +}
    • changedInput schema / properties / keyword / description
      Previous value: -"One keyword, up to 60 characters."New value: +"Legacy keyword-metrics sample: one keyword, up to 60 characters."
    • addedInput schema / properties / service
      Added value: +{
      +  "description": "Service id for a per-service sample, e.g. google-serp (see list_services, field free_sample).",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "keyword"
      -]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the per-service-per-day limit, the shared daily total, the 3-failed-samples cap, and the three named error codes (sample_used, sample_exhausted, sample_failures). It also discloses the return contract (same JSON plus `sample: true`, no result_token), which is the key behavioral difference from the paid path. No contradiction with readOnlyHint, since the call only reads data.

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?

Front-loaded with the core value and the mode split, then limits, then exclusions — a sound ordering with no filler sentences. It is dense and parenthetical, so it reads as a run-on, but every clause carries operational information (thresholds, error codes, alternatives).

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 tool with 5 optional, mode-dependent parameters and no output schema, the description still covers invocation modes, eligibility ceiling, quota rules, error returns, and the shape of the response. Nothing an agent needs to call it correctly or interpret a failure is missing.

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%, so baseline is 3, but the description adds real semantics the schema cannot: the two parameters are alternatives forming mutually exclusive modes, `input` must mirror the paid tool's arguments, and `service` must be one flagged free_sample in list_services. The only gap is that `language_code` and `location_code` are left to the schema.

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?

The description states a specific capability: a free-tier invocation of a paid service, with two explicit modes (one keyword-metrics lookup via `keyword`, or one call of any service up to 0.05 USDC via `service` + `input`). It also distinguishes itself from the paid siblings by noting it takes 'the same arguments as the paid tool' and returns the same JSON plus `sample: true`. An agent can tell exactly what this does versus `google_serp` or `keyword_metrics`.

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?

Explicit when-to-use ('try a service without paying'), explicit when-not (packages such as local_market_check and services above 0.05 USDC have no sample), and an explicit routing instruction ('call list_services and check free_sample per service'). Quota and failure-budget rules are spelled out with the exact error identifiers that signal them.

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