hemmiles-mcp-server

List Hemmiles pages

hemmiles_list_pages

Read-onlyIdempotent

List public Hemmiles.com pages by section to find marketing, product, and documentation URLs from the site sitemap. Filter by section or locale.

Instructions

List the public pages of hemmiles.com, grouped by section, as discovered from the site's sitemap.

Hemmiles is field-visit / field-sales SaaS (not an online store), so this returns marketing and documentation pages — the closest equivalent to "categories". Sections include: home, product, pricing, features, teams, integrations, security, resources, docs, help, guides, blog, company.

Args:

section (string, optional): restrict to one section (e.g. 'features').
locale ('global'|'in'|'us'|'gb'|'ca'|'au'|'nz'|'ie'|'sg'|'ae'|'za', optional): which market's URLs to return; defaults to the server's locale.
response_format ('markdown'|'json'): output format (default markdown).

Returns JSON: { total, count, sections: string[], pages: [{ url, path, section, locale }] }.

Examples:

"What pages does Hemmiles have?" -> no args.
"List the feature pages" -> section='features'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`locale`	No	Market locale/region. One of: global, in, us, gb, ca, au, nz, ie, sg, ae, za. 'global' uses the locale-less canonical pages. Defaults to the server's configured locale.
`section`	No	Filter to one section, e.g. 'features', 'teams', 'guides', 'blog', 'pricing'.
`response_format`	No	Output format: 'markdown' (human-readable) or 'json' (structured).	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`pages`	Yes
`total`	Yes
`sections`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish that this is a safe, idempotent, open-world read, so the description doesn't need to repeat that. It does add real context beyond the annotations: the data source is the sitemap, results are marketing/docs pages rather than commerce categories, and locale defaults to the server's configured market.

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 with the core purpose, then args, return shape, and examples in a scannable order with no filler. It is slightly longer than strictly necessary given the schema already documents all three params, but every line carries 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?

The tool is simple (3 optional params, 0 required), annotations cover the safety profile, and an output schema exists, so the return-shape sentence is a bonus rather than a necessity. The one gap is that the overlap with hemmiles_list_features and hemmiles_get_page is not resolved for the agent.

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?

With 100% schema description coverage the baseline is 3, but the description adds value beyond the schema by giving example section values, explaining that 'global' corresponds to locale-less canonical pages, and showing intent-to-argument mappings in the examples.

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 (list public pages of hemmiles.com, grouped by section, sourced from the sitemap) and enumerates the sections returned. It also pre-empts a likely confusion by explaining that Hemmiles is field-sales SaaS, not a store, so pages are the closest thing to 'categories'.

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 examples map natural user intents to concrete argument choices ('What pages does Hemmiles have?' -> no args; 'List the feature pages' -> section='features'), which is strong guidance. However, it never mentions when to prefer siblings such as hemmiles_list_features (which overlaps with section='features'), hemmiles_get_page, or hemmiles_search_site.

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

Deploy Server