- Reliability 7/20
- This review is based solely on the README text; the server manifest is marked 'not cached' and no source code, CI workflow, or test files were supplied as evidence, so the MCP init/tool-list handshake and the accuracy of the ~70 declared tools cannot be verified against real behavior. The README's own Troubleshooting section actually reveals a history of genuine interface bugs (Pydantic model objects passed where dicts were expected, swapped argument order for auth_manager/server_config), indicating the implementation has had real instability; the claim that these are 'now handled automatically' is asserted, not evidenced by any changelog or regression test. Per the static calibration rule, reliability is capped at 12 without verifiable CI+test evidence, and given the near-total absence of evidence plus a documented history of defects, a score of 7 is assigned.
- Security and permissions 4/20
- Red line triggered: the tool set includes multiple irreversible or deploy-type operations (delete_workflow, delete_script_include, delete_story_dependency, remove_group_members, commit_changeset/publish_changeset to production, approve_change/reject_change) and the README does not mention any confirmation step, dry-run mode, approval gate, or least-privilege scoping for these — they appear to execute directly against a live ServiceNow instance when invoked. Credentials are configured in plaintext via a .env file (Basic/OAuth/API Key) with no guidance on secret storage, scope limitation, or least-privilege practice, and there is no discussion of outbound network boundaries or data-exfiltration safeguards. Per the rubric, irreversible delete/deploy defaults without confirmation constitute a red line, so security is capped at 0-4.
- Maintenance 9/20
- The repository is MIT-licensed and not archived, with 32 open issues indicating ongoing usage and feedback, but no commit history, release cadence, changelog, or dependency-update policy was available for this review, and the README does not disclose versioning practices, a security-response channel, or maintainer identity. The contribution guide is a generic fork-and-PR flow without further governance detail. Given the lack of verifiable maintenance-activity evidence, only a below-average score is warranted based on the 'not archived + licensed + some responsiveness signal' baseline.
- Documentation 16/20
- Documentation is fairly extensive: it covers installation, three authentication method configurations, both stdio and SSE run modes, the MCP_TOOL_PACKAGE tool-packaging mechanism, a list of nearly 70 tools, many natural-language usage examples, a troubleshooting section, and links to topic-specific docs (catalog.md, change_management.md, etc.) plus example scripts. Points are deducted because individual tools lack parameter-level documentation (only a name and one-line description, no types/required fields/return shape), and there is no disclosure of rate limits, cost, data retention, or permission boundaries, so it falls short of full marks.
- Setup experience 13/20
- The setup path is clear: clone the repo, create a virtualenv, pip install -e ., write a .env credentials file, register via CLI or mcp install, with a concrete Claude Desktop claude_desktop_config.json example and SSE-mode host/port customization instructions — the steps are explicit and code examples are provided. However, per the static-review rule, setup cannot exceed 15 without CI workflows and real tests proving these steps are reproducible; the process also depends on the user manually supplying real credentials and adjusting OS-specific paths, introducing some manual/environment-dependent fragility, so it is scored below that ceiling.