New Runtime public records

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by disclosing 'Free, no auth' and describing the output (New Runtime records, related records, patterns, hub, next steps). This goes beyond the structured annotations and helps the agent understand what to expect without contradicting 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?

The description is concise and well-structured: it front-loads the usage guidance, then describes the return value, adds cost/auth info, and provides a concrete example. Every sentence earns its place, and the example makes the tool immediately understandable.

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 tool with 2 parameters and no output schema, the description is complete enough: it lists what will be returned (records, patterns, hub, next steps), notes it is free and auth-free, and gives a clear example. Minor gaps like error behavior or rate limits are acceptable given the simplicity and annotation support.

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 'url' and 'task' are already documented with descriptions and examples. The tool description offers an example JSON usage, but it doesn't add significant semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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's function: given an external AI/software URL, it returns New Runtime records, related records/patterns, the source's hub, and next steps. The specific verb 'returns' and the explicit resource make the purpose concrete, and the 'Use first when...' opening positions it distinctly from siblings like search_archive or get_record.

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 explicitly says 'Use first when you found an AI or software URL elsewhere' and gives example contexts (release note, repo, blog post, tweet). This is clear when-to-use guidance. It does not name specific alternatives or exclusions, but the context is unambiguous enough for an agent to select it over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context by stating that it is free, requires no auth, and that resolved forecasts include grade and evidence. No contradiction with annotations exists.

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 compact and front-loaded: the primary use case appears first, followed by return-content details and the free/no-auth note. The example is minimal and adds practical value without bloat.

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 optional-parameter read tool, the description covers the key context: what data is returned, resolved-versus-open behavior, and authentication requirements. There is no output schema, but the description provides enough shape for an agent to invoke it 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 0%, so the description must compensate. It provides an example payload and mentions open versus resolved forecasts, but it never explicitly explains what `limit` controls or defines the `status` filter values, including the default 'all'.

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: reading New Runtime's dated forecasts and public scorecard. It enumerates the contained fields (claim, probability, due date, source analysis, hit rate, Brier score), which makes the tool's scope precise and distinct from the generic sibling tools.

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 opens with an explicit 'Use when...' condition tied to needing falsifiable predictions with a track record. It does not name sibling alternatives or explicitly say when not to use it, so it lacks full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: free, no auth, no arguments, and the return format (Markdown up to 12,000 characters with title, date, URL). This goes beyond the annotations and fully discloses what the agent should expect.

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 sentences with zero waste. The usage condition is front-loaded, followed by the return details. Every word adds value, and the structure is clear and 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?

For a zero-parameter, simple read tool, the description fully covers what the tool does, what it returns, the format, size limit, contents, and authentication requirement. There is no output schema, so the description carries the full burden and meets it completely.

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?

There are zero parameters, and the description explicitly states 'No arguments.' The schema is empty, so there is nothing more to explain. This meets the baseline for 0 parameters.

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 a specific verb (get) and resource (latest weekly metadox), and explains what a metadox is (the week's central contradiction, counter-evidence, dated forecasts) plus output format (Markdown, up to 12,000 chars, with title, date, URL). It also distinguishes itself from 'a list', which differentiates it from list-oriented 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?

The opening line gives an explicit condition: 'Use when you want one synthesis of the week in AI engineering instead of a list.' This tells the agent when to use it and implicitly when not to (when you want a list), but it does not name specific sibling tools. That is clear context but lacks explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating 'Free, no auth' and clarifying what the tool returns in full. This goes beyond the structured annotations and covers the main behavioral surface for a read-only tool.

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 two sentences plus an example, with the usage context front-loaded. Every sentence carries useful information, and the example is compact without redundant elaboration.

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 tool, the description covers when to use it, what it returns, input alternatives, auth requirements, and an example. There is no output schema, but the description adequately explains the return content, and annotations cover safety and idempotency.

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 only 33%, but the description compensates by explaining the key relationship: pass either the URL or kind+slug. It also provides a concrete example and clarifies that these are alternative input modes, which is not obvious from the schema alone.

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's purpose with a specific verb and resource: 'read one record in full' and lists the content fields (title, dates, source URLs, topics, body text). It also distinguishes when this tool is relevant by naming its sibling predecessors (search_archive, whats_new, what_changed), making it easy to choose over alternatives.

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?

It gives explicit placement guidance: 'Use after search_archive, whats_new or what_changed' and explains the two input modes (URL or kind+slug), plus an example. It doesn't explicitly state when not to use it or name a full-record alternative, but the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description only needs to add context. It does so by noting the query is scoped to the caller's submitted items and only exposes public moderation fields, preventing unrealistic expectations about internal details.

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 sentence delivers the purpose first, then the required id format, then the output scope. There is no filler, repetition, or unnecessary detail.

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 one-parameter read-only query with full schema coverage, the description provides everything an agent needs: what to pass, what kind of result to expect, and that only public moderation fields are returned. The examples of statuses add useful context despite the lack of an output 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?

The schema already fully documents submission_id, including its format and origin ('returned by a submit tool'). The description does not add meaningful parameter semantics beyond what the schema provides, so the baseline 3 for full schema coverage 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?

The description states a specific purpose: retrieving the moderation status of user-submitted sources, corrections, or usage receipts by as_ submission id. It clearly distinguishes this tool from siblings like get_record or search_archive by emphasizing the moderation-specific query and the 'you submitted' scope.

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 triggering context: after a submit tool returns an as_ id, call this to check the moderation outcome. It does not explicitly name alternatives or a when-not-to-use condition, so it falls just 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context: it is free, requires no auth, returns data in one call, and covers a two-week publication window. No contradictions with annotations were found.

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 compact and front-loaded with the primary use case. Every sentence adds value: what the tool returns, the data window, auth/pricing, an example, and where to find valid topics. No filler or redundant restating of the tool name.

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 one-parameter read-only tool with no output schema, the description covers input, output categories, freshness window, auth, cost, example usage, and a source for valid values. Nothing essential is missing for an agent to invoke it 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?

The schema already documents the single parameter as 'Topic slug or name' with 100% coverage. The description adds a concrete example ('coding-agents') and a topic list URL, helping the agent select valid topic values beyond the schema's examples.

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 uses a specific verb ('get the background') and names the resource ('one AI-engineering topic'), then lists the exact contents returned: summary, fortnight publications, related patterns, shifts, field notes, and news signals with URLs. This clearly distinguishes it from sibling tools like search_archive or whats_new, which serve different purposes.

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 explicitly starts with 'Use when you need the background on one AI-engineering topic in one call,' giving clear conditions for use. It does not mention when not to use it or point to an alternative sibling, but the use case is clear enough for an agent to select this tool appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds useful context beyond that: it is free, accepted evidence gets public credit, and returned tasks are filtered by staleness or low confidence. No contradiction with 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?

The description is compact: three sentences plus an example, with the trigger condition front-loaded. Each sentence adds meaningful information, and the inline JSON example is helpful, though slightly dense.

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 tool with two optional parameters and no output schema, the description covers the selection criteria, output contents, cost, public credit, and an example. It is missing explanation of each kind value and limit's default behavior, but these are minor gaps for successful 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 0%, so the description must compensate for parameter meaning, but it only provides one example kind and does not explain the three enum values or the limit parameter. An agent can infer that 'kind' selects task type from the example, but the meanings of find_counter_evidence and confirm_or_refute_shift are left unexplained, and limit's behavior is unaddressed.

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 action ('list'), a clear resource ('open verification tasks'), and precise scoping ('stale or below high confidence, on New Runtime patterns and shifts'). It goes beyond the title by specifying what each task entry contains, though it does not explicitly differentiate from sibling tools.

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?

Starts with an explicit trigger: 'Use when you can contribute evidence.' It also tells the agent that accepted evidence is credited publicly and that the response indicates which submit tool to use, which orients the agent to when this tool is appropriate. It does not name specific alternatives or exclusions, but the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by stating 'Free to call' and enumerating the output content (endpoint, USDC price, input example, charging timing, payment method). No contradiction with annotations, and it enriches understanding of what the tool returns.

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, information-dense sentence. It front-loads the usage condition and then packs relevant details (tools, prices, output elements). While long, every clause adds value, and it is well-structured for quick scanning.

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?

Given there are no input parameters and no output schema, the description fully covers what an agent needs: when to use, what it returns, and that it is free. It leaves no ambiguity about how to invoke the tool (no args needed) or what to expect.

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 tool has zero parameters, so the schema is trivially covered at 100%. The description correctly focuses on output details rather than parameter explanations, which is appropriate. Since there are no params to document, baseline 4 fits perfectly.

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 lists New Runtime's x402 paid tools, specifying the verb 'list' and the resource. It provides specific details about the tools (primary source check, rumour check, research bundle, prior-coverage check) and their attributes, making it unambiguous and distinct from sibling tools that likely handle free operations.

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 explicitly says when to use: 'when the free tools left a question open and you can pay per call.' It implies that free tools are the alternative, but does not name specific sibling tools or provide explicit 'when-not' conditions. The guidance is clear enough for an agent to decide, but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context: 'Free, no auth' and the return structure ('up to 10 hits with title, date, one-line summary and URL'). It doesn't mention rate limits or no-result behavior, but given annotations, this is a solid addition beyond structured data.

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 two sentences plus an example, with zero fluff. It front-loads the use case and immediately specifies what it searches, what it returns, and how to proceed. The example is compact and practical, and every sentence earns its place.

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 all necessary information: what it searches, what it returns, limitations (up to 10 hits), authentication (none), and downstream action (get_record). Annotations cover safety. Nothing an agent needs to call it correctly is missing, including a realistic example.

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 67% (query and kind have descriptions; limit does not). The description itself does not explain the parameters beyond an example JSON, which adds limited value. The 'kind' semantics are already in the schema. The example helps but the description does not compensate fully for the missing limit documentation.

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 action ('Searches New Runtime's Field Notes, Raw Signals and Analyses'), a concrete resource (New Runtime archive), and the returned data (title, date, summary, URL). It differentiates itself from sibling tools by explicitly pointing to get_record for full text, so an agent can tell it apart without opening schemas.

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?

It gives clear context: 'Use when you need dated, source-linked coverage... without crawling the web.' This implies when to use it. It also names a follow-up action (get_record) but does not explicitly state when not to use it or list alternative tools like get_forecasts or what_changed. Still, the guidance is adequate for routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations provide no meaningful behavioral signals, so the description carries the burden. It discloses key non-obvious effects: submissions are not published, review happens weekly on Monday, accepted items are credited in the record's weekly update, and the service is free. It does not cover response behavior or duplicate handling, but the process details go well beyond annotation defaults.

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 compact and front-loaded: purpose first, then policy details, then a schema link. Every sentence adds distinct information, with no redundancy 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?

The tool has 7 parameters, a nested agent object, and no output schema or annotations. The description explains the review process and links a schema, but stops short of describing what a caller should expect after submission, how to format record values, or how to fill optional fields. It is adequate but not fully complete.

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 only 43%, and the description compensates minimally by naming 'outdated, unsupported or contradicted' (mirroring the problem enum) and 'with evidence' (pointing toward evidence_url). It adds no meaning for note, confidence, the agent object, or the accepted record formats, leaving the agent dependent on the linked schema.

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 action ('Report a claim in a published record'), the target resource, and the problem categories (outdated, unsupported, contradicted). The title and description clearly distinguish this from siblings like submit_source and submit_usage_receipt by focusing on corrections to existing claims.

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 when to use the tool: when a claim in a published record needs correction, and it adds policy context (free, weekly review). However, it does not explicitly provide when-not-to-use guidance or compare with alternatives, so the agent must infer the boundary relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations are minimal (readOnlyHint=false, etc.), so the description must carry the behavioral burden. It transparently explains that submissions are not published, reviewed weekly, accepted items credited, and it returns a submission id and status URL. This goes beyond what annotations provide, disclosing the review workflow and non-immediate outcome.

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 concise sentences: first states purpose, second covers constraints and process, third states return value and schema link. No fluff, front-loaded, and each sentence earns its place.

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 submission tool with a nested agent object and no output schema, the description adequately covers the workflow (propose, review, credit) and return type (submission id, status URL). It does not detail error handling or edge cases, but those are largely covered by the schema, making it sufficiently complete for an agent to call 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 coverage is 75%, with all parameters already having descriptive text. The tool description adds no extra meaning for url, reason, agent, or related_record; it merely references a schema URL. It does not compensate for the coverage gap or clarify parameter usage beyond the schema, so a 2 is appropriate.

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 clear verb ('Propose') and resource ('a source ... for a New Runtime record or topic'), and specifies the source types (primary page, paper, repo, docs). It is distinct from siblings like submit_correction and submit_usage_receipt, though it does not explicitly name them, so it earns a 4 rather than 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?

The description provides context (free, weekly review, not published) but gives no explicit guidance on when to use this tool versus alternatives like submit_correction or submit_usage_receipt. There is no 'use this when' or 'instead of' statement, leaving the agent to infer selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations provide no meaningful behavioral signal (all false), so the description carries the disclosure burden. It transparently states that submissions are not published, are reviewed weekly on Monday, and accepted items are credited in the record's weekly update. This goes beyond the annotation fields and gives the agent a clear picture of side effects and post-submission handling.

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 four sentences long, with the core purpose front-loaded in the first sentence. The subsequent sentences add useful process context and a schema link, with no significant filler. Minor items like 'Free;' are arguably unnecessary, but the overall structure is efficient and well-ordered.

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 tool with no output schema and a nested agent object, the description explains the entire post-submission lifecycle: not published, reviewed weekly, credited if accepted. It also links to a full schema for parameter details. It does not describe the immediate response or error behavior, but that is a minor gap for a simple submission 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 75%, so the schema already documents most parameters in detail, including accepted URL formats for record and the meaning of public_url. The description only loosely maps to parameters ('used a record and for what... where it can be seen') and adds little beyond the schema. The agent object's purpose is also left to its nested schema descriptions, making the baseline 3 appropriate.

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 opens with a specific verb and resource: 'Record that you used a New Runtime record and for what (optionally where it can be seen).' This clearly distinguishes the tool from sibling submission tools like submit_correction and submit_source by focusing on usage receipts. The added context about helping the weekly desk further clarifies the tool's intent.

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 an agent has used a New Runtime record and wants it credited, and it explains the review process. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. The usage context is present but left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnly/idempotent annotations, the description adds useful behavioral context: the tool compares against New Runtime's stored knowledge, reuses prior understanding, deduplicates web-derived changes, and is free with no auth required. It also discloses the important nuance that it separates new facts from new angles on known stories.

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 front-loads the usage condition and capability, then follows with benefit, auth status, and an example. It is somewhat dense due to the long colon list, but each sentence contributes new information and does not merely repeat structured fields.

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, no-output-schema tool, the description covers the use case, return content categories, auth status, and gives an example. The main gap is that it implies you must already know a topic even though the `topic` parameter is optional, leaving the no-topic invocation case slightly ambiguous.

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 the baseline is 3. The description adds semantic context by explaining that `since` means your last run or report dateaging, and it provides a concrete combined JSON example for both parameters, which helps the agent understand how to invoke the tool correctly.

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 names the action (what changed since a date), the reference frame (against what New Runtime already knew), and enumerates the exact output categories: stronger/weaker patterns, obsolete items, resolved forecasts, new facts vs. new angles, and what still holds. This clearly positions it as a delta-report tool, distinguishing it from broader search or topic-brief 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?

'Use when you already know a topic and need only what changed since a date' gives an explicit trigger condition and even a realistic use case: 'your last run, a report date.' It does not explicitly name sibling alternatives or state when not to use it, so it falls just 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context beyond that: 'Free, no auth' (auth requirement), 'newest first' (ordering), 'at most 40 items' (pagination/limit), and the output fields (title, date, URL, one-line why). These are not in annotations and are genuinely useful for invocation.

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 sentences plus a JSON example, with no filler. The core purpose and scope are front-loaded, the example is compact, and the alternative tool is mentioned at the end without bloating the text. Every sentence earns its place.

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, but the description explicitly lists the returned fields (title, date, URL, one-line why) and the maximum count. Parameters are fully documented in the schema, the safety profile is in annotations, and the alternative tool is named. Nothing an agent needs to call this tool correctly 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%, so the baseline is 3. The description adds a concrete JSON example that demonstrates how to use both parameters together, and clarifies that 'kinds' is optional with a default of all. The example adds value beyond the schema's field-level descriptions, so a 4 is justified.

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 ('quick feed'), a resource ('New Runtime published items'), a time window (1-14 days), content types, ordering, and a limit (40 items). It also names the sibling it is not (what_changed) and the condition that selects it, so an agent can disambiguate at a glance.

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?

It explicitly says 'Use for a quick feed' and then directs the agent to the alternative: 'For what changed against what you already knew, use what_changed.' This gives both a when-to-use and a when-not-to-use, plus the sibling name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.