Skip to main content
Glama

claim_workbench_evidence_ledger

Forensic claim workbench — analyzes a folder of mixed evidence (XER chain + MSG/PDF/DOCX/XLSX correspondence) and produces a unified workbench dashboard.

        Built from the real-world workflow where forensic delay
        analysis starts from a folder containing schedule updates,
        owner correspondence, RFIs, change orders, and meeting
        minutes — all mixed together. The workbench produces:

          - Evidence ledger (chronological): all artifacts dated and
            summarized
          - Schedule chain-diff: 14-category manipulation log
            (TASKPRED add/remove, constraint flips, retroactive
            baseline edits, completion reversals)
          - Rolling baseline: per-activity baseline-at-introduction
            across the entire XER chain
          - Trust score: statistical impossibilities flagged
            (zero-duration-variance schedules, no-new-activities,
            every-activity-hits-baseline, etc.)
          - Slip-to-evidence cross-reference: each forensic slip
            auto-paired with documents in its window mentioning
            affected activity codes
          - Unified HTML dashboard with all of the above

        Use this tool when starting forensic delay analysis from raw
        evidence. For single-XER-pair forensic with hand-prepared
        events, use ``forensic_windows_analysis`` instead.

        Two input modes (supply exactly one):
          * ``folder_path`` — a server-side evidence folder that already
            resolves UNDER the server temp directory (the path guard).
            Hosted callers cannot reach a desktop path this way.
          * ``evidence_files`` — a CONTENT MANIFEST: a list of
            ``{"name": str, "content_b64": str}`` entries carrying
            base64-encoded file BYTES (handles binary PDF/XLSX/MSG as
            well as text). The tool decodes each blob, sanitizes the
            filename to a bare basename (rejecting path separators,
            ``..``, absolute/drive paths, control chars, dot-only
            traversal), writes it into a FRESH per-call tempdir under
            the allowed server-tempdir root, runs the analysis on that
            staged folder, then cleans the staged dir up. Caps: at most
            500 files and 60 MB total decoded bytes — an over-cap
            manifest returns a clear ``tool_error`` naming the cap and
            the actual size (NEVER silently truncated).

        Args:
            folder_path: path to the evidence folder (mode 1; must
                exist and resolve under the server tempdir).
            evidence_files: content manifest (mode 2); list of
                ``{"name": str, "content_b64": str}``.
            output_dir: optional dir for outputs (tempdir if "").
            project_name: optional override.
            original_baseline_xer_filename: optional filename in the
                folder identifying the baseline XER.
            contract_form: contract template tag (default 'CCDC2').
            run_forensic: when True (default), also runs
                forensic_windows_analysis on the discovered XER chain.

        Returns:
            {
              "evidence_ledger":     {...},
              "chain_diff":          {...} | None,
              "rolling_baseline":    {...} | None,
              "trust_score":         {...} | None,
              "cross_reference":     {...} | None,
              "forensic_result":     {...} | None,
              "output_files":        {...},
              "errors":              {...} (per-step failure log)
            }
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
output_dirNo
folder_pathNo
project_nameNo
run_forensicNo
contract_formNoCCDC2
evidence_filesNo
original_baseline_xer_filenameNo

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so comprehensively. It discloses path resolution restrictions, file sanitization rules, per-call tempdir creation and cleanup, size caps (500 files/60 MB), explicit error behavior when over cap, and that run_forensic triggers forensic_windows_analysis. No annotation contradiction exists.

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

Conciseness5/5

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

Despite its length, the description is well-structured with a purpose-led opening, bulleted output list, explicit usage guidance, two clearly delineated input modes, and an Args/Returns section. Every sentence adds technical or operational value; there is no padding or repetition.

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?

Given the tool's high complexity, absence of annotations, and absence of an output schema, the description is exceptionally complete. It covers input modes, security constraints, resource caps, error handling, and the full return shape, leaving an agent with all necessary context to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. Every parameter is explained: folder_path with path guard behavior, evidence_files with exact manifest structure and decoding semantics, output_dir, project_name, original_baseline_xer_filename, contract_form default, and run_forensic default with behavioral implication. This goes well beyond the bare schema.

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 a specific verb ('analyzes') and resource ('a folder of mixed evidence'), and enumerates detailed deliverables (evidence ledger, chain-diff, rolling baseline, trust score, cross-reference, HTML dashboard). It also distinguishes itself from the sibling forensic_windows_analysis by explicitly naming the alternative for single-pair analysis.

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?

Explicit guidance is provided: 'Use this tool when starting forensic delay analysis from raw evidence' and 'For single-XER-pair forensic with hand-prepared events, use forensic_windows_analysis instead.' It also details two input modes and when to use each (folder_path vs evidence_files), including path guard and content manifest specifics.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation4/5

Each tool targets a distinct analytical deliverable (windows analysis, concurrency matrix, slip velocity, TIA, collapsed as-built, SRA, etc.), and descriptions explicitly cross-reference sibling tools to clarify boundaries. Some pairs like critical_path_validator vs dcma14_health_check and forensic_windows_analysis vs concurrent_delay_matrix share inputs and close conceptual territory, but the stated distinctions are clear enough to prevent misselection.

Naming Consistency4/5

All tool names follow a consistent lowercase snake_case style with descriptive noun phrases (e.g., forensic_windows_analysis, slip_velocity, xer_parser), so there is no mixing of conventions. However, the pattern is not verb_noun and a few names embed acronyms or numbers (dcma14_health_check, monte_carlo_p50_p80, woet_classifier), which is a minor deviation from a fully uniform naming scheme.

Tool Count5/5

13 tools is well-scoped for a forensic CPM/schedule delay analysis server. Each tool covers a distinct method or deliverable—parsing, logic health, DCMA-14, windows analysis, concurrency, slip trends, TIA, collapsed as-built, Monte Carlo SRA, maturity assessment, WOET, path tracing, and an evidence workbench—so every tool earns its place without redundancy.

Completeness5/5

The tool surface comprehensively covers the forensic delay analysis lifecycle: input parsing, schedule logic validation, DCMA-14 health assessment, retrospective windows analysis, concurrency attribution, slip trending, prospective TIA, collapsed as-built, probabilistic SRA, maturity rating, execution classification, and raw-evidence workbench. Minor gaps like schedule editing or cost analysis exist but are outside the server's stated forensic-analysis purpose.