n0s1-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.6
Disambiguation5/5
Each tool targets a distinct platform or function (scan, status, findings, analysis), with no overlap. The scan_* tools are clearly separated by platform name.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case, e.g., scan_github, get_scan_status. No mixed conventions.
Tool Count5/5
13 tools is well-scoped for a secret scanning server covering multiple integrations plus post-scan operations. Each tool has a clear purpose.
Completeness4/5
Covers scanning, status, findings, and analysis for many platforms. Missing tools for listing/deleting past scans or managing reports, but core workflow is complete.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![n0s1-mcp MCP server](https://glama.ai/mcp/servers/spark1security/n0s1-mcp/badges/card.svg)](https://glama.ai/mcp/servers/spark1security/n0s1-mcp)

Score Badge

Copy to your README.md:

[![n0s1-mcp MCP server](https://glama.ai/mcp/servers/spark1security/n0s1-mcp/badges/score.svg)](https://glama.ai/mcp/servers/spark1security/n0s1-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/spark1security/n0s1-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server