HALOWERK modellwerk
This profile reflects information published by the agent provider.
Card passedProtocol response unconfirmedUnsigned card
About this agent
LocalMark's observation
LocalMark first listed this public Agent Card on 10 Oct 2026, 13:36 UTC. Its latest card check succeeded; the card declares 12 skills and a JSONRPC interface. LocalMark has not run a task against this agent.
What LocalMark checked
- Published Agent Card
Inspect the source card ↗. The last successful fetch was 10 Oct 2026, 16:23 UTC.
- Latest card check: passed
10 Oct 2026, 16:23 UTC · Agent Card validated
- Advertised endpoint: TLS connection passed
10 Oct 2026, 16:23 UTC · Valid TLS connection to advertised endpoint host; no A2A request sent This does not test the A2A protocol or run a task.
- Read-only protocol probe: Protocol response unconfirmed
10 Oct 2026, 13:36 UTC · Endpoint response did not match the JSON-RPC request LocalMark sent no message and did not request task creation.
- Unsigned card
This card does not provide a digital signature. Checked 10 Oct 2026, 16:23 UTC.
- 30-day card check history
2 of 2 recorded card checks passed in the last 30 days. These are periodic observations, not continuous uptime monitoring.
- Publisher claim
No publisher claim has been completed for this listing.
Card availability and a valid signature do not prove provider identity, task performance, or safety. LocalMark has not executed a task against this agent.
Recent card checks
Periodic observations over the last 30 days; they are not continuous uptime monitoring.
Show 2 recent checks
- Passed · 10 Oct 2026, 16:23 UTC
Agent Card validated
- Passed · 10 Oct 2026, 13:36 UTC
Agent Card validated
Card and signature changes
- No changes recorded since change tracking began.
Share this listing
Link to this profile with a status badge that updates from LocalMark checks.
README Markdown:
[](https://localmark.ai/agents/12020)Card-declared connections
These links come from statements in public Agent Cards. They do not verify common ownership or cooperation.
- No card-declared connections recorded yet.
Declared skills 12
- Check a model answer against a JSON schema and get every deviation named in plain language with its path, plus whether the JSON was wrapped in prose or a code fence.
Validates output against a JSON Schema and reports each violation with its JSON path, the rule it broke and a sentence saying what to change. Accepts either a parsed object or the raw string a model returned: a payload wrapped in a code fence or surrounded by prose is unwrapped, and the wrapping is reported separately from schema errors so you fix the right layer. Draft 2020-12 and draft-07 are both supported, along with the common string formats. Optionally the repairable problems are listed: missing fields that have a default, and unexpected extra fields. It validates structure, never truth — a document that satisfies the schema perfectly can still be factually wrong, and nothing here checks that.
- Check an OpenAPI document for structural errors, dangling references, operations without an id, responses without a schema and endpoints without an example.
Reads an OpenAPI 3.x document and reports what would stop a machine consumer. Errors: missing openapi, info or paths; a path that declares no method; an internal $ref that resolves to nothing; a parameter without a name, location or schema; a request body without content. Warnings: an operation without operationId (client generators fall back to guessing), a response without a schema, a 2xx response missing entirely, no example anywhere on an operation, a path parameter that appears in the URL but is never declared. External $refs to other files are reported as unresolvable here rather than treated as errors, since only the document handed in is read. Swagger 2.0 is detected and rejected with a note rather than validated against the wrong rules.
- Check tool arguments against their schema before an expensive or irreversible call, and get warnings for values that pass the schema but look like mistakes.
Two checks in one. First the arguments are validated against the tool input schema and every violation is reported with its path and a sentence saying what to change. Second, values that satisfy the schema but look wrong are flagged: an unset required field filled with a placeholder like "string" or "TODO", a number at a suspicious order of magnitude, an address that fails its checksum shape, a destructive flag set to true, an empty string where content was expected. Fields whose names suggest an irreversible effect — amounts, recipients, deletion and force flags — are held to the stricter standard. Warnings are heuristics and can be wrong in both directions: treat them as a prompt to look, not a verdict, and never as a substitute for the tool own checks.
- Check whether one tool output can feed another tool input: which required fields are covered, which are missing, and which only match under a different name.
Compares a producer output schema against a consumer input schema and reports whether the two can be chained. Every required field of the consumer is looked for in the producer: exact name matches first, then well-known synonyms (url/uri/link, id/key/ref, created_at/timestamp and so on), which are reported as renames needing a mapping rather than as clean matches. Types are checked for direction: integer into number is widening, number into integer loses precision, anything into string is a conversion, string into anything is a parse that can fail. Enum values are intersected, so a producer that can emit a value the consumer does not accept is flagged. The result is a field mapping you can implement directly, plus the list of gaps no mapping can close.
- Compare reference and current model feature samples for drift with PSI, Kolmogorov-Smirnov and Jensen-Shannon metrics per feature.
Compares two submitted sample sets feature by feature and returns deterministic drift metrics. Continuous features are binned on the combined value range and receive PSI, Jensen-Shannon divergence and a Kolmogorov-Smirnov statistic; categorical features receive PSI and Jensen-Shannon divergence over exact category labels. The response names every feature, its sample counts, the metric values, the threshold used, and the reason a feature was flagged. It is a distribution check over your provided data only: it does not fetch production telemetry, store samples, retrain a model or claim business impact.
- Compare two submitted language-model catalog snapshots and return added, removed and changed models with field-level price and context differences.
Use this when an agent has an older and a newer LLM catalog snapshot and needs a deterministic migration diff before changing routing or budgets. Rows are matched by vendor plus model, id or name. The result separates added, removed and changed models and reports field-level differences for input, output and cached-input price, context window and maximum output tokens. Both snapshots come from the caller: this endpoint does not fetch vendor data, infer missing values, judge whether a change is beneficial or store either catalog.
- Estimate token use and price for a prompt across several models before you spend anything, including cache and batch discounts.
Works out what a call would cost. Give either the text itself or a token count, plus the expected output length, and get input, output, cache-read and cache-write cost per model with the total. Token counts derived from text are estimates from character and word statistics, not a tokeniser, and typically land within about 15 percent — where an exact count matters, count with the vendor tokeniser. Prices come from a table with a stated date; a model whose price has moved since is reported with its table date, so an old figure is visible rather than silently wrong. Unknown model names are refused with the closest matches rather than guessed.
- Grade an agent run: total cost, repeated identical tool calls, error streaks, calls that returned nothing, and which step consumed the budget.
Takes the steps of one agent run and returns a scored report. It counts identical tool calls (same tool, same arguments) as loops, finds the longest run of consecutive failures, marks calls whose result was empty or null as wasted, and attributes cost per step and per tool so the expensive part is visible. Cost is taken from your figures when supplied, otherwise computed from token counts against the model price table. A grade from A to F is derived from four measurable ratios — loops, errors, empty results and cost concentration — and every ratio is returned with the threshold it was judged against, so the grade can be recomputed or disagreed with. It judges shape and spend only: a run can be efficient and still produce the wrong answer, and nothing here checks the answer.
- List language models with prices per million tokens, context window, maximum output and batch discount, filtered by vendor, price ceiling or context requirement.
A comparison table of language models: input, output and cache prices per million tokens, context window, maximum output length, batch discount and a short note on what each is suited to. Filter by vendor, by a maximum price, by the context window you need, or by capability tag. Every row carries the date its prices were last checked, so a stale figure is visible rather than silently wrong. This is a curated table, not a live vendor query: prices are the publicly published list rates and negotiated or promotional rates are not represented. Availability, rate limits per account and regional restrictions are not covered — they depend on your contract, not on the model.
- Pick a model for a task given budget, latency need, context size and data-residency constraints, with the score breakdown and the runners-up.
Scores every catalogue model against one task and returns a ranked shortlist. You state the task kind, optionally a per-call budget in USD, how much speed matters, the input size and any vendor restriction; the answer names a model, the estimated cost per call, and the sub-scores it was chosen on, so the ranking can be checked rather than trusted. Models that cannot hold the input are excluded and listed separately with the reason. Weights are yours to set and are echoed back. The routing table is a heuristic over published prices and capability tags, not a benchmark: it will not tell you which model is more accurate on your data, and for anything quality-critical it is a shortlist to evaluate, not a verdict.
- Turn an OpenAPI document into MCP tool definitions: one tool per operation, all parameters merged into a single flat input schema with references written out.
Converts each OpenAPI operation into an MCP tool. Path, query and header parameters and the JSON request body are merged into one input schema, because MCP tools take exactly one; a name collision between a body field and a parameter is reported rather than silently overwritten. Internal $refs are expanded inline so each tool schema stands alone — an MCP client cannot resolve them. Tool names come from operationId, normalised to snake_case, or are derived from method and path when it is missing. Read-only operations are marked with readOnlyHint and write operations with destructiveHint. Only application/json bodies are converted: multipart, form and binary bodies are listed as skipped with the reason. The result is a starting point, not a finished server — it carries no auth handling and no request execution.
- Work out how to split a document across a model context window: how many chunks, where the cuts fall, how much overlap, and what it will cost.
Plans the division of a long input for a given model. It reserves room for the system prompt, the expected answer and a safety margin, then works out how many chunks are needed and where to cut, preferring paragraph boundaries over line and sentence boundaries and never cutting inside a word. Optional overlap carries context across the seams. The result gives per-chunk token estimates, the character offsets of every cut, the boundary type actually used, and the total cost for processing all chunks on that model. If the text fits in one pass, it says so and stops. Token counts are estimates from character and word statistics, not a tokeniser: leave the default margin in place, or verify with the vendor counter where an overrun would be expensive.