Loading ToolBench
MCP server for NowSecure Platform: pull assessment remediation findings and generate PDF reports, bypassing the broken UI report renderer.
This server exposes 2 tools with basic descriptions and parameter schemas, but several critical gaps limit production readiness. Both tools have valid enum constraints on impactTypes and non-trivial descriptions (120-180 chars), meeting baseline length requirements. However, output schemas are not documented, error handling lacks recovery guidance, and parameter relationships are underdescribed. The naming is clear (verb_noun pattern: get_*, generate_*) and tool responsibilities are distinct. The server accepts optional UUID parameters for flexibility, which is good design. However, the lack of guidance on how to resolve appRef/assessmentRef when both are omitted, and missing output structure definitions, creates friction for LLM usage. Baseline: 549 production tools average 194 chars for tool descriptions and 72 chars per param; this server meets or slightly exceeds those averages. 90% of A+ tools start with action verbs, this server complies.
Generate a PDF report for a NowSecure assessment. Includes findings, impact summary, remediation guidance, code samples, and evidence chains. Stores PDF locally and returns the file path.
Fetch remediation findings for a NowSecure assessment. Returns findings filtered by impact type and remediation status (detected/fail/open/reopened). Includes full evidence chains, code samples, and guidance links.
Output schemas not documented. Neither tool specifies what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract relevant data without knowing the response schema.
Parameter mutual exclusivity underdescribed. Both tools accept optional appRef and assessmentRef, with a fallback to 'latest assessment'. The description states 'if omitted, uses latest on app' but does not explicitly warn that passing neither may fail if the app has no assessments, or clarify the resolution order.
Error handling lacks recovery guidance. The code throws errors like 'NowSecure REST 401' or 'NowSecure GraphQL errors: [...]' but does not tell the LLM what to do next. Is it retryable? Should the user provide a valid token? Should a different parameter be used? Pattern:recovery-guide requires actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Output limits not stated. get_assessment_findings returns a potentially large array of findings with nested evidence chains. The tool description does not specify a cap on result count or explain pagination.
PDF generation lacks dry-run or confirmation. generate_assessment_pdf writes to the filesystem and returns a local path, but offers no confirmation step. If an LLM mistakes the outputPath, the file is created without agent approval. Destructive/state-modifying tools should support a dry-run or confirmation pattern.
impactTypes parameter defaults are implicit. The description says '(default: blocker,critical,high,medium)' in text, but the schema does not capture this as a JSON Schema default property. LLMs may not respect textual defaults and could pass unexpected values.
Response field naming and chaining unclear. If get_assessment_findings returns findings with a 'ref' field, will downstream tools that modify findings accept that same 'ref' field? The source code does not show response serialization or field names, making chaining difficult for LLMs.