Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_environment_preflight

Read-only

Check repository, policy, Source Graph, and provider readiness before launching workers; confirm the environment is ready to avoid failed runs.

Instructions

READ-ONLY: unified repository/policy/Source Graph/provider readiness. Use before launching workers to confirm readiness; use aiworkhub_doctor_diagnose when something is already failing.

Provider access is reported as observed only when an adapter-specific bridge or credential readiness source proves it; installed CLI binaries alone remain installed_unverified_access.

detail="summary" (default) folds Source Graph's refresh-job report to identity plus state, providers to a flat {adapter_id: status} map, provider_route_contracts.route_families to one {family, status, count} row each, policy to its verdict fields, worker_finalization to its state fields, and each of provider_summary's route/capability lists and its route_status_questions block to a count plus a short id preview (or identity); with adapter_id given, providers and provider_observability.adapters/providers are filtered to that adapter. detail="evidence" behaves like "full": both return repo_policy.build_preflight exactly.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aiworkhub_environment_preflight"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNosummary (default) folds the report to counts and short previews; evidence and full both return the complete report.summary
adapter_idNoOptional provider adapter id to check and to narrow the provider report to; an unsupported id adds selected_adapter_unsupported to errors. Omit to report every adapter.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.67
    • addedInput schema / properties / adapter_id / description
      Added value: +"Optional provider adapter id to check and to narrow the provider report to; an unsupported id adds selected_adapter_unsupported to errors. Omit to report every adapter."
    • addedInput schema / properties / detail / description
      Added value: +"summary (default) folds the report to counts and short previews; evidence and full both return the complete report."
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, so the 'READ-ONLY' prefix is partly redundant. Beyond that, the description adds genuinely non-obvious behavior: access is only reported as observed when a bridge or credential source proves it, and installed binaries alone yield 'installed_unverified_access' — a semantic detail an agent could not infer from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage are correctly front-loaded, but the final paragraph is one very long, backtick-dense sentence enumerating fold targets that is difficult to scan and borders on reference documentation rather than tool selection guidance.

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?

With an output schema present, return values need not be spelled out, and the description correctly focuses on scope, when-to-use, filtering, and detail-mode behavior. Coverage is strong; only minor gaps remain around error/empty-result handling, which the schema partly covers via selected_adapter_unsupported.

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?

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds meaning the schema does not: it enumerates which report sections get folded under detail='summary' and confirms adapter_id narrows both 'providers' and 'provider_observability', going beyond the field-level text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It names a specific composite resource — repository, policy, Source Graph and provider readiness — and the 'confirm readiness before launching workers' framing makes the intent concrete. It is weaker than a crisp verb+object phrasing because the first line is a compound noun list, but an agent can still distinguish it from siblings like aiworkhub_doctor_diagnose.

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 states the trigger ('Use before launching workers to confirm readiness') and names the alternative with its own trigger ('use aiworkhub_doctor_diagnose when something is already failing'). This is a clean when/when-not/alternative split.

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

Deploy Server

Other Tools