tls_header_report
TLS and security-header report from a supplied HTTPS probe. Costs $0.15 Base USDC.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes |
DeltaBot Utility Suite
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It adds the cost detail ('Costs $0.15 Base USDC') but does not clarify whether the tool performs a live network probe, consumes an existing probe payload, what the response looks like, or whether any side effects occur. The input semantics are also ambiguous.
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 short sentences with no filler: the first front-loads the tool's purpose, the second conveys the price. Every word contributes useful signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description omits critical execution details: how to structure the probe input, what fields the probe must contain, what the report should include, and what the return format is. The tool is simple in parameter count but still under-specified for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single nested 'input' object with no documented properties and zero schema description coverage. The description only says a 'supplied HTTPS probe' is needed, but an agent cannot determine required fields, format, or how to structure the probe input.
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 states a specific deliverable ('TLS and security-header report') and the input context ('from a supplied HTTPS probe'), which clearly differentiates it from sibling report tools like website_health or seo_meta_audit. Despite lacking an explicit verb, 'report' conveys the expected action unambiguously.
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 'from a supplied HTTPS probe' implies when to use it: when an HTTPS probe is available and a TLS/security-header assessment is needed. However, it names no alternatives, exclusions, or conditions for choosing this tool over related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
C2.5/5.0
Disambiguation3/5
Most tools are distinguishable by their input source (HTTPS probe, JSON snapshots, OpenAPI, ABI, CSV, etc.), but several report-style tools overlap in purpose, such as changelog_generator vs. release_dependency_risk and csv_profile vs. data_quality_profile. Descriptions help, but an agent could easily hesitate between similarly named change/health/report tools.
Naming Consistency4/5
All names are lowercase snake_case and generally follow a <domain>_<artifact> pattern, which is predictable and readable. The suffixes vary considerably -- report, summary, digest, audit, health, profile, generator, validator, risk, radar -- so it is not a strict verb_noun convention, but the style is consistent enough.
Tool Count3/5
25 tools is at the upper edge of the borderline-heavy range. The suite spans web, data, repository, security, and wallet domains, so each tool has a plausible place, but the sheer number makes navigation heavier than a typical cohesive toolset.
Completeness3/5
The suite provides broad coverage for reporting, validation, and change detection, but there are notable gaps such as generic raw data fetching, a generic diff utility, and obvious transforms beyond CSV-to-JSON. For a broadly scoped utility suite, coverage is partial but not severely incomplete.