Micro-settled web content extraction and JSON schema validation utilities for AI agents and MCP clients, backed by the Bristlecone Logic API engine.
Scored across 6 tools
Each tool targets a completely distinct operation: DNS auditing, text chunking, expression evaluation, web extraction, JSON repair, and schema validation. Descriptions even include explicit 'Do not use for' boundaries that further sharpen the edges between them, so misselection is highly unlikely.
Every tool follows the same clear verb_noun snake_case convention (audit_dns, chunk_text, eval_expression, extract_web, repair_json, validate_schema). There is no deviation in style or casing across the set.
Six tools is a well-scoped size for a general-purpose logic/utility server, and each tool occupies a distinct niche with no redundant members. Nothing feels padded or sparse.
As a heterogeneous utility toolkit the surface covers the core agent needs it advertises (network verification, text prep, safe computation, web fetch, JSON repair, schema check) with no obvious dead ends within that scope. Some adjacent utilities (e.g. encoding, regex, date helpers) are absent, but the stated purposes are fully served.
Performs forward DNS resolution and network routing verification for a target domain. Resolves IPv4 and IPv6 addresses. Use to verify host reachability and guard autonomous agents against Server-Side Request Forgery (SSRF) before making HTTP requests. Do not use for WHOIS domain registration lookups or deep port scanning.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The fully qualified domain name (FQDN) or hostname to resolve (e.g. 'api.github.com' or 'openai.com'). Do not include http/https protocols or URL paths. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it resolves both IPv4 and IPv6, and it frames the tool as an SSRF guard, which tells the agent the return signal is meant to gate subsequent HTTP calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, mechanism/record types, then positive and negative usage guidance. It is front-loaded with the verb+resource and contains 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 single-parameter read-only tool with full schema coverage and annotations, the description is nearly complete. It covers purpose, safety framing, and exclusions. The only gap is that the SSRF-guard phrasing implies a return signal (e.g., resolved IPs vs. private ranges) without describing what the output contains, and there is no output schema to fill that 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 100% – the single 'domain' parameter is fully documented in the schema, including the FQDN format and the explicit warning not to include protocols or URL paths. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear compound verb phrase – 'forward DNS resolution and network routing verification' – naming the resource (a target domain) and even the record types (IPv4/IPv6). It distinguishes itself from siblings implicitly (none do DNS) and explicitly excludes WHOIS and port scanning, though it never names actual sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states an explicit positive trigger ('before making HTTP requests', 'verify host reachability') and an explicit negative exclusion ('Do not use for WHOIS domain registration lookups or deep port scanning'). The SSRF-guard framing gives the agent a concrete when-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Partitions raw text documents into uniform sliding-window segments with configurable character overlap. Returns an array of formatted text chunks. Use when preparing unstructured documents for vector database embeddings and RAG retrieval pipelines. Do not use for syntactic token counting or semantic sentence segmentation.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The source document text string to segment into discrete chunks. | |
| chunk_size | No | Maximum character length of each individual chunk segment. Defaults to 500 characters. | |
| chunk_overlap | No | Number of overlapping characters shared between consecutive chunks to maintain semantic context. Defaults to 50 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the sliding-window/overlap semantics and the return shape ('array of formatted text chunks'), which matters because no output schema exists. It does not mention edge cases such as behavior when text is shorter than chunk_size, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: capability, return value, then usage/anti-usage. It is front-loaded, free of filler, and every sentence contributes distinct 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?
With no output schema, the description usefully states that an array of formatted text chunks is returned, and annotations cover the read-only safety profile. The primary use case and exclusions are complete; only minor operational details (e.g., what 'formatted' means, empty/oversized input handling) are absent, which is acceptable for a three-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents text, chunk_size (default 500, min 50), and chunk_overlap (default 50, min 0) in detail. The description only echoes 'configurable character overlap' and adds no syntax, constraints, or interaction rules (e.g., overlap < chunk_size) beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Partitions raw text documents into uniform sliding-window segments') with the key mechanism (configurable character overlap) named up front. An agent can distinguish it from siblings like repair_json or validate_schema immediately, since none of them concern text segmentation.
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?
Gives an explicit positive trigger ('Use when preparing unstructured documents for vector database embeddings and RAG retrieval pipelines') and negative guidance ('Do not use for syntactic token counting or semantic sentence segmentation'). Both when-to-use and when-not-to-use are spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministically evaluates arithmetic, mathematical, and logical expressions inside an AST-isolated sandbox. Prevents LLM calculation errors while strictly blocking arbitrary code execution. Use for reliable numerical calculations and boolean logic. Do not use for executing arbitrary Python statements or importing external libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | A valid mathematical, arithmetic, or boolean expression string (e.g. '((150 * 12) / 4) + 18.5'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, but the description adds critical behavioral context: deterministic evaluation, AST-isolated sandboxing, and strict blocking of arbitrary code execution. This goes well beyond the safety hints and is essential for an agent to trust the 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?
Four tight sentences: the core operation is front-loaded, followed by the value proposition, usage guidance, and exclusions. No redundant or filler text.
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 low complexity and rich schema/annotations, the description covers purpose, usage, and constraints well. However, with no output schema, it does not mention what the tool returns (e.g., a numeric/boolean value or an error object), leaving a small gap for an agent invoking it.
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% and the single parameter is fully described with an example. The description does not add any syntax, format, or constraint details beyond what the schema already provides, so the baseline of 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?
States a specific verb (evaluates) and resource (arithmetic, mathematical, and logical expressions) with the scope of an AST-isolated sandbox. Clearly distinguishes itself from any code-execution tool by specifying what it does and does not support.
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?
Gives explicit when-to-use (reliable numerical calculations and boolean logic) and when-not-to-use (executing arbitrary Python statements or importing external libraries). Does not name an alternative tool, but none of the siblings provide comparable functionality, so the exclusion is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches and sanitizes readable text content from any public HTTP or HTTPS web page. Strips boilerplate HTML tags, navigation bars, and scripts. Returns clean body text and HTTP status code. Use when an agent needs primary webpage content for summarization or analysis. Do not use for authenticated pages or executing JavaScript.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The complete target website URL including http:// or https:// protocol prefix (e.g. 'https://docs.python.org/3/'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context about what gets stripped and what is returned, plus usage boundaries. However, it omits potential rate limits, timeouts, or error-handling details for non-HTML or failed requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and output, then adds usage conditions and exclusions. Every sentence contributes directly to correct invocation without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries return information (clean body text and HTTP status code) and operational boundaries. It provides enough context for an agent to call the tool correctly given its simplicity and annotation coverage.
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% and the single URL parameter is fully documented in the schema. The description does not add syntax or format details 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetches and sanitizes readable text content from public HTTP/HTTPS web pages. It clearly distinguishes the tool's output and scope, and no sibling tool performs the same 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?
It explicitly says when to use it (needs primary webpage content for summarization or analysis) and when not to use it (authenticated pages or JavaScript execution). This leaves no ambiguity for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministically parses and repairs malformed, truncated, or unclosed JSON strings produced by LLMs (e.g. missing closing brackets, unescaped quotes, trailing commas). Returns parsed valid JSON object. Use when an LLM produces syntax-broken JSON. Do not use on valid non-JSON prose or for modifying data values.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_json | Yes | The unparsed, malformed, or incomplete JSON text string requiring syntax repair into standard RFC 8259 format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: deterministic (not heuristic/best-effort) repair, the specific defect classes handled, and the explicit non-goal of altering data values.
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?
Four tight sentences with no filler; purpose and determinism are front-loaded, followed by return value, then usage and exclusions. Every sentence adds distinct 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?
For a single-parameter, side-effect-free tool with no output schema, the description covers purpose, input defect classes, return value, and boundaries. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes further by enumerating the kinds of malformation the single raw_json input may contain (missing closing brackets, unescaped quotes, trailing commas), giving the agent a concrete sense of what counts as repairable input.
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?
States a specific verb (parses/repairs) and resource (malformed, truncated, or unclosed JSON strings), with concrete examples of the failure modes it handles. The 'produced by LLMs' qualifier and the sibling landscape (e.g. validate_schema) make it clear this is repair, not validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('Use when an LLM produces syntax-broken JSON') and gives two exclusions (valid non-JSON prose, modifying data values). It stops short of naming a sibling alternative such as validate_schema for the already-valid case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministically validates that a target JSON payload contains all mandatory keys specified in a reference schema dictionary. Returns a boolean validation status and a list of missing keys. Use when verifying payload structure before downstream processing. Do not use for regex string validation or deep recursive type casting.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The target JSON data object to inspect and validate against the schema definition. | |
| schema_definition | Yes | A JSON object defining mandatory keys required in the target payload (e.g. {'user_id': '', 'status': ''}). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context: it is deterministic, checks only mandatory keys, and returns a boolean plus a list of missing keys. Minor gap: no statement about behavior with malformed input or deeply nested keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences: capability, return value, positive usage, negative usage. Front-loaded with the core action and 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?
No output schema exists, and the description compensates by naming the return values (boolean status and missing-key list). Combined with 100% schema coverage and annotation-supplied safety profile, an agent has everything needed to call this 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% and both parameters are already documented in the schema with examples, so the baseline is 3. The description restates the semantic relationship (target vs reference) but adds no syntax or format detail 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?
States a specific verb (validates) and resource (target JSON payload against a reference schema dictionary), plus the precise scope: mandatory keys only. The exclusions at the end differentiate it from a nearby capability like regex validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives both when to use ('before downstream processing') and when not to ('not for regex string validation or deep recursive type casting'), which directly resolves ambiguity against siblings such as extract_web or repair_json.
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.
audit_dns1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "domain": {
- "type": "string"
- },
- "ip_addresses": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "status": {
- "type": "string"
- }
- },
- "required": [
- "domain",
- "ip_addresses",
- "status"
- ],
- "type": "object"
-}New value: +nullchunk_text1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "chunks": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "total_chunks": {
- "type": "integer"
- }
- },
- "required": [
- "total_chunks",
- "chunks"
- ],
- "type": "object"
-}New value: +nulleval_expression1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "expression": {
- "type": "string"
- },
- "result": {
- "type": [
- "number",
- "boolean",
- "null"
- ]
- },
- "success": {
- "type": "boolean"
- }
- },
- "required": [
- "expression",
- "result",
- "success"
- ],
- "type": "object"
-}New value: +nullextract_web1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "content": {
- "type": "string"
- },
- "status_code": {
- "type": "integer"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url",
- "status_code",
- "content"
- ],
- "type": "object"
-}New value: +nullrepair_json1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "repaired_json": {
- "type": "object"
- },
- "status": {
- "type": "string"
- }
- },
- "required": [
- "status",
- "repaired_json"
- ],
- "type": "object"
-}New value: +nullvalidate_schema1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "missing_keys": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "valid": {
- "type": "boolean"
- }
- },
- "required": [
- "valid",
- "missing_keys"
- ],
- "type": "object"
-}New value: +nullaudit_dns1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "ip_addresses": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "ip_addresses",
+ "status"
+ ],
+ "type": "object"
+}chunk_text1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "chunks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total_chunks": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_chunks",
+ "chunks"
+ ],
+ "type": "object"
+}eval_expression1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "expression": {
+ "type": "string"
+ },
+ "result": {
+ "type": [
+ "number",
+ "boolean",
+ "null"
+ ]
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "expression",
+ "result",
+ "success"
+ ],
+ "type": "object"
+}extract_web1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "type": "string"
+ },
+ "status_code": {
+ "type": "integer"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "status_code",
+ "content"
+ ],
+ "type": "object"
+}repair_json1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "repaired_json": {
+ "type": "object"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "repaired_json"
+ ],
+ "type": "object"
+}validate_schema1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "missing_keys": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "valid": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "valid",
+ "missing_keys"
+ ],
+ "type": "object"
+}audit_dnschunk_textcode_sandbox_evaldns_security_auditeval_expressionextract_web3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / url / descriptionAdded value: +"The complete target website URL including http:// or https:// protocol prefix (e.g. 'https://docs.python.org/3/')."Input schema / properties / url / formatAdded value: +"uri"json_repairrepair_jsontext_chunkervalidate_schema3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / data / descriptionAdded value: +"The target JSON data object to inspect and validate against the schema definition."Input schema / properties / schema_definition / descriptionAdded value: +"A JSON object defining mandatory keys required in the target payload (e.g. {'user_id': '', 'status': ''})."code_sandbox_evaldns_security_auditextract_webjson_repairtext_chunkervalidate_schema
