io.github.crunchtools/airlock

Official

by crunchtools

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation4/5
Most tools are clearly distinguished by mode (safe, quarantine, deep) and input type (inline, URL, file, search). However, 'deep_quarantine_scan_tool' and 'deep_scan_content_tool' have overlapping purposes, both performing deep analysis on raw content, which could cause confusion.
Naming Consistency4/5
Tool names follow a consistent prefix + action/content_type pattern (e.g., safe_fetch, quarantine_read). All use snake_case. Minor inconsistency: 'deep_quarantine_scan_tool' and 'deep_scan_content_tool' mix modes slightly, but overall naming is predictable.
Tool Count5/5
14 tools is well-suited for a security scanning server covering multiple input types (inline, URL, file, web) and operation modes (safe, quarantine, deep, scan-only). Each tool serves a distinct function, and the count feels neither sparse nor bloated.
Completeness5/5
The tool set comprehensively covers the domain: scanning, sanitizing, fetching, reading, searching, deep analysis, cache management, and stats. All common workflows (detect, sanitize, quarantine, diagnose) are supported. No obvious gaps for the stated purpose.
Average 4/5 across 14 of 14 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 93 commits in the last 12 weeks
- Last stable release on June 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states what is retrieved without mentioning permissions, side effects, or any operational constraints.
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 efficient sentence with no waste. It starts with the action verb 'Get', but is arguably too brief to provide full context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is adequate but does not elaborate on the structure or purpose beyond listing three items. It could be more informative about the summary nature of the output.
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?
There are no parameters, and the schema description coverage is 100% trivially. The description adds meaning by specifying the three data categories retrieved, which goes beyond the empty 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 uses a specific verb 'Get' and clearly identifies the three resources (trentina configuration, Q-Agent status, blocklist summary). It distinguishes this tool from sibling tools, which focus on scanning, fetching, reading, or searching quarantine or safe content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not provide context on appropriate use cases or when other sibling tools might be preferred.
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?
In the absence of annotations, description discloses important behavioral traits: L1 for stats, L2/L3 analyze raw content, and higher risk of Q-Agent compromise. This adds transparency beyond the schema.
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?
Description is concise with only a few sentences, each adding value. Could be slightly more streamlined, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are covered externally. Description covers key behavioral aspects but omits error conditions or prerequisites. Adequate for a simple 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 schema already documents both parameters. The description adds minimal new meaning beyond noting content is 'raw unsanitized', so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs a deep security scan on inline content, mentioning L1/L2/L3 levels and distinguishing from scan_content via cross-reference. However, it could more explicitly differentiate from similar sibling tools like quarantine_scan_tool.
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?
Provides context about L1/L2/L3 behavior and advises cross-referencing with scan_content for completeness, but lacks explicit when-to-use or when-not-to-use guidance relative to alternatives.
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?
With no annotations, the description fully covers behavior: pipeline stages (L0 to L3), return format (synthesized prose, source URLs, structured extraction with summaries and relevance scores), and a specific warning about classifier_warning indicating potential compromised content. This adds significant transparency.
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?
Description is concise (7 lines) and well-structured: purpose sentence, pipeline overview, output description, and warning. No extraneous information.
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 complexity (multi-stage pipeline) and presence of output schema, the description covers key aspects: pipeline flow, output format, and a critical warning. However, it does not explain the individual L stages or how this relates to siblings, which could be useful.
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 baseline is 3. The description does not add new parameter semantics beyond what the schema already provides (e.g., query, prompt, num_results are already documented in schema). No additional detail is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search the web with full quarantine pipeline' and explains pipeline stages, making the purpose specific. However, it does not explicitly differentiate from sibling safe_search_tool, which likely also performs search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like safe_search_tool. The description implies it's for searches needing quarantine, but no when-not or exclusion criteria are provided.
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?
With no annotations provided, the description bears full burden. It discloses that the tool 'proceeds on injection' (no blocking) and treats content as potentially manipulated when blocklist_warning is present. This is adequate behavioral context for an AI agent to anticipate outcomes.
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 concise, using two short paragraphs. The first sentence delivers the main function, and the second provides critical safety instructions. It is front-loaded and avoids redundancy, though the important note could be slightly more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and the critical injection warning. However, it lacks details about the return format of the Q-Agent extraction (despite an output schema existing) and does not elaborate on how the sanitization works or what constitutes 'inline content.' This leaves some completeness gaps for a tool with no annotations.
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 adds no extra meaning beyond the schema definitions for parameters like content, prompt, and content_type. The warning about response blocklist_warning is not parameter-specific.
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 function: 'Sanitize inline content + Q-Agent extraction.' This distinguishes it from sibling tools like scanning or fetching tools. The verb 'sanitize' and resource 'content' are specific, and the extraction purpose is explicit.
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 warns about injection and instructs how to handle blocklist_warning responses, but it does not specify when to use this tool versus alternatives like deep_quarantine_scan_tool or safe_content_tool. The guidance is limited to post-processing, not selection context.
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?
With no annotations, the description discloses key behaviors: quarantine extraction processing, text-only restriction, and the blocklist_warning signal. It does not mention error handling, non-text file behavior, or permission requirements, but the security warning adds significant transparency.
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 concise and well-structured, with a clear separation of the main purpose and an important security note. However, the warning section is slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence and context signals, the description covers the key extraction and security aspects. However, it lacks details on input validation (e.g., what happens if the file is not text) and error conditions, making it moderately 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% and both parameters are described in the schema. The description adds no additional meaning beyond what the schema provides, so baseline score applies.
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 a local file with full quarantine extraction (Layer 1 + Layer 2 Q-Agent), using specific verbs and resources. It distinguishes from siblings like safe_read_tool by emphasizing quarantine extraction and text-only restriction.
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 a constraint ('Text files only') and a security warning, but does not explicitly state when to use this tool vs alternatives like safe_read_tool or other quarantine tools. Usage context is implied but not differentiated.
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?
With no annotations provided, the description effectively discloses behavioral traits: sanitization layer, detection of injections, failure modes, and different handling for trusted vs untrusted domains. This adds significant value beyond the schema.
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 relatively concise, front-loading the core purpose. The trusted/untrusted distinction could be more compact, but there is no fluff or 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 the single parameter and presence of an output schema, the description provides sufficient behavioral context (sanitization, failure, domain handling) for an agent to understand usage. It does not need to detail return values due to output schema.
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% for the single 'url' parameter. The description adds security context but does not enhance the parameter's semantics (format, constraints) 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's action ('Fetch URL') and its special behavior ('Layer 1 sanitization', 'fails if injection detected'). It distinguishes itself from siblings like quarantine_fetch_tool by specifying the security layer and failure conditions.
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 context on when to use by differentiating trusted and untrusted domains, and mentions failure/blocking behavior. However, it does not explicitly state when not to use or suggest alternatives like deep_quarantine_scan_tool for deeper scanning.
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?
Without any annotations, the description carries the burden of behavioral disclosure. It states the action (flush caches) but does not mention potential side effects such as performance impact, cache rebuilding time, or whether the operation is safe to call frequently. The description is truthful but lacks depth in behavioral context.
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 extremely concise: two sentences that are front-loaded with the main purpose. Every sentence adds value with no wasted words. The structure clearly separates the default behavior from the variant with a backend.
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 low complexity (1 optional parameter, no required, output schema exists), the description covers all variations. It does not explain error handling (e.g., invalid backend name) but this is minor. Overall, it provides sufficient information for an AI agent to use the tool correctly.
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 the description adds minimal extra meaning beyond the schema. It restates that omitting the backend flushes all and providing a name flushes that backend. This matches the schema's default null. The description does not introduce new semantic information, so 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 clearly states the tool flushes gateway tool list caches, with a specific verb 'flush' and resource 'gateway tool list caches'. It distinguishes between flushing all caches (no args) and a specific backend, differentiating it from all sibling tools which are related to scanning and quarantine, not cache management.
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 guidance: no arguments flushes all caches, specifying a backend flushes only that backend. This helps the agent decide when to use each variant. However, it does not explicitly mention when not to use the tool or suggest alternatives, which would be helpful for a cache management tool.
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 that it runs three detection layers, uses SHA-256 for blocklist, and fails on injection. However, it does not explain what happens when content is safe (e.g., returned as-is or cleaned) or the exact failure mode, leaving some ambiguity.
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 three concise sentences, front-loaded with the core purpose, and contains no redundant information.
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 simple parameter structure and existence of an output schema, the description covers key behavioral aspects. It could be more explicit about usage context with siblings, but is 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% with parameter descriptions already present. The description adds high-level context (e.g., 'Always untrusted') but does not elaborate on parameter specifics 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's purpose: 'Sanitize inline content with all three layers' and specifies it fails on injection. It differentiates from sibling tools by focusing on sanitization with multiple detection layers and a blocklist hash.
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 implicitly guides when to use the tool (for sanitizing untrusted content) but does not explicitly exclude alternatives or compare to siblings like scan_content_tool or quarantine_content_tool.
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?
With no annotations, the description carries the full burden. It discloses the two-layer processing, the risk of prompt injection, and instructs the agent to treat extracted content as untrusted and not follow instructions. It does not cover other behaviors like error handling, but the critical safety behavior is well communicated.
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 consists of two concise sentences followed by a necessary warning block. It is front-loaded with the core action and use case. The warning is somewhat lengthy but justified by the importance of safety.
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 and the presence of an output schema, the description covers the essential aspects: purpose, usage context, and a critical safety warning. It does not detail error conditions or edge cases, but the provided information is sufficient for safe and effective use.
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% with both parameters described. The description adds no additional meaning beyond the schema for the 'url' and 'prompt' parameters, meeting 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 defines the tool's action (fetch URL with full quarantine) and its two layers (sanitization + Q-Agent extraction). It specifies the use case for untrusted content needing structured extraction despite risk, effectively differentiating it from safe siblings like safe_fetch_tool.
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 states when to use the tool (untrusted content) and provides an important warning about blocklist_warning. While it does not explicitly list when not to use or directly name alternatives, the context of sibling tools implies safe alternatives exist for trusted content.
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?
With no annotations provided, the description fully covers behavior: it explains the three-layer process (L1 sanitizes, L2 and L3 analyze), and states that no content is returned, only risk level, vector counts, and observations. This is good disclosure of what the tool does and does not do.
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 extremely concise: two sentences and a bullet list, all front-loaded with the core purpose. No superfluous information, every sentence earns its place.
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 existence of an output schema and the tool's moderate complexity, the description covers all needed context: what the tool does, how it works (three layers), and what it returns. No gaps identified.
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% with clear parameter descriptions. The tool description adds minimal extra value beyond the schema, such as mentioning 'inline content' but no additional detail on parameters. Baseline of 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 clearly states the tool performs a 'Three-layer security scan on inline content' and that it 'Returns threat assessment only', specifying the verb, resource, and output. It distinguishes from siblings by noting it only returns threat assessment and no content.
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: it scans inline content and returns only a threat assessment, implying it is for security evaluation. It does not explicitly state when not to use it or name alternatives, but the behavior is well-defined enough for an agent to infer appropriateness.
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?
No annotations provided, so description carries burden. It explains the two-layer approach (Layer 1 for stats, Q-Agent sees raw content), and explicitly states the risk of compromise. Does not mention if destructive, but likely read-only. Good transparency beyond 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?
Concise and front-loaded: first sentence states purpose, then explains layer details, then usage advice. No wasted words. Every sentence adds value.
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 complexity (deep scan with Q-Agent risk) and presence of output schema, description adequately covers the two-layer mechanism, risk tradeoff, and cross-reference advice. Could mention preconditions (e.g., if content must be quarantined), but overall sufficient.
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% with descriptions for both parameters. Description adds no additional context beyond what's in the schema (e.g., 'URL to scan (optional)' is already in schema). 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?
Clear verb ('analyze') and resource ('raw unsanitized content'). Specifies it's a deep diagnostic scan. Differentiates from sibling 'quarantine_scan_tool' by noting it runs on original content with higher risk but better detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'diagnostic deep-dives on suspicious content'. Includes caution about risk ('Higher risk of Q-Agent compromise') and advises cross-referencing with 'quarantine_scan' for completeness. No when-not, but implied.
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?
Despite no annotations, the description fully discloses behavioral traits: sanitization level (Layer 1), failure on injection, and file type constraints. This provides clear expectations for the 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?
Three brief sentences convey the tool's purpose, constraints, and failure mode with zero waste. Well structured and front-loaded.
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 one required parameter and an output schema (implied by context), the description is complete. Minor gap: could mention relation to sibling tools, but not essential.
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 input schema has 100% coverage with a single 'path' parameter. The description adds no additional meaning beyond what the schema already 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 a local file with Layer 1 sanitization, distinguishing it from siblings by specifying file type restrictions and injection failure handling.
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 implies usage for text files and rejection of binaries, suggesting when not to use it. However, it does not explicitly list alternatives among the many sibling tools.
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 details the safety pipeline (L0 through L2), including injection detection that causes failure. It also explains the return format (sanitized text + source URLs) and suggests follow-up actions. This is comprehensive without 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 five sentences, each adding value. It front-loads the core purpose, then explains the pipeline and output, and ends with a usage hint. No superfluous content.
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 (safety pipeline, injection detection) and the existence of an output schema, the description is largely complete. It could mention error handling for injection failures, but overall it provides sufficient context.
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?
Input schema has 100% coverage with clear descriptions for both parameters (query and num_results). The description does not add additional meaning beyond the schema, meeting the baseline.
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 tool name and description clearly state it performs web search with safety features. It distinguishes itself from siblings like quarantine_search_tool by specifying web search and returning sanitized text with source URLs.
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 suggests a workflow: search then use quarantine_fetch for full content. It does not explicitly state when to avoid this tool or contrast it with all siblings, but provides enough context for typical use.
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?
With no annotations, the description fully carries the transparency burden. It discloses that it does not return content, returns a threat assessment with risk level, vector counts, and Q-Agent observations, and always runs full detection. This is transparent, though it could mention if any state is modified or if authentication is required.
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 three sentences, no redundant words, and front-loads the purpose. Every sentence adds essential information: purpose, input constraint, output summary, and behavioral note.
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 simple 2-parameter schema with no required fields and the existence of an output schema, the description covers the tool's role (pre-flight scan), constraints, and return structure sufficiently. No critical gaps are apparent.
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?
The input schema has 100% description coverage, but the tool description adds the crucial constraint 'Provide either url or path (not both),' which is not in the schema. This adds meaningful behavioral semantics beyond the parameter 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 is a 'Pre-flight security scan' that detects injection vectors without returning content. The verb 'scan' and resources 'URL or path' are explicit, and the phrase 'without returning content' distinguishes it from siblings like scan_content_tool that may return scanned content.
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 gives explicit guidance: 'Provide either url or path (not both).' It also states it 'Always runs full detection regardless of trust level,' providing context for when it runs. However, it does not explicitly name alternative tools or scenarios when not to use it, leaving some inference required.
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:

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

Score Badge

Copy to your README.md:

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

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/crunchtools/mcp-trentina'

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