This server exposes secret-scanning capabilities as MCP tools, allowing AI assistants to scan various platforms and filesystems for leaked credentials and secrets.
Scanning
Jira — Scan tickets for leaked secrets, with JQL query scoping and optional auto-posting of warning comments
Confluence — Scan pages using CQL query scoping
Slack — Scan channels using a bot token
GitHub — Scan repositories with optional branch/repo filtering
GitLab — Scan projects, including self-hosted instances
Zendesk — Scan tickets for leaked secrets
Linear — Scan issues for leaked secrets
Asana — Scan tasks with optional workspace/project scoping
Wrike — Scan tasks with optional folder/space scoping
Local filesystem — Scan a local path, with support for custom regex rules
Monitoring & Analysis
Check scan status — Monitor progress of a running scan via its UUID
Get scan findings — Retrieve paginated, severity-filterable findings from completed scans
Analyze reports — Queue async AI-powered credential validation on scan results (requires n0s1 Professional)
Other features: Multiple report formats (n0s1, sarif, gitlab), credentials passable as tool arguments or environment variables, and custom UUID assignment for scan reports.
Scan Asana tasks for leaked secrets, including task details and attachments.
Scan Confluence pages for leaked secrets, including page content and attachments.
Scan GitHub repositories for leaked secrets, including code, issues, and pull requests.
Scan GitLab projects for leaked secrets, including code, issues, and merge requests.
Scan Jira tickets for leaked secrets using the n0s1 engine, including ticket contents and metadata.
Scan Linear issues for leaked secrets, including issue descriptions and comments.
Scan Slack channels for leaked secrets, including messages and files.
Scan Zendesk tickets for leaked secrets, including ticket comments and attachments.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@n0s1-mcp Scan the GitHub org mycompany for exposed API keys"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes n0s1 secret-scanning capabilities as tools for AI assistants (Claude, Cursor, etc.).
Scan Jira, Confluence, Slack, GitHub, GitLab, Zendesk, Linear, Asana, Wrike, and local filesystems for leaked secrets — directly from your AI workflow.
No install required. Add this to your MCP client config and run via uvx:
{
"mcpServers": {
"n0s1": {
"command": "uvx",
"args": ["n0s1-mcp"]
}
}
}For Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
For Claude Code: .claude/mcp.json in your project, or ~/.claude/mcp.json globally.
Related MCP server: vibescan-mcp-server
Tool | Description | Required params |
| Scan Jira tickets |
|
| Scan Confluence pages |
|
| Scan Slack channels |
|
| Scan GitHub repositories |
|
| Scan GitLab projects |
|
| Scan Zendesk tickets |
|
| Scan Linear issues |
|
| Scan Asana tasks |
|
| Scan Wrike tasks |
|
| Scan local filesystem |
|
| Get status of a running/completed scan |
|
| Get paginated findings for a completed scan |
|
| Submit or advance async AI credential validation |
|
All scan_* tools accept these optional parameters:
Parameter | Description |
| UUID to assign to the scan report. When set, overrides the auto-generated UUID written to the report JSON. |
| Queue async AI credential validation after the scan (requires n0s1 Professional) |
| n0s1 API key; overrides |
| Allow encrypted secrets to be uploaded to the n0s1 backend (default: |
Pass wait_minutes to analyze_report (or directly on a scan tool alongside ai_analysis) to block until analysis completes.
Credentials can be passed as tool arguments or pre-set as environment variables:
Variable | Used by |
| All scan tools with |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example with env vars pre-configured:
{
"mcpServers": {
"n0s1": {
"command": "uvx",
"args": ["n0s1-mcp"],
"env": {
"GITHUB_TOKEN": "ghp_...",
"JIRA_TOKEN": "ATATT..."
}
}
}
}Once connected, ask your AI assistant:
"Scan my Jira project SEC for leaked secrets"
"Check the GitHub org mycompany for exposed API keys"
"Scan the /home/user/project directory for secrets"
"Run an AI analysis on the scan report abc123"
For full parameter reference and AI analysis workflow details, see docs/ai.md.
pip install hatch
hatch build
hatch publishGNU General Public License v3 — same as n0s1.
Submit or advance async AI credential validation for a previously uploaded scan report. Side effects: sends live HTTP validation requests to check whether discovered credentials are still active — this contacts the services where the secrets were found. Auth: requires n0s1_api_key or N0S1_TOKEN env var (n0s1 Professional account). Call once to queue, then poll until ai_analysis_status is 'complete' or 'failed'. Pass report_file when status is 'waiting_client' to inject credentials into validators. Pass wait_minutes to block until a terminal state or timeout; returns ai_analysis_status='timeout' if the deadline is reached without completion.
| Name | Required | Description | Default |
|---|---|---|---|
| report_uuid | Yes | UUID returned by a scan_* tool or a previous analyze_report call | |
| n0s1_api_key | No | n0s1 API key (or set N0S1_TOKEN env var) — required for AI analysis | |
| report_file | No | Path to local report JSON file — required when status is 'waiting_client' | |
| wait_minutes | No | Poll the backend every 30 s until a terminal state or this many minutes elapse. Returns ai_analysis_status='timeout' if the deadline is reached. |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| ai_analysis_status | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses significant behavioral details beyond sparse annotations: live HTTP validation requests contacting external services, authentication requirements, polling behavior, and timeout return. No contradiction with annotations (readOnlyHint=false is consistent with side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with multiple well-structured sentences; information is front-loaded with primary action. Packed but efficient, though could be slightly improved with bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, side effects, authentication, multiple parameters), the description covers all necessary aspects for correct usage, including progression states, return behavior, and prerequisites. Output schema exists, so return format documentation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are covered in schema (100% coverage), but description adds actionable context: conditional use of report_file, blocking semantics of wait_minutes, and source of report_uuid. This adds value beyond bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool submits or advances async AI credential validation for previously uploaded scan reports, with specific verb ('submit or advance'), resource ('async AI credential validation'), and scope. It distinguishes from sibling scan tools that collect data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage steps: call once to queue, poll until complete, pass report_file when status is 'waiting_client', use wait_minutes to block. Context is clear but lacks explicit exclusions or direct comparison to alternatives like get_scan_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a paginated list of findings for a completed scan. Read-only with no side effects. All secret values are redacted — raw secrets are never returned. Pass next_cursor from a previous response to retrieve subsequent pages.
| Name | Required | Description | Default |
|---|---|---|---|
| report_uuid | Yes | UUID returned by the originating scan_* call | |
| page | No | Opaque cursor from a previous response (omit for first page) | |
| severity | No | Filter findings to this severity level |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| findings | Yes | |
| next_cursor | No | |
| total | Yes | |
| usage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces the readOnlyHint annotation with 'Read-only with no side effects' and adds critical info about secret redaction and pagination behavior, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three lean sentences: purpose, side effects, and key behavioral detail (redaction + pagination). Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, read-only guarantee, redaction, and pagination. Could mention what happens if scan is not completed, but output schema likely handles error cases. Largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-defined in the schema. Description only paraphrases the pagination cursor behavior, adding no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a paginated list of findings for a completed scan, using a specific verb and resource. The name and context distinguish it from sibling tools that initiate scans or check status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the tool is for completed scans and mentions pagination with next_cursor, but does not explicitly compare to sibling tools like analyze_report or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current status of a previously started scan. Read-only with no side effects — queries in-process scan state only. Returns 'pending' if the report_uuid is not yet known.
| Name | Required | Description | Default |
|---|---|---|---|
| report_uuid | Yes | UUID returned by the originating scan_* call |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| progress_pct | No | |
| error | No | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by clarifying it queries in-process state only and explaining the return value for unknown UUIDs ('pending'). This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds value with no redundancy. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers behavioral details (read-only, pending status). No gaps apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'report_uuid' is fully described in the schema. The description's reference to 'previously started scan' adds context but does not provide additional meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return the current status of a previously started scan,' clearly identifying its purpose of querying scan status. This distinguishes it from sibling tools that initiate scans (scan_*) or retrieve findings (get_scan_findings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used after starting a scan, but does not explicitly state when to use this tool versus alternatives like analyze_report or get_scan_findings. No guidance on conditions where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Asana tasks and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Asana — no tasks or comments are written. Auth: requires an Asana personal access token; set ASANA_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Asana API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Asana personal access token (or set ASANA_TOKEN env var) | |
| scope | No | Workspace or project scope filter | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool never modifies Asana (read-only), but the annotations set readOnlyHint to false, indicating it is not read-only. This is a direct contradiction, making the description unreliable for behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and covers key details concisely. It could be broken into sections for easier scanning, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers auth, side effects, return format (redacted), and rate limits. An output schema exists but the description does not reference it. Given the tool's complexity and 8 parameters, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. The tool description adds context beyond the schema, such as explaining the purpose of allow_secret_upload and show_matched_secret_on_logs, and how api_key can be set via env var.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads Asana tasks/comments to detect leaked secrets, and explicitly says it never modifies Asana. This differentiates it from sibling scanner tools for other platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (scan Asana for secrets) and what not to do (never modifies). Auth requirements and side effects are mentioned, but it does not explicitly compare with sibling scanners.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Confluence pages and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Confluence — no pages or comments are written. Auth: requires CONFLUENCE_TOKEN (falls back to JIRA_TOKEN) and CONFLUENCE_EMAIL (falls back to JIRA_EMAIL) env vars, or pass api_key/email directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Confluence API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Confluence server URL e.g. https://company.atlassian.net | |
| Yes | Confluence user email (or set CONFLUENCE_EMAIL / JIRA_EMAIL env var) | ||
| api_key | Yes | Confluence API token (or set CONFLUENCE_TOKEN / JIRA_TOKEN env var) | |
| scope | No | CQL query e.g. cql:space=SEC and type=page | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all behavioral traits: it explicitly states the tool never modifies Confluence, details authentication requirements, describes side effects (uploading redacted/encrypted data to backend), mentions rate limits, and explains data handling (redacted output, no raw secrets). This goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) and adds significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that front-loads the purpose and safety, then covers auth, side effects, and optional behaviors. It is concise but includes necessary details; a minor improvement could be breaking it into bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, external APIs, side effects), the description covers all essential context: authentication, safety (no modification), side effects (backend upload), data protection (redaction), rate limits, and optional features. The presence of an output schema means return values don't need to be detailed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, each parameter already has a description. The tool description adds extra meaning by explaining fallback logic for auth parameters and grouping related options (e.g., allow_secret_upload, ai_analysis). This provides context beyond the schema, warranting a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read Confluence pages and comments to detect leaked secrets (API keys, tokens, passwords).' It uses a specific verb (read), target resource (Confluence pages/comments), and goal (detect secrets), differentiating it from other scan_ tools by naming Confluence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it specifies authentication methods (env vars or direct params), declares it never modifies Confluence, and mentions side effects (upload to backend). However, it does not explicitly state when to use this tool over alternative scanning tools, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read GitHub repository code, issues, and pull requests to detect leaked secrets. Never modifies GitHub — no commits, comments, or PRs are created. Auth: requires a personal access token with repo (or public_repo) scope; set GITHUB_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to GitHub API rate limits (5,000 req/hr authenticated).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | GitHub personal access token with repo scope (or set GITHUB_TOKEN env var) | |
| owner | Yes | GitHub org or user name | |
| repo | No | Repository name (optional — omit to scan all repos for owner) | |
| branch | No | Branch to scan (optional — defaults to default branch) | |
| scope | No | Search query e.g. search:org:myorg | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects beyond annotations: uploading a redacted report to n0s1 backend, optional AES-encrypted upload, and rate limits. It also confirms no modifications to GitHub. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single paragraph that front-loads the purpose. Every sentence adds value, covering what the tool does, what it doesn't do, authentication, side effects, and limitations. No unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers input, authentication, side effects, rate limits, and the tool's role among siblings. It is sufficient for an agent to understand the tool's behavior and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3. The description adds value by clarifying authentication (api_key or env var), explaining the side effect of allow_secret_upload, and providing context for the report_format. However, it does not significantly elaborate on individual parameters beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads GitHub code, issues, and PRs to detect secrets. It explicitly says it never modifies GitHub, distinguishing it from write tools. Among sibling scan tools for different platforms, it uniquely identifies GitHub as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (detect secrets in GitHub) and specifies authentication requirements. While it doesn't provide explicit 'when not to use' or alternatives, the sibling tool names imply the context (other platforms), and the description is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read GitLab project code, issues, and merge requests to detect leaked secrets. Never modifies GitLab — no commits, comments, or MRs are created. Auth: requires a personal access token with read_api scope; set GITLAB_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to GitLab API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | GitLab personal access token with read_api scope (or set GITLAB_TOKEN env var) | |
| server | No | GitLab server URL (default: https://gitlab.com or GITLAB_URL env var) | |
| owner | Yes | GitLab group or user name | |
| repo | No | Project name (optional — omit to scan all projects for owner) | |
| branch | No | Branch to scan (optional — defaults to default branch) | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects (uploading redacted reports to n0s1 backend, optional encrypted upload) and notes API rate limits. However, there is a contradiction: annotations set readOnlyHint: false, but the description claims 'Never modifies GitLab'. This inconsistency hurts reliability for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, then covers safety, auth, side effects, and output. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and an output schema (not shown but available), the description covers essential aspects: purpose, read-only guarantee, auth, side effects, output format (redacted), and rate limits. It does not detail return values, but the output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter's description in the schema is detailed. The description adds little new semantic information beyond repeating authentication methods and side effects. It does not deepen understanding of individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans GitLab projects for leaked secrets, using specific verbs (Read, detect) and resource (GitLab project code, issues, MRs). It distinguishes itself from sibling tools that target other platforms (e.g., scan_github, scan_jira).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: for detecting secrets in GitLab. It notes the tool never modifies GitLab (read-only) and describes authentication requirements. It does not explicitly list when not to use or alternatives, but the sibling list implies other platform-specific scanners. The guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Jira tickets and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Jira — no comments are posted, no tickets are changed. Auth: requires JIRA_TOKEN and JIRA_EMAIL env vars, or pass api_key/email directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Jira API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Jira server URL e.g. https://company.atlassian.net | |
| Yes | Jira user email (or set JIRA_EMAIL env var) | ||
| api_key | Yes | Jira API token (or set JIRA_TOKEN env var) | |
| scope | No | JQL query e.g. jql:project = SEC | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits beyond annotations: it's read-only on Jira, uploads a report, optionally uploads encrypted secrets, respects rate limits, and never outputs raw secrets. No contradictions with annotations (readOnlyHint=false due to upload, but correctly labeled as non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is informative and front-loaded but slightly dense. Every sentence adds value, though a bulleted or structured format could improve readability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 params, output schema exists), the description covers auth, behavior, side effects, output characteristics, and rate limits. It provides enough context for correct agent invocation without needing to infer missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining that auth params can be env vars, clarifying allow_secret_upload (AES-encrypted upload for AI validation), and ai_analysis (async AI validation). These details are not in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads Jira tickets and comments to detect leaked secrets, with a strong verb-resource pairing ('Read Jira tickets...'). It distinguishes itself from sibling scan tools by specifying the platform (Jira) and the action (scanning for secrets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (to detect secrets in Jira) and when not (never modifies Jira). It provides authentication options (env vars or direct params) and mentions side effects. However, it does not explicitly compare with alternative tools or state exclusions for non-secret scanning use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Linear issues and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Linear — no issues or comments are written. Auth: requires a Linear personal API key (lin_api_...); set LINEAR_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Linear API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Linear personal API key (lin_api_...) (or set LINEAR_TOKEN env var) | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing side effects (upload of redacted report), authentication needs, and that findings are redacted. It confirms the tool is not destructive and is open-world, aligning with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and every sentence adds necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, side effects, output schema), the description covers all critical aspects: purpose, auth, side effects, output format, and rate limits. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the purpose of `allow_secret_upload` and the optional upload for AI validation. This extra context improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Linear issues/comments to detect leaked secrets. It specifies the resource (Linear) and action (scan for secrets), distinguishing it from sibling tools that target different platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides authentication requirements (Linear API key) and notes that the tool never modifies Linear. However, it does not explicitly guide when to use this tool over others, though sibling names make the platform distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a local filesystem path for leaked secrets (API keys, tokens, passwords). Fully local — no network calls, no data sent to any external service. Never modifies scanned files. No authentication required. Returns redacted findings — raw secret values are never included in the output.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_path | Yes | Absolute or relative path to scan | |
| regex_file | No | Path to custom regex YAML file (optional) | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds critical behavioral details beyond annotations: 'Never modifies scanned files', 'No authentication required', and 'Returns redacted findings — raw secret values are never included'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, locality, safety, and output redaction. Every sentence adds value. No redundant or unnecessary text. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively covers core behavior and safety. With an output schema available, return values are partially explained (redacted findings). It omits details about optional parameters like regex_file or show_matched_secret_on_logs, but these are in the schema. Adequate for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides. However, it summarizes the overall behavior (scan path, report format, etc.) without adding new semantic meaning for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a local filesystem for leaked secrets, listing specific secret types. It distinguishes itself from sibling tools that scan remote platforms (e.g., scan_github) by emphasizing 'Fully local — no network calls'. The action and resource are both specific and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when to use (local filesystem scanning), what it doesn't do (no network calls, no data sent externally), and prerequisites (no authentication required). It lacks an explicit comparison to siblings, but the 'local' distinction is evident from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Slack messages to detect leaked secrets (API keys, tokens, passwords). Never modifies Slack — no messages are posted or edited. Auth: requires a bot token with channels:history and channels:read scopes; set SLACK_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Slack API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Slack bot token with channels:history and channels:read scopes (or set SLACK_TOKEN env var) | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: non-modification of Slack, side effect of uploading reports and optionally encrypted secrets, auth requirements, redaction of raw secrets, and subject to Slack API rate limits. This adds substantial value beyond annotations (which indicate non-read-only, non-destructive, open-world). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with 6 sentences, each delivering key information: purpose, safety, auth, side effects, output behavior, and rate limits. It is front-loaded with the main action. Minor redundancy (auth details already in schema) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, output schema, multiple side effects), the description covers purpose, auth, side effects, output redaction, and rate limits. It does not explain the output schema but that is separate. The description is complete enough for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The tool description adds extra context: mentions that api_key can also be set via environment variable (schema says same), that ai_analysis requires n0s1 Pro (schema lacks that), and overall side effects. While parameters are well-documented, the description does not detail each one but provides overarching context that aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read Slack messages to detect leaked secrets' and resource 'Slack messages'. It explicitly distinguishes from sibling scan tools by focusing on Slack platform and emphasizes non-modification: 'Never modifies Slack — no messages are posted or edited.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (detecting secrets in Slack), auth requirements (bot token with specific scopes, env var or api_key), and side effects (upload to n0s1 backend). It does not explicitly state when not to use or name alternatives, but the sibling tools are for different platforms so it's clear this is for Slack only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Wrike tasks and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Wrike — no tasks or comments are written. Auth: requires a Wrike permanent access token; set WRIKE_TOKEN env var or pass api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Wrike API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Wrike permanent access token (or set WRIKE_TOKEN env var) | |
| scope | No | Folder or space scope filter | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently discloses read-only behavior on Wrike, upload side effects to n0s1 backend, AES encryption option, redacted output, and rate limits. This goes well beyond annotations (destructiveHint=false, openWorldHint=true) by explaining the actual side effects and security considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose, auth, side effects, and output behavior. It is front-loaded with the main action. Slightly more structured formatting (e.g., bullet points) could improve skimmability, but it is still concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (8 parameters, output schema exists, siblings are other platform scans), the description covers purpose, auth, side effects, rate limits, redacted output, and AI validation. It is complete without needing to repeat output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for 8 parameters, so baseline is 3. The description adds context for 'api_key' (set env var or pass directly) and 'allow_secret_upload' (AES encryption for AI validation), but does not elaborate on other parameters like 'scope' or 'report_format' beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Wrike tasks and comments to detect secrets. It specifies the resource (Wrike) and action (scan for leaked secrets), distinguishing it from sibling tools that scan other platforms like Asana, GitHub, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides auth instructions and states the tool does not modify Wrike, but it lacks explicit guidance on when to use this tool versus alternatives or when not to use it. Usage context is implied (e.g., for Wrike secret scanning), but no exclusions or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Zendesk tickets and comments to detect leaked secrets (API keys, tokens, passwords). Never modifies Zendesk — no tickets or comments are written. Auth: requires ZENDESK_TOKEN, ZENDESK_EMAIL, and ZENDESK_SERVER env vars, or pass server/email/api_key directly. Side effects: a redacted scan report is uploaded to the n0s1 backend; set allow_secret_upload=True to also upload AES-encrypted secret values for AI validation. Returns redacted findings — raw secret values are never included in the output. Subject to Zendesk API rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Zendesk subdomain e.g. mycompany.zendesk.com (or set ZENDESK_SERVER env var) | |
| Yes | Zendesk agent email (or set ZENDESK_EMAIL env var) | ||
| api_key | Yes | Zendesk API token (or set ZENDESK_TOKEN env var) | |
| report_format | No | Output report format | n0s1 |
| show_matched_secret_on_logs | No | Include redacted secret snippets in logs (default: false) | |
| ai_analysis | No | Queue async AI credential validation after the scan (requires n0s1 Pro) | |
| n0s1_api_key | No | n0s1 API key; overrides the N0S1_TOKEN env var | |
| allow_secret_upload | No | Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false) | |
| report_uuid | No | UUID to assign to the scan report; overrides the auto-generated one |
| Name | Required | Description |
|---|---|---|
| report_uuid | Yes | |
| status | Yes | |
| summary | Yes | |
| findings | No | |
| next_cursor | No | |
| usage | Yes | |
| ai_analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive but not read-only. The description adds critical context: side effects (uploading scan reports, optional encrypted secret upload), auth requirements, and rate limits. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences front-load the core purpose and non-modification. While informative, some details (auth, side effects) are mixed; room for minor tightening but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, required 3, output schema present), the description covers purpose, behavior, auth, side effects, and rate limits. Return format is handled by output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds value by explaining env var alternatives and the behavior of allow_secret_upload for AI validation, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read Zendesk tickets and comments to detect leaked secrets', specifying a specific verb and resource. It distinguishes itself from sibling tools like scan_github and scan_jira by focusing on Zendesk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it never modifies Zendesk and lists required auth credentials. While it doesn't explicitly state when not to use, the sibling list implies platform-specific targeting. Provides clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.6analyze_report1 field changedInput schema / properties / n0s1_api_key / descriptionPrevious value: -"n0s1 API key; overrides the N0S1_TOKEN env var"New value: +"n0s1 API key (or set N0S1_TOKEN env var) — required for AI analysis"scan_asana3 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Asana personal access token"New value: +"Asana personal access token (or set ASANA_TOKEN env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_confluence4 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Confluence API token"New value: +"Confluence API token (or set CONFLUENCE_TOKEN / JIRA_TOKEN env var)"Input schema / properties / email / descriptionPrevious value: -"Confluence user email"New value: +"Confluence user email (or set CONFLUENCE_EMAIL / JIRA_EMAIL env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_github6 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"GitHub personal access token"New value: +"GitHub personal access token with repo scope (or set GITHUB_TOKEN env var)"Input schema / properties / branch / descriptionPrevious value: -"Branch to scan (optional)"New value: +"Branch to scan (optional — defaults to default branch)"Input schema / properties / owner / descriptionPrevious value: -"GitHub org or user"New value: +"GitHub org or user name"Input schema / properties / repo / descriptionPrevious value: -"Repository name (optional, scans all repos if omitted)"New value: +"Repository name (optional — omit to scan all repos for owner)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_gitlab7 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"GitLab personal access token"New value: +"GitLab personal access token with read_api scope (or set GITLAB_TOKEN env var)"Input schema / properties / branch / descriptionPrevious value: -"Branch to scan (optional)"New value: +"Branch to scan (optional — defaults to default branch)"Input schema / properties / owner / descriptionPrevious value: -"GitLab group or user"New value: +"GitLab group or user name"Input schema / properties / repo / descriptionPrevious value: -"Project name (optional, scans all if omitted)"New value: +"Project name (optional — omit to scan all projects for owner)"Input schema / properties / server / descriptionPrevious value: -"GitLab server URL (default: https://gitlab.com)"New value: +"GitLab server URL (default: https://gitlab.com or GITLAB_URL env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_jira5 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Jira API token"New value: +"Jira API token (or set JIRA_TOKEN env var)"Input schema / properties / email / descriptionPrevious value: -"Jira user email"New value: +"Jira user email (or set JIRA_EMAIL env var)"Input schema / properties / post_commentRemoved value: -{
- "description": "Auto-post warning comments on findings",
- "type": "boolean"
-}Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_linear3 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Linear API key (lin_api_...)"New value: +"Linear personal API key (lin_api_...) (or set LINEAR_TOKEN env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_local1 field changedInput schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_slack3 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Slack bot token (xoxb-...)"New value: +"Slack bot token with channels:history and channels:read scopes (or set SLACK_TOKEN env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_wrike3 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Wrike permanent access token"New value: +"Wrike permanent access token (or set WRIKE_TOKEN env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"scan_zendesk5 fields changedInput schema / properties / allow_secret_upload / descriptionPrevious value: -"Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)"New value: +"Upload AES-encrypted secret values to the n0s1 backend for AI validation (default: false)"Input schema / properties / api_key / descriptionPrevious value: -"Zendesk API token"New value: +"Zendesk API token (or set ZENDESK_TOKEN env var)"Input schema / properties / email / descriptionPrevious value: -"Zendesk user email"New value: +"Zendesk agent email (or set ZENDESK_EMAIL env var)"Input schema / properties / server / descriptionPrevious value: -"Zendesk subdomain e.g. mycompany.zendesk.com"New value: +"Zendesk subdomain e.g. mycompany.zendesk.com (or set ZENDESK_SERVER env var)"Input schema / properties / show_matched_secret_on_logs / descriptionPrevious value: -"Show matched secret values in reports and logs (default: false)"New value: +"Include redacted secret snippets in logs (default: false)"v1.1.4analyze_report2 fields changedInput schema / properties / wait_minutesAdded value: +{
+ "description": "Poll the backend every 30 s until a terminal state or this many minutes elapse. Returns ai_analysis_status='timeout' if the deadline is reached.",
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Result returned by analyze_report.",
+ "properties": {
+ "ai_analysis_status": {
+ "title": "Ai Analysis Status",
+ "type": "string"
+ },
+ "message": {
+ "title": "Message",
+ "type": "string"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "ai_analysis_status",
+ "message"
+ ],
+ "title": "AnalysisStatus",
+ "type": "object"
+}get_scan_findings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Paginated findings list for an existing scan.",
+ "properties": {
+ "findings": {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "title": "Findings",
+ "type": "array"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "total": {
+ "title": "Total",
+ "type": "integer"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "findings",
+ "total",
+ "usage"
+ ],
+ "title": "FindingsPage",
+ "type": "object"
+}get_scan_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "Lightweight status check for an existing scan.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error"
+ },
+ "progress_pct": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Progress Pct"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status"
+ ],
+ "title": "Status",
+ "type": "object"
+}scan_asana4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_confluence4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_github4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_gitlab4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_jira4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_linear4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_local3 fields changedInput schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_slack4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_wrike4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}scan_zendesk4 fields changedInput schema / properties / allow_secret_uploadAdded value: +{
+ "description": "Allow encrypted secrets to be uploaded to the n0s1 backend (default: false)",
+ "type": "boolean"
+}Input schema / properties / report_format / descriptionAdded value: +"Output report format"Input schema / properties / report_uuidAdded value: +{
+ "description": "UUID to assign to the scan report; overrides the auto-generated one",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Finding": {
+ "description": "A single redacted secret finding.",
+ "properties": {
+ "file": {
+ "title": "File",
+ "type": "string"
+ },
+ "line": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line"
+ },
+ "redacted_match": {
+ "title": "Redacted Match",
+ "type": "string"
+ },
+ "severity": {
+ "$ref": "#/$defs/Severity"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "file",
+ "type",
+ "severity",
+ "redacted_match"
+ ],
+ "title": "Finding",
+ "type": "object"
+ },
+ "ScanSummary": {
+ "description": "Aggregate counts from a completed scan.",
+ "properties": {
+ "by_severity": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "propertyNames": {
+ "$ref": "#/$defs/Severity"
+ },
+ "title": "By Severity",
+ "type": "object"
+ },
+ "by_type": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "By Type",
+ "type": "object"
+ },
+ "total_findings": {
+ "title": "Total Findings",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_findings",
+ "by_severity",
+ "by_type"
+ ],
+ "title": "ScanSummary",
+ "type": "object"
+ },
+ "Severity": {
+ "enum": [
+ "info",
+ "low",
+ "medium",
+ "high",
+ "critical"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "Usage": {
+ "description": "Token-usage accounting block.",
+ "properties": {
+ "savings_pct": {
+ "title": "Savings Pct",
+ "type": "number"
+ },
+ "tokens_in_estimate": {
+ "title": "Tokens In Estimate",
+ "type": "integer"
+ },
+ "tokens_out_actual": {
+ "title": "Tokens Out Actual",
+ "type": "integer"
+ },
+ "tokens_saved_estimate": {
+ "title": "Tokens Saved Estimate",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tokens_in_estimate",
+ "tokens_out_actual",
+ "tokens_saved_estimate",
+ "savings_pct"
+ ],
+ "title": "Usage",
+ "type": "object"
+ }
+ },
+ "description": "Full result returned by every scan_* tool.",
+ "properties": {
+ "ai_analysis_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Analysis Status"
+ },
+ "findings": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/Finding"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Findings"
+ },
+ "next_cursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Next Cursor"
+ },
+ "report_uuid": {
+ "title": "Report Uuid",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "running",
+ "complete",
+ "failed"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/ScanSummary"
+ },
+ "usage": {
+ "$ref": "#/$defs/Usage"
+ }
+ },
+ "required": [
+ "report_uuid",
+ "status",
+ "summary",
+ "usage"
+ ],
+ "title": "ScanResult",
+ "type": "object"
+}v1.1.1analyze_reportget_scan_findingsget_scan_statusscan_asanascan_confluencescan_githubscan_gitlabscan_jirascan_linearscan_localscan_slackscan_wrikescan_zendeskScored across 13 tools
Each tool targets a distinct platform or function (scan, status, findings, analysis), with no overlap. The scan_* tools are clearly separated by platform name.
All tools follow a consistent verb_noun pattern in snake_case, e.g., scan_github, get_scan_status. No mixed conventions.
13 tools is well-scoped for a secret scanning server covering multiple integrations plus post-scan operations. Each tool has a clear purpose.
Covers scanning, status, findings, and analysis for many platforms. Missing tools for listing/deleting past scans or managing reports, but core workflow is complete.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Scan GitHub-hosted AI skills for vulnerabilities: prompt injection, malware, OWASP LLM Top 10.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
