Five sourced lines from a video, podcast, article or PDF, and a check that a quote is in its source
Scored across 7 tools
Tools mostly target distinct purposes: check_memory is a batch version of check_quote; get_yank retrieves a specific yank by slug while get_lines_for_url retrieves everything held for a source URL; search_lines searches extracted lines while search_transcripts searches full transcripts. The batch/single and slug/URL distinctions are clear, but check_memory vs check_quote and get_yank vs get_lines_for_url could still cause slight hesitation for an agent.
Most names follow a verb_noun pattern (check_memory, check_quote, get_yank, search_lines, search_transcripts). recent_yanks is adjective_noun and get_lines_for_url includes a preposition, which are minor deviations but still readable and predictable in context.
Seven tools are well-scoped for a verification and search server: two check operations, two get operations by different identifiers, one recent listing, and two search scopes (lines vs transcripts). Each earns its place without redundancy or sprawl.
The surface covers reading, searching, and checking quotes, but there is no tool to create or extract a new yank, despite descriptions referencing 'yank it first' and yankThisPartUrl. This leaves a notable gap in the lifecycle, as agents cannot add sources to the library through this server.
check_quote over a batch, for auditing what an agent wrote down earlier. Give it up to 10 remembered claims, each with the source it is attributed to, and it returns the same verdict and receipt for every one: FOUND, CLOSE MATCH, DISTILLED MATCH, NOT FOUND or CAN'T ESTABLISH, with where, the speaker and the class of that claim, the passage, which representation was read and how much of it, and when. Reach for it when a note, a memory store or a shared workspace has accumulated claims nobody re-checked, and you want the ones no source supports. The summary counts verdicts and lists the claims that came back NOT FOUND; it is deliberately not a score, a percentage or a trust rating, because a NOT FOUND is bounded to the representation Yank read and is never a claim that the words were not said. A claim whose source is audio Yank would have to transcribe returns CAN'T ESTABLISH rather than being paid for. No model is consulted anywhere in this: every verdict resolves against the representation itself, and none of them is a judgement on whether a claim is true.
| Name | Required | Description | Default |
|---|---|---|---|
| claims | Yes | The remembered claims to check, up to 10 per call. Each one is checked against its own source. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world safety, and the description adds substantially more: the full verdict taxonomy, what the summary counts and lists, the deliberate refusal to produce a score or trust rating, the CAN'T ESTABLISH rule for audio sources, and the guarantee that no model is consulted. It also bounds the meaning of NOT FOUND to the representation read, which is exactly the kind of caveat an agent needs before acting on a negative result.
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 identity of the tool and the batching rule, and most sentences carry unique information (verdict list, summary shape, audio caveat). The closing pair of clauses about 'not a score' and 'not a judgement on whether a claim is true' restate the same caveat and could be merged, costing it the top mark.
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 carries the full burden of describing return values — and it does, enumerating every verdict plus the receipt fields (where, speaker, class, passage, representation read, timestamp) and the summary's contents. Nothing an agent needs in order to interpret the response 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 coverage is 100% and the single nested param is fully documented, so baseline 3 applies. The description restates the 10-claim cap and the statement/source pairing but adds no format or syntax detail beyond what the schema already says.
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 ('check_quote over a batch') and names the exact scope: auditing remembered claims against attributed sources. It directly distinguishes itself from the sibling check_quote by framing itself as the batch form, so an agent can route single vs. bulk checks without opening either 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?
'Reach for it when a note, a memory store or a shared workspace has accumulated claims nobody re-checked, and you want the ones no source supports' gives a concrete triggering situation. The batch framing implies check_quote is the single-claim alternative, but the description never states that exclusion explicitly, so routing is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yank Check: a statement and the source it is supposed to come from, in; a verdict and a receipt, out. FOUND (the words are in the representation Yank inspected), CLOSE MATCH (substantially the same wording, with the difference shown), DISTILLED MATCH (a passage shares most of the statement's content words but not its literal words; shared words can say the opposite, so read the passage), NOT FOUND (Yank inspected an adequate representation and could not find support), or CAN'T ESTABLISH (Yank could not obtain or inspect enough evidence; the reason says why). With where (a moment for media, the publisher's page opened on the exact words for an article), speaker with the class of that claim (file-stated, representation-stated, not-established), the passage around it, which representation was read (captions, transcript, article text, filing, document) and how much of it (inspected: words, duration), and when. A NOT FOUND is a bounded claim scoped to the representation read, never a claim that the words were not said; a CLOSE MATCH lists the words that differ (difference.tokens), never a similarity number; every verdict carries one plain sentence (finding). No model is consulted: the verdict resolves against the representation itself. Sources Yank already holds check immediately; an article, a public PDF (located by page) or a captioned video is read for the check; audio that would need transcribing is not spent on here and returns CAN'T ESTABLISH with acquisition_required, so yank it first. None of the verdicts is a judgement on whether the statement is true.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The public http(s) link the statement is supposed to come from. | |
| statement | Yes | The words to check, as claimed. One claim at a time, up to 600 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich context beyond annotations: defines all five verdicts, explains that no model is consulted, that NOT FOUND is a bounded claim about the representation, that CLOSE MATCH lists difference tokens, and that every verdict carries a finding. Annotations only cover read-only/idempotent safety, so the description does the heavy lifting on behavior.
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-loads the core input/output, but then delivers a dense, run-on block of verdict definitions and caveats without structural breaks (e.g., bullet lists). Each clause adds some value, but the wall of text is not optimally concise or scannable.
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 thoroughly explains return fields (where, speaker, passage, representation, inspected, when, finding, difference.tokens) and the meaning of each verdict. It also covers limitations (no truth judgement, bounded NOT FOUND) and the audio edge case, making it complete for this tool.
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 schema already documents both parameters (statement and source). The description only restates them in passing and adds no format or constraint detail beyond what the schema provides, so 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 (check) and resource (statement against its source), and describes the output (verdict and receipt). Implicitly distinguishes from siblings by directing audio that needs transcription to 'yank it first' (get_yank) and by defining its scope as checking against already-held representations.
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 says when sources are checked immediately (ones Yank already holds, articles, public PDFs, captioned video) and when not (audio needing transcription returns CAN'T ESTABLISH with acquisition_required, so yank first). This clearly routes the agent to the alternative tool for unacquired media.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask before you extract: everything yank.info already holds from one source URL. Any form of the link works (a youtu.be short link with a timestamp, a watch URL with a playlist, an article with tracking parameters, an Apple Podcasts or Overcast episode link); equivalent URLs return the same answer. Returns real counts (yanks, lines, verbatim lines) and, for up to five yanks, every line with its verbatim flag, timestamp, moment link, context and permanent card URL. Zero yanks is an answer, not an error. Reads the library only; never fetches the source.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The source URL in any of its forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, and the description adds substantial behavior beyond them: equivalent URLs return the same answer (URL normalization/determinism), 'zero yanks is an answer, not an error' (empty-result semantics), 'for up to five yanks' (truncation cap), and 'never fetches the source' (side-effect guarantee). No contradiction with annotations.
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, each earning its place and front-loaded in order: purpose, parameter semantics, return format/empty semantics, and safety guarantee. The parenthetical URL-form list is long, but it justifies its length by making the hard-to-guess normalization behavior concrete.
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 must carry the return contract, and it does: real counts (yanks, lines, verbatim lines) plus per-line details for up to five yanks. It also covers empty-result semantics, the truncation cap, and the no-fetch safety guarantee, leaving nothing missing for a single-parameter, read-only tool.
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 coverage is 100%, but the description converts the schema's generic 'in any of its forms' into actionable specifics: youtu.be timestamp short links, playlist watch URLs, tracking-parameter-laden articles, Apple Podcasts/Overcast episodes. It also attaches the normalization guarantee to the sole parameter, materially enriching the single url field.
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?
Opens with the directive 'Ask before you extract' and names the resource precisely: 'everything yank.info already holds from one source URL.' The breakdown of return values (counts, lines, verbatim flags, timestamps, moment links, card URLs) makes the scope concrete, and the strict one-URL focus differentiates it from the search/quote siblings without needing to name them.
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?
'Ask before you extract' frames the tool as a pre-extraction lookup, giving clear workflow context for when it should be called first. However, no sibling tool is mentioned, so there is no explicit when-not-to-use routing; the boundary versus search_lines and get_yank must be inferred from the 'one source URL' vs. query/ID framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a yank (five extracted lines from one source) by its slug, the last path segment of a yank.info/y/ URL. Includes every line's verbatim flag, timestamp, moment link, surrounding context, permanent card URL, share image, plus the whole yank as Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | e.g. stanford-connect-the-dots-looking-1s52rgg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds valuable behavioral context beyond annotations by enumerating the response contents (verbatim flag, timestamp, moment link, surrounding context, permanent card URL, share image, and Markdown), which helps the agent anticipate the output structure. No contradiction with annotations.
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?
The description is a single, compact sentence that front-loads the action and then lists the included data fields. It is informative without being verbose, and every clause contributes to understanding the tool's function and output. The structure is clear and easy to scan.
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 simple single-parameter tool with annotations covering safety and no output schema, the description is fully adequate. It covers what a yank is, how to identify it, and what the response includes. There are no missing pieces that would prevent an agent from calling the tool correctly. Even without an output schema, the description preemptively details the return payload.
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?
The schema provides a single 'slug' parameter with an example, but the description adds semantic meaning by explaining the slug is 'the last path segment of a yank.info/y/<slug> URL'. This clarifies how to derive the value, going beyond the schema's example. With 100% schema coverage, the description adds supplementary context that improves parameter understanding.
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 clearly states the verb 'Fetch' and the resource 'a yank', and details exactly what is retrieved (five extracted lines, verbatim flag, timestamps, etc.). It defines the identifier (slug) as the last path segment of a yank.info/y/<slug> URL, making the tool's function unambiguous and distinct from sibling tools like search_lines or recent_yanks.
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 the tool should be used when you have a specific slug and need comprehensive details of a single yank. However, it does not explicitly mention when not to use it or compare with sibling tools like check_quote or get_lines_for_url. There is no guidance on alternative selection, but the required parameter and identifier format make the usage context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest yanks in the library, one card each (rank-1 line, author, source type, URL).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety behavior is covered. The description adds useful output-format context (one card each with specific fields) and implies recency ordering, which goes beyond the structured data. It does not mention pagination or limit effects, but those are minor for a read-only listing.
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?
The description is a single sentence that front-loads the core purpose ('newest yanks') and packs the key output detail into a parenthetical. There is no redundant wording or 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?
For a simple read-only listing tool with one parameter, the description plus annotations and schema provide enough to call it correctly. It specifies the output structure and the ordering, though it omits any usage boundary with sibling tools and does not clarify that limit controls how many cards are returned.
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?
The description never mentions the 'limit' parameter, and schema_description_coverage is 0%. Even though the schema fully constrains the parameter with default, minimum, and maximum, the description adds no semantic meaning or guidance about how the limit behaves in relation to the returned cards.
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 clearly states the tool returns the newest yanks in the library and specifies the card structure with rank-1 line, author, source type, and URL. It does not explicitly contrast itself with sibling tools like get_yank or search_lines, so it stops short of full differentiation.
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?
No guidance is provided about when to use this tool versus alternatives such as get_yank, search_lines, or get_lines_for_url. There are no conditions, exclusions, or hints about when this tool is preferred, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across every line yank.info has ever extracted. Returns quotable lines with a verbatim flag (true = literal substring of the source transcript; false = labeled paraphrase), the speaker/author, the source, a timestamp and a moment link where the source is a video, and the permanent card URL to cite. Supports quoted phrases and a leading minus to exclude a word.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words, a name, a show, or a quoted phrase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description goes beyond by detailing the exact return structure (verbatim flag semantics, source, timestamp, moment link, permanent URL) and query capabilities (quoted phrases, negation), giving the agent concrete expectations beyond the structured fields.
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?
The description is dense but efficient: it front-loads the core function, then lists output fields, then query syntax. There is no fluff or redundancy; every sentence contributes essential information, making it highly scannable for an agent.
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 search tool with no output schema, the description covers scope, return fields, and query syntax sufficiently. It does not mention pagination or sorting, but the limit parameter is present and defaults are known. Minor gap: no explanation of what happens when no results are found, but this is acceptable for typical search usage.
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 coverage is 50% (only query has a description). The description enriches query semantics by explaining quoted-phrase and minus-exclusion syntax, which is valuable. However, the limit parameter is undocumented in both schema and description, and the description does not address it, so compensation is incomplete.
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 clearly states the tool performs full-text search across every line yank.info has ever extracted, and enumerates the returned fields (verbatim flag, speaker, source, timestamp, moment link, card URL). This unambiguously distinguishes it from siblings like get_lines_for_url or get_yank, which target specific URLs or yanks.
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 usage as a general search over the whole corpus but does not explicitly state when to use it vs. alternatives like check_quote or recent_yanks. It mentions query syntax (quoted phrases, minus) but offers no exclusions or comparison to sibling tools, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search inside the whole transcripts of every podcast and video yank.info has yanked, not only their five lines (§10.424). Returns moments: the source, where in it (startSeconds, endSeconds), the words around the match (snippet, the match between « and »), a moment link that opens the source at that second, and yankThisPartUrl, which yanks the few minutes around it. The words are a machine transcript (representation: transcript), not a checked line: to quote one, yank that part or use check_quote. Supports quoted phrases and a leading minus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words, a name, or a quoted phrase, as it might have been said. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds real context beyond them: the words are a machine transcript rather than a checked line, the units returned are 'moments', and query syntax (quoted phrases, leading minus) is supported. It does not state result-count limits or failure modes.
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-loads the core purpose and search scope, then layers return shape, a quotability caveat, and syntax support. Dense with parentheticals but every sentence carries information; nothing is 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?
With no output schema, the description takes on the burden of describing returns and does so concretely (source, startSeconds/endSeconds, snippet with «» markers, moment link, yankThisPartUrl). Combined with the annotation-covered safety profile and the transcript caveat, an agent has enough to call and interpret the tool.
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 coverage is 50% (query is documented, limit is bare), so the description must compensate. It adds genuine meaning by describing query syntax (quoted phrases, leading minus) beyond the schema's simple 'words or quoted phrase' note. It still says nothing about the limit parameter.
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 (full-text search over full transcripts of every podcast/video) and explicitly scopes it apart from the sibling concern ("not only their five lines", i.e. search_lines). An agent can distinguish it from search_lines and get_lines_for_url 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?
Routes the agent for the quoting case explicitly ("to quote one, yank that part or use check_quote"), and the contrast with the five-lines tool implies when search_lines is the wrong choice. There is no explicit statement of when to prefer search_lines or get_yank, so it stops short of full when/when-not guidance.
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.
search_transcriptscheck_memorycheck_quoteget_lines_for_urlget_yankrecent_yankssearch_linesChecks that every quote in an AI-written script appears word for word in its source.
Check that a source really says what your claim says, before you publish. Verbatim, multi-path.
Roboto videos, client interviews, articles and social posts with source citations.
Verified reference data; each record carries its source URL and quote. verify_quote checks claims.
Add one secure layer between your agents and this server.