Diogenes Microservice Gateway

Deterministic Edge DOM CSS Selector Scraper & Isolator

isolate_css_selectors

Read-onlyIdempotent

Extract targeted text, HTML, or attributes from HTML DOM trees by evaluating CSS selector queries, enabling precise parsing of elements like pricing badges, titles, and review cards.

Instructions

Evaluates CSS selector queries against HTML DOM trees to extract targeted inner text, outer HTML, or element attributes. Use when targeting specific elements like pricing badges, product titles, review cards, or navigation breadcrumbs; for parsing unstructured contact information, use extract_contact_info instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'html_content' and 'selector_query' ('extraction_mode' defaults to 'inner_text'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.

Input Schema

Name	Required	Description
`html_content`	Yes	HTML source markup to query against using CSS selector matching rules.
`selector_query`	Yes	CSS selector query expression (e.g., '.pricing-card', '#main h2', 'article p').
`extraction_mode`	No	DOM extraction representation: text content, outer HTML snippet, or attribute key-value map.

Output Schema

Name	Required	Description
`elements`	Yes	Extracted textual or markup contents of matched DOM elements.
`matched_count`	Yes	Number of DOM nodes matching the provided CSS selector query.
`selector_used`	Yes	Normalized CSS selector executed during edge DOM traversal.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.6.0Oct 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new operational context: statelessness, the 32 KB input ceiling, 60 RPM rate limit, the ?demo=true bypass or L402 pricing at 10 sats, and the HTTP 400 failure mode. That is exactly the kind of behavioral detail structured fields do not carry.

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

Conciseness4/5

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

Two sentences that front-load the purpose then pack constraints into a compact clause list. The second sentence is dense and semi-colon heavy, but nearly every fragment (limits, auth, error) carries decision-relevant information.

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?

With an output schema present, return values need no explanation; the description still covers input limits, rate limits, payment/auth paths, and error behavior, which is everything an agent needs to invoke it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds the non-obvious fact that extraction_mode defaults to inner_text, which the schema does not state. Required inputs are also named, giving more than the schema alone.

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?

Opens with a specific verb+resource ('Evaluates CSS selector queries against HTML DOM trees') and enumerates the three output representations. It distinguishes itself from the closest sibling by naming extract_contact_info as the tool for unstructured contact parsing.

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?

Gives concrete positive triggers ('pricing badges, product titles, review cards, navigation breadcrumbs') and one explicit exclusion routing to extract_contact_info. It does not mention adjacent siblings like parse_html_tables or extract_page_hyperlinks, but the core when-to-use guidance is clear.

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

Deploy Server