Server Quality Checklist

Tool Scores

• identify_hashA
  3.6/5.0
  Behavior3/5

  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 does communicate that identification is based on 'shape' and that the output includes implications for cracking or reuse. However, it does not disclose how unknown/unrecognized hashes are handled, what exact output format is returned, or that the analysis is heuristic, which leaves meaningful gaps.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It immediately states the action and resource, then efficiently enumerates the supported hash categories and the practical value of the output. Every clause earns its place.

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

  Completeness4/5

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

  For a one-parameter, low-complexity identification tool, the description covers what it accepts, what it does, and what the result means operationally. It does not describe the precise response structure, but since there is no output schema and the tool's function is simple, the gaps are minor.

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

  Parameters3/5

  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 single 'hash' parameter. It partially does so by indicating that the input is a hash string and listing recognized hash families. It does not specify accepted string encodings, prefixes, or edge-case formats, but the single self-descriptive parameter limits the damage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Identify'), a concrete resource ('a hash'), and enumerates the recognized hash families (bcrypt, Argon2, yescrypt, Unix crypt, LM:NT, MD5/NTLM, SHA variants). It clearly distinguishes this from sibling tools like decode_jwt or extract_iocs by making the target resource and action explicit, though it does not name a sibling alternative directly.

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

  Usage Guidelines3/5

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

  The intended usage is implied: when an agent encounters a hash and needs to identify its type or understand cracking/reuse implications, this tool is relevant. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites, and no comparison to sibling tools that might also handle hash-like data.

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

• latest_field_noteA
  3.8/5.0
  Behavior3/5

  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 disclose that the tool reads a public RSS feed, implying a read-only external fetch. However, it does not mention output format, default behavior beyond the schema, network dependencies, or 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose, follows with the value proposition, and closes with the data source. There is no filler or redundant information.

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

  Completeness4/5

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

  For a simple tool with one optional parameter and no output schema, the description conveys the essential purpose, the source (public RSS feed), and the content of the returned episodes. It could be more explicit about the exact return structure, but it is sufficient for correct selection and invocation.

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

  Parameters3/5

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

  The schema already provides complete documentation for the single optional 'count' parameter, including its default value of 3. The description adds no additional parameter-level meaning, which aligns with the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: retrieving the most recent This Week in Security episodes and summarizing what was exploited, patched, and what it means. It names a specific resource and a clear action, though it does not explicitly contrast itself with sibling tools.

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

  Usage Guidelines4/5

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

  The description establishes a clear use context: when an agent needs recent security episode content about exploits, patches, and implications for defended systems. It does not explicitly list exclusions or alternatives, but the intended use is reasonably evident.

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

• convert_timestampA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses key behavior: epoch units are detected by digit count, 'now' is accepted, and output includes UTC, weekday, and relative time, which goes beyond a generic 'convert timestamp' claim. However, it does not mention handling of malformed input, timezone interpretation of the source timestamp, or the exact response shape/error behavior.

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

  Conciseness5/5

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

  A single, dense sentence front-loads the action and then lists supported formats in a clear, scannable series. No words are wasted and every clause adds useful information.

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

  Completeness3/5

  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 the description covers accepted inputs and output content, so it is largely usable. The lack of an output schema means the description should ideally state the returned structure (e.g., JSON/text) and failure behavior; these are absent, leaving a small but real completeness gap.

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

  Parameters4/5

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

  The schema only defines 'value' as a string with no description, and coverage is 0%, so this description is the only documentation for the parameter. It compensates well by enumerating accepted input families (Unix epoch in s/ms/µs, FILETIME, ISO 8601, RFC 2822, 'now') and even explains detection logic. It could be slightly more precise about exact string formatting, but the added meaning is strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action ('Turn any timestamp') and names the exact resource and outputs (Unix epoch, FILETIME, ISO 8601, RFC 2822, 'now'), which clearly separates it from the forensic siblings like identify_hash or decode_jwt. It is immediately obvious 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.

  Usage Guidelines3/5

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

  The phrase 'an investigation needs' implies a digital-forensics context and positions the tool for timestamp-format conversion, but it never states when to choose it over an alternative or mentions any exclusions. There are no sibling timestamp tools, so the guidance is implied rather than explicit.

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

• cvss_scoreA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full disclosure burden. It does transparently state the algorithm guarantee and the exact outputs: base score, severity band, normalized vector, and impact/exploitability sub-scores. However, it does not disclose behavior for invalid vectors, conflicting vector+metrics input, or edge cases in normalization, which leaves some uncertainty.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The purpose and algorithm fidelity are front-loaded, and the input options plus return values are compressed into a single clear clause. Every sentence earns its place.

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

  Completeness4/5

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

  For a stateless computation tool with no output schema, the description is quite complete: it names both accepted input forms, gives a concrete vector example, and enumerates all important outputs. It is missing only minor edge-case guidance such as error handling and whether the two parameters are mutually exclusive, which are not critical for this type of tool.

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

  Parameters3/5

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

  The input schema already documents both parameters fully with 100% description coverage. The tool description reinforces the vector-or-metrics alternative and gives an example vector, but it adds little semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: 'Score a vulnerability with CVSS v3.1.' Adding 'exactly as the FIRST specification computes it' pins down the algorithm variant and distinguishes it from any other CVSS implementation. It also states the accepted input forms and the return values, making the purpose fully concrete.

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

  Usage Guidelines4/5

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

  The description clearly says to pass either a vector string or the eight base metrics, giving immediate operational guidance. It does not list exclusions or alternative tools, but none of the sibling tools overlaps with vulnerability scoring, so the usage context is sufficient without an explicit when-not-to-use clause.

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

• extract_iocsA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses meaningful behaviors: defanged input is refanged first, filenames are not mistaken for domains, and output is sectioned/defanged. This exceeds a minimal 'extracts IOCs' statement. Missing details like output structure or size limits, but the core behavioral traits are transparent.

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

  Conciseness5/5

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

  Three sentences with no filler. The main purpose is front-loaded, the UIOC types are enumerated compactly, and the edge case about filenames is a useful one-liner. Every sentence adds value.

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

  Completeness4/5

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

  For a simple 2-parameter tool with no output schema, the description explains input types, output sections, defanging/refanging behavior, and an edge case. It does not specify the exact return structure or field names, which would help an agent parse results, but the lack of an output schema lowers that burden slightly. Overall, it is nearly complete for its complexity.

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

  Parameters3/5

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

  Schema description coverage is 50%: 'defanged' is described, 'text' is not. The description compensates for the 'text' parameter by specifying valid inputs (reports, alerts, email) and mentions defanging behavior, but it never explicitly names the 'defanged' parameter or its default. It adds some semantic value beyond the schema but does not fully bridge the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Pull every indicator out of a blob of text') and resource, enumerates supported IOCs, and states the output treatment (sectioned and defanged). It clearly differentiates from sibling tools like defang_text by adding extraction + refanging behavior. 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.

  Usage Guidelines3/5

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

  It implies the use case ('a report, an alert, a mail — and return them sectioned and defanged, ready for a ticket') and that defanged input is handled. However, it never explicitly contrasts alternatives like defang_text or identify_hash, so an agent might not know when to choose this tool over a sibling. Usage context is present but exclusions are absent.

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

• decode_layersA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It effectively discloses that the tool chains operations, shows every intermediate result, defaults to a single base64_decode, and stops at the first failure while identifying the failing step. This is strong context, though it does not cover output format or edge cases like empty input.

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

  Conciseness5/5

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

  The description is two tight sentences that front-load the core concept and then add behavior details. Every clause adds value: operation list, intermediate result visibility, default chain, and failure behavior. There is no filler or repetition of schema content.

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

  Completeness4/5

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

  For a two-parameter tool with no output schema and no annotations, the description is nearly complete: it explains the operation chain, the default, and the failure mode. It does not specify the exact shape of the output or the format of failure messages, and an example would improve usability, but an agent already has enough context to invoke it correctly.

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

  Parameters3/5

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

  Schema coverage is 50%: the ops parameter is described in the schema, but input is not. The description adds useful meaning for ops by stating the default chain and failure behavior, but it only loosely refers to input as 'a layered payload' and provides no additional format, constraints, or examples for that parameter. It partially compensates but does not fully close the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pair ('Peel a layered payload') and names the exact operation set, making the tool's scope concrete. It implicitly distinguishes itself from siblings like decode_jwt by focusing on layered payloads and listing eight specific encoding/decoding operations rather than token-specific decoding.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: use this when you need to peel a layered payload and inspect intermediate results. It also explains the default behavior when no ops are supplied. It does not explicitly mention when not to use it or name alternative tools, so it misses the top score.

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

• defang_textA
  4.2/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full burden — and it delivers: it discloses bidirectional behavior ('and back'), the specific transformations applied, and the purpose context. It does not specify how unrecognized or non-indicator text is treated, but for a deterministic local transformation tool this is a minor gap.

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

  Conciseness5/5

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

  Two sentences with zero waste: the first defines the action with illustrative examples, the second gives the usage context. Every clause earns its place, and the core action is front-loaded before the usage note.

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

  Completeness4/5

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

  For a simple 2-parameter, no-output-schema transformation tool, the description covers what it does, how (via examples), and when to use it. The return value (transformed text) is implied but not stated, and edge-case handling is unspecified — acceptable gaps given the tool's simplicity, though a sentence on output would push this to a 5.

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

  Parameters3/5

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

  With 50% schema coverage, the text parameter is undocumented in the schema, and the description only partially compensates by implying text holds the indicators to transform. The mode parameter's meaning ('defang' default or 'refang') already lives in the schema, so the description adds transformation semantics but does not fully document both parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific action ('Defang or refang') on a specific resource ('indicators in text'), then grounds it with concrete transformation examples (http→hxxp[://], dots→[.], @→[at]). This clearly distinguishes it from its analysis-oriented siblings (identify_hash, cvss_score, lookup_kev), which all inspect rather than transform text.

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

  Usage Guidelines4/5

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

  'Use before pasting live URLs into anything that auto-links' provides a concrete, contextual trigger for when to invoke the tool. It does not explicitly name alternatives or state when not to use it, but no sibling performs text transformation, so the usage niche is already unambiguous.

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

• lookup_kevA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It does well by revealing that this is the only tool that touches the network and that the catalog is cached for an hour, which are meaningful behavioral traits. It could add more about failure modes or rate-limit behavior, but what is disclosed is genuine and useful.

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

  Conciseness5/5

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

  The description is tightly written with no wasted sentences. It front-loads the core purpose as a question, follows with concrete output details, and ends with a high-value network/caching caveat. Every sentence earns its place.

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

  Completeness4/5

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

  For a single-parameter lookup tool with no output schema, the description is nearly complete: it explains what the tool checks, what data it returns, what input it accepts, and a caching/network caveat. It does not explicitly describe the behavior for non-exploited or unknown CVEs, but the core decision an agent needs to make is well supported.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description's statement 'Accepts any text containing CVE ids' largely mirrors the schema's parameter description, adding no substantially new semantic information. It is adequate but not additive.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a direct, operational question—'Is this CVE exploited in the wild?'—and then names the exact resource being queried: CISA's Known Exploited Vulnerabilities catalog. It enumerates the specific fields returned (date added, federal due date, ransomware usage, required action), making the tool's purpose and scope unmistakable and distinct from siblings.

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

  Usage Guidelines4/5

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

  The description clearly tells the agent when to use the tool: whenever CVE exploit status in the wild is needed. It also provides practical input guidance ('Accepts any text containing CVE ids') and a key environmental note that it is the only network-touching tool. It stops short of explicitly naming alternative tools or exclusion conditions, but the context is strong.

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

• analyze_email_headersA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden and does so well: it enumerates the analysis outputs, ordering of the Received chain, per-hop delays, and specific anomaly checks. It does not mention return format or error behavior, but the disclosed output contract is unusually rich.

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

  Conciseness5/5

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

  One dense, front-loaded sentence delivers the purpose first and then a structured list of concrete outputs. Every clause adds useful information, with no filler or repetition.

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

  Completeness5/5

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

  Despite having no output schema, the description effectively serves as the return contract by detailing exactly what analysis results and flagged anomalies will be produced. Combined with a single fully documented parameter, an agent has enough information to invoke and interpret the tool correctly.

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

  Parameters3/5

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

  The only parameter, headers, already has a 100% descriptive schema ('The raw message source, or at least the header block'). The tool description reaffirms that same concept without adding new parameter-level details, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies a specific resource (raw email headers) and a precise task (phishing triage), then enumerates concrete outputs such as the Received chain, originating IP, and authentication verdicts. This clearly distinguishes the tool from its unrelated siblings.

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

  Usage Guidelines4/5

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

  The context is explicit: this is for phishing triage on raw email headers. It does not explicitly state when not to use it or name alternatives, but the sibling tools are unrelated enough that the intended use case is clear.

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

• decode_jwtA
  4.3/5.0
  Behavior4/5

  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 explicitly states that JWT signatures are not verified and describes the useful behaviors: converting iat/nbf/exp to dates and flagging alg:none, missing alg, expiry, non-expiring tokens, and long-lived tokens. It does not define thresholds like 'long-lived' or describe malformed-token handling, but the disclosure is still substantial.

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

  Conciseness5/5

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

  The entire behavior is captured in one efficient, front-loaded sentence. It starts with the core action, then lists all significant outputs and checks without redundant phrasing. The parenthetical 'it says so' is slightly informal but does not waste meaningful space.

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

  Completeness5/5

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

  For a single-parameter read-only decode tool with no output schema, the description is complete enough for an agent to invoke it correctly and anticipate the main results. It covers what is decoded, the timestamp formatting, and the security-related flags. Missing details like exact output formatting are not necessary for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100% and there is only one parameter, so the schema already fully documents the token parameter, including the optional 'Bearer ' prefix. The description's value is mostly about output behavior rather than adding parameter-level meaning, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: 'Decode a JWT's header and payload'. It also enumerates what the tool reports (date conversion, security flags), making it clearly distinguishable from siblings like decode_layers, convert_timestamp, and identify_hash without needing to open the schema.

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

  Usage Guidelines4/5

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

  The parenthetical 'no verification' clearly tells agents this is not the tool for signature validation, and the decode/flag behavior makes the intended use obvious. It does not explicitly name an alternative tool or provide formal when-not conditions, so it falls just short of a 5.

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