Search The Durability Curve: essays, claim ledgers, weekly calls, its five laws and free tools.
Scored across 4 tools
Each tool targets a distinct resource: essay text, claim ledger, weekly calls, and archive search. Descriptions clearly delineate the boundaries between retrieval tools and discovery via search.
Three tools follow a consistent get_<resource> snake_case pattern, while 'search' breaks the verb_noun convention. The deviation is minor and the overall naming remains predictable.
Four tools is a lean but reasonable set for a focused content retrieval server. However, the breadth of content types (essays, claims, calls, laws, tools) suggests one or two more retrieval tools could be justified.
Core content types (essays, claim ledgers, weekly calls) have dedicated retrieval tools, but laws, principles, and free tools appear only in search results with no way to read them in full. This creates a dead end for those match kinds.
Get the claim ledger for one essay: each load-bearing claim it makes, the source it was checked against, the quoted words, where in the source they appear, the date the source was read, and a status saying how the claim was checked. The response defines every status. Claims removed during checking are listed separately under "struck", with the reason; they are not claims the essay makes. Only some essays have a ledger: search results and get_essay link to one when it exists. These tools retrieve The Durability Curve's public material. They do not certify that any claim is true.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The essay's slug, as in durabilitycurve.com/claims/<slug>/. Get it from search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description is free to add real value — that the response defines every status and that removed claims appear separately under 'struck' and are not claims the essay makes. That clarifies output semantics in a way annotations cannot. It doesn't cover rate limits or failure behavior, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the resource and its contents, then the 'struck' caveat, then routing and scope disclaimers. All carry information, though the closing certification disclaimer could arguably be consolidated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 burden of describing return values and it does so thoroughly — contents, statuses, and the struck section. Combined with the routing precondition, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single slug parameter is already documented with its source ('as in durabilitycurve.com/claims/<slug>/. Get it from search'). The description adds no format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get the claim ledger for one essay') and then enumerates exactly what the ledger contains — claims, source, quoted words, location, read date, status. The mention that search and get_essay link to a ledger when one exists helps an agent place it relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent the precondition ('Only some essays have a ledger: search results and get_essay link to one when it exists') and the scope limitation (public material, no truth certification). It stops short of an explicit 'do not call for essays without a ledger' instruction, but the routing context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full public text of one Durability Curve essay as markdown. Its frontmatter carries the title, date, series and canonical URL, and a link to the essay's claim ledger when it has one. For a paid essay only the free part is public, and the text says where it stops. When citing, link the canonical URL in the frontmatter. These tools retrieve The Durability Curve's public material. They do not certify that any claim is true.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The essay's slug: the last part of its address, as in durabilitycurve.com/blog/<slug>/. Lowercase letters, digits and hyphens. Get it from search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantive behavior: paid essays expose only the free portion and the text marks where it stops, frontmatter carries title/date/series/canonical URL and a claim-ledger link, and the tool does not certify claim truth. That is real context beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and output format, then metadata and caveats. The closing 'these tools retrieve...' sentence is slightly generic but earns its place by scoping expectations for citation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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-value burden well: markdown body, frontmatter fields, claim-ledger link, and truncation behavior for paid essays. Nothing needed to call or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the slug format and provenance are already documented in the schema. The description adds nothing new about the parameter (the 'get it from search' hint duplicates the schema text), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the full public text of one Durability Curve essay as markdown') and its output format, which cleanly separates it from get_claim_ledger and search. An agent can identify the tool's job without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description points to 'search' as the way to obtain the slug and notes that these tools only retrieve public material, which implies usage. However, it never states when to choose this tool over get_claim_ledger, nor any preconditions beyond obtaining a slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the calls printed in The Durability Curve Weekly: dated, checkable predictions, each with the confidence printed at the time and the date or event it resolves on. The wording is exactly as printed and never changes after publication. outcome is null until a call resolves. These tools retrieve The Durability Curve's public material. They do not certify that any claim is true.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | open, resolved or all (default). | all |
| resolves_before | No | YYYY-MM-DD. Only calls whose latest resolution date is before this day, earliest first. A call that resolves on an event "or" a date counts by that date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, non-destructive, and closed-world hints. The description adds that wording never changes after publication and that outcome is null until resolution, which are meaningful behavioral constraints beyond the structured annotations. It does not, however, mention pagination, rate limits, or output shape. Given the annotation coverage, this is a useful addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are front-loaded with the core purpose, then a behavioral detail, then a scope disclaimer. All sentences are relevant and none are filler, though the final sentence about not certifying truth is a scope caveat rather than operational guidance. It remains appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with a full schema and rich annotations, the description supplies the key behavioral facts (immutable published wording, null outcome pre-resolution) and a scope disclaimer. It omits return format and pagination, but with no output schema and the current level of detail, it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema itself. The description notes that calls are 'dated' and have resolution dates, but adds no syntax or filtering semantics beyond what the schema already states for status and resolves_before. Baseline 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it retrieves 'the calls printed in The Durability Curve Weekly.' It further distinguishes the content (dated, checkable predictions with confidence printed at the time and resolution date/event) from what sibling tools likely cover. An agent can identify exactly what this tool returns without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for retrieving weekly calls, but it never explicitly says when to use it versus siblings such as get_claim_ledger or search. There are no exclusions or alternative-tool routing statements. For a read-only retrieval with a clear domain, this is adequate but not rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and the free tools. With a query, returns ranked matches, each with its kind (essay, claim, call, law or tool), a snippet and the canonical URL; "title_matched" says whether any essay title contains every word of the query. With an empty query, lists newest first, filtered by kind, series or has_ledger, and "total" counts every match. Read a match in full with get_essay, get_claim_ledger or get_weekly_calls. These tools retrieve The Durability Curve's public material. They do not certify that any claim is true.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | 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. | |
| sort | No | relevance (default for a query) or newest. A list is always newest first. | |
| limit | No | How many results to return, 1 to 25. Default 5. | |
| query | No | 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. | |
| series | No | Only essays (and their claims) in this series, e.g. "The Blueprint". Case does not matter. | |
| has_ledger | No | true: only essays that have a claim ledger. false: only essays without one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description goes further by disclosing the return shape (kind, snippet, canonical URL), the meaning of title_matched and total, and an important epistemic caveat that results are not certified as true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the scope of the archive before detailing query vs list behavior, and every sentence carries information. It is dense as a single block and slightly long, but there is little filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by describing the match fields and the total counter, plus the query-vs-list duality. For a six-parameter read tool with no output schema, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter is already documented with enums, defaults, bounds and examples. The description mostly restates those semantics (empty query lists, kind filtering) rather than adding new syntax or constraints, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search or list) and enumerates the exact resources covered: essays, claim ledgers, weekly calls, laws/principles, and tools. It also names the sibling tools used to read a match in full, so an agent can distinguish search from retrieval without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly branches on the query parameter: a non-empty query returns ranked matches, an empty query lists newest-first filtered by kind/series/has_ledger. It names the alternatives (get_essay, get_claim_ledger, get_weekly_calls) and when to escalate to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search2 fields changedInput schema / properties / kind / descriptionPrevious 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."Input schema / properties / kind / enumPrevious value: -[
- "essay",
- "claim",
- "call"
-]New value: +[
+ "essay",
+ "claim",
+ "call",
+ "law",
+ "tool"
+]get_claim_ledgerget_essayget_weekly_callssearchSearch, read & publish paid essays. Pay-per-read in USDC on Base (x402); wallet-only, no account.
Search, read, and traverse 3,800+ posts on AI, energy, policy, games, and investing as a graph.
Search and read essays by Ben Milne on payments, stablecoins, and company building.
Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Add one secure layer between your agents and this server.
