npm · mcp0.20.5

Evidence

/**

 * admin — CLI admin subcommands for gramatr user/org/team management.

 *

 * Calls the server REST API admin endpoints with local auth credentials.

RemediationAI

The problem is that the 'restore-access' handler in admin.js calls the REST API endpoint without checking whether the caller has admin or ownership scope over the target user or organization. Add a scope validation check before the API call by calling an authorization function (e.g., `await requireAdminScope(caller, targetEmail)`) that verifies the caller's JWT token contains 'admin' or 'owner' scope. This ensures only authorized users can restore access. Verify the fix by attempting to call 'restore-access' with a non-admin token and confirming it returns a 403 Forbidden error.

Evidence

/**

 * admin — CLI admin subcommands for gramatr user/org/team management.

 *

 * Calls the server REST API admin endpoints with local auth credentials.

RemediationAI

The problem is that the 'restore-access' handler in admin.js calls the REST API endpoint without checking whether the caller has admin or ownership scope over the target user or organization. Add a scope validation check before the API call by calling an authorization function (e.g., `await requireAdminScope(caller, targetEmail)`) that verifies the caller's JWT token contains 'admin' or 'owner' scope. This ensures only authorized users can restore access. Verify the fix by attempting to call 'restore-access' with a non-admin token and confirming it returns a 403 Forbidden error.

Evidence

/**

 * admin — CLI admin subcommands for gramatr user/org/team management.

 *

 * Calls the server REST API admin endpoints with local auth credentials.

RemediationAI

The problem is that the 'restore-access' handler in admin.js calls the REST API endpoint without checking whether the caller has admin or ownership scope over the target user or organization. Add a scope validation check before the API call by calling an authorization function (e.g., `await requireAdminScope(caller, targetEmail)`) that verifies the caller's JWT token contains 'admin' or 'owner' scope. This ensures only authorized users can restore access. Verify the fix by attempting to call 'restore-access' with a non-admin token and confirming it returns a 403 Forbidden error.

Evidence

/**

 * admin — CLI admin subcommands for gramatr user/org/team management.

 *

 * Calls the server REST API admin endpoints with local auth credentials.

RemediationAI

The problem is that the 'restore-access' handler in admin.js calls the REST API endpoint without checking whether the caller has admin or ownership scope over the target user or organization. Add a scope validation check before the API call by calling an authorization function (e.g., `await requireAdminScope(caller, targetEmail)`) that verifies the caller's JWT token contains 'admin' or 'owner' scope. This ensures only authorized users can restore access. Verify the fix by attempting to call 'restore-access' with a non-admin token and confirming it returns a 403 Forbidden error.

Evidence

/**

 * admin — CLI admin subcommands for gramatr user/org/team management.

 *

 * Calls the server REST API admin endpoints with local auth credentials.

RemediationAI

The problem is that the 'restore-access' handler in admin.js calls the REST API endpoint without checking whether the caller has admin or ownership scope over the target user or organization. Add a scope validation check before the API call by calling an authorization function (e.g., `await requireAdminScope(caller, targetEmail)`) that verifies the caller's JWT token contains 'admin' or 'owner' scope. This ensures only authorized users can restore access. Verify the fix by attempting to call 'restore-access' with a non-admin token and confirming it returns a 403 Forbidden error.

Evidence

// gramatr-allow: c1

const API_KEY_LEGACY = process.env['GMTR_API_KEY'] || '';

const API_KEY = API_KEY_PRIMARY || API_KEY_LEGACY;

const cliEnv = { home: HOME_DIR, serverUrl: SERVER_URL, apiKey: API_KEY };

// ---- Config helpers --------------------------------------------------------

function getServerBase() {

    return cliEnv.serverUrl.replace(/\/mcp\/?$/, '');

RemediationAI

The problem is that adminFetch() uses a module-level API_KEY credential loaded at import time from process.env, which means all requests use the same static credential regardless of the actual caller's identity or permissions. Replace the static API_KEY with a per-request credential by accepting the caller's token as a parameter to adminFetch() and passing it in the Authorization header instead of using process.env['GMTR_API_KEY']. This ensures each API call is authenticated as the actual caller, not as a shared service account. Verify the fix by logging the Authorization header in adminFetch() and confirming it contains the caller's token, not a static service key.

Evidence

export async function readInteractive() {

    log('');

    log('Paste your gramatr API key below.');

    log('(keys usually start with sk_)');

    log('');

    process.stdout.write('  Key: ');

    const rl = createInterface({ input: process.stdin, output: process.stdout });

RemediationAI

The problem is that validateAgainstServer() accepts a user-supplied API key and validates it against the server without verifying that the caller is authorized to use that key (i.e., the key belongs to the caller). Add an authorization check that compares the key's owner (extracted from the server response or a key metadata store) against the caller's identity before accepting the key as valid. This prevents users from validating or using API keys that belong to other users. Verify the fix by attempting to validate an API key belonging to a different user and confirming the validation fails with a 403 Forbidden error.

Evidence

#!/usr/bin/env node

import { existsSync, unlinkSync } from 'fs';

import { join } from 'path';

import { getGramatrDirFromEnv, getHomeDir } from '../config-runtime.js';

RemediationAI

The problem is that clearAll() deletes sensitive files (~/.gramatr.json and settings.json) without documenting this destructive side effect in the function signature or JSDoc comment. Add a JSDoc comment above the clearAll() function that explicitly states `@side-effect Deletes ~/.gramatr.json and settings.json from the filesystem` and rename the function to something more explicit like `clearAllCredentialsAndSettings()` to signal the destructive behavior. This makes the impact visible to callers and code reviewers. Verify the fix by checking that the JSDoc renders correctly in your IDE and that the function name clearly indicates file deletion.

Evidence

#!/usr/bin/env node

import { chmodSync, existsSync, readFileSync, writeFileSync } from 'fs';

import { join } from 'path';

import { createInterface } from 'readline';

RemediationAI

The problem is that writeKey() writes credentials to ~/.gramatr.json without documenting this filesystem side effect in the function signature or JSDoc comment. Add a JSDoc comment above writeKey() that explicitly states `@side-effect Writes API key to ~/.gramatr.json with restricted permissions (0600)` so callers understand the impact. This makes the side effect visible to code reviewers and maintainers. Verify the fix by checking that the JSDoc renders correctly in your IDE and that the filesystem operation is documented.

Evidence

#!/usr/bin/env node

import { chmodSync, copyFileSync, existsSync, mkdirSync, readFileSync, rmSync, writeFileSync, } from 'node:fs';

import { execFileSync } from 'node:child_process';

import { dirname, join, resolve } from 'node:path';

RemediationAI

The problem is that buildMcpb() performs multiple filesystem side effects (ensureDir, writeManifest, copyRuntimeFiles, buildArchive) without documenting them in the function's JSDoc comment. Add a JSDoc comment above buildMcpb() that explicitly states `@side-effect Creates directories, writes manifest files, copies runtime files, and builds archive to disk` so callers understand the full scope of effects. This makes the impact visible to code reviewers and maintainers. Verify the fix by checking that the JSDoc renders correctly in your IDE and that all filesystem operations are documented.

Evidence

/**

 * brain — CLI subcommand for bulk file upload to the grāmatr brain.

 *

 * Reads local files (txt, md, csv, pdf, docx) and uploads them to the server

RemediationAI

The problem is that the brain upload tool description does not fully disclose that it performs network side effects (callTool invokes bulk_upload MCP tool) and filesystem side effects (writeManifestAtomic writes manifest files). Update the tool description in brain.js to explicitly state `Reads local files and uploads them to the server via bulk_upload MCP tool; writes manifest files to disk` so callers understand the full scope of effects. This makes the impact visible to code reviewers and MCP clients. Verify the fix by checking that the tool description in the MCP manifest includes both network and filesystem side effects.

Evidence

#!/usr/bin/env node

import { chmodSync, existsSync, readFileSync, writeFileSync } from 'fs';

import { join } from 'path';

import { createInterface } from 'readline';

RemediationAI

The problem is that writeKey() writes credentials to ~/.gramatr.json without documenting this filesystem side effect in the function signature or JSDoc comment. Add a JSDoc comment above writeKey() that explicitly states `@side-effect Writes API key to ~/.gramatr.json with restricted permissions (0600)` so callers understand the impact. This makes the side effect visible to code reviewers and maintainers. Verify the fix by checking that the JSDoc renders correctly in your IDE and that the filesystem operation is documented.

Evidence

/**

 * brain — CLI subcommand for bulk file upload to the grāmatr brain.

 *

 * Reads local files (txt, md, csv, pdf, docx) and uploads them to the server

 * via the `bulk_upload` MCP tool. The server is the single source of truth

 * for validation, idempotency (sha256-based dedup), virus scanning (ClamAV),

 * and entity/observation creation. The CLI is a thin wrapper.

 *

 * Migrated in epic #1904 PR 3 from the legacy `create_entity` + `add_observation`

 * chain. The orphan-fix that PR 1 added to

RemediationAI

The problem is that brain upload reads untrusted file content from the local filesystem and ships raw bytes to the server without clear provenance delimiters or validation, making it difficult to trace which uploaded content came from which file or to detect tampering. Wrap each uploaded file's content with explicit provenance markers (e.g., `[FILE: filename.txt START] <content> [FILE: filename.txt END]`) and include file metadata (hash, size, timestamp) in the upload payload so the server can validate and audit the source. This ensures uploaded content is traceable and tamper-evident. Verify the fix by uploading a test file and confirming the server response includes the provenance markers and file metadata.

Evidence

"vitest": "^4.0.18"

  },

  "scripts": {

    "postinstall": "node scripts/postinstall.mjs",

    "build": "tsc --build && node ./scripts/build-marketplace.mjs",

    "build:binary": "node ./scripts/build-binary.mjs",

    "build:marketplace": "node ./scripts/build-marketplace.mjs",

RemediationAI

The problem is that package.json declares a postinstall hook that runs arbitrary code (node scripts/postinstall.mjs) whenever the package is installed, which poses a supply-chain risk if the script is compromised or contains unintended side effects. Review the contents of scripts/postinstall.mjs to confirm it is necessary; if it only performs optional setup (e.g., optional build steps), move it to a separate setup script that users must explicitly invoke (e.g., `npm run setup`) instead of running automatically. If the hook is truly necessary, add a clear comment in package.json explaining why and document all side effects in the script. Verify the fix by removing the postinstall hook, reinstalling the package, and confirming the package still functions correctly.

Evidence

# @gramatr/mcp

Intelligence middleware for AI agents by [gramatr](https://gramatr.com).

Pre-classifies every request, injects relevant memory and behavioral context,

enforces data quality, and maintains session continuity across Claude, ChatGPT,

Codex, Cursor, Gemini, and any MCP-compatible client.

## Quick Install (Claude Code)

```bash

npx @gramatr/mcp install

```

Idempotent. Safe to re-run for upgrades. Configures everything in one shot:

1. **Auth check** — runs device-flow login if `~/.

RemediationAI

The problem is that the MCP manifest does not declare an authentication mechanism, making it unclear whether the server relies on network-layer auth, host-level auth, or API keys, which blinds security reviewers. Add an explicit `auth` field to the MCP manifest (e.g., `"auth": {"type": "apiKey", "location": "header"}` or `"auth": {"type": "bearer"}`) that documents the real authentication mechanism used by the tools. This makes the security model visible to reviewers and MCP clients. Verify the fix by checking that the MCP manifest includes an auth field and that it accurately describes how the server authenticates requests.

Evidence

stdio: "inherit",

      timeout: 300000, // 5 min — enough for OAuth browser flow

    });

  } catch {

  }

}

main().catch(() => process.exit(0));

RemediationAI

The problem is that the catch block in scripts/postinstall.mjs silently swallows exceptions with no logging, metrics, or trace, which blinds incident response and hides real failures during package installation. Replace the empty catch block with `catch (err) { console.error('postinstall failed:', err); process.exit(1); }` to log the error and exit with a non-zero status, ensuring installation failures are visible and the package installation fails cleanly. This makes failures visible to users and CI/CD systems. Verify the fix by intentionally causing an error in the postinstall script and confirming the error is logged and the installation fails.