Loading ToolBench
MCP front for the ReportItNow FastAPI surface. A thin proxy that routes tool calls to a FastAPI backend for POSH (Prevention of Sexual Harassment) complaint handling, with role-based access control, audit chain, and six AI components (CA, RA, IA, RPA, CPA, AR).
Server has 19 tools with explicit definitions, good naming conventions (verb_noun pattern), and comprehensive descriptions. However, schemas lack formal JSON Schema type declarations in the visible code, parameters are inferred from Python type hints rather than explicitly registered. Output schemas are undocumented. Error handling is minimal; no recovery guidance or categorization. Security-critical tools (file_complaint, transition_case, submit_response) lack permission/scope declarations. Descriptions are solid (avg ~150 chars) but some lack actionable constraints (e.g., 'target' in transition_case lists allowed values in description but not as enum). Composition is good, tools are single-responsibility and chainable, but some complex operations (file_complaint) bundle multiple concerns (case creation + AI structuring).
Audit Reviewer: pull a metadata window for forensic / procedural questions. Returns metadata only; role-boundary filter rejects any reply that would leak actor identities or case content.
Audit Reviewer: verify the tamper-evident audit chain and retrieve metadata-only access (timestamps, component IDs, hashed actor identifiers, input/output hashes). No case content visible.
Presiding Officer authorisation of a draft document. Required before a draft can be referenced in a state transition (e.g. moving to Filed).
Role-bounded freeform chat endpoint. Routes questions and follow-ups through the role-specific AI component. Output is filtered by role-boundary filter to prevent leakage of case content or actor identities.
Retrieve prior conversation history for a given role.
Output schemas undocumented. No tool returns a documented schema, LLMs cannot predict response structure or plan downstream calls. Critical for chaining tools.
Input schemas lack formal JSON Schema type declarations. Parameters are inferred from Python type hints, not explicitly registered with types/descriptions in MCP schema format. Schema score capped at 40 for all tools.
Enum constraints not formalized. 'target' in transition_case lists allowed values in description ('filed, conciliation, ...') but not as JSON Schema enum. LLMs may hallucinate invalid states.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Clear all prior conversation history for a given role.
Exact statutory figures for the named fiscal year. Restricted to employer / ICC / PO / Compliance Admin / DO / auditor.
RPA: format the inquiry record into the Section 13 report (four distribution copies). `outcome` is set by the ICC ('proved' or 'not_proved'); findings + conclusions are left as placeholders for committee authorship.
IA Phase 1: enumerate every distinct evidence item in the record. `record_pages` is a list of {page_no, text}. Returns a structured evidence list with id, source, claim, locator, and a digital-evidence flag for Section 63 BSA review.
File a new POSH complaint. Creates a case, runs the Complainant Assistant to structure the narrative, and returns the case id, intake-gate routing (icc/lcc/pocso_police), and the draft document id awaiting Presiding Officer authorisation. `narrative` must be the complainant's own words — they are preserved verbatim alongside the structured version (no-narrative-loss invariant).
Build the four annual outputs: Section 21 / Rule 14 ICC report, Section 22 employer report, Board's Report extract under Rule 8(5)(x), and the state portal payload. Aggregates only — no case content.
Presiding Officer rejects a draft. Keeps draft status, appends an audit entry for visibility.
Schedule and record a hearing. `members` is a list of {user_id, role_at_hearing, present}. Rule 7(7) quorum is checked server-side: refused if fewer than three ICC members including the Presiding Officer are marked present.
Rule 7(2) service: PO authorises delivery of the authorised written complaint to the respondent through the case file (separate from the RA channel, which never sees the full narrative).
Run the Respondent Assistant for the named case. The RA never receives the complainant's raw narrative — the `allegation_summary_authorised` field must be the PO-cleared summary, not a paraphrase of the complaint document. The full complaint reaches the respondent separately through the case file (Rule 7(2)), not via the RA.
IA Phase 2: build a timeline + contradiction table + neutral summary from the Phase 1 evidence list. The original record is NOT passed in — this is the position-bias mitigation. No credibility, no findings.
Move a case to a new state. Allowed targets follow the design's state graph (filed, conciliation, conciliation_breached, inquiry, report, employer_action, appeal, closed, terminated). FastAPI enforces role + invariants + audit log inside one transaction.
Public-facing transparency dashboard with differential privacy applied. Figures are aggregates only; no case content. Small-n suppression and Laplace mechanism applied per design.
Return the authenticated user's id, email, display name, and held roles. Useful at the start of a session for the model to understand which tools it can legitimately call (each tool's role check is enforced by FastAPI).
No error handling guidance. Tools return raw HTTP errors (raise_for_status()) with no recovery hints. LLMs cannot distinguish retryable from fatal errors or know what to do next.
Security-critical tools lack permission/scope declarations. file_complaint, submit_response, transition_case, and authorise_document modify case state but do not declare required roles or permissions. No audit trail visible in MCP layer.