Proving Lab

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

No annotations are present, so the description carries full responsibility. It discloses that numbers are 'small and stated as such rather than dressed up' and that it 'returns what is deliberately not counted' to avoid overstating completeness. This gives honest insight into the tool's limitations and data framing.

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 but informative, packed into two sentences. The first sentence front-loads the core purpose and data contents, while the second provides usage guidance and a transparency note. Every clause adds value without fluff.

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 and no annotations, the description must explain what the tool returns. It does so thoroughly by listing the specific metrics and explicitly noting what is excluded. It also gives context on data interpretation and use cases, making it complete for a no-parameter statistics 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?

The tool has zero parameters, so there is no parameter information to document. The description focuses on what the tool returns and when to use it, which is appropriate for a parameterless tool. A score of 4 reflects the baseline for no-param tools.

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 phrase 'How much this endpoint and its install route are actually used' and enumerates concrete metrics (requests to /mcp, discovery paths, store version, user count). It clearly differentiates from sibling tools by focusing on adoption statistics rather than citations, measurements, or installation actions.

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 states when to call: 'Call this when deciding whether to rely on this server, when comparing it against alternatives, or when reporting on it.' This provides direct contextual guidance and implies alternatives by mentioning comparison.

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?

With no annotations, the description carries the full burden and does exceptionally well. It discloses that it plainly reports error pages or access walls instead of inventing references, that a nextStep field is returned with browser actions, and even includes measured performance stats on 20 mixed sources. This goes far beyond typical descriptions.

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 front-loaded with the core function, then usage, then behavior and performance. It is longer than average but every sentence contributes useful information. The measurement sentence is unusual but justifies reliability. 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?

Given there is no output schema, the description sufficiently explains what the tool returns (structured record, RIS, BibTeX) and handles failure modes (nextStep field). It also gives a concrete sense of expected success rates. For a single-parameter read tool, this is 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?

The input schema already describes the single parameter 'url' as 'Address of the page to read', giving 100% coverage. The description adds only that the page declares citation details about itself, but doesn't add syntax or format nuance. Baseline 3 is appropriate since the schema does the heavy lifting.

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 reads citation details a web page declares about itself and returns them as a structured record plus RIS and BibTeX. It also lists supported source types, which adds specificity. However, it does not explicitly distinguish itself from the sibling tool 'extract_citations', so it misses full sibling 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?

The description provides explicit usage context: 'Use when a source has to be cited, archived, or added to a reference manager.' It doesn't mention when not to use it or name alternatives, but the guidance is clear enough for typical selection.

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?

With no annotations, the description carries full weight. It discloses performance metrics, the 50-address limit, parallel fetching of 5, the return shape with a summary, and critically warns that refused records still carry titles, requiring the `complete` flag check. This is exemplary transparency.

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?

Every sentence earns its place: triggering usage, performance benchmarks, limits/parallelism, return shape, and a critical caveat about the `complete` flag. The progression is logical and there is no fluff.

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 single-parameter tool with no annotations and no output schema, the description covers the return format, summary contents, operational limits, and the essential flag-checking behavior. It also links to extract_citation for shape context. This is more than sufficient for correct 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 100%, so the parameter is already documented as 'Addresses to read, at most 50'. The description repeats the limit and adds behavioral details (parallel fetching) but no new semantic meaning about the parameter itself, matching the baseline for high schema coverage.

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 is for multi-source reading lists, contrasting with the single-source sibling extract_citation, and explicitly notes it returns one record per address. The use cases (bibliography, links to verify, archive) reinforce a specific verb+resource 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?

It opens with 'Use when you have a reading list rather than one source' and provides concrete scenarios. The reference to extract_citation as the singular equivalent implies the alternative, giving clear when-to-use and when-not-to-use 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?

With no annotations, the description carries the burden. It discloses that the return includes values, control run, and limiting conditions, and emphasizes dataset stability ('does not change when someone edits a page'). It does not mention error behavior, but for a getter this is acceptable.

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, front-loaded with the primary use case ('Use before quoting a figure'), and every sentence adds value. There is 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?

For a single-parameter tool with no output schema or annotations, the description explains the return content (values, control run, conditions) and the proper context for use. It lacks details on error handling but is still fairly complete for a getter 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% (the 'dataset' parameter is described as 'Dataset URL or bare filename'). The description adds no additional parameter syntax details, but reinforces that the dataset is the object to cite, which is helpful context. Baseline of 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 returns the measurement data behind a figure (values, control run, conditions). It distinguishes this from sibling tools like extract_citation and get_method by focusing on raw data retrieval.

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 tells the agent to use this tool before quoting a figure and to cite the dataset rather than the article. It gives clear context but does not explicitly name alternative tools or exclusion 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?

With no annotations, the description is the sole source of behavioral disclosure. It does reveal that omitting the argument lists available methods, but it doesn't state whether the operation is read-only, if it has side effects, or what happens for invalid names. This falls short of full transparency.

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 with a clear colon-separated enumeration of examples, followed by a direct instruction about the optional argument. Every clause adds value; there's no filler or redundancy.

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 the tool's simplicity (one optional param, no output schema), the description covers the core purpose, example methods, and argument behavior. However, it doesn't describe the return format or error behavior, which would be helpful for agents unfamiliar with 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?

The schema provides a single optional string parameter 'name' with no description. The description clarifies the argument's role: providing a name fetches a specific method, and omitting it lists all methods. It also gives concrete examples of method topics, giving the agent a sense of valid values, though it doesn't specify exact string formats.

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 fetches a reproducible method for specific tasks, citing examples like browser extension permissions, OCR recall, and print-to-PDF vs screen capture. The verb 'Fetch' and resource 'method' make the purpose unambiguous, though it doesn't explicitly distinguish from similar sibling tools like 'how_to_capture'.

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 through examples ('reading...', 'measuring...', 'choosing between...'), suggesting the tool provides procedural guidance for these scenarios. However, it lacks explicit 'when not to use' guidance or references to alternative sibling tools, so the context is implied rather than explicit.

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?

With no annotations provided, the description carries the full burden. It is transparent about what the tool returns (install links, instructions, CDP routes), qualifies that it handles pages 'this endpoint cannot read', and even warns about 'traps that cost time'. It lacks exact output shape, but for an informational tool this is reasonable.

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 front-loaded with the core purpose, then lists returns, then gives usage guidance. It is three sentences and dense, though phrases like 'the sources it hands back' and 'traps that cost time' are slightly vague and add a little wordiness.

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 two well-documented optional params, no output schema, and no annotations, the description covers the main return content and key use cases. It explains both the 'human' path and agent-driven browser paths, making it reasonably complete, though a bit more detail on output structure would be helpful.

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 provides 100% coverage with detailed enum descriptions for both parameters. The description adds value by linking agent behavior to route types and browser to install links, e.g., 'for agents that drive their own browser, the unpacked-load and CDP routes'. This goes beyond the baseline 3.

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: getting a runnable route for saving a web page that the endpoint cannot read. It specifies the resource (web pages/citations), the action (get route/instructions), and the scope (install links, human instructions, CDP routes), distinguishing it from siblings like extract_citation.

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 explicit when-to-use guidance: 'Call this instead of guessing when a citation comes back complete:false, or when asked how to archive a source...' This is clear context, though it does not explicitly name alternative tools or when-not-to-use scenarios, so it stops 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?

With no annotations provided, the description carries the full burden, and it delivers: it reveals that the tool returns a self-verifying script, explains non-zero exit behavior, gives measured runtimes, and even discloses failure traps and limitations. This goes far beyond a generic 'install extension' statement.

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 opening sentence is strong and front-loaded, but the rest is a dense run-on that packs many distinct ideas into one long paragraph. The content is valuable, yet it could be restructured into clearer separate points without losing meaning.

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 no output schema and no annotations, the description is remarkably complete: it covers the return artifact, verification behavior, failure semantics, timing, usage triggers, limitations, and even decision authority around installation. An agent has enough context to invoke the tool 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%, so the input schema already documents both parameters thoroughly, including the default behavior of 'both.' The description reinforces install/uninstall and browser names but does not need to add parameter-level detail because the schema already handles 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?

The description names a specific verb and resource: install or uninstall the capture extension in Firefox or Chrome. It also clearly scopes the behavior (no window, no click, no admin rights), which sets it apart from any capture-route tooling among the 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?

It explicitly states when to call the tool: when a capture route needs the extension present, when a run is finished and it should be gone, or when asked whether an agent can set up a browser extension by itself. This gives concrete decision criteria rather than leaving usage 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It adds useful context that every entry includes raw data, method, and a control run, which implies verifiability. However, it does not explicitly state that the tool returns a list of all measurements, nor does it describe the return format, pagination, or whether it is read-only. The behavior is implied but not fully transparent.

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, but the first sentence is long and lists multiple domains, making it somewhat dense. Still, each sentence earns its place: the first defines the use case, and the second explains the data content. It is reasonably concise but could be more front-loaded with the explicit 'list' 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 tool with no parameters and no output schema, the description covers essential context: when to use it and what entries contain (raw data, method, control run). This is complete enough for a simple list tool, though it does not explicitly state the return type or whether it returns all entries. The lack of output schema raises the need for more explicit return details, but the description provides sufficient context.

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 and the schema confirms this with 100% coverage. The description does not need to explain inputs, and the baseline for 0 params is 4. It adds no parameter-specific information, which is acceptable given the schema already fully documents the absence of 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 conveys the tool's role as a source of measurement numbers for browser tools, capture quality, OCR recall, and citation extraction. It implies the action of listing entries by saying 'Start here' and 'Every entry carries...', but it does not explicitly state the verb 'list' or contrast with sibling tools like get_measurement_data. The purpose is clear but not as direct as it could be.

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 states when to use the tool: when a claim needs a number behind it or to check one of ours. It also instructs 'Start here', indicating it is the entry point. However, it does not mention when not to use it or point to alternatives such as get_measurement_data or get_method, which would strengthen the guidelines.

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?

Given no annotations, the description carries the behavioral transparency burden. It uses active verbs 'List' and 'Returns' indicating a read-only operation, and adds contextual detail about the most useful contribution, but does not explicitly state a lack of side effects or permissions.

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 packs purpose, usage, and output into two sentences with no filler. Every clause earns its place, including the motivational note about measurement contributions, which clarifies priority.

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 with one optional parameter and no output schema, the description sufficiently covers what it does, when to use it, and what it returns. This fully equips 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 100%, and the sole 'label' parameter is fully described in the schema. The tool description adds no extra parameter meaning, so the baseline of 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 'List what this project needs done' and specifies it returns open GitHub issues with labels and the location of contribution rules. It distinguishes itself from sibling tools by framing it as the contribution entry point, especially for measurement reproduction.

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 instructs 'Call this when asked to contribute to provinglab.dev or Full Page PDF Snap, or when looking for a measurement to reproduce'. This provides clear, context-rich guidance on when to invoke the tool, with no ambiguity.

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?

With no annotations, the description carries the transparency burden. It discloses that the tool outputs settings with measurement rationale or an explicit 'none exists' note, and it warns about output file size variation (8.5% to 100%) depending on a setting. This is meaningful behavioral disclosure, though it doesn't explicitly state the tool is read-only.

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: function, usage, and rationale. Every sentence earns its place, no fluff. The key information is front-loaded.

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 description explains what the tool returns, how to use it, and why timing matters. For a simple one-parameter tool with no output schema, this is complete enough for an agent to correctly invoke it and interpret results.

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 covers the parameter and enum values 100%, but the description adds context: purpose values are listed and the choice matters because source kind is known before capturing. This goes beyond the schema's 'what the capture is for' and justifies the 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?

The description clearly states the tool recommends capture settings for a given purpose, with specifics about what is returned (measurement or explicit note). It distinguishes from siblings like extract_citation and get_measurement_data by focusing on pre-capture settings recommendation.

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 before capturing' and explains why the timing matters (source kind known now, not afterwards). While it doesn't name alternative tools, the context and purpose are clear enough for an agent to decide when to invoke this tool.

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