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

No annotations exist, so the description carries the burden. It does disclose a key behavioral trait: a cost of $0.10 USDC per call. It also implies the tool returns an estimate. However, it does not mention authentication, rate limits, or how errors (e.g., invalid polyline) are handled, which leaves notable gaps.

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 short sentences that convey the core purpose and the cost. Every word is necessary, with no padding or repetition of schema details. It is front-loaded with the main action and then provides the cost caveat.

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 4 parameters, no annotations, and no output schema, a single sentence is insufficient. The description does not explain the 'toll_maneuvers' parameter, the return format, or any prerequisites (e.g., navigating to a route). Given the tool's moderate complexity, more behavioral and parameter context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies that 'axle count' and 'vehicle height' refer to 'axles' and 'height_ft', giving them context. However, it does not mention 'toll_maneuvers', and with schema coverage only at 25%, the description should compensate more. The polyline parameter is already documented in the schema, so the net addition is partial.

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: estimating tolls for a known route polyline, with specific inputs (axle count and vehicle height). It uses a specific verb ('Estimate') and resource ('tolls for a known route polyline'), making it easily distinguishable from sibling tools that handle document parsing or government data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It implies the user already has a polyline, but does not mention that freight_truck_route could generate one, nor any exclusions or prerequisites. The description lacks any 'use this when' or 'instead of' references.

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 burden of behavioral disclosure. It does add useful context by disclosing the $0.15 USDC cost per call, which is significant operational information. However, it does not explain behavior around missing/empty inputs, which combination of parameters to use, potential errors, or the exact structure of the returned JSON, leaving some ambiguity.

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, tight sentence that communicates the tool's purpose and a critical business detail (cost) without any filler. Every word earns its place and the key action word 'Parse' 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 tool has four optional parameters and no output schema, so the description is the only source of context for expected output and invocation. It says output is 'structured JSON' but does not clarify which parameters are typical (e.g., text vs file_path vs pdf_base64), default behavior of 'mode', or what happens on failure. The sibling list provides document-type context, but the description alone leaves moderate gaps for a paid tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each of the four parameters (mode, text, file_path, pdf_base64) is already explained in the input schema. The description adds no parameter-level details beyond noting PDF or text inputs, so the baseline score of 3 is appropriate given 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 opens with a specific verb 'Parse' and names the exact resource type ('Bill of Lading / Proof of Delivery'), making it clear what document this tool handles. It also distinguishes itself from sibling parse tools like freight_parse_fuel_receipt or freight_parse_w9 by document type. The mention of 'PDF or text' and 'structured JSON' gives a precise 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 clearly implies this tool is for Bills of Lading and Proofs of Delivery, which helps an agent choose among the document-specific sibling parse tools. However, it does not explicitly say when not to use it or mention alternatives such as freight_parse_fuel_receipt for other document types, 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?

No annotations are provided, so the description carries the full burden. It discloses the cost of $0.05 USDC per call, which is a meaningful behavioral trait. However, it does not mention whether the operation has side effects (likely none), how input data is handled, or error behavior. The description adds cost and input format context but misses deeper 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 extremely concise: two sentences that front-load the core purpose followed by cost. Every word earns its place, with no unnecessary detail. This is exemplary conciseness.

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 5 optional parameters, no required parameters, and no output schema. The description covers the general use case but does not explain how to choose among modes (auto, fast, llm, ocr), whether multiple input parameters can be combined, or what the resulting JSON structure looks like (beyond 'structured JSON'). Given the moderate complexity, the description is adequate but lacks operational guidance.

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 parameters are already well documented (mode, text, file_path, pdf_base64, image_base64). The description adds no additional meaning beyond restating that inputs can be text, PDF, or image, which is already evident from the schema. 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 action ('Parse'), resource ('fuel receipt'), acceptable formats ('text, PDF, or image'), and output ('structured JSON for IFTA / expense tracking'). This explicitly distinguishes it from sibling parse tools like freight_parse_bol_pod or freight_parse_w9.

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 clear context for when to use this tool: when parsing fuel receipts for IFTA or expense tracking. It does not explicitly name alternative tools or exclusions, but the purpose is specific enough that the agent can infer the appropriate use case.

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 does disclose the cost per call ($0.08 USDC) and the input types, which is useful. However, it does not mention whether the tool is read-only, error handling, limitations, or what happens with invalid inputs. Parsing is inherently safe, but the description lacks deeper behavioral context beyond cost and input 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 a single sentence that packs purpose, accepted inputs, output format, and cost into a concise, front-loaded statement. No wasted words; the cost detail is additional but relevant for decision-making. Excellent conciseness.

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 5 parameters, no required fields, and no output schema, yet the description only provides a high-level overview and cost. It does not describe the structure of the returned JSON, the semantics of the 'mode' parameter, or how to handle conflicting inputs. Given the complexity of a document parser, this leaves meaningful gaps for an agent to use it correctly beyond a basic call.

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 has 100% coverage with descriptions for all 5 parameters, so the schema already does the heavy lifting. The description adds no parameter-specific guidance (e.g., how to choose between 'fast', 'llm', and 'ocr' modes, or which input parameter to prefer). It merely repeats the input type categories, so it does not compensate beyond the schema baseline.

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 action ('Parse'), the specific resource ('ACORD 25 Certificate of Insurance'), the accepted input formats ('text, PDF, or image'), and the output ('structured JSON'). This specific verb-and-resource phrasing distinguishes it from sibling parse tools that handle other document types (e.g., BOL/POD, fuel receipt, W9).

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 for parsing insurance certificates because the name and resource are explicit, but it does not state when to use this tool instead of a sibling or provide explicit exclusions/alternatives. No guidance on when to prefer this over other parse tools, though the resource specificity makes the use case reasonably 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?

No annotations are provided, so the description carries the burden. It discloses the $0.25 USDC cost and input formats (PDF or image), but doesn't describe output details, error behavior, or authentication requirements. The cost disclosure adds value, but behavioral traits beyond cost are absent.

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 the main action first and cost second. Zero waste.

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 handles 4 input parameters and has no output schema. The description states the output is 'structured JSON' but doesn't detail the structure or guide parameter selection. The state coverage and cost are mentioned, but for a parse tool with multiple input modes, more guidance would improve completeness.

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 mentions PDF or image inputs, but the schema already details each parameter; no additional parameter meaning is added.

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 and resource: 'Parse an oversize/overweight trucking permit (PDF or image) into structured JSON across 22 US states.' It clearly distinguishes the tool from siblings like freight_parse_bol_pod or freight_parse_w9.

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 a clear use case (oversize/overweight permits) but doesn't explicitly state when not to use it or mention alternatives. The context is clear enough for an agent to infer appropriate use.

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. It discloses the cost ($0.10 USDC) and input formats (PDF or text), which is useful. However, it does not mention what happens on parse failure, auth requirements, or any unique side effects beyond the cost.

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, front-loaded with the core purpose, followed by cost. No filler or redundancy. 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?

Without an output schema, the description enumerates the extracted fields, which is valuable. It also includes pricing and input flexibility. Lacks explicit details about error handling or output schema structure, but is reasonably complete for a parse tool with 4 parameters.

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%, with each parameter already described. The description adds a list of extracted fields, which gives context for the 'text' and 'file_path' parameters, but does not clarify parameter-specific syntax or constraints beyond the 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?

The description uses a specific verb and resource ('Parse a freight rate confirmation') and lists the extracted fields (load #, broker, rate, stops, equipment). This clearly distinguishes it from sibling tools that parse other document types like BOLs or fuel receipts.

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 mode parameter hints at use cases ('fast=regex, llm=GPT-4o-mini, ocr=scanned/image OCR'), but there is no explicit statement of when to choose this tool over alternatives. Sibling names make the document-type distinction obvious, so the guidance is adequate but not fully 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?

No annotations are present, so the description carries the burden. It discloses the cost ($0.07 USDC per call) and indicates a read-only transformation to JSON, but does not cover failure modes, input handling precedence, or potential quality issues with scans/OCR. This is useful but not comprehensive.

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, front-loaded sentence that states the purpose and input formats, followed by a clear cost note. There is no filler; every piece of information 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?

The description explains the output type (structured JSON) but does not specify that at least one input parameter must be provided or how to prioritize when multiple are supplied. Given the tool has 5 parameters and no output schema, these missing details make the description incomplete for correct 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?

The input schema already provides descriptions for all 5 parameters (100% coverage), including mode enums and input source details. The tool description adds no extra parameter-specific semantics, so the baseline of 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?

Description uses the specific verb 'Parse' with a clear resource ('IRS Form W-9') and a specific output ('structured vendor-onboarding JSON'). This clearly distinguishes it from sibling document parsers like freight_parse_bol_pod or freight_parse_fuel_receipt.

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 identifies the exact document type and accepted input formats (text, PDF, image), which implies when to use this tool over sibling parsers. However, it does not explicitly mention exclusions or provide guidance on choosing between the 'fast', 'llm', and 'ocr' modes, though the schema descriptions offer some help.

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?

No annotations are provided, so the description carries the full burden. It adds a notable behavioral detail: the cost of $0.01 USDC per call. However, it does not disclose whether the operation is read-only, what side effects if any, or the output format. This is a simple compute operation, so risk is low, but the description leaves room for more 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?

Two concise sentences. The first sentence states the core functionality, and the second adds the cost. No wasted words, 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 tool has nested objects and no output schema, yet the description does not explain the return value, the exact behavior of the options, or any constraints on input pings. The description is too brief to fully guide an agent on invocation and interpretation of 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?

Schema description coverage is only 50%. The description mentions 'array of GPS pings' which aligns with the 'pings' parameter, but it does not clarify the 'options' parameter (fuel_price, assumed_mpg) or the individual fields within pings (speed, fuelRateGph). It adds minimal value beyond what the schema already states, and fails to compensate for the undocumented options.

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 starts with 'Compute trip analytics' and specifies distance, idle, harsh events, and fuel burn. It clearly identifies the input as an array of GPS pings, which distinguishes it from sibling tools like freight_calculate_tolls or freight_parse_bol_pod that handle different resources.

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 clearly implies when to use this tool: when you have GPS ping data and need trip analytics. It does not explicitly mention alternatives or exclusions, but the input type and purpose are clear enough to guide selection. It lacks explicit 'use instead of' guidance, so it doesn't earn 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It adds useful context: truck-legal constraints, inclusion of tolls/weigh stations/truck stops, turn-by-turn maneuvers, and a cost of $0.50 USDC per call. However, it doesn't mention return format, failure handling, or how truck profile affects routing, which leaves some gaps.

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: the first packs all functional details, the second provides pricing. No wasted words, front-loaded with the primary purpose, and easily 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 tool with six parameters, nested objects, and no output schema, the description is only partially complete. It clarifies the core functionality and some output aspects (turn-by-turn), but lacks details on how optional parameters modify behavior, what the route response looks like, and error/edge-case behavior. This is adequate but not thorough.

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% (origin and truck have descriptions). The tool description does not compensate for the undocumented parameters: via_points, include_truck_stops, include_weigh_stations, destination, and the truck profile subfields are not explained. It only vaguely mentions 'truck-legal' without linking to the truck object's meaning.

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: 'Truck-legal routing between origin and destination' with specific features like tolls, weigh stations, truck stops, and turn-by-turn maneuvers. This distinguishes it from siblings such as freight_calculate_tolls, which focuses solely on toll calculation.

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?

Usage is implied by the purpose: use for truck-legal route planning. However, there is no explicit guidance on when to prefer this over alternatives (e.g., freight_calculate_tolls for toll-only calculations) or when not to use it. No exclusions or prerequisites are mentioned.

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 behavioral disclosure. It mentions the cost per call, which is useful, but it does not disclose return format, pagination, error behavior, authentication needs, or what happens when optional parameters are omitted.

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 one compact sentence that efficiently communicates the data source, the query scope, the parameter names, and the cost. There is no wasted wording or redundant repetition of the schema.

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 lookup, the description covers the core purpose and cost. However, it does not describe the output shape, and it creates slight ambiguity by stating 'by NPI and year' when year is optional in the schema. Without an output schema, some description of return behavior would improve completeness.

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 has 100% coverage with descriptions for both parameters. The description merely restates the parameter names without adding extra meaning, so it adds no value beyond what the schema 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 identifies the resource (CMS Open Payments data) and the scope (industry payments to a physician by NPI and year). It lacks an explicit imperative verb like 'retrieve' or 'get', but the intent is unambiguous. It also distinguishes itself from unrelated 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 gives no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only lists parameters and cost, so the agent has to infer usage context from the tool name.

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?

No annotations are provided, so the description carries the full burden. It discloses the $0.01 USDC per-call cost, which is valuable behavioral context, but it does not explicitly state read-only nature, authentication, rate limits, or response format.

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 short sentences cover purpose and cost with no redundant text. The information is front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description tells what the tool does and its cost, but omits parameter combination guidance, expected return structure (no output schema exists), and any usage caveats. For a simple query tool without annotations, this is adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description merely lists parameter names without adding meaning. Since schema coverage is only 50% (from_year and to_year lack descriptions), the description should have clarified their semantics, but only hints at a 'year range' without details on inclusivity or optionality.

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 identifies the tool as the FBI Crime Data Explorer and states it provides offense counts by state and year range. This scoping distinguishes it from other government-related siblings like gov_query or gov_cms_open_payments, though it lacks an explicit verb (e.g., 'retrieves').

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?

Usage context is implied by the domain (FBI crime data), but there is no explicit guidance on when to choose this tool over alternatives like gov_query. No exclusions or conditions are mentioned.

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 of behavioral disclosure. It adds context beyond the name by clarifying the relationship with gov_query and the return fields. The explicit 'FREE — no payment' is a helpful behavioral trait. It does not mention authentication or error behavior, but for a simple listing tool, the essentials are covered.

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 exceptionally concise: two sentences that front-load the main purpose and then add a crucial cost note. Every word earns its place, with no 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?

The tool is simple (one optional parameter, no output schema), and the description covers the core necessity: what the tool does and what fields are returned. Slightly more detail about the output format (e.g., JSON array of objects) would elevate it to a 5, but the given information is sufficient for an agent to use it effectively.

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 provides a complete description for the only parameter (category: 'Optional filter: data | search | maps.'), so the baseline is 3. The tool description adds no additional information about the parameter's usage or semantics beyond what the schema provides, so no score above baseline is warranted.

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: 'List all SuVerse government services callable via gov_query'. It identifies the specific verb (list), the resource (SuVerse government services), and even enumerates the returned fields (id, category, description, params). This distinguishes it from sibling tools like gov_query (which queries a specific service) and other data 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 implies a clear use case: to discover which services are available to call via gov_query. The note 'FREE — no payment' serves as a guideline suggesting it is a low-cost way to explore services. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls 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 disclosure burden, but it only adds a cost figure and doesn't state whether calls are read-only, require special permissions, or have any side effects. It also omits rate-limit or error behavior, so the agent has incomplete behavioral expectations.

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 tight sentences: first states purpose with examples, second gives discovery instruction and cost. No filler, all information is action-relevant.

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 tells the agent how to find services and parameters and how much it costs, but it never describes the response format or any failure modes, which is significant because there is no output schema. The pointer to gov_list_services compensates for parameter discovery but not for return-value expectations.

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 covers both parameters (service and params), and the description adds the crucial guidance that valid service IDs are discoverable via gov_list_services and gives two examples. This goes beyond the schema's static property descriptions, helping the agent populate the params object meaningfully.

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?

Clearly states it can call any of SuVerse's 128 US-government data/search services by ID, with concrete examples ('sec.company_info', 'nps.parks'). This distinguishes it from sibling tools that target specific agencies; it's the generic invocation endpoint.

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 to use gov_list_services to discover service IDs and their parameters, which tells the agent how to find the necessary inputs. It also states the per-call cost, helping with cost-conscious selection, though it doesn't mention dedicated siblings as 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It states this is a read operation and discloses that the wallet is 'configured' (not user-specified) and that the call is free. This adds meaningful context beyond a simple 'read balance' statement, though it does not detail response format or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every phrase contributes: the resource, the action, the additional output, and the free-to-use note. Highly concise and well-structured.

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, read-only utility, the description is complete. It specifies the balance source and the call-remaining information. No output schema exists, so the description partially covers return values by stating 'how many calls remain for each tool'. Minor gaps: it doesn't specify the response structure or whether the balance is in decimal units, but overall it is sufficient.

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 coverage is 100% (empty schema). The description adds meaning by clarifying what data is read (on-chain USDC balance for the configured Base wallet) and the output includes call counts per tool. With no parameters to explain, the baseline of 4 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 clearly states the tool's function with a specific verb ('Read') and names the exact resource ('configured Base wallet's on-chain USDC balance') and the additional output ('how many calls remain for each tool'). It distinguishes itself from sibling suverse_* tools by focusing on balance and call quotas.

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 makes the intended use obvious: check USDC balance and remaining calls. It indicates the tool is free to use ('FREE — no payment'), which is a clear usage context. However, it does not explicitly compare to alternative suverse tools or provide 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 full burden. It discloses key behavioral traits: the tool estimates cost without paying and is explicitly 'FREE — no payment.' This is crucial safety-relevant information. However, it does not mention authentication requirements, rate limits, or response format, so it is 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 three short sentences, front-loaded with the main action and followed by usage guidance and a reinforcing 'FREE — no payment.' Every sentence earns its place with 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?

Given the tool's simplicity, the description covers purpose, usage, and the free/no-payment trait. Since there is no output schema, the description should ideally hint at the return value, which it does implicitly ('Estimate the USDC cost'). It lacks details on batch limits or response structure, but is sufficient for a simple estimate 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%, and the schema already describes 'tool' as 'A single tool name to price' and 'calls' as 'A batch of calls to price.' The description adds no extra semantics beyond these, so the baseline of 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?

The description clearly states the tool's function: 'Estimate the USDC cost of one or more tool calls WITHOUT paying.' It specifies the action (estimate), the resource (USDC cost), and the key qualifier (without paying), which distinguishes it from any cost-incurring execution. There is no sibling tool with similar purpose, so it stands alone clearly.

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: 'Useful before batch operations.' This tells the agent when to use the tool. However, it does not mention when not to use it or name any alternatives, though no direct alternatives exist among siblings. This warrants a 4 rather than 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?

No annotations exist, so the description carries the full burden. It thoroughly discloses the $0.10 USDC cost, the requirement for payment_signature to get the full response, the 402 behavior without payment, and the beta status of Base coverage. This is strong behavioral 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 front-loaded with the core purpose and packed with useful details, but it is a long paragraph that could be broken into clearer sections. Every sentence earns its place, though the structure is somewhat 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?

With no output schema, the description does a good job explaining the return values: verdict enum, summary, confidence, signals, and raw data. It covers payment behavior and data coverage caveats, making it sufficiently complete for the tool's complexity.

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 payment_signature at 100% coverage, providing the baseline of 3. The description adds extra meaning by explaining what happens when payment_signature is omitted, the forwarding behavior, and that the server never signs payments.

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 answers what crypto market regime is occurring, with specific outputs (verdict enum, summary, confidence) and data sources. It is distinct from all sibling tools, which focus on freight, government, and wallet utilities.

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 provides clear context on when to use the tool: to determine market regime and smart money accumulation/distribution. It does not explicitly name alternatives or exclusions, but no direct sibling overlaps exist, and the payment flow is clearly described.

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 operation is a search (implying read-only), is free, and returns specific fields (URL, price, networks, quality signals). It does not mention pagination or rate limits, but search tools are typically safe.

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 main purpose, and contains no redundant information. Every clause adds value: scope, sources, return fields, and cost.

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 covers the core aspects: what it searches, sources, return contents, and cost. Without an output schema, it summarizes the response fields well. It does not explain pagination defaults, but those are in 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add additional parameter semantics, but the schema already provides clear meaning.

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 and resource: 'Search every paid x402 endpoint' with clear scope (own + mirrored catalogs). This clearly distinguishes it from sibling tools like suverse_estimate_cost or suverse_balance, 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 provides clear context for when to use the tool: when searching paid x402 endpoints. It mentions 'FREE — no payment', which is a practical usage hint, but does not explicitly name alternatives or 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?

With no annotations, the description fully discloses cost ($0.05 USDC), payment flow (402 instructions without signature, paid response with signature), and the limitation that the elite-flow signal is often absent. It also clarifies the tool itself doesn't pay and the server doesn't hold keys.

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 front-loaded with purpose, followed by cost and a caveat. Every sentence carries useful information with no fluff or repetition.

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 paid API tool with no output schema, the description is comprehensive: it explains what the verdict includes, how payment works, and the limitations of the signal. No critical information 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?

The schema already documents both parameters thoroughly (token format, payment_signature mechanics). The description adds the behavioral context that without payment_signature, the tool returns price and 402 instructions, which helps interpret the optional parameter. This is a value-add beyond the 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?

The description explicitly states the tool answers whether a Solana token is sane to enter, with a verdict containing risk level and specific flags. It distinguishes from siblings like suverse_market_pulse by focusing on a specific token's safety and liquidity.

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 clear context for when to use (to evaluate a token before entry) and includes a caveat about the elite-flow signal being Solana-only and often zero. It does not explicitly name alternative tools or exclusions, 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 reveals key behaviors: the $0.03 USDC cost, the x402 payment flow (returns price/instructions without payment_signature), the on-chain-only data basis, and the 'unknown' tier for unindexed wallets. This substantially covers the tool's side effects and edge cases, though no rate limits or error handling are described.

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 uses three sentences and front-loads the purpose before addressing cost and limitations. It is efficient but somewhat dense, packing a lot of detail into a paragraph format. No redundant words, but the structure could be slightly improved with bullet points.

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 explains what the verdict contains (tier, activity class, flags, stats, trades), the payment/cost model, and the edge case for unindexed wallets. This is fairly complete for an agent deciding whether to invoke it, though it doesn't detail response format or errors beyond the 'unknown' tier.

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 both parameters at 100% coverage, so the baseline is 3. The description adds value by clarifying the two-call payment workflow involving payment_signature (unpaid call returns price/instructions; paid call returns full response) and the Solana-specific scope for the wallet 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 opens with a clear question that defines the tool's function: assessing whether a Solana wallet's trading can be trusted or copied. It enumerates the output components (skill tier, activity class, flags, stats, trades) and the Solana-only scope, distinguishing it from the other suverse_* 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 implies the tool's use case (wallet reputation evaluation) but does not explicitly state when to use it over alternatives or mention exclusions. It notes the Solana-only limitation and payment requirement, which helps, but no alternative tools are referenced or compared.

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