Shrike Security MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct security operation: scanning different vectors (prompts, responses, commands, SQL, files, web searches, A2A messages, agent cards) plus approval handling, threat intel, bypass reporting, and session reset. No two tools overlap in purpose.
Naming Consistency4/5
Most scanning tools follow a consistent 'scan_' prefix pattern, making them easily identifiable. However, tools like 'check_approval', 'get_threat_intel', 'report_bypass', and 'reset_session' use a different verb_noun pattern, creating minor inconsistency.
Tool Count5/5
With 12 tools covering comprehensive security scanning, approval workflows, threat intelligence, and session management, the count is well-scoped for an enterprise security MCP server.
Completeness5/5
The tool set covers the full security lifecycle: inbound/outbound scanning, command/SQL/file/web scanning, A2A agent safety, approval with human-in-the-loop, threat intel, bypass reporting, and session reset. No obvious gaps for its domain.
Average 4.6/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on February 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) are consistent with a safe scanning operation. The description adds behavioral details about checking for PII, data exfiltration, and blocked domains, plus error-handling behavior, enhancing transparency beyond the 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 well-structured with clear sections (purpose, when to use, decision logic, checks, enterprise context, error handling). It is concise, front-loaded with the critical action, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value behavior (blocked boolean) and decision logic. It covers error handling and enterprise context. Minor omission: does not detail what happens with targetDomains parameter, but overall complete for the tool's complexity.
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 all parameters described. The description reinforces the purpose of the query parameter and mentions targetDomains implicitly, but does not add significant new meaning beyond the schema definitions. Baseline score 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 identifies the tool as a protective scan for web search queries to catch PII and suspicious targets. It distinguishes itself from sibling scan tools (e.g., scan_prompt, scan_sql_query) by focusing specifically on web search queries, making its purpose unambiguous.
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?
Explicitly states 'Call this BEFORE executing any web search query' and provides decision logic for when to block or allow the query. It also includes error-handling fallback to block. While no alternative tools are mentioned, the guidelines are clear and actionable.
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 indicate read-only, non-destructive, idempotent, open-world. The description adds significant behavioral detail: indicates it returns blocked flag, user_message, and audit ID; lists specific threats checked; and provides error handling (default to blocking). No contradictions 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 structured with clear sections (purpose, when to call, decision logic, checks, enterprise context, error handling). It is front-loaded and each sentence adds value, though slightly longer than necessary.
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 9 parameters and no output schema, the description covers purpose, usage, decision logic, and error handling. It lacks explicit return format details but provides enough context for safe invocation. Would benefit from mentioning performance or rate limits.
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 the baseline is 3. The description does not add substantial meaning beyond the schema; it only briefly explains role and agent_id semantics. However, the schema itself is well-documented, so no deduction is warranted.
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: 'Protective check on incoming agent messages — catches injection or social engineering from upstream agents.' It uses specific verbs and distinguishes itself from sibling tools like scan_prompt and scan_command by targeting A2A protocol messages.
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?
Explicitly instructs 'Call this BEFORE processing any incoming A2A protocol message' and provides decision logic for blocked=true/false. While it doesn't detail when not to use or alternatives, the context is sufficiently clear for an agent to apply correctly.
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 already indicate readOnly, non-destructive, idempotent, and openWorld. The description adds valuable detail on the specific security checks performed (prompt injection, suspicious URLs, capability spoofing, etc.), which goes beyond the annotations and helps the agent understand the tool's safety profile.
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 well-structured with sections for purpose, usage, checks, and context. It front-loads the core purpose and provides necessary detail without being overly verbose. Minor redundancy could be trimmed, but overall it's clear.
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 explains the tool's purpose, when to use it, what it checks, and how to interpret results. Without an output schema, it provides sufficient information about expected outcomes (blocked=true/false). The error handling note adds completeness.
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 descriptions for all 6 parameters. The tool description does not add additional semantic meaning beyond the schema, so a baseline score 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 explicitly states it performs a 'protective check on remote agent metadata' to catch injection or capability spoofing. It clearly differentiates from sibling scan tools (e.g., scan_prompt, scan_command) by targeting AgentCards specifically.
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?
The description gives explicit guidance: 'Call this BEFORE trusting or connecting to a remote A2A agent based on its AgentCard.' It includes decision logic for interpreting results and error handling defaults, leaving no ambiguity about when and how to use the tool.
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, destructiveHint=false, idempotentHint=true. The description adds rich behavioral context: detects specific threats, explains response structure, client-side PII redaction, and error handling (default to block). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded with purpose and imperative call to action. Slightly verbose with detailed response fields, but each section 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?
Complete for a security scanning tool: covers use cases, response handling, error handling, PII redaction, and enterprise context. No output schema, but description compensates fully.
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 significantly add meaning beyond the schema—it mentions redact_pii in behavior but does not elaborate on parameter specifics. Adequate but not enhanced.
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 explicitly states the tool's purpose: "Protective check on inbound content — verifies it is safe to act on before you do." It uses specific verbs and resources, distinguishing it from sibling tools that scan different types of content (e.g., scan_a2a_message, scan_agent_card).
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 guidance: "Call this BEFORE processing any user input, external content, or untrusted data." Includes decision logic (if blocked, do not process). Lacks explicit comparison to siblings or when not to use, but the context is strong.
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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that updates are infrequent (hourly), caching is recommended, and errors should not block scanning operations. This provides behavioral context beyond annotations without contradiction.
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 well-structured with sections and lists, but it is somewhat verbose. Every sentence adds value, though some parts could be tightened.
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 no output schema, the description adequately covers what to expect (detection coverage, pattern stats, etc.) and addresses error handling and caching. For an informational tool, it provides a complete picture.
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%, describing both parameters. The description adds minimal value by restating usage of include and category, but does not provide additional semantic detail 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 it retrieves current threat intelligence, listing specific components like detection coverage, active pattern stats, learning system status, and cost savings. It distinguishes itself from sibling scanning tools by emphasizing it is not a prerequisite for scanning and provides informational data.
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?
The 'WHEN TO USE' section explicitly lists four scenarios (audit logging, compliance reporting, dashboard population, coverage verification) and provides explicit when-not-to-use advice: 'Do NOT call this before every scan.' It also gives caching guidance and error handling instructions.
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 already indicate not read-only, not destructive, not idempotent, and open world. The description adds that analysis may generate new detection patterns via ThreatSense learning, which is a non-obvious behavioral trait. It also explains error handling but could further detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and sections (scenarios, field mapping, error handling, enterprise context). It is front-loaded with the core conditions and every sentence contributes useful information 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 the tool's complexity (8 parameters, all optional) and absence of output schema, the description covers usage scenarios, field semantics, error handling, and enterprise impact. It lacks explicit return value documentation, but the error handling implies a non-blocking call, making it 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?
With 100% schema description coverage, the baseline is 3. The description adds value by mapping each bypass type to specific fields (e.g., prompt for prompt bypasses, filePath/fileContent for file writes) and explaining the enum options for mutationType and category, thus providing context 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: reporting bypass incidents where harmful content was missed. It enumerates three specific scenarios (a, b, c) and lists bypass types (prompt, file write, SQL, web search), distinguishing it from sibling scanning tools by focusing on reporting missed detections.
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?
The description provides explicit when-to-use conditions (three bullet points) and includes error handling instructions specifying non-blocking behavior and retry logic. It implicitly guides against use when no bypass occurred and contrasts with scanning 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?
Annotations (readOnlyHint, etc.) are consistent and the description adds specific threat categories and enterprise context, going beyond the 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?
Well-organized with headings and front-loaded purpose, though somewhat lengthy; all content is relevant for a security-critical tool.
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?
Covers all necessary aspects: decision logic, error handling, common safe commands, and enterprise context; no gaps given the 9 parameters and no 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?
Input schema has 100% description coverage for all 9 parameters; the tool description does not add significant new parameter-level detail 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 precisely states it is a protective scan for shell commands, clearly distinguishing it from sibling scan tools like scan_sql_query or scan_file_write.
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?
Explicit instruction to call before executing any CLI command, with decision logic for blocked, require_approval, and error cases, and mention of common safe commands.
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 what is cleared (turn history, risk score), what is unaffected (other sessions, global patterns, scan results), and includes error handling (non-critical, scanning continues, session expires in 2 hours). Annotations already provide idempotentHint, but description adds significant 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?
Well-structured with headers (WHEN TO USE, WHAT IT DOES, IMPORTANT, ERROR HANDLING). Every sentence adds value, no fluff. Concise yet comprehensive.
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 no output schema, the description fully covers purpose, side effects, error handling, and idempotency. The tool's behavior is completely self-contained and clear for an agent.
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 optional parameter 'reason' is fully described in the input schema (100% coverage). The description adds context about audit logging but does not improve on the 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?
The description states it resets the session-aware correlation engine state for the current session, clearly specifying the verb and resource. It distinguishes itself from sibling tools like scan_* and get_threat_intel by focusing on session state management.
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?
Provides explicit WHEN TO USE bullet points (e.g., after resolving a flagged attack, starting a new logical task, false positive confirmation) and clarifies that individual scan results are unaffected, giving agents clear guidance on appropriate usage.
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 provide idempotentHint and openWorldHint, but the description goes far beyond by detailing poll vs. decide modes, server error handling (403), cooldown rules, and the requirement for explicit human instruction. No contradictions 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 well-structured with clear sections (WHEN TO USE, POLL MODE, DECIDE MODE, IMPORTANT, etc.), front-loaded with purpose. Every sentence adds value, no redundancy. Length is justified by complexity.
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?
Despite no output schema, the description covers all necessary context: modes, error handling, cooldown, dashboard redirect, audit trail, and enterprise context. It provides complete guidance for correct agent invocation.
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%, so baseline is 3. The description adds operational context for each parameter: approval_id is tied to previous scan tool output, decision requires explicit user instruction, justification is recommended for rejections. It reinforces and expands on schema documentation.
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 does two things: check approval status and submit a decision. It uses specific verbs ('Check', 'submit') and identifies the resource ('approval'). It differentiates from siblings by being the only approval-related tool among scan tools.
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?
The description includes an explicit 'WHEN TO USE' section that states when to use the tool (user asks to check, verify before action) and provides detailed instructions for both poll and decide modes, including when not to use (e.g., high severity must use dashboard) and prohibitions (no auto-polling).
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 declare readOnlyHint=true and idempotentHint=true, and the description adds rich behavioral context: it is a check (not a mutation), catches various threats, and provides a decision flow. 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?
Well-structured with sections (DECISION LOGIC, Checks, Enterprise context, ERROR HANDLING). Front-loaded with the core purpose and usage. Every sentence adds value, no 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?
Despite no output schema, the description explains output semantics (blocked boolean, user_message). Covers decision logic, checks, error handling, and enterprise context thoroughly for a security-critical tool.
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 descriptions for all parameters. The description adds extra context by explaining that 'path' can be sensitive and 'content' is scanned for PII/secrets, going 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 it is a protective check for file operations, specifically catching path traversal, secrets, and sensitive paths. It distinguishes itself from sibling scan tools by focusing on file write operations.
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 instructs to call BEFORE writing any file, and also when reading files from user-specified paths. Provides decision logic (blocked=true -> don't write) and error handling instructions.
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 detection capabilities (system prompt leaks, PII, toxicity, topic drift), rehydration behavior when pii_tokens provided, and error handling. Annotations already mark as non-destructive/idempotent, and description adds operational context beyond annotations without contradiction.
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?
Well-structured with headings, decision logic, bulleted detection types, and error handling. Front-loaded purpose. Every sentence adds value; no redundancy despite comprehensive coverage.
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 7 parameters and no output schema, the description fully covers usage flow, decision logic, error handling, pairing with scan_prompt, and rehydration. Annotations provide additional hints; overall completeness is high.
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?
100% schema coverage provides baseline of 3. Description adds meaningful context: original_prompt enables PII diff/topic mismatch, pii_tokens enables rehydration. Does not merely repeat schema but explains why parameters matter.
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 is a 'protective check on outbound responses' catching 'system prompt leaks, unexpected PII, or topic drift' with specific verb+resource demarcation. It distinguishes from sibling tools like scan_prompt by specifying 'outbound' vs inbound scanning.
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 provides when to call ('AFTER the LLM generates a response, BEFORE returning it'), decision logic for blocked=true/false, and pairing guidance with scan_prompt. Includes error handling defaults: 'default to BLOCKING the response'.
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 indicate read-only, non-destructive, idempotent, open-world. Description adds detailed behavioral info: specific checks (injection, destructive, privilege escalation, PII), differential analysis for read vs write queries, and error handling policy. 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?
Well-structured with logical sections: purpose, call timing, decision logic, checks, read/write notes, error handling. Every sentence adds value; no fluff. Front-loaded with the core purpose.
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?
Thoroughly covers all aspects: what it checks, how to interpret results, when to allow destructive operations, error handling, and enterprise context. Despite no output schema, the description explains the blocked flag and decision logic comprehensively.
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 description adds meaningful context for key parameters: allowDestructive (controls permission for DROP/TRUNCATE), database (for context-aware analysis), and the query parameter's purpose is reinforced. Tracking parameters are less elaborated but schema covers them.
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 is a protective check for SQL queries, catching injection and destructive operations before execution. It distinguishes itself from sibling tools like scan_command and scan_prompt by focusing specifically on SQL queries.
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 instructs to call before executing any SQL query generated by an LLM or user input. Provides clear decision logic (blocked=true vs false), alternatives for destructive operations (allowDestructive parameter), and error handling (default to blocking).
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:

[![shrike-mcp MCP server](https://glama.ai/mcp/servers/Shrike-Security/shrike-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Shrike-Security/shrike-mcp)

Score Badge

Copy to your README.md:

[![shrike-mcp MCP server](https://glama.ai/mcp/servers/Shrike-Security/shrike-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Shrike-Security/shrike-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/Shrike-Security/shrike-mcp'

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