22 pay-per-call developer, security, network and data utilities using x402 on Base.
Scored across 31 tools
Many tools are clearly distinct utilities, but the security-audit family overlaps heavily: get_dns_lookup, get_domain_intelligence, get_web_audit, get_security_posture, and post_domain_due_diligence all cover similar DNS/TLS/headers territory with varying scope and scoring. The repo risk reports also form an escalating hierarchy (standard/deep/due diligence) that requires careful reading to select correctly.
The set consistently uses snake_case and a get_/post_ prefix pattern, but the semantic structure varies: some names are noun phrases like get_dns_lookup and get_security_headers, while others embed verbs like get_jwt_decode, post_json_minify, and get_timestamp_convert. This makes the convention readable but not fully predictable.
31 tools is well beyond the typical well-scoped 3-15 range and falls into the 'too many' category. The high count is further aggravated by the lack of a single focused domain, as the tools span DNS/TLS audits, encoding utilities, JSON/text helpers, Quebec invoices, repo risk reports, and blockchain payment checks.
There is no coherent domain to evaluate for lifecycle completeness; the server appears to be a grab bag of unrelated utilities and specialized reports. Within individual subareas some coverage exists, but the overall surface has no clear purpose and leaves obvious gaps relative to any implied domain.
Resolve ONE DNS record type for a domain. For all record types at once use /domain/intelligence; for a bundled DNS+TLS+headers audit use /web/audit or /security/posture; for mail-security plus a scored verdict use /domain/due-diligence.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| record_type | No | A |
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 communicates the key scoping behavior (one record type per call) but does not describe return format, error behavior, or whether an external network query is performed. This is adequate but leaves the safety and output profile largely implicit.
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 first sentence states the core action, and the second sentence packs all alternative routing into compact, scannable clauses. Every part earns its place with zero 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 two-parameter lookup, the selection context is nearly complete, but invocation details are not. There is no accepted-value list for record_type, no return description, and no output schema or annotations to fill the gaps, so an agent has enough to choose the tool but not quite enough to call it with full confidence.
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?
Input schema descriptions cover 0% of parameters, so the description must compensate, but it only implies the domain and record_type roles. It clarifies that record_type is a single type, yet it never lists accepted record types or domain formatting, leaving an agent to guess beyond the default A.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Resolve ONE DNS record type for a domain,' immediately distinguishing this from broader domain tools. It names sibling alternatives for different use cases, so an agent can disambiguate without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing guidance: use /domain/intelligence for all record types at once, /web/audit or /security/posture for a bundled audit, and /domain/due-diligence for mail-security plus scored verdict. These are concrete when-to-use conditions and clear exclusions for the current tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect ALL common DNS record types (A/AAAA/MX/NS/TXT/CAA) for a domain in one call -- the multi-record bundle version of /dns/lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
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 does reveal that the tool aggregates multiple record types in a single request, which is useful. However, it does not mention potential limitations such as missing record types, timeouts, rate limits, or the exact response format. This is a gap but not a severe one for a simple DNS lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise clauses with zero filler. It front-loads the action and scope, then provides the comparison to the sibling via a dash. Every word 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?
Given this is a simple one-parameter tool with no output schema and no annotations, the description covers the core purpose and identifies the alternative. It does not discuss error handling or edge cases, but for a read-only DNS lookup tool, the essential context is present. A 4 is justified because it is nearly complete, missing only minor non-essential details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter is 'domain,' and the description explains that it is the domain for which records are collected. This adds some meaning beyond the bare schema (type string, title 'Domain'). However, it does not clarify format expectations (e.g., whether protocol/subdomain is accepted), but domain is a familiar concept, so a 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 uses a specific verb ('Collect') with a clear resource ('ALL common DNS record types') and enumerates the exact types (A/AAAA/MX/NS/TXT/CAA). It also differentiates itself from the sibling get_dns_lookup by framing itself as the 'multi-record bundle version.' This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need multiple DNS record types in one call, as opposed to a single-record lookup. It explicitly references '/dns/lookup' as the alternative, which is a sibling. However, it does not explicitly state when not to use it (e.g., when only one record type is needed), 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.
Decode a JWT payload without signature verification.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does reveal one important trait—signature verification is not performed—but omits expected output format, error behavior on invalid or malformed JWTs, and whether the raw token may include a 'Bearer ' prefix.
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 entire description is one short sentence that front-loads the action and the most important caveat. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is adequate for a trivial one-parameter decoder, but it lacks return-value and error-handling details that would matter without an output schema. The caveat about signature verification helps, but the agent still cannot predict invalid-token behavior or the exact payload representation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about the 'token' parameter beyond what the schema already shows. It does not clarify accepted token format (with/without header/payload/signature, Bearer prefix), so the single parameter is under-documented.
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 ('Decode'), a specific resource ('JWT payload'), and a key qualifier ('without signature verification'), so an agent can tell exactly what is offered. It also stands apart from the sibling utilities, none of which claim JWT decoding.
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 intended use: inspecting or extracting a JWT payload rather than checking authenticity. It gives no explicit when-to-use conditions and names no alternative for signature verification, leaving the routing decision partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect HTTP security headers for ONE URL only. For headers combined with TLS and DNS, use /web/audit (raw) or /security/posture (scored).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the single-URL limitation, which is useful, but doesn't describe whether the tool follows redirects, whether it checks live or cached headers, or what happens on connection failure. The main behavioral trait (single-URL constraint) is disclosed, but richer detail would be needed for a thorough pass.
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?
Exactly two sentences: the first states the core function and the single-URL constraint; the second names alternatives for broader scans. No filler or redundant phrasing.
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 one parameter, no output schema, and no annotations. The description captures the essential purpose, scope limitation, and alternative routes for adjacent needs. It lacks details about return shape or failure behavior, but for a simple single-parameter inspection tool, the coverage is quite good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the schema only lists 'url' as a string with no description. The description compensates by clarifying that the URL must be a single URL and specifically for HTTP security headers. It doesn't state URL format requirements, but with only one parameter and no schema guidance, the description adds meaningful clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Inspect'), resource ('HTTP security headers'), and clear scope ('for ONE URL only'). This distinguishes it from broader audit/posture tools and sibling tools like get_ssl_check or get_dns_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool is for one URL only and routes to use /web/audit or /security/posture for headers combined with TLS/DNS. It doesn't enumerate exclusions vs all siblings, but the single-URL constraint and alternative routing are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess TLS and HTTP security posture for a public HTTPS website -- the SAME inspection as /web/audit, but returns a 0-100 score/grade and findings instead of raw fields.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
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 does disclose the output transformation behavior (score/grade/findings instead of raw fields) and narrows the target to public HTTPS sites, but it does not mention whether this involves a live scan, potential latency, failure behavior, or any rate/usage constraints.
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 entire description is one compact sentence that front-loads the purpose, identifies the inspection scope, names the sibling alternative, and states the key output difference. Every clause contributes meaning with no repetition 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 simple one-parameter GET-style tool without an output schema, the description is largely sufficient: it states what is assessed, the output format, and the relationship to a sibling tool. It could be more complete with an explicit usage recommendation and a bit more detail about the returned findings, but nothing essential is missing for basic 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 only defines 'url' as a required string with 0% description coverage, so the description must compensate. It adds the key semantic that the URL should be a public HTTPS website, but it does not specify URL format details or whether the scheme must be explicit, leaving some ambiguity for a single-parameter tool.
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 ('Assess'), names the exact resource (TLS and HTTP security posture for a public HTTPS website), and distinguishes itself from the sibling get_web_audit by clarifying it returns a score/grade/findings rather than raw fields. It clearly differentiates the tool within the sibling set.
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 points to the same inspection as /web/audit, which identifies get_web_audit as the alternative, and implies the choice depends on whether the caller wants a summarized score/grade/findings versus raw fields. It provides clear context but does not explicitly state when to choose one over the other or give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the TLS certificate for ONE hostname only. For TLS combined with HTTP headers and DNS, use /web/audit (raw) or /security/posture (scored).
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes |
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 behavioral disclosure. It communicates the single-hostname constraint, which is a useful behavioral trait, but it does not disclose the return format, whether the full trust chain is inspected, failure modes, or any potential side effects. For a read-only inspect operation this is acceptable but not thorough.
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: the first states the core function and scope, the second routes to alternatives. Every word earns its place, and the most critical constraint ('ONE hostname only') is front-loaded. 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 simple single-parameter tool with no output schema, the description covers the core purpose, scope, and when not to use it. It could mention what the response contains (certificate details, expiration, issuer) but the tool name and purpose make that largely inferable. The main missing piece is parameter format guidance, already penalized in parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds only the constraint of 'ONE hostname' but does not clarify acceptable formats (e.g., bare domain vs. URL-with-scheme, whether ports are allowed). An agent could plausibly pass 'https://example.com/path' because the format is not specified. This is a real gap given the low 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 uses a specific verb ('Inspect') and resource ('TLS certificate') and explicitly limits scope to 'ONE hostname only.' This clearly differentiates it from sibling tools like get_dns_lookup or get_security_headers, which target different resources. The purpose is unambiguous and immediately actionable.
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 this tool vs alternatives: 'For TLS combined with HTTP headers and DNS, use /web/audit (raw) or /security/posture (scored).' It names concrete sibling tools and the exact condition that should route an agent away from this tool. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate subnet information from CIDR notation.
| Name | Required | Description | Default |
|---|---|---|---|
| cidr | Yes |
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 does not mention what subnet information is returned, how invalid CIDR input is handled, or whether IPv4/IPv6 are supported. The description adds no behavioral context beyond the tool's name.
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. It communicates the essential operation efficiently and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves return values and behavioral outcomes undefined. It is minimal enough that an agent must guess what 'subnet information' includes and whether edge cases like malformed CIDR are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only repeats 'CIDR notation,' which adds little beyond the parameter name 'cidr.' No format examples, constraints, or clarification of expected values are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Calculate subnet information') applied to a specific input ('CIDR notation'). It distinguishes itself from the sibling tools because no other sibling is dedicated to subnet calculation, so the purpose is unambiguous.
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?
There is no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. The description implies usage only through its purpose statement, which is not enough to help an agent decide between this and related network utilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Unix timestamp to UTC ISO-8601.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It clearly discloses the transformation and the expected output format. It does not mention edge cases like seconds versus milliseconds or invalid input handling, but for a simple pure conversion the core behavior is 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 a single efficient sentence with no filler or redundancy. It is front-loaded with the action and directly states both input and output, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter pure transformation with no output schema, the description covers the input, the conversion operation, and the output format. The only minor omission is explicit handling of Unix timestamp units or invalid inputs, but nothing essential is missing for selecting and invoking 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?
The input schema only provides a generic 'Timestamp' number, so the description adds meaningful semantics by identifying it as a Unix timestamp and specifying the desired output. It does not explicitly state whether the value should be in seconds, but 'Unix timestamp' is a widely understood convention and the single required parameter is well contextualized.
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 ('Convert'), the input resource ('Unix timestamp'), and the output format ('UTC ISO-8601'). This is specific and differentiates the tool from all sibling utilities such as get_jwt_decode or get_uuid_generate.
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?
While the description does not explicitly name alternatives or exclusion conditions, the purpose is self-contained: an agent can infer it should be used whenever a Unix timestamp needs conversion to UTC ISO-8601. No similar timestamp-conversion sibling exists, so additional routing guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a URL into structured components.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden, yet the single sentence adds no context about error handling for malformed URLs, whether a scheme is required, or any normalization behavior. It does not contradict the (absent) annotations, but it tells the agent nothing about what happens on invalid input.
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 clean, front-loaded sentence with the verb leading and no filler words. It could have packed slightly more meaning (e.g., naming the components) at the same length, but it is appropriately sized for a one-parameter utility.
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 definition is materially incomplete: the agent has no way to learn what 'structured components' concretely means, what the response shape is, or how invalid URLs are handled. For a tool that an agent must invoke correctly, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the required url parameter, so the description must compensate. 'Parse a URL' merely restates the parameter name and adds no format requirements or accepted-input details, leaving the agent without compensating semantics for the undocumented schema field.
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 ('Parse') and a clear resource ('a URL'), and the operation is distinct enough from siblings like get_dns_lookup and get_jwt_decode that an agent can tell it apart. However, 'structured components' is left undefined — the agent is not told which components (scheme, host, path, query, fragment) are produced, which prevents a top score.
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 when-to-use guidance is provided at all. With 34 siblings, none is named as an alternative or explicitly excluded, so an agent must infer entirely from the name when URL parsing is preferable to adjacent tools like get_domain_intelligence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random UUID version 4.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
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 states the core behavior (generating a random UUID v4) but does not disclose the effect of the 'count' parameter (likely producing multiple UUIDs), the output format, or any side effects/limitations. This leaves the agent guessing about batch behavior and response shape.
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 word contributes to conveying the tool's purpose, making it highly efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotation, the description should explain return values and parameter effects. It does neither. For an agent to call this tool correctly with a custom count, it must infer semantics from the parameter name alone, which is a clear gap for such a minimal definition.
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 has 0% description coverage for the sole parameter 'count', and the description does not explain what count does or how it affects the result. The parameter name and default value hint that it controls the number of UUIDs generated, but the description adds no meaning beyond the raw 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 clearly states the tool's function with a specific verb and resource: 'Generate a random UUID version 4.' It is immediately distinguishable from all sibling tools, which cover DNS, JWT, security headers, JSON utilities, etc., none of which overlap with UUID generation.
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 explicit when-to-use guidance or alternatives are mentioned. However, the use case is self-evident from the description—use when a random UUID v4 is needed—and no sibling tool appears to offer this functionality. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidated DNS, TLS and HTTP security audit for a public HTTPS website, returned as RAW findings (no score) -- the bundled version of /dns/lookup + /ssl/check + /security/headers. Use /security/posture instead for a 0-100 score/grade.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
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 reveal a key behavior: output is raw findings and no score is computed. It also indicates the audit is a combination of DNS, TLS, and HTTP checks. However, it does not mention authentication requirements, rate limits, or the exact structure of the findings, which are relevant for a security audit tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core purpose, clearly states the output style, and includes an alternative in a compact way. Every word 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 tool combines multiple audit areas and there is no output schema, so the description should provide more context about what the raw findings include or how they are structured. It does mention the components (DNS, TLS, HTTP headers) and the no-score nature, but lacks details on the response format, error behavior, or required URL validation rules. Given the moderate complexity, this is acceptable but not 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 schema has a single 'url' parameter with zero description coverage. The tool description only mentions 'a public HTTPS website,' which hints at the expected input type but does not clarify URL format, protocol requirements, or how the parameter is used in the audit. Given the low coverage, the description should compensate more explicitly, but it does not.
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 performs a consolidated DNS, TLS, and HTTP security audit for a public HTTPS website, and specifies it returns raw findings without a score. It also explicitly differentiates itself from sibling tools by identifying it as the bundled version of three separate endpoints, so an agent knows exactly what resource this tool covers.
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 a clear alternative: 'Use /security/posture instead for a 0-100 score/grade.' This tells the agent when to choose a different tool if a score is desired. However, it does not elaborate on specific scenarios where the bundled audit is preferable over individual lookups beyond the implicit 'bundled' nature, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode Base64 to UTF-8 text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full responsibility for behavioral disclosure. It accurately describes the transformation and output encoding, but it does not mention behavior on malformed Base64, non-UTF-8 bytes, or the envelope of the returned response.
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 short sentence with no filler. Every word contributes meaning, and the core action 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?
For a one-parameter utility with no output schema and no annotations, the description states the essential input and output clearly. It omits edge-case handling details, but nothing critical is missing for an agent to invoke the tool correctly in the common case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining what the 'text' parameter represents. 'Decode Base64' implies that the single parameter is Base64-encoded input, which adds meaning beyond the bare schema, though it does not explicitly define accepted variations such as padding or whitespace.
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, 'Decode', a specific resource, 'Base64', and the output format, 'UTF-8 text'. It clearly distinguishes the tool from its sibling post_base64_encode because it captures the inverse operation.
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 intended use is implied by the verb 'decode' and the target 'UTF-8 text', so an agent can infer when to use it. However, it provides no explicit guidance about alternatives such as post_base64_encode or related text/data transformation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode UTF-8 text using Base64.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
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 accurately states the core transformation but does not mention output representation, base64 padding, handling of invalid UTF-8, or whether the operation is stateless. These are minor gaps for a simple encoder, so a mid score is appropriate.
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 word adds meaning: the verb, the input format, and the algorithm are all specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter pure encoding utility, this description is largely sufficient: an agent can infer the Base64 output and that no side effects are involved. The only missing piece is an explicit statement of the return format, but the tool name and sibling post_base64_decode make the result obvious.
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 defines one 'text' string parameter with 0% description coverage, so the tool description must compensate. The phrase 'UTF-8 text' clarifies the expected input encoding beyond the bare parameter name, but it does not define constraints like empty strings, maximum length, or how non-ASCII characters are handled.
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 ('Encode'), a resource ('UTF-8 text'), and the encoding method ('Base64'), which clearly distinguishes it from sibling post_base64_decode and other transform tools. It is immediately clear what the tool does and how it differs from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives such as post_base64_decode or post_data_transform. The description gives no selection criteria, exclusions, or pairing advice, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize and transform common structured text automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| operation | No | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'automatically' hints at auto-detection of the operation, but the description does not explain how that behaves, what happens on unrecognized input, or what output format to expect. This is especially weak for a POST tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, which is structurally clean. However, it is under-specified for the tool's apparent breadth—conciseness here comes at the cost of useful details.
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 enum-based operation parameter and the availability of sibling tools for each specific transformation, the description is not complete enough. It does not list the supported operations, explain the auto mode, or clarify the relationship to specialized sibling endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds essentially no parameter-level meaning. It does not explain the 'operation' enum, the default 'auto' behavior, or how each operation affects the 'text' input. The mention of 'structured text' is the only indirect clue about the text 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 states a general purpose—normalizing and transforming structured text—but it is vague. It does not mention specific supported transformations such as JSON pretty/minify, Base64, or deduplication, nor does it differentiate from sibling tools like post_json_pretty or post_base64_encode.
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?
There is no guidance on when to use this tool versus the many sibling tools that cover specific operations. The description does not say 'use this for auto-detected transformations' or 'use the dedicated tool for X'. An agent must infer usage entirely from the schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most comprehensive domain assessment: DNS + mail security (SPF/DKIM/DMARC) + TLS + HTTP headers, scored. The only endpoint in this group that adds mail-security analysis. Use for a one-shot decision-grade verdict on an unfamiliar domain; use /dns/lookup, /ssl/check, /security/headers, /web/audit or /security/posture instead for a single fact or a cheaper signal.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public domain name to assess |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does disclose the core behavior: it performs a scored assessment rather than a mutation, and enumerates exactly what it analyzes. It does not explicitly mention auth needs, rate limits, or a statement that no changes are made to the domain, but the 'assessment' and 'verdict' framing makes the non-destructive nature reasonably clear.
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 tightly written sentences with no filler. It front-loads the core value ('most comprehensive domain assessment'), summarizes scope, adds the unique differentiator, and closes with actionable routing to alternatives. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex assessment endpoint, the description covers its scope, output nature ('scored', 'decision-grade verdict'), and when to use alternatives. With no output schema present, it could add the scoring scale or response shape, but the given detail is sufficient for an agent to select and invoke the tool correctly with only a required `domain` parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter (`domain`) with a description, title, example, and minLength, so schema coverage is 100%. The tool description reinforces that the domain should be a public, unfamiliar domain to assess, but it does not add materially deeper parameter semantics beyond what the schema provides.
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 ('comprehensive domain assessment'), enumerates the checked areas (DNS, SPF/DKIM/DMARC, TLS, HTTP headers), and notes it is scored. It also explicitly distinguishes itself from sibling endpoints by being 'the only endpoint in this group that adds mail-security analysis.'
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: 'Use for a one-shot decision-grade verdict on an unfamiliar domain.' It also names concrete alternatives ('/dns/lookup, /ssl/check, /security/headers, /web/audit or /security/posture') for cheaper or single-fact needs, making the choice unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flags pinned dependencies in a repository's requirements.txt, package-lock.json, or uv.lock published more recently than a freshness threshold -- a supply-chain-compromise tripwire. Free CLI (requirements.txt/package-lock.json only, uv.lock support pending there): github.com/sbakhour/freshdep.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional branch/tag to check out instead of the default branch. | |
| repo_url | Yes | Full https://github.com/<owner>/<repo> URL to scan. | |
| threshold_days | No | Flag anything published more recently than this many days ago. Defaults to 7. |
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 communicates that the tool performs a read-only flagging operation on specific lock files, but it does not disclose potential limitations such as repository-access requirements, rate limits, or the shape of the 'flags' output. This is adequate but not thorough.
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 first sentence front-loads the core purpose and scope efficiently. The second sentence adds a CLI link that is not clearly relevant to invoking this API tool, but the overall description remains compact and readable.
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, with three well-documented parameters, and the description covers the core behavior and target files. However, since there is no output schema, the description does not clarify what the tool returns (e.g., a list of flagged dependency names), which would help an agent use the result 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 parameters are already documented in the schema. The description adds useful context around 'freshness threshold' and 'pinned dependencies,' but it does not materially expand the semantics of repo_url, ref, or threshold_days beyond what the schema already provides.
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 the concrete verb 'Flags' and identifies the exact resources scanned (requirements.txt, package-lock.json, uv.lock) plus the freshness-threshold condition. This makes the tool's purpose unmistakable and clearly differentiates it from the broader repo-risk-report 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 phrase 'supply-chain-compromise tripwire' implies a security-audit use case, but the description never explicitly says when to prefer this tool over the post_security_repo_risk_report_* siblings. The usage context is present but the comparison and exclusion guidance are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate SHA-256 digest from text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It communicates the operation and output concept (digest), but it does not state output encoding (e.g., hex), determinism, or absence of side effects. For a simple pure hash function this is a moderate gap.
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 with no filler and front-loads the action and algorithm. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter pure hash tool with no output schema, the description is nearly complete. The only clear omission is the exact return representation, but 'digest' conveys the expected output well enough for SHA-256.
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 0%, but the description's 'from text' clarifies that the single required text parameter is the input to hash. Since the parameter name is already self-descriptive, the minimal description is sufficient.
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 (Generate), a precise resource (SHA-256 digest), and the input source (text). It is immediately distinguishable from sibling tools such as post_hash_sha512 and the get_* 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?
The description gives no guidance about when to prefer this tool over alternatives or any exclusions. Use case must be inferred entirely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate SHA-512 digest from text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the input and operation but does not specify output format (e.g., hex vs base64), character encoding support, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words. The key information (verb and resource) appears upfront.
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 one string parameter and no annotations or output schema, the description is minimal but mostly adequate for invocation. However, it omits the return value format, which is important for consuming the result.
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 0%, so the description must compensate. It does indicate the text parameter is the input to be hashed, but adds no details about encoding, length limits, or required format.
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 the verb 'generate' and names the specific resource 'SHA-512 digest', making the tool's function unambiguous. The algorithm name differentiates it from sibling post_hash_sha256, though it does not explicitly reference that alternative.
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 provided on when to use this tool versus other hash or transform siblings. The description only states what it does, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Minify valid JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates that the operation is a transformation and sets an input precondition ('valid JSON text'), but it does not describe invalid-input handling, the exact output shape, or whether the operation has any side effects. This is adequate for a simple pure transformation but not rich.
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 five words long, front-loaded, and contains no filler. Every word contributes: 'Minify' states the action, 'valid' sets the precondition, and 'JSON text' identifies the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter transformation tool with no annotations and no output schema, the description is largely adequate: it identifies the input and operation. However, it omits return-value details, error behavior, and any routing among closely related JSON tools, leaving a modest completeness gap.
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 only defines 'text' as a string with 0% description coverage, so the tool description must add meaning. 'Minify valid JSON text' tells the agent that the parameter must contain valid JSON, which is essential semantic information beyond the raw schema. For a single obvious parameter, this is sufficient.
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 ('minify') and a specific resource ('valid JSON text'). This clearly distinguishes it from siblings like post_json_pretty, post_json_validate, and post_json_repair, since each has a distinct verb and purpose.
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 word 'valid' implies a prerequisite: this tool is meant for valid JSON input, not for repairing or validating it. However, it does not explicitly name alternatives or state when to prefer this tool over sibling tools such as post_json_pretty or post_data_transform, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pretty-print valid JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It communicates the core transformation and an input precondition ('valid JSON') but does not disclose what happens with invalid input, the output format details, or whether the operation is purely transformative. For a simple stateless formatter this is adequate but not deeply 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 a single, front-loaded sentence with no filler. Every word adds value: 'pretty-print' states the action and 'valid JSON text' states the input requirement. It is appropriately minimal for a tool of this simplicity.
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 tool with one string parameter and no output schema, the description is mostly complete: it names the input precondition and the expected transformation. It falls slightly short by not stating invalid-input behavior or confirming the return value, but an agent can reasonably infer the standard formatter behavior.
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 no property descriptions, giving 0% schema coverage. The description adds some meaning by indicating the 'text' parameter must be valid JSON, but it does not specify encoding, size limits, whitespace handling, or examples. The single parameter named 'text' is fairly self-explanatory, so a mid-range score 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 uses a specific verb and resource: 'Pretty-print valid JSON text.' This clearly differentiates the tool from its JSON-related siblings such as post_json_minify, post_json_validate, and post_json_repair by focusing on formatting rather than validating, repairing, or minifying.
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 states what the tool does but provides no guidance on when to choose it over alternatives. It does not explicitly say to use post_json_minify for compact output or post_json_validate/post_json_repair for invalid JSON. The agent must infer usage context from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repair common malformed JSON formatting issues.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
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 explaining behavior. It says only that it repairs malformed JSON but does not disclose what transformations are applied, whether valid JSON is passed through unchanged, what happens if repair is impossible, or whether the response contains the repaired text.
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 very short and front-loaded, with no filler words. However, it is under-specified; the brevity comes at the cost of omitting behavioral details and parameter clarification, so it is not 'appropriately sized' for the tool's needs.
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 annotations, no output schema, and an undocumented parameter, the description is incomplete. An agent cannot confidently call this tool without knowing what counts as a repairable issue, what output to expect, or how it differs operationally from the JSON validate/minify/pretty siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify that the single 'text' parameter is the JSON string to repair. The parameter name and tool name offer a weak inference, but the description fails to specify expected input format, size limits, or how the repaired result is returned.
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, 'Repair', and a resource, 'common malformed JSON formatting issues', which clearly distinguishes it from siblings like post_json_validate, post_json_minify, and post_json_pretty. It is not a tautology and gives a usable idea of the tool's job, though 'common' and 'issues' remain somewhat vague.
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?
There is no guidance on when to use this tool versus alternatives such as post_json_validate or post_json_minify. The description does not mention when it should be preferred, what inputs are suitable, or what scenarios are not covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON text and return parsing details.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral disclosure burden. It says 'return parsing details' but does not specify what happens for valid versus invalid JSON, whether errors are thrown or returned, or what the parsing details include. This is a meaningful gap for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, gets straight to the point, and is easy to parse. It is appropriately concise for a tool with a single parameter and no nested schemas.
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 no annotations and no output schema, so the description needed to explain the return contract. 'Parsing details' is too vague: an agent cannot predict the exact response shape, how invalid JSON is signaled, or whether validation results include error positions. The description is adequate for basic selection but not complete for reliable 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 schema defines a single required 'text' string with no description, and the tool description only adds that it is JSON text. This confirms the parameter's role but does not provide additional detail such as size limits, whether empty strings are allowed, or whether the text must be a complete JSON document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Validate JSON text') and the expected outcome ('return parsing details'). It is also naturally distinguished from sibling JSON tools like post_json_minify, post_json_pretty, and post_json_repair, since validation is semantically different from formatting or repairing.
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 provided about when to use this tool versus alternatives such as post_json_repair or post_json_pretty. The description does not state whether this tool should be used as a precursor to other JSON operations or what conditions would make a different sibling a better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an image between common formats (e.g. PNG/JPEG/WebP) from a URL or base64 payload.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It states the conversion action but does not indicate whether the operation has side effects, how the output is returned, whether it is asynchronous, or any limits/errors. This is a significant gap for a tool with no other behavioral metadata.
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 is front-loaded with the action and resource, then adds examples and input source types. Every word contributes value, and there is no redundant or fluff content. It is 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?
Given the empty input schema, lack of annotations, and no output schema, the description is far from complete. It leaves critical information missing: required parameters, accepted formats beyond examples, how targets are specified, and what the response looks like. While it provides a basic idea of the operation, it is not enough for an agent to call 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?
The input schema is empty, so there are no parameter names or types documented. The description mentions 'URL or base64 payload' but does not specify how to pass these values, nor does it mention a target format parameter or output configuration. This provides only a vague hint of the required inputs, insufficient for correct invocation.
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 ('Convert') with a clear resource ('image'), names source types ('URL or base64 payload'), and gives concrete formats (PNG/JPEG/WebP). It is unambiguous and easily distinguished from sibling tools like post_media_video_generate_*, which are about video generation, so the purpose is fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an image needs format conversion and is available via URL or base64. However, it does not explicitly mention alternatives, exclusions, or conditions such as size limits or unsupported formats. Usage context is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies GST/QST were calculated correctly per Revenu Quebec's current (non-compounded) formula, and flags whether a French invoice version is present per Charter of the French Language s.57/89/91. Pure arithmetic + text check; not legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| subtotal | Yes | Pre-tax subtotal in CAD. | |
| gst_amount | Yes | GST amount as shown on the invoice. | |
| qst_amount | Yes | QST amount as shown on the invoice. | |
| french_text | No | The invoice's French text, if any (optional -- its absence is itself flagged). | |
| english_text | No | The invoice's primary/other-language text (optional but needed for the language check). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the tool performs only arithmetic and text checks, states the formula is non-compounded, flags absence of French text, and explicitly disclaims legal/tax advice. It does not detail error cases or threshold rounding behavior, but it gives strong transparency for a pure validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with high information density. It front-loads the main verification action, adds the French-language check, and ends with a useful disclaimer. Every phrase earns its place, and the optional-parameter clarification is packed into the schema text rather than bloating the main description.
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 does not explain the return shape, but the tool's outcomes are comparatively simple (pass/fail style flags for arithmetic and language presence). The main gaps are lack of explicit rounding rule and return structure, but the tool is simple enough that an agent can invoke it correctly with the provided 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 coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that gst_amount and qst_amount are the values shown on the invoice, subtotal is pre-tax CAD, and the absence of french_text is itself flagged. It also clarifies that english_text is optional but needed for the language check, going beyond the schema's terse labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verifies') and resource ('GST/QST calculation per Revenu Quebec formula') plus a second check (French invoice presence per Charter provisions), and clarifies it is a pure arithmetic/text check, not legal advice. This distinguishes it from siblings such as post_quebec_invoice_generate because it is a compliance verification tool, not a generation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when checking Quebec invoice compliance for GST/QST and French-language requirements. It does not explicitly name alternatives or when not to use it, but the sibling list clearly separates generation (post_quebec_invoice_generate) from checking, and the description's own scoping ('not legal or tax advice') adds a practical boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assembles a bilingual (French/English) Quebec invoice document with GST/QST computed exactly per Revenu Quebec's current formula -- you supply both languages' line-item text, this does not translate. Not legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| line_items | Yes | Each item needs description_en, description_fr (both required -- this assembles, it does not translate), and amount. | |
| seller_name | Yes | Seller/business name to display. | |
| invoice_number | Yes | Your own invoice number/reference. | |
| seller_gst_number | No | GST registration number, optional. | |
| seller_qst_number | No | QST registration number, optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It usefully discloses that GST/QST are computed exactly per Revenu Quebec's current formula, that translation is not performed, and that the output is not legal or tax advice. It does not specify the output document format, but the core non-obvious behavior is 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 two efficiently front-loaded sentences: the first states the action, scope, and key non-translation constraint; the second adds the legal disclaimer. Every phrase earns its place and there is no 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 generation tool with no output schema and no annotations, the description plus fully covered schema gives an agent enough to select and invoke the tool correctly. A brief mention of the return format or of the compliance-check sibling would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces that line-item text must be bilingual and is not translated, but it does not add new parameter syntax, formats, or constraints beyond what the schema already provides.
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 ('Assembles') and a specific resource ('bilingual (French/English) Quebec invoice document'), and it adds a key constraint that the tool does not translate. It does not explicitly differentiate from the sibling tool post_quebec_invoice_compliance_check, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it assembles, does not translate, and requires the caller to supply both languages' line-item text. This implies when to use it, but it does not explicitly mention alternatives or a when-not scenario relative to the compliance-check sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything in the standard report, plus a repo-wide secret/credential exposure scan (matched values are never returned).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional branch/tag to analyze. Defaults to the repository's default branch. | |
| repo_url | Yes | Public https://github.com/... or https://gitlab.com/... repository URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It uses that space to guarantee that matched secret values are never returned, which is a meaningful output-privacy behavior beyond the schema. It also indicates the scan is repo-wide. It does not mention auth, runtime, or side effects, but the redaction guarantee is valuable.
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 entire description is one well-structured sentence that front-loads the relationship to the standard report and appends the key caveat. There is no filler and no repetition of schema information.
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 essential selection point (deep vs standard) and the key redaction behavior. However, it does not describe the report's return format or how this tool compares with the due_diligence sibling. With no output schema and no annotations, a bit more context about what the agent receives 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 documents both parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific syntax or constraints; 'repo-wide' and 'standard report' are tool-scope context rather than parameter semantics.
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 concrete deliverable (repo risk report) and adds the differentiating secret/credential exposure scan, so an agent can distinguish it from the standard variant. It never states a direct verb like 'generates' or 'returns', relying on the tool name and 'report' for the action. Still, the resource and extra feature are clear.
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 phrase 'Everything in the standard report, plus...' signals that the deep variant is for situations where a standard repo risk report should also include a secret/credential scan. This gives a clear context for choosing this tool over the standard report. It does not explicitly say when not to use it or how it relates to the due_diligence sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything in the deep report, plus real OpenSSF Scorecard maintainer/governance signals and a prioritized recommendation. An automated baseline positioned against $5,000-$95,000 human technical due diligence.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional branch/tag to analyze. Defaults to the repository's default branch. | |
| repo_url | Yes | Public https://github.com/... or https://gitlab.com/... repository URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context about report contents ('real OpenSSF Scorecard maintainer/governance signals', 'prioritized recommendation') and calls itself an 'automated baseline.' However, it does not disclose limitations, result shape, external calls, or any failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the functional distinction from the deep report. The second sentence about $5,000-$95,000 human due diligence is more positioning than tool-usage guidance, slightly reducing its value, but overall the description remains appropriately short.
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 report-generation tool with no annotations and no output schema, the description gives a reasonable sense of the deliverable's contents. It does not describe the output format, how results are returned, or how this report differs operationally from deep/standard reports, leaving some ambiguity for an agent deciding between sibling tools.
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 both parameters with 100% coverage, so the schema carries the parameter documentation burden. The description adds no extra meaning about repo_url or ref, which is acceptable but not additive.
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 identifies the report as an extension of the deep report with added OpenSSF Scorecard signals and a prioritized recommendation, which distinguishes it from sibling report tools. However, it never states an explicit verb such as 'generates' or 'produces,' relying on the tool name and sibling comparison to convey the action.
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 phrase 'Everything in the deep report, plus...' implies this tool is a superset of the deep report and therefore positions it as a more comprehensive option. Yet it does not explicitly state when to choose this over standard/deep reports, nor does it name the alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SBOM inventory plus real OSV.dev dependency-vulnerability matches and dependency-freshness signals for a public Git repository. One-shot alternative to a per-seat secret-scanning subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional branch/tag to analyze. Defaults to the repository's default branch. | |
| repo_url | Yes | Public https://github.com/... or https://gitlab.com/... repository URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does provide meaningful specifics: it reports real OSV.dev matches and freshness signals rather than mere placeholders. It does not disclose output format, potential external calls, or any limitations, but the core behavior is reasonably 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?
Two sentences with no filler; the substantive content is front-loaded. The second sentence is positioned as a value proposition rather than technical detail, but it is still brief and useful.
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 gives a clear sense of what the tool analyzes and what signals it reports, which is helpful given the absence of an output schema. It does not explain the return structure or how the 'standard' tier differs from sibling risk-report tools, leaving some context 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?
Schema coverage is 100%, so both repo_url and ref are already described in the input schema. The description adds limited extra parameter context beyond emphasizing that the repository must be public.
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 that the tool produces an SBOM inventory, OSV.dev dependency-vulnerability matches, and dependency-freshness signals for a public Git repository. This makes the resource and content unmistakable, though it does not explicitly distinguish this tool from the sibling risk-report variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context by positioning the tool as a one-shot alternative to a secret-scanning subscription, implying a single-use, public-repo scenario. However, it does not state when to choose this 'standard' report over the 'deep' or 'due_diligence' sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove duplicate lines while preserving original order.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It usefully reveals that original order is preserved, but it does not specify exact duplicate matching (e.g., whitespace/case sensitivity), blank-line handling, or whether the result is returned as new text.
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 communicates the full operation and a meaningful behavioral guarantee without any filler. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter utility with no output schema, the description is nearly sufficient: it tells the agent what happens and the ordering guarantee. It stops short of explicitly stating the return value and edge-case behavior, but those are reasonably inferable for this transformation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare text parameter. The word 'lines' gives the key semantic that text is treated as a line-oriented string, which the schema does not state, but details like line delimiters and formatting are not provided.
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 operation — removing duplicate lines — on a specific resource (text), and adds a clear ordering guarantee. This is easily distinguishable from the sibling tools, none of which appears focused on line deduplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a user needs duplicate lines removed while keeping order. It does not explicitly name alternatives or state when not to use it, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate character, word, line and byte statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It clearly implies a pure calculation with no side effects, but it does not disclose return format, encoding assumptions, or edge-case behavior. This is acceptable for a simple calculator but leaves 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, focused sentence with no filler. The core action and target resource are front-loaded and every word contributes to 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?
The tool is simple: one required string parameter and a straightforward calculation. The description covers what the tool does and identifies the input, but without an output schema it does not specify how results are returned. This is a minor gap for such a simple 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 0%, so the description must compensate. It clarifies that 'text' is the input to be analyzed for character, word, line, and byte statistics. However, it adds no details about expected encoding, empty strings, or constraints, so it only partially compensates.
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: 'Calculate character, word, line and byte statistics.' This clearly states what the tool does and is distinguishable from text-modifying siblings like post_text_dedupe_lines. It does not explicitly name a sibling or scope limitation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as post_text_dedupe_lines or other text utilities. The intended context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live, on-demand check of ONE x402-protected endpoint before you pay it: payment-requirements structure, TLS certificate, payTo on-chain balance, known-asset recognition, resource/host consistency, and discovery-manifest cross-check -- not a cached aggregate reputation score.
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | The full https:// URL of the x402-protected endpoint to evaluate. | |
| target_method | No | HTTP method to request target_url with. Defaults to GET; use POST for action-style endpoints that only 402-challenge on POST. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the check is live, on-demand, limited to one endpoint, and non-cached, and it lists the evaluated dimensions. However, it does not describe return format, error/timeout behavior for unreachable targets, authentication/rate limits, or whether the tool itself initiates any network request or payment.
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 focused sentence with the main action and timing front-loaded, followed by a compact list of check dimensions. Every phrase earns its place, and the negative 'not a cached aggregate reputation score' is an efficient scope marker.
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 a composite check with no output schema and no annotations, and the description does not specify what the returned report looks like or how failures are surfaced. The parameter and scope information is strong, but an agent still lacks expected return/error context for a fairly complex operation.
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 schema already documents target_url and target_method with defaults and intent; the description adds no new parameter-level detail. Baseline 3 is appropriate because no extra guidance is needed 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 names a concrete action ('Live, on-demand check'), a specific resource ('ONE x402-protected endpoint'), and enumerates six distinct checks it performs. It also distinguishes itself from 'a cached aggregate reputation score,' making its scope easy to separate from any sibling tool.
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 tells the agent when to call the tool ('before you pay it') and what it is not ('not a cached aggregate reputation score'), giving clear usage context. It does not name a sibling tool to use instead for cached reputation, so it stops short of a fully explicit alternatives recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
post_media_video_generate_longpost_media_video_generate_mediumpost_media_video_generate_shortget_dns_lookupget_domain_intelligenceget_jwt_decodeget_security_headersget_security_postureget_ssl_checkget_subnet_calculateget_timestamp_convertget_url_parseget_uuid_generateget_web_auditpost_base64_decodepost_base64_encodepost_data_transformpost_domain_due_diligencepost_freshdep_scanpost_hash_sha256post_hash_sha512post_json_minifypost_json_prettypost_json_repairpost_json_validatepost_media_image_convertpost_media_video_generate_longpost_media_video_generate_mediumpost_media_video_generate_shortpost_quebec_invoice_compliance_checkpost_quebec_invoice_generatepost_security_repo_risk_report_deeppost_security_repo_risk_report_due_diligencepost_security_repo_risk_report_standardpost_text_dedupe_linespost_text_statspost_x402_service_trust_reportx402-paid agent tools: 18 over HTTP, 14 over stdio. USDC per call, no API key.
x402 router-proxy + 79 keyless pay-per-call tools on Base. Pay once, we run the best tool.
29 pay-per-call DNS, SEO, SSL, security, and dev tools for AI agents. x402, no API key.
38 x402 pay-per-call tools for AI agents (USDC/USDT on Base): web, crypto, on-chain, geo, packages
Add one secure layer between your agents and this server.
