Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add hostinger/api-mcp-server --skill 06-frontendgit clone --depth 1 https://github.com/hostinger/api-mcp-serverWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/hostinger/api-mcp-server/06-frontend)<a href="https://agentmods.dev/skills/hostinger/api-mcp-server/06-frontend"><img src="https://agentmods.dev/badge/skills/hostinger/api-mcp-server/06-frontend/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/hostinger/api-mcp-server/06-frontend"><img src="https://agentmods.dev/badge/skills/hostinger/api-mcp-server/06-frontend.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00078 | $0.03581 |
| Opus 5.5 | $0.00031 | $0.01432 |
| Sonnet 5.5 | $0.00016 | $0.00716 |
| Haiku 4.5 | $0.00008 | $0.00358 |
Grade A, and why
headless-step-frontend scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 182 lines — stays where its author put it; the contents beside it link to each section on GitHub.
headless-step-frontend
Build the site's frontend against the backend from site.json, implementing the look the design step
already chose and wrote to design.md (plus the logo in brand/). The design is decided; this step
is where it becomes real code. There's no per-framework recipe — use good judgement, follow design.md
as the contract, and ask only for the clarifications you genuinely need. Out: source in the site
workspace ~/.hostinger/<domain>/src/.
⚠️ Build mode: "Bring your own frontend"? Read this first (any backend)
Read
brief.md→ Build mode. When it is Bring your own frontend, the user already has a frontend (the project in the folder the command was run in) and this step wires it to the backend fromsite.json— it does not scaffold a new project and there is usually nodesign.mdto implement (the design step deferred to the user). Use their project as the source: copy or point~/.hostinger/<domain>/src/at it, keep its framework and UI, and collaborate on changes at the user's direction (vibe-code with them). Your job is to connect it to the live backend (WordPresswp/v2reads, the WooCommerce/Ecommerce Store API, env/keys) and make it deployable (setengines.nodeto22, remove any.htaccess), then hand off to deploy. This generalises the Webapp "existing app" case below to WordPress and Ecommerce too. When Build mode is "Agent designs and builds", ignore this box and proceed normally (scaffold + implementdesign.md).
⚠️ Webapp backend? Read this first
A
webappbrief has no CMS/store and nocontent-model.md— the app owns its own data (its own API, or the MySQL database recorded insite.json → database). It comes in two shapes, decided back in refine:
- An existing app the user brought to deploy (refine routes "deploy my app" here). Use their project as the source — copy/point
~/.hostinger/<domain>/src/at it and keep its own framework and UI. Do not scaffold a new project, and do not re-implementdesign.mdover it (so the design step does not apply to an app that brings its own UI). Your job is only to make it deployable: setengines.nodeto22, remove any.htaccess, wire its data/env, then hand off to deploy. Skip the Step 2 design pass, and ignore thecontent-model.mdrequirement in Step 3.- A new app built from the brief. Scaffold and build it from
brief.md(anddesign.mdif the design step produced one — design does run for a from-scratch app). Its data is owned by the app, so there is still nocontent-model.mdto bind against.Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in Step 3 are WordPress / WooCommerce / Ecommerce only — for a webapp follow the Webapp bullet there.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today Changed · +6 lines 78a73a17fcff
- 5d ago Changed · +15 lines 2783b21dd7cd
- 7d ago First seen · 161 lines · 78 tokens per session scan A 11a1ba8bd995
headless-step-frontend is a skill published in the GitHub repository hostinger/api-mcp-server (164 stars, last pushed yesterday), licensed MIT. It adds 78 tokens to every session and 3,581 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-20.
Other skills, from other repositories
Contract Testing with Pact
Consumer-driven contract testing skill using Pact, covering consumer tests, provider verification, Pact Broker integration, and CI/CD workflows.
API Fuzzing
API endpoint fuzzing for discovering unexpected behaviors, crashes, and security vulnerabilities through malformed requests, boundary values, and protocol violations.
API Rate Limiting Testing
Testing API rate limiting implementations including throttling behavior, burst handling, rate limit headers, and distributed rate limiting patterns.
API Versioning Testing
Testing API versioning strategies including URL path, header, and query parameter versioning with backward compatibility validation.
Contract-First Testing
Contract-first testing approach using Pact, Spring Cloud Contract, or Dredd for ensuring API consumer-provider compatibility.
smarterweather-api
Build integrations against the Smarter Weather developer platform — the REST API at api.smarterweather.com. Covers authentication via API key, calling /v1/weather and the other routes in the OpenAPI contract, handling the RFC 9457 error envelope, respecting RateLimit- headers, retrying safely, and choosing between…