symbol-mcp-server

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All work happens on feature branches merged through pull requests into main, so every intermediate change between releases is public and reviewable in the repository history and in the pull requests. https://github.com/inotakeh/symbol-mcp-server/pulls?q=is%3Apr

Repository on GitHub, which uses git. git is distributed.

Every release published to npm has a unique version number (e.g. 0.7.0), recorded in package.json, CHANGELOG.md and server.json; npm does not allow a published version to be reused. https://www.npmjs.com/package/symbol-mcp-server?activeTab=versions

Each release is identified by a git tag of the form vX.Y.Z (from v0.3.0 onwards; 0.2.0 was the initial manual publish). Pushing the tag triggers the release workflow, and tag creation is restricted to the maintainer by a repository ruleset. https://github.com/inotakeh/symbol-mcp-server/tags

Non-trivial release notes file in repository: https://github.com/inotakeh/symbol-mcp-server/blob/main/CHANGELOG.md.

No publicly known vulnerabilities (CVE or similar) have been reported in the project's results. If one is fixed in a future release, it will be listed in CHANGELOG.md under a Security heading, as described in SECURITY.md.

Bug reports are submitted through GitHub Issues, using a bug report form that asks for the version, client, network, tool input and output. https://github.com/inotakeh/symbol-mcp-server/issues/new/choose

GitHub Issues is used as the issue tracker. https://github.com/inotakeh/symbol-mcp-server/issues

No bug reports have been submitted by users so far (the project is new). The maintainer watches the repository and will acknowledge new reports; defects found by the maintainer are fixed through pull requests (e.g. the finality participation fix in 0.5.0).

No enhancement requests have been submitted by users so far. Requests are accepted through the feature request form in GitHub Issues and will be answered by the maintainer.

GitHub Issues and pull requests are public, permanent and searchable, and each is addressable by URL. https://github.com/inotakeh/symbol-mcp-server/issues?q=is%3Aissue

SECURITY.md describes how to report a vulnerability (GitHub private vulnerability reporting), what is in scope, and the expected response time. https://github.com/inotakeh/symbol-mcp-server/blob/main/SECURITY.md

Private reports are sent through GitHub private vulnerability reporting (Security tab, "Report a vulnerability"), which is visible only to the reporter and the maintainer. The issue form's configuration links there and asks reporters not to open public issues for security problems. https://github.com/inotakeh/symbol-mcp-server/security/advisories/new

No vulnerability reports have been received in the last 6 months. SECURITY.md commits to an initial response within 7 days.

The TypeScript sources are compiled with npm run build (tsc), which regenerates dist/ from source; CI and the release workflow run the same command. https://github.com/inotakeh/symbol-mcp-server/blob/main/CONTRIBUTING.md

The build uses standard tools of the ecosystem: npm scripts and the TypeScript compiler (tsc).

All build and test tools are FLOSS: Node.js, npm, TypeScript, Vitest and Biome.

The project has an automated FLOSS test suite (Vitest, about 890 tests: unit tests, tool-layer tests that run the MCP server in-process against synthetic fixtures on both protocol eras, and opt-in integration tests against a live node). How to run it is documented in CONTRIBUTING.md and the README, and CI runs it on every pull request. https://github.com/inotakeh/symbol-mcp-server/blob/main/CONTRIBUTING.md https://github.com/inotakeh/symbol-mcp-server/blob/main/.github/workflows/ci.yml

The tests run with the standard npm test command.

Every tool has tool-layer tests covering its successful outputs (validated against the published outputSchema), input validation errors, node error paths (HTTP errors, timeouts, missing data) and a check that no host other than the configured node is contacted; the domain logic (amounts, time, epochs, receipts, voting, finality, ranking, prices) has unit tests with fixed expected values. No line-coverage percentage is published.

GitHub Actions runs lint, typecheck, the test suite and the build on Node.js 22 and 24 for every pull request, together with dependency review and CodeQL; these checks are required before merging into main. https://github.com/inotakeh/symbol-mcp-server/actions

CONTRIBUTING.md requires that new behaviour comes with tests and that npm test passes; the pull request template has a "New behaviour has tests" checklist item. https://github.com/inotakeh/symbol-mcp-server/blob/main/CONTRIBUTING.md https://github.com/inotakeh/symbol-mcp-server/blob/main/.github/pull_request_template.md

Recent feature pull requests each added unit and tool-layer tests for the new functionality, e.g. symbol_holdings_value (#36), symbol_account_rank (#34) and the check CLI subcommand (#31). https://github.com/inotakeh/symbol-mcp-server/pull/36 https://github.com/inotakeh/symbol-mcp-server/pull/34 https://github.com/inotakeh/symbol-mcp-server/pull/31

The policy is documented in CONTRIBUTING.md and in the pull request template checklist. https://github.com/inotakeh/symbol-mcp-server/blob/main/CONTRIBUTING.md

TypeScript is compiled in strict mode (npm run typecheck) and Biome is used as a linter (npm run lint); both run in CI on every pull request.

The linter and type checker report zero warnings on main; the last remaining lint warnings were fixed in a dedicated cleanup pull request, and CI fails on type errors. https://github.com/inotakeh/symbol-mcp-server/pull/33

TypeScript runs with strict enabled and Biome's recommended rule set is enforced on src/, test/ and scripts/.

The primary developer designed the server around least privilege and a small attack surface: it is read-only, never accepts private keys or tokens, contacts only the configured node URL(s) (no URL arguments, which prevents SSRF), validates every input and REST response against schemas, caps response sizes and concurrency, treats on-chain strings as untrusted, and publishes releases through OIDC trusted publishing without stored tokens. These decisions are documented in docs/DESIGN-BRIEF.md and SECURITY.md. https://github.com/inotakeh/symbol-mcp-server/blob/main/docs/DESIGN-BRIEF.md

The developer addresses the common error classes for an MCP server and Node.js package: prompt injection through tool output (on-chain strings stripped of control and bidi characters and length-limited), SSRF (fixed destinations only), injection and malformed input (schema validation), path traversal (the only file write is confined to SYMBOL_STATE_DIR with an inside-directory check, 0700/0600 modes and atomic rename), resource exhaustion (response size cap, timeouts, concurrency limit, paging limits), secret leakage (no secrets handled; secret scanning with push protection) and supply-chain attacks (lockfile, npm ci --ignore-scripts, dependency allowlist, actions pinned to commit SHAs, provenance).

The only cryptographic algorithms used are the published hash functions SHA3-256 and RIPEMD-160, required by the Symbol address and namespace identifier formats; network traffic uses TLS through Node.js's standard HTTPS client.

Hashing is done with Node.js's built-in crypto module (backed by OpenSSL); the project does not implement cryptographic primitives itself.

All cryptographic functionality comes from FLOSS components (Node.js and OpenSSL).

The software has no security mechanism that uses keys: it never generates, stores or uses private keys and performs no encryption or signing. TLS parameters are those of Node.js.

No broken algorithms (MD4, MD5, DES, RC4, Dual_EC_DRBG) are used; only SHA3-256, RIPEMD-160 (for Symbol identifiers) and TLS as provided by Node.js.

No algorithms with known serious weaknesses such as SHA-1 are used by the project's code.

The software implements no key agreement protocol; HTTPS connections use Node.js's TLS defaults.

The software does not store passwords or authenticate users.

The software does not generate cryptographic keys or nonces.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

No hashes are retrieved over plain HTTP. The package is distributed through the npm registry over HTTPS with integrity hashes, registry signatures and SLSA provenance attestations (verifiable with npm audit signatures).

There are no known unpatched vulnerabilities in the project or its dependencies: npm audit reports none, Dependabot alerts are enabled, and dependency review runs on every pull request.

No critical vulnerabilities have been reported. SECURITY.md commits to an initial response within 7 days, and dependency vulnerabilities are surfaced by Dependabot alerts and security updates.

The project holds no credentials: npm publishing uses OIDC trusted publishing with no token, and the server needs no secrets. GitHub secret scanning with push protection is enabled, and a pre-push hook blocks private identifiers from being committed.

CodeQL (GitHub code scanning, default setup for JavaScript/TypeScript, Python and Actions) and the Biome linter are applied to every pull request and every push to main, so every release is analysed before it is published. https://github.com/inotakeh/symbol-mcp-server/security/code-scanning

CodeQL's security queries look for common vulnerability classes in JavaScript/TypeScript (injection, path traversal, SSRF, prototype pollution, insecure randomness, etc.) and in GitHub Actions workflows. OpenSSF Scorecard also checks the workflows for dangerous patterns weekly.

There are no open code scanning alerts; any confirmed medium or higher finding would be fixed before the next release, as with other security issues (SECURITY.md).

CodeQL and Biome run on every pull request and on every push to main; Scorecard runs weekly.

The software is written in TypeScript/JavaScript, a memory-safe language; no C or C++ is produced by the project.

The test configuration validates every REST response against zod schemas and every tool result against its published outputSchema, and the tests assert exact expected values; these checks are part of every test run.

No dedicated dynamic analysis tool is used, and the test suites have not found any exploitable vulnerability. Any would be handled as described in SECURITY.md.