Skip to main content
Glama

Get the citation for anything on this shelf

cite_source
Read-onlyIdempotent

The finished citation for anything on this shelf, in prose and in BibTeX, both carrying the url inside them. Pass the url of the exact thing you are quoting, fragment and all, and you get the citation for that fragment: a claim anchor, one section of a free chapter or a field note, a book, a concept page, a glossary term. Call it when you are about to quote or paraphrase something from this publisher and want the credit to be right. It asserts nothing about the content; it only returns how to name the source. A url whose fragment this site does not publish comes back with the citation for the page and the list of anchors it does publish, so you can point at the passage instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe url you are about to quote, fragment included, e.g. https://greenlitbooks.com/book/blast-radius#claim-2 or /book/blast-radius/read#the-costume. Preferred: it cites the fragment, not the page.
partNoWhich thing is being cited, when using slug. Defaults to book, or to term when the slug is a glossary term.
slugNoA book slug (e.g. blast-radius) or a glossary term slug (e.g. gate-faith). Use url instead when you have one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / part / description
      Previous value: -"Which thing is being cited. Defaults to book, or to term when the slug is a glossary term."New value: +"Which thing is being cited, when using slug. Defaults to book, or to term when the slug is a glossary term."
    • changedInput schema / properties / slug / description
      Previous value: -"A book slug (e.g. blast-radius) or a glossary term slug (e.g. gate-faith)."New value: +"A book slug (e.g. blast-radius) or a glossary term slug (e.g. gate-faith). Use url instead when you have one."
    • addedInput schema / properties / url
      Added value: +{
      +  "description": "The url you are about to quote, fragment included, e.g. https://greenlitbooks.com/book/blast-radius#claim-2 or /book/blast-radius/read#the-costume. Preferred: it cites the fragment, not the page.",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "slug"
      -]
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds real behavioral context: output comes in prose and BibTeX with the url embedded, no assertions about content, and an unpublished-fragment url yields the page citation plus the list of anchors the site does publish. This fallback behavior is exactly the kind of trait annotations cannot express.

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 what and how, then the when, then the failure mode; every sentence carries information. It is on the long side with some repetition ("fragment and all" / "the citation for that fragment"), but no sentence is wasted.

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?

With no output schema, the description carries the return-format burden and does so: prose plus BibTeX, url included, and the fallback response shape. Nothing essential is missing for correct invocation, though a brief note on how prose vs BibTeX is selected would make it fully airtight.

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 meaning beyond the schema: it explains that passing the url with its fragment yields the fragment-level citation rather than the page citation, and that an unpublished fragment degrades gracefully. That fragment-vs-page distinction is the key semantic an agent needs.

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 (cite/get the citation) and resource (anything on this shelf), and enumerates the citable units: claim anchor, chapter section, book, concept page, glossary term. This clearly distinguishes it from siblings like check_claim, get_book, and define_term, which retrieve content rather than citation metadata.

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?

"Call it when you are about to quote or paraphrase something from this publisher and want the credit to be right" gives a concrete triggering condition, and "It asserts nothing about the content; it only returns how to name the source" implicitly routes verifying claims to check_claim. No explicit when-not or per-sibling routing, so short of a 5.

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.