Daily feed of AI releases, tools and techniques, each labeled with how it was checked.
Scored across 3 tools
The three tools target distinct access patterns: today's claims, the source registry, and historical claim search. get_latest and search_claims both return claims, but the time scope and searchable ledger distinction are clearly described.
list_sources and search_claims follow a clear verb_noun pattern. get_latest is a minor deviation because 'latest' is adjectival rather than a noun object, but it remains readable and predictable.
Three tools is well-scoped for a focused claim-verification ledger: latest claims, source trust data, and historical search. Each tool earns its place without redundancy.
The surface covers the main read-only workflows: browsing today's claims, inspecting sources, and searching the published claim ledger. Minor gaps exist, such as direct retrieval by claim id or filtering by source/status, but agents can mostly work around these via search.
Return today's checked AI claims (releases, tools, techniques), each with its verification status, source trust score and evidence links. Optionally filter by a topic word such as 'claude', 'codex' or 'open weights'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum items to return (default 15) | |
| topic | No | Optional word or phrase to filter items by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and closed-world behavior, so the description appropriately adds return-content context: verification status, source trust score, and evidence links. It still does not describe empty-result or pagination behavior, but it adds meaningful value beyond the 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?
Two tightly written sentences with the core purpose front-loaded and no wasted wording. The optional filtering detail follows naturally without burying the primary action.
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 two-parameter read tool with full schema coverage and strong annotations, the description supplies enough return-value context to use it correctly. Nothing essential for selecting or invoking the tool appears 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%, so both parameters are documented, giving a baseline of 3. The description adds concrete topic examples ("claude", "codex", "open weights") that clarify filtering semantics beyond the schema wording.
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 ("Return") and resource ("today's checked AI claims") with a clear scope and examples of claim types. The "today's" scope and claim focus distinguish it from list_sources and broader search_claims usage 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?
The description gives clear context for when this tool is appropriate: retrieving today's checked AI claims, with optional topic filtering examples. It does not explicitly route historical or broad searches to search_claims, so there is a minor gap in alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sources Context Pill reads, with tier, trust score (posterior mean), its conservative lower bound (LB10) and the number of resolved tips. Optionally filter by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional source name filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world, so safety is covered. The description adds meaningful behavioral context by defining the output semantics — trust score as posterior mean, a conservative lower bound (LB10), and resolved tip counts — which is information not present in the 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?
A single front-loaded sentence that names the resource, its returned fields, and the optional filter with zero wasted words.
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 read-only list tool with no output schema, the description is nearly complete because it enumerates the returned fields and explains what the trust metrics mean. It does not mention whether the list is paginated or bounded, a minor gap given the simplicity of 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 description coverage is 100% for the single optional parameter, so the baseline is 3. The description's phrase 'Optionally filter by name' merely restates the schema and adds no matching syntax or semantics beyond it.
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 ('List the sources Context Pill reads') and enumerates the returned fields (tier, trust score, LB10, resolved tips), so the agent knows exactly what it gets. Sibling tools (get_latest, search_claims) are not named or contrasted, which keeps it short of a 5.
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?
'Optionally filter by name' implies the only usage variation, but there is no explicit when-to-use guidance, no exclusions, and no comparison to get_latest or search_claims. Usage is inferable from the description but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the claims Context Pill has published (the ledger), with their status at publication, how each was checked, current state (pending, resolved, corrected or closed-inconclusive), the re-check outcome and any correction. Removed items keep only an id, date and reason, so they don't show up in a word search. Use it to see whether a specific tool, model or feature claim has been checked.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum claims to return (default 10) | |
| query | Yes | Words to look for, e.g. a tool or model name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and closed-world, so the bar is lower, yet the description still adds a genuinely useful caveat: removed items retain only id/date/reason and therefore will not surface in a word search. It also names the possible state values, which helps an agent interpret results rather than just retrieve them.
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?
Purpose is front-loaded in the first clause, followed by return-field detail and one usage sentence. Dense but every clause carries information; the long first sentence is heavy, though nothing is truly redundant.
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 read-only search with no output schema, the description adequately enumerates what comes back and flags the removed-item edge case. The only shortfall is that result ordering and the limit default/interaction with paging are left entirely to the schema.
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 (query, limit) are already documented in structured data. The description reinforces that query targets tool/model/feature names but adds no syntax, matching or paging 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 and resource ('Search the claims Context Pill has published (the ledger)') and enumerates the returned facets (status, check method, current state, re-check, correction). It distinguishes the tool from siblings implicitly by scope but never names get_latest or list_sources, so an agent must infer the boundary.
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?
'Use it to see whether a specific tool, model or feature claim has been checked' gives a clear positive use case, which is more than implied. However, no when-not condition or alternative tool is mentioned, and with get_latest as a close sibling the absence of routing guidance is a real gap.
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.
get_latestlist_sourcessearch_claimsSourced register of open-weight AI model releases and AI news. Every field cites its source.
AI model releases, price changes and deprecations in one feed: chat, embedding, speech, video.
Daily leaderboard of newly-launched AI tools with real launch dates and Stripe-verified revenue.
Free fact-checks, papers, source vetting, plus verified AI pricing, comparisons, guides, and tools.
Add one secure layer between your agents and this server.