Skip to main content
Glama

Search The Durability Curve

search
Read-onlyIdempotent

Search or list the public archive of The Durability Curve: essays on which kinds of work keep their value as AI gets cheaper, the checked claims in each essay's claim ledger, the dated calls printed in The Durability Curve Weekly, the five laws and two derived principles the essays are tested against, the free tools, and AI model releases. With a query, returns ranked matches, each with its kind (essay, claim, call, law, tool or model), a snippet and a URL (canonical for essay citations); "title_matched" says whether any essay title contains every word of the query, and "none_found" is true when nothing matches enough of the query (the nearest misses are then under "closest", not "results"). With an empty query, lists newest first, filtered by kind, series, has_ledger or access, and "total" counts every match. Read a match in full with get_essay, get_claim_ledger, get_weekly_calls or get_ai_models. These tools retrieve The Durability Curve's public material. They do not certify that any claim is true.

Input Schema

NameRequiredDescriptionDefault
kindNoOnly this kind of result: essay, claim, call, law (the framework's laws and principles), tool (the free tools) or model (AI model releases). A list (empty query) defaults to essays.
sortNorelevance (default for a query) or newest. A list is always newest first.
limitNoHow many results to return, 1 to 25. Default 5.
queryNoWhat to look for, in plain words, e.g. "agent reliability", "memory chip deposits", a call ID like "W02-5" or a model name like "Claude Opus 5.5". Leave empty to LIST instead (newest first), with the filters below.
accessNoOnly essays a reader of durabilitycurve.com gets in full ("free") or only in part ("part paid": the rest is for paid subscribers).
seriesNoOnly essays (and their claims) in this series, e.g. "The Blueprint". Case does not matter.
has_ledgerNotrue: only essays that have a claim ledger. false: only essays without one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / access
      Added value: +{
      +  "description": "Only essays a reader of durabilitycurve.com gets in full (\"free\") or only in part (\"part paid\": the rest is for paid subscribers).",
      +  "enum": [
      +    "free",
      +    "part paid"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / kind / description
      Previous value: -"Only this kind of result: essay, claim, call, law (the framework's laws and principles) or tool (the free tools). A list (empty query) defaults to essays."New value: +"Only this kind of result: essay, claim, call, law (the framework's laws and principles), tool (the free tools) or model (AI model releases). A list (empty query) defaults to essays."
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "essay",
      -  "claim",
      -  "call",
      -  "law",
      -  "tool"
      -]New value: +[
      +  "essay",
      +  "claim",
      +  "call",
      +  "law",
      +  "tool",
      +  "model"
      +]
    • changedInput schema / properties / query / description
      Previous value: -"What to look for, in plain words, e.g. \"agent reliability\", \"memory chip deposits\" or a call ID like \"W02-5\". Leave empty to LIST instead (newest first), with the filters below."New value: +"What to look for, in plain words, e.g. \"agent reliability\", \"memory chip deposits\", a call ID like \"W02-5\" or a model name like \"Claude Opus 5.5\". Leave empty to LIST instead (newest first), with the filters below."
  2. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"Only this kind of result. A list (empty query) defaults to essays."New value: +"Only this kind of result: essay, claim, call, law (the framework's laws and principles) or tool (the free tools). A list (empty query) defaults to essays."
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "essay",
      -  "claim",
      -  "call"
      -]New value: +[
      +  "essay",
      +  "claim",
      +  "call",
      +  "law",
      +  "tool"
      +]
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-open-world and non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: the ranked-match response shape, 'title_matched', the 'none_found'/'closest' fallback, and the explicit caveat that retrieved material is not certified true.

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 and mode distinction are front-loaded and each clause carries information (response fields, fallback behavior, sibling routing, trust caveat). The downside is that it reads as one dense run-on paragraph, which makes it harder to scan than a segmented version would be.

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 7 parameters, no output schema and no nested objects, the description covers what an agent needs: both call modes, what each result contains, how near-misses surface, and where to go for full content. Nothing material is left for the agent to guess.

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 the baseline is 3, but the description adds cross-cutting meaning the schema alone doesn't: a list defaults to essays, sort is relevance for a query but always newest for a list, and query accepts call IDs and model names. These are useful behavioral notes rather than restatements.

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 opens with a specific verb and resource ('Search or list the public archive of The Durability Curve') and enumerates the content types it spans (essays, claim ledgers, weekly calls, laws, tools, models). It also distinguishes itself from the get_* siblings by routing to them for full reads.

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?

It states the two modes clearly: with a query you get ranked matches, with an empty query you get a newest-first list filtered by kind/series/has_ledger/access. It names get_essay, get_claim_ledger, get_weekly_calls and get_ai_models as the way to read a match in full. It does not address when to use this over the related_to sibling.

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