Public assessment

juanisidoro/securecode-mcp (@securecode/mcp-server)

securecode-mcp-server · v0.15.4 · scanned Aug 3, 2026

What changed in the harness

Selection accuracy 100→100, token cost up 6%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

25.0 / 30

25.0 out of 30

03Economics

19.1 / 20

19.1 out of 20

04Discoverability

11.6 / 20

11.6 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

12 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`get-secret`	no_return_description	Get a secret by its exact name, using tags to disambiguate when multiple secrets share that name. By default, writes the value to a local file so it never appears in the AI conversation and returns a confirmation that the secret was injected; set reveal:true to instead have the raw value returned in the conversation (audited as a conscious action). Set cleanup:true to remove all injected secret files from disk.
`create-secret`	name_restates_behavior no_return_description	Store a new secret value under a name so it can be retrieved later; secrets with the same name can coexist when they have different tags. Optionally attach a description, username, domain, and key/value tags, and set ttlHours to make the secret expire, or omit it for permanent storage. Returns a confirmation of the stored secret with its name and tags.
`renew-secret`	name_restates_behavior no_return_description	Reactivate an expired secret or change when it expires by setting a new ttlHours value; omit ttlHours to make the secret permanent, and pass tags to disambiguate when several secrets share the same name. Returns a confirmation with the secret's updated expiration status.
`delete-secret`	name_restates_behavior no_return_description	Remove a secret using a soft delete so it can be recovered afterward instead of being permanently destroyed; supply tags to disambiguate when multiple secrets share the same name. Returns a confirmation that the secret was removed.
`get-status`	no_return_description	Returns your account status as data: plan, usage limits, secrets count, and MCP server version. Useful to check remaining capacity and verify the server is up to date.
`wake-session`	no_return_description	Wake (unlock) the session to make secret access available, optionally restricting access to a specific tag scope and setting an inactivity auto-sleep timer with autoSleepMinutes. Returns the session status confirming it is awake and which scope is active.
`sleep-session`	no_return_description	Lock the session immediately so all secret access is blocked until it is woken again; use when you finish working. Returns confirmation that the session is now locked.
`session-status`	no_return_description	Returns the session status as data: whether it is active or sleeping, any applicable scope restrictions, and the time remaining before auto-sleep.
`byebye`	no_return_description	End the work session for the day: locks the session, cleans up all injected secret files from disk, and returns a goodbye message confirming the session ended.
`get-active-rules`	no_return_description	Returns the list of active MCP access rules so you can understand why a secret access was blocked; since rules can only be created or modified from the dashboard, this view is read-only.
`onboard`	no_return_description	Progresses the user through SecureCode setup — signup, .env import, API key creation, MCP configuration, and optional SDK setup — all from Claude Code; call multiple times to advance through the steps, using the action parameter to pick the step. Returns the next onboarding step's instructions or questions for the user.
`help`	no_return_description	Returns SecureCode documentation for the requested topic (all, tools, sdk, sessions, rules, import-export, or troubleshooting), covering available tools, usage patterns, SDK setup, and common workflows, so you can understand how to help the user with SecureCode.

Selection evidence

Confusable tool pairs.

7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`get-status`	`session-status`	medium	Both check 'status' but of different targets: get-status covers account/plan/usage while session-status covers active vs sleeping session. A task like 'check my current status' or 'how is my session doing' is ambiguous between them since only the shared 'status' keyword is salient.
`create-secret`	`update-secret`	medium	Setting or changing a secret value is naturally phrased as 'store this new key' or 'change my secret to this value'. If the secret already exists, update is correct; if not, create is. A task like 'I need to put my new API key in' doesn't disambiguate create vs update without checking existence first.
`import-env`	`export-env`	medium	Both handle secrets in .env format but in opposite directions. Tasks like 'give me my .env file' (export) versus 'load this .env into SecureCode' (import) are usually clear, but phrasing like 'sync my .env secrets' or 'I want to work with my .env' can select the wrong direction since import/export share the same env+secret tokens.
`get-secret`	`list-secrets`	low	A task phrased 'get all my secrets' or 'get my secrets for prod' could lead an agent to get-secret, but get-secret requires an exact name and list-secrets is described as enumerating secrets with tags and expiration, so the distinction is usually recoverable.
`create-secret`	`renew-secret`	low	For a task like 'I need a secret because my old one expired', an agent could pick create-secret to make a fresh secret instead of renew-secret which exists specifically to reactivate expired secrets; descriptions mostly disambiguate but the overlap on 'secret' plus a valid 'new secret' interpretation makes mild confusion possible.
`renew-secret`	`update-secret`	low	Both modify an existing secret, and a task like 'update my secret's expiration' or generically 'update this secret' could target update-secret (value/metadata) rather than renew-secret (TTL/expiration); renew's description naming TTL helps but a generic 'update the secret' request remains ambiguous.
`get-secret`	`get-status`	low	A user asking 'what is the status of my secret' or 'is my secret okay' could pull an agent toward either tool, since get-secret returns the value and get-status returns account-level info like secret counts; neither precisely returns a secret's health, so the wrong pick is plausible but unlikely given get-injection semantics.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard