Skip to main content
Glama

Check US public-domain status

check_public_domain
Read-only

Check whether a specific book, film, song, recording or artwork is in the US public domain, and the date it enters it. Use this instead of answering from memory when the work was published 1929–1963 (its status depends on a copyright renewal that models usually don't know), when the work is obscure, or when you need a citable answer before quoting, reprinting, adapting, selling or training on it. Looks up 2.38M US Copyright Office registrations and 434k renewals; a title is usually enough for 1923–1977 books. Returns status, date, confidence, a one-line reason and record IDs, plus a second opinion from HathiTrust's human copyright reviewers and a free-copy link when there is one. Add countries=uk,eu,canada,australia,japan,china,india (or all) to get the answer for those countries in the same call. Not charged if it can't answer. Costs $0.01 (x402, USDC on Base).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "check_public_domain"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoKind of work (default book)
yearNoYear of first publication; inferred for 1923–1977 books when omitted
titleYesTitle of the work
authorNoAuthor, composer or creator (improves matching)
originNoCountry of first publication
countriesNoAlso answer for other countries: comma-separated uk, eu, canada, australia, japan, china, india, or all. Same price.
work_for_hireNo
author_death_yearNoFor works published 1978 or later

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / countries
      Added value: +{
      +  "description": "Also answer for other countries: comma-separated uk, eu, canada, australia, japan, china, india, or all. Same price.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses things annotations cannot: the underlying corpus (2.38M registrations, 434k renewals), the returned fields including a HathiTrust second opinion and free-copy link, a no-charge-if-unanswerable policy, and the $0.01 x402/USDC-on-Base payment mechanism. Cost and refund behavior are exactly the kind of operational context an agent needs before invoking a paid tool, and nothing contradicts openWorldHint=false, since the lookups are a fixed database.

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?

The opening sentence front-loads what the tool does, and the when-to-use conditions follow immediately. It is dense and runs long, with pricing details tacked onto the final sentence, but nearly every clause carries information an agent needs; only the 'Not charged if it can't answer. Costs $0.01...' pair reads as slightly bolted-on.

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 must carry the return contract and it does: status, date, confidence, one-line reason, record IDs, a HathiTrust reviewer second opinion and a free-copy link. Inputs, cost, refund policy and geographic extension are all covered, so an agent can call this correctly without further context.

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 already 88%, so the baseline is 3, but the description adds real matching guidance the schema does not: 'a title is usually enough for 1923–1977 books' and that year is inferred in that range. The countries parameter is described in the prose as well, including that it is the same price, though work_for_hire and author_death_year are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (US public-domain status for a named work) and scopes it precisely to books, film, songs, recordings and artwork, with an explicit note that multi-country answers come back in the same call. It never distinguishes itself from the sibling 'check_public_domain_full', so an agent must guess which of the two to pick for a fuller query.

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?

Usage conditions are unusually concrete: use it rather than answering from memory when the work was published 1929–1963, when the work is obscure, or when a citable answer is needed before quoting, reprinting, adapting, selling or training. What's missing is routing against the sibling tools (check_public_domain_full, search_copyright_renewals, copyright_rules_for_year), which are never mentioned.

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.