hemmiles-mcp-server

Get a Hemmiles page

hemmiles_get_page

Read-onlyIdempotent

Fetch any hemmiles.com page and return its normalized title, headings, breadcrumbs, links, JSON-LD types, and body text to read full page details.

Instructions

Fetch a single hemmiles.com page and return its normalized content: title, description, headings, breadcrumbs, in-page links, the detected JSON-LD schema types, and the main body text.

This is the detail view — the brief's "get_product_details" — adapted to a SaaS marketing site. For pricing use hemmiles_get_pricing; for FAQs use hemmiles_get_faqs.

Args:

path (string): page path (e.g. 'features/route-planning', 'product') OR a full https://hemmiles.com URL.
locale (optional): market prefix for a bare path (default: server locale). Ignored for full URLs.
response_format ('markdown'|'json').

Returns JSON: { url, path, locale, title, description, headings:[{level,text}], breadcrumbs:[], jsonldTypes:[], links:[{text,href}], text }.

Error handling:

NOT_FOUND if the page does not exist — use hemmiles_list_pages / hemmiles_search_site to find valid paths.
DISALLOWED_PATH for robots-blocked paths such as /api/...

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes	Page path (e.g. 'pricing', 'features/gps-check-in') or a full https://hemmiles.com/... URL.
`locale`	No	Market locale to prefix onto a bare path. Ignored if a full URL is given.
`response_format`	No	Output format: 'markdown' (human-readable) or 'json' (structured).	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`path`	Yes
`text`	No
`links`	No
`title`	No
`locale`	Yes
`headings`	No
`breadcrumbs`	No
`description`	No
`jsonldTypes`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes beyond the annotations (which already declare readOnly/idempotent/non-destructive/open-world) by documenting the error taxonomy — NOT_FOUND and DISALLOWED_PATH for robots-blocked routes like /api/ — plus the rule that locale is ignored when a full URL is passed. Minor flaw: it says 'Returns JSON' while response_format permits 'markdown', leaving the actual return shape slightly ambiguous.

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?

Front-loaded summary, then a correctly separated Args block and error-handling block — easy to scan. It loses a point for restating parameter meanings already present in the schema, which is the only real redundancy.

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?

Covers the full burden for this tool: what is fetched, how paths resolve, output shape, and failure modes with recovery paths. Since an output schema exists and 100% of parameters are schema-documented, nothing an agent needs in order to call this correctly is missing.

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 the descriptions already state the path-or-URL behavior, the locale-ignored-for-full-URLs rule, and the response_format enum. The Args block largely restates those facts, so the description adds little semantic value beyond the schema; baseline 3 applies.

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?

States a specific verb and resource ('Fetch a single hemmiles.com page') and immediately enumerates what comes back: title, description, headings, breadcrumbs, links, JSON-LD types, body text. It also positions itself against siblings by naming the pricing and FAQ equivalents, so an agent can distinguish it without opening another schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: pricing goes to hemmiles_get_pricing, FAQs to hemmiles_get_faqs, and NOT_FOUND conditions point to hemmiles_list_pages / hemmiles_search_site for discovering valid paths. Both the when-to-use and the recovery alternatives are stated rather than implied.

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

Deploy Server