PQC scanner for GitHub repos and smart contracts. Detects quantum-vulnerable ECDSA/RSA.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: instant algorithm check, repository scanning, smart contract scanning, and result retrieval. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (check_pqc_risk, get_scan_result, scan_contract, scan_repository), making them predictable and easy to understand.
With 4 tools, the set is concise yet covers key workflows: quick assessment, repository scan, contract scan, and result polling. No unnecessary tools.
The tools cover the main PQC scanning lifecycle: instant check, scan submission for repos and contracts, and result retrieval. Minor gap: no tool to list or manage scans, but core needs are met.
check_pqc_riskAInspectInstant check (no DB, no scan) — returns whether a list of algorithm names are quantum-vulnerable. Useful for quick risk assessment before calling scan_repository. Rate-limited: 100 calls/day per IP (free), 500/day per API key (paid).
| Name | Required | Description | Default |
|---|---|---|---|
| algorithms | Yes | Algorithm names, e.g. ["ECDSA", "RSA-2048", "ML-KEM-768"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is instant, does not use DB or scan, and states rate limits (100/day free, 500/day paid). This covers all key behavioral traits beyond what the input schema alone provides.
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 that are clear and front-loaded with the core purpose. Every sentence adds value (purpose, context, rate limits). No redundant or unnecessary 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 tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It explains the purpose, when to use (before scan_repository), and rate limits. All essential information is covered.
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 add meaning beyond the schema's parameter description, which already provides examples. No additional constraints or usage hints are given.
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's function: instantly checking if algorithm names are quantum-vulnerable. It uses a specific verb ('check'), identifies the resource ('list of algorithm names'), and distinguishes from siblings by mentioning 'before calling scan_repository'.
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 guides usage: 'Useful for quick risk assessment before calling scan_repository.' This provides context on when to use it versus scanning tools. However, it does not mention other siblings like get_scan_result or scan_contract, nor 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.
get_scan_resultAInspectGet the result of a previously submitted scan. Returns status (submitted | working | completed | failed) and, when completed, a full CBOM (Cryptographic Bill of Materials) compliant with EIP-7789 and CycloneDX CBOM 1.6, plus a quantum risk score (0 = fully safe, 100 = fully vulnerable). Rate-limited: 60 calls/min per IP or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | UUID returned by scan_repository |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses behavior: returns status and CBOM when completed, includes a quantum risk score scale, and specifies rate limits. No contradictions with missing 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?
Two concise sentences cover purpose, return values, and rate limits. No wasted words, effectively front-loaded.
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?
No output schema, but the description fully explains return values (status, CBOM, risk score) and constraints. Complete for a retrieval tool with one required parameter.
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 a clear description ('UUID returned by scan_repository'). The tool description does not add further parameter details beyond the schema, so baseline 3 applies.
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 retrieves results of a previously submitted scan, with explicit statuses and content (CBOM, quantum risk score). It differentiates from sibling tools like scan_repository (submit) and check_pqc_risk (different analysis).
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 usage after submitting a scan, and mentions rate limiting (60 calls/min). It does not explicitly state when not to use or list alternatives, but the context is clear for a retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_contractAInspectScan a verified on-chain smart contract for quantum-vulnerable cryptography AND today's fraud patterns (rug pulls, honeypots, uncapped mints, reentrancy). Use this BEFORE signing a transaction, interacting with a DeFi protocol, or integrating a contract into an agent workflow. Synchronous — result is immediate (no polling needed). Requires the contract to be verified on Sourcify (https://sourcify.dev). Returns risk score 0-100, agent risk score, finding breakdown, and concrete PQC migration steps. Rate-limited: same as scan_repository (10/day per IP free, credit-based paid).
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Chain ID. Default: 1 (Ethereum Mainnet). Supported: 1, 137 (Polygon), 42161 (Arbitrum One), 10 (Optimism), 8453 (Base), 56 (BNB Chain), 43114 (Avalanche C-Chain). | |
| contract_address | Yes | Ethereum-format contract address (0x + 40 hex chars). Example: 0xdAC17F958D2ee523a2206206994597C13D831ec7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the scan is synchronous (immediate result), requires a verified contract, and is rate-limited (same as scan_repository). It also summarizes the return values. This is good but could mention error scenarios (e.g., unverified contract).
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, each with a clear purpose: (1) what it does, (2) when to use, (3) synchronous nature and requirement, (4) outputs and rate limit. It is front-loaded and 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 the tool's complexity (quantum + fraud scan, two parameters, no output schema, no annotations), the description covers essential aspects: input requirements (verified contract on supported networks), synchronous behavior, output summary, rate limit. Minor gaps: no explanation of specific fraud patterns beyond examples, no error handling details, no mention of default network. Still, it is fairly 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 baseline is 3. The description adds no additional semantics for the parameters beyond what the schema already provides (contract_address, network with chain IDs). The description focuses on tool purpose and usage, not parameter details.
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 scans a verified smart contract for quantum-vulnerable cryptography and today's fraud patterns. It uses the specific verb 'scan' and resource 'verified on-chain smart contract', differentiating it from siblings like check_pqc_risk (likely only quantum) and scan_repository (code repos).
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 tells when to use the tool: 'BEFORE signing a transaction, interacting with a DeFi protocol, or integrating a contract into an agent workflow.' It also mentions the requirement of contract verification on Sourcify. However, it does not explicitly state when not to use or name alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_repositoryAInspectSubmit a GitHub, GitLab, or Bitbucket repository for post-quantum cryptography (PQC) vulnerability scanning. Returns a scan_id. Call get_scan_result to poll for the result. Free tier: 10 scans/day per IP. Paid tier: credit-based (register at /api/agent/register).
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | Full repository URL. Example: https://github.com/uniswap/v3-core |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a scan_id, requires polling, and has rate limits (10 scans/day free). 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 concise sentences. No filler. Front-loaded: action, input, return, next step, limits.
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 simple input (1 param, no output schema), the description covers submission, return value, polling workflow, and usage limits. Fully adequate.
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?
Only one parameter (repo_url) with 100% schema coverage. Description adds context that it supports multiple platforms (GitHub, GitLab, Bitbucket) and provides an example, going 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 submits a GitHub, GitLab, or Bitbucket repository for PQC vulnerability scanning, and distinguishes from siblings like 'check_pqc_risk' and 'scan_contract' by specifying the input type and workflow.
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 (submit a repo for scanning) and directs to call 'get_scan_result' for polling. Mentions free/paid tiers but does not explicitly differentiate from siblings like 'scan_contract'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
