VHGENGINE

by app.railway.up.engine-production-3bdc

health

Read-only

Deep health: DB read+write probe, worker/queue, backup + integrity. Free. Uses the same DB, backup, offsite, and integrity probes as GET /health; status is "ok" only when the DB reads and writes. Returns status/time/LLM, outcome, queue, backups, integrity, commission/source/extract readers, profile readiness, and source writer state. Readable schema 3 proves codec support only; readiness separately proves this process has the exact authorization, private queue, deletion, and immutable-lineage substrate. llm_configured never calls an LLM; check job_worker_alive before start_generate_job.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`time`	No	Server time, ISO-8601 UTC.
`status`	No	'ok' only when the DB both READS and WRITES (a write probe, not just a ping); 'unavailable' otherwise.
`offsite`	No	Off-volume upload health: {enabled, last_upload_at, last_status, remote_retained}. In-memory, no live S3 call. Null when status is unavailable.
`version`	No	Server version.
`build_sha`	No	Exact deployed Git commit, or null when the platform cannot prove one.
`integrity`	No	Weekly PRAGMA quick_check result: {last_check_at, ok}, both null before the first check has ever run. Null (the whole object) when status is unavailable.
`backup_count`	No	How many daily backups are retained. Null when status is unavailable.
`last_backup_at`	No	Newest nightly backup's timestamp, ISO-8601 UTC. Null before the first backup runs, or when status is unavailable.
`llm_configured`	No	Whether an LLM key is configured. false means smart/research are unavailable and mode=auto resolves to instant. A pure config read, never a live call.
`job_queue_depth`	No	Jobs queued and not yet claimed, across all accounts. Null when status is unavailable.
`job_worker_alive`	No	Whether this deployment runs the job worker. FALSE means start_generate_job would queue a job nothing executes: use generate_hooks instead.
`outcomes_reported_total`	No	Size of the shared outcome corpus (60s-cached COUNT). Null when status is unavailable.
`release_artifact_sha256`	No	SHA-256 of the exact installed Python package bytes and relative paths.
`extract_schema_read_versions`	No	Permanent Extract schema versions this process can decode. A listed version does not enable extraction.
`hook_research_provider_ready`	No	Whether every approved live hook-research capability is present.
`source_lineage_writes_enabled`	No	Whether authoritative source/extract writers are active on this process. ARCH-103A2 intentionally reports false.
`research_intent_writes_enabled`	No	Whether schema-v4 research-intent writers and workers are active. API-105A intentionally reports false while its permanent readers are deployed.
`commission_schema_read_versions`	No	Permanent commission schema versions this process can decode. Schema 3 being listed does not by itself enable profile-bound generation.
`hook_research_provider_prepared`	No	Whether the exact signed provider graph is validated while dispatch may remain closed.
`creator_profile_generation_ready`	No	Whether this process can safely execute exact schema-3 profile commissions: authorization, private queue ownership, deletion races, payload scrubbing, and immutable lineage are enforced. Public profile-reference input fields remain a separate surface contract.
`hook_research_provider_policy_id`	No	Frozen provider runtime policy identity.
`source_asset_schema_read_versions`	No	Permanent SourceAsset schema versions this process can decode. A listed version does not enable ingestion.
`source_metric_schema_read_versions`	No	Permanent source-metric observation schema versions this process can decode without enabling a metric writer.
`hook_research_capability_receipt_id`	No	Exact complete capability receipt identity, null while closed.
`hook_research_provider_policy_sha256`	No	SHA-256 of the frozen provider runtime policy.
`research_result_schema_read_versions`	No	Permanent standalone research result and occurrence schema versions this process can decode without enabling research delivery.
`extraction_result_schema_read_versions`	No	Permanent standalone extraction result and occurrence schema versions this process can decode without enabling extraction delivery.
`hook_research_prepared_capability_receipt_id`	No	Exact target capability identity, null until closed preparation succeeds.

TDQS

A3.8/5.0

Behavior1/5

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

The description states it is a 'DB read+write probe' and that status is 'ok' only when the DB writes, which implies write side effects. However, annotations declare readOnlyHint: true. This is a direct contradiction, so the behavioral transparency score is 1.

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?

The description is somewhat long but every sentence provides unique information: the scope of the probe, the condition for 'ok', the list of returned values, and clarifications about schema and worker status. It is dense but not wasteful.

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?

Despite the annotation contradiction, the description thoroughly explains what the tool does, what it returns, and how to interpret readiness. An output schema exists, so further detail on return values is unnecessary. The description is complete for the tool's complexity.

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?

The tool has zero parameters, so there is no need for parameter documentation in the description. The description still adds value by explaining the output semantics (e.g., what status/time/LLM and readiness mean), which is useful context.

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?

The description clearly states the tool is a health probe that checks DB read/write, worker/queue, backup, and integrity. It uses a specific verb+resource structure and distinguishes itself from other tools by focusing on system health rather than data operations.

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 description gives concrete usage guidance, such as 'check job_worker_alive before start_generate_job', and explains the meaning of readiness. It doesn't explicitly list alternatives or exclusions, but it provides clear context for when to invoke this tool.

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

All VHGENGINE tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action, e.g., signup vs. delete_account, create_key vs. revoke_key, generate_hooks vs. score_hook. Even similar tools like generate_hooks and generate_hooks_batch are clearly differentiated by single vs. batch operation.

Naming Consistency5/5

All 32 tools use a consistent verb_noun snake_case pattern (e.g., add_credits, create_checkout, revoke_key, list_outcomes) with no mixing of camelCase or other conventions.

Tool Count4/5

32 tools is slightly above the typical 15-tool range, but the domain is broad (account, keys, webhooks, generation, scoring, jobs, outcomes), and each tool has a specific purpose. No tools seem redundant.

Completeness4/5

The tool surface covers most lifecycle operations: CRUD for accounts/keys/webhooks, generation/scoring with batch and async variants, outcomes reporting, and auxiliary tools. Missing explicit delete for hooks (expire automatically) and some update operations, but no critical gaps.

Resources

Need Help?