Use when a claim about browser tools, capture quality, OCR recall or citation extraction needs a number behind it — or when you want to check one of ours. Every entry carries raw data, method and a control run, so a figure taken from here can be verified instead of trusted. Start here.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, such as single vs batch citation extraction. The only potential confusion is between list_measurements and get_measurement_data, both of which return measurement data; however, their descriptions indicate one lists available data and the other retrieves a specific figure's backing data.
Tool names predominantly follow a verb_noun pattern (extract_citation, install_extension, list_measurements). Two exceptions—adoption_stats and how_to_capture—deviate from this pattern, but they are still readable and not chaotic.
Ten tools is a reasonable scope for a specialized server covering citation extraction, measurements, capture guidance, and project status. No tool is redundant, and the count is neither too sparse nor overwhelming.
The server covers the main workflows: single/batch citation extraction, retrieving and listing measurement data, fetching reproducible methods, and obtaining capture setup instructions. Minor gaps exist, such as no tool for creating new measurements, but the domain is primarily read-only and contribution is handled through open_work.
