Conflux hyperscale orchestration runtime - an MCP server for distributed task orchestration, conflict resolution, adversarial auditing, and governance enforcement
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Conflux defines 2 tools with minimal schema documentation and vague descriptions. Both tools lack parameter descriptions, proper type annotations, and output schema documentation. The tool names are verb-led (good), but descriptions are too brief (18-20 chars, well below the 50-200 char target). Input schemas are present in the function signatures but lack JSON Schema formalization in the registration. No error handling guidance, no security annotations, and no output structure specification. The tools appear to be thin wrappers around internal Sentinel methods with no LLM-facing schema clarity.
Tools (2)
harmonize_trackwritesource verified40/100
Harmonization Sentinel: Resolves conflicts or verification failures.
Descriptions are critically short (18-20 characters). Both tool descriptions lack context for LLM selection (no WHAT/WHEN/WHY), no prerequisites, and no explanation of when to use harmonize_track vs run_sentinel_adversarial_audit.
No parameter descriptions. track_id and content in run_sentinel_adversarial_audit, and track_id/conflict_diff in harmonize_track lack any explanation of format, expected values, or constraints. Rubric requires 'Every parameter needs a description.' This forces LLMs to guess.
No output schema documented. Both tools return JSON strings (f-strings with json.dumps()) but LLMs have no declared schema to understand result structure. Rubric: 'Document the output schema. LLMs need to know what fields to expect.'
run_sentinel_adversarial_auditharmonize_track
Recommendations
Expand tool descriptions to 80-150 characters each, following the pattern: '[WHAT] This tool [does specific action]. [WHEN] Call it when [context/prerequisite]. [RETURN] It returns [key fields/format].' Example: 'Runs a structural adversarial audit on track content to validate implementation safety. Call this after modifying a track. Returns audit result with pass/fail status and detailed violations.'
Add parameter descriptions for all 4 parameters. For track_id: 'Unique track identifier (alphanumeric, 1-64 chars, e.g., "audit-track-001"). Used to locate the track in the conductor state.' For content: 'The content to audit (source code, config, or implementation body). Must be valid text/plaintext (max 100KB).' For conflict_diff: 'Git unified diff format showing the conflict (optional; if omitted, harmonize_track performs auto-fix). Expected format: lines starting with -, +, @@.' Add constraints to optional params: 'conflict_diff: optional string; if provided, must be valid unified diff format; if omitted, auto-fix is triggered.'
Document output schemas explicitly. For run_sentinel_adversarial_audit, add a docstring block showing: '{"pass": bool, "violations": [{"id": str, "severity": str, "msg": str}], "kg_validation": {"ok": bool, "blocked": bool?, "reason": str?}}.' For harmonize_track: '{"resolution_type": "conflict"|"auto_fix", "success": bool, "actions": [str], "details": object}.' Include field meanings.
Add error handling return cases. When ctx.sentinel.audit_implementation() fails, catch and return: '{"pass": false, "error": "audit_failed", "reason": "<specific error>", "recovery": "Verify track content is valid. Try run_sentinel_adversarial_audit again after fixing issues."}' Categorize errors as retryable (network), user-fixable (invalid input), or fatal (permission denied).
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling guidance. Tools can fail (e.g., sentinel.audit_implementation() or sentinel.resolve_git_conflict()) but return no structured error responses, no recovery paths, and no categorization (retryable vs fatal). Rubric: 'Error responses must tell the LLM what to do next.'
harmonize_track has a poorly-named optional parameter 'conflict_diff'. No description of what format this expects (unified diff? git diff output?), whether it's required, or what happens if omitted (auto-fix is triggered). Rubric: 'When one parameter's valid values depend on another, document this in both parameter descriptions.'
harmonize_track's behavior is context-dependent and opaque: if conflict_diff is None, it performs auto-fix on a hardcoded path (conductor/tracks/{track_id}). No description explains this branching logic or when each path is triggered. Rubric: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.'
Ambiguous tool naming distinction. 'run_sentinel_adversarial_audit' vs 'harmonize_track' do not follow consistent verb_noun patterns (one is run_X, one is verb_object with no clear action). Unclear which resolves what type of conflict. Rubric: 'When multiple tools operate on the same resource, their names must make the distinction obvious.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). run_sentinel_adversarial_audit is READ_ONLY; harmonize_track is WRITE (may modify state). These semantic hints must be explicit in tool metadata for agent safety, but the code shows no annotation mechanism in the @mcp.tool() decorator.
track_id and content parameters in run_sentinel_adversarial_audit lack format/length constraints. No description clarifies whether track_id is a UUID, slug, or arbitrary string; whether content is code, config, or plaintext; or what size limits apply. Rubric: 'Specify minimum and maximum for numeric parameters' and describe format/charset for strings.
run_sentinel_adversarial_audit
Rename or clarify tool purposes. Consider: 'audit_track_content' (instead of run_sentinel_adversarial_audit) and 'resolve_track_conflicts' (instead of harmonize_track). Or add a discovery tool 'list_sentinel_tools' that explains what each does, so agents understand the toolkit.
Add tool annotations to tool registration. Use a structured metadata dict in the @mcp.tool() decorator or server config: e.g., @mcp.tool(readOnlyHint=True) for audit, @mcp.tool(destructiveHint=True) for harmonize_track. This signals agent safety constraints.
Document parameter interdependencies explicitly. In harmonize_track description, state: 'If conflict_diff is provided, resolves that specific conflict. If omitted, auto-fixes all failures in the track. Exactly one mode is triggered per call.' Use parameter descriptions to reinforce: 'conflict_diff: optional; if provided, conflict_diff is used; otherwise, auto-fix mode.' Avoid conditional logic hidden in implementation.
Add examples in descriptions without embedding literal values. Instead of 'e.g., track-001', describe the format: '(e.g., a unique identifier like "audit-track-001")'. Or better, use an enum if there are known track types.
Consider whether these tools should return paginated results if track_id can map to multiple items. If not, clarify that track_id is always unique and single-item. If yes, add limit/offset parameters and return a count.
Add recovery guidance in error messages. If harmonize_track fails to auto-fix, suggest: 'Auto-fix failed. Provide a conflict_diff manually, or call run_sentinel_adversarial_audit to identify root causes before retrying.'