The OWASP Agentic MCP server provides security assessment tools for AI agents, focused on the OWASP Top 10 for Agentic AI.
Full Agent Security Assessment (assess_agent_security): Comprehensive evaluation across 10 OWASP dimensions — input validation, output filtering, tool allowlists, least privilege, context isolation, action logging, inter-agent authentication, resource limits, dependency scanning, and alignment testing.
Prompt Injection Detection (check_prompt_injection): Analyze input text for known prompt injection attack patterns to identify manipulation attempts.
Tool Poisoning Detection (check_tool_poisoning): Inspect a tool's name, description, and source for signs of manipulation, including signature verification and trusted registry origin checks.
Excessive Agency Assessment (check_excessive_agency): Evaluate whether an agent has more permissions than necessary (least privilege violations), examining filesystem, network, code execution, data modification access, and tool usage ratios.
Data Leakage Risk Assessment (check_data_leakage): Assess cross-context data exposure risks, checking for context isolation, session boundaries, PII detection, output sanitization, and third-party data sharing.
All tools are read-only, stateless, and idempotent, with rate limits applying on the free tier (10/day) and unlimited usage on Pro.
Security assessment against the OWASP Top 10 for Agentic AI, providing tools to detect prompt injection, tool poisoning, excessive agency, and data leakage.
OWASP Top 10 for Agentic AI security MCP server — prompt injection detection, tool poisoning, exc...
OWASP Top 10 for Agentic AI security MCP server — prompt injection detection, tool poisoning, excessive agency, data leakage assessment
OWASP Top 10 for AI Agents Security Assessment — Prompt Injection, Tool Poisoning, Data Leakage
# Install via pip
pip install owasp_agentic_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install owasp-agentic-mcp --client claudeRelated MCP server: Agent Delegation MCP
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic →
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support
View Pricing → | Contact Sales →
This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT © CSOAI-ORG
Tool | Description | Parameters |
| Full OWASP Agentic Top 10 security scan |
|
| Assess against specific OWASP Agentic categories |
|
| Test for prompt injection vulnerabilities |
|
| Check for tool poisoning risks |
|
| Assess agency level vs minimum required |
|
pip install mcp{
"mcpServers": {
"owasp-agentic": {
"command": "python",
"args": ["path/to/server.py"]
}
}
}{
"agent_config": {
"system_prompt": "You are a helpful assistant that can access email, calendar, and file system.",
"allowed_tools": ["send_email", "read_calendar", "write_file"]
},
"permissions": ["email:send", "calendar:read", "files:write"]
}{
"system_prompt": "You are a financial advisor bot",
"user_input_template": "{user_query} Please provide investment advice."
}Free: 10 scans/day
Pro: $99/mo — unlimited scans + detailed reports
Enterprise: $499/mo — continuous monitoring + custom rules
Built by MEOK AI Labs | meok.ai
Tier | Price | What you get | Stripe |
Smoke test | £1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | £9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | £29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe — VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Full OWASP Agentic AI Top 10 security assessment.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. has_input_validation (bool): The has input validation to analyze or process. has_output_filtering (bool): The has output filtering to analyze or process. has_tool_allowlist (bool): The has tool allowlist to analyze or process. has_least_privilege (bool): The has least privilege to analyze or process. has_context_isolation (bool): The has context isolation to analyze or process. has_action_logging (bool): The has action logging to analyze or process. has_auth_between_agents (bool): The has auth between agents to analyze or process. has_resource_limits (bool): The has resource limits to analyze or process. has_dependency_scanning (bool): The has dependency scanning to analyze or process. has_alignment_testing (bool): The has alignment testing to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| has_input_validation | No | ||
| has_output_filtering | No | ||
| has_tool_allowlist | No | ||
| has_least_privilege | No | ||
| has_context_isolation | No | ||
| has_action_logging | No | ||
| has_auth_between_agents | No | ||
| has_resource_limits | No | ||
| has_dependency_scanning | No | ||
| has_alignment_testing | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers side effects (read-only, idempotent), authentication, rate limits, error handling, and data privacy in a structured 'Behavioral Transparency' section.
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?
Well-organized with sections, but contains redundancy (Behavior and Behavioral Transparency overlap) and overly repetitive parameter descriptions. Could be trimmed.
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?
Thorough coverage of behavior, usage, and transparency. Only weakness is weak parameter descriptions, but output schema exists and the overall context is 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 0%, so the description must compensate. However, the 'Args' section provides only minimal, repetitive descriptions like 'The has_input_validation to analyze or process.' that add little meaning beyond the parameter names.
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 starts with 'Full OWASP Agentic AI Top 10 security assessment', a clear verb+resource. It distinguishes from sibling tools like check_data_leakage by being an overall assessment.
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?
Has explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts and a caveat against real-time use without human review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess cross-context data exposure risks.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. has_context_isolation (bool): The has context isolation to analyze or process. has_session_boundaries (bool): The has session boundaries to analyze or process. has_pii_detection (bool): The has pii detection to analyze or process. has_output_sanitization (bool): The has output sanitization to analyze or process. shares_memory_across_users (bool): The shares memory across users to analyze or process. logs_contain_user_data (bool): The logs contain user data to analyze or process. third_party_data_sharing (bool): The third party data sharing to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| has_context_isolation | No | ||
| has_session_boundaries | No | ||
| has_pii_detection | No | ||
| has_output_sanitization | No | ||
| shares_memory_across_users | No | ||
| logs_contain_user_data | No | ||
| third_party_data_sharing | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers extensive behavioral details: read-only, stateless, idempotent, authentication requirements, rate limits, error handling, and data privacy. This fully informs the agent of the tool's behavior.
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 well-organized into sections (Behavior, When to use, Args, Behavioral Transparency) and front-loaded with the purpose. However, there is some redundancy between the Behavior section and the later Behavioral Transparency details, and the Args section is lengthy with low-value content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, presence of output schema), the description covers all necessary aspects: purpose, usage guidelines, behavioral traits, parameters, and error handling. It provides sufficient information for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides one-line descriptions for each of the 10 parameters, but these are mostly tautological (e.g., 'The agent name to analyze or process') and do not add meaningful semantics beyond the schema's titles and types. With 0% schema description coverage, the description should compensate but fails to do so effectively.
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 starts with 'Assess cross-context data exposure risks', a specific verb+resource that clearly indicates the tool's function. It distinguishes from sibling tools like assess_agent_security and check_excessive_agency, which focus on other security aspects.
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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear context for invocation. It advises against real-time production use without human review, but does not directly compare with sibling tools, reducing the score from perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess agent for excessive permissions (least privilege).
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. tools_available (int): The tools available to analyze or process. tools_used_in_task (int): The tools used in task to analyze or process. has_approval_gates (bool): The has approval gates to analyze or process. has_scope_limits (bool): The has scope limits to analyze or process. can_access_filesystem (bool): The can access filesystem to analyze or process. can_access_network (bool): The can access network to analyze or process. can_execute_code (bool): The can execute code to analyze or process. can_modify_data (bool): The can modify data to analyze or process. can_send_communications (bool): The can send communications to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| tools_available | No | ||
| tools_used_in_task | No | ||
| has_approval_gates | No | ||
| has_scope_limits | No | ||
| can_access_filesystem | No | ||
| can_access_network | No | ||
| can_execute_code | No | ||
| can_modify_data | No | ||
| can_send_communications | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly covers read-only, stateless, idempotent, rate limits (10/day free, unlimited pro), authentication (none required for basic), error handling (structured errors), and data privacy (no storage). All key behavioral traits disclosed.
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?
Well-structured with clear sections (Behavior, When to use, etc.), but contains redundancy (e.g., behavior info repeated in both 'Behavior' and 'Behavioral Transparency'). Could be more concise; some sentences are wordy.
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 has 12 parameters (1 required) and an output schema, the description covers behavior thoroughly and provides some parameter guidance. However, parameter descriptions are shallow and do not fully explain purpose or constraints for all fields, leaving some gaps.
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 0%, but the description includes an 'Args' section listing each parameter with a short description (e.g., 'The agent name to analyze or process'). These descriptions are present but mostly generic and repetitive, adding limited meaning beyond parameter names.
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 starts with 'Assess agent for excessive permissions (least privilege)' – a specific verb+resource that clearly states the tool's purpose. It is distinct from sibling tools like assess_agent_security or check_data_leakage, which focus on other security aspects.
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?
Includes explicit 'When to use' and 'When NOT to use' sections, providing context for appropriate invocation. However, the 'When to use' is somewhat generic ('structured analysis') and could be more specific to excessive agency assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check text for prompt injection attack patterns.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: input_text (str): The input text to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| input_text | Yes | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It covers side effects (read-only, stateless), authentication, rate limits, error handling, idempotency, and data privacy in a dedicated section.
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 well-structured with clear sections and front-loaded purpose. It is somewhat long but every sentence adds value; minor redundancy exists (e.g., repeating behavioral details in both inline and a dedicated section).
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 no annotations and an output schema present, the description covers behavioral aspects thoroughly. However, it misses describing the 'caller' parameter and has slight inconsistency about api_key/authentication, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It describes 'input_text' and 'api_key' in an Args block but omits the 'caller' parameter entirely. The descriptions given are minimal (e.g., 'The input text to analyze'). Partial coverage prevents a higher score.
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 checks text for prompt injection attack patterns. It uses a specific verb-resource combination and distinguishes from sibling tools like check_tool_poisoning or check_data_leakage.
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 includes dedicated 'When to use' and 'When NOT to use' sections, providing clear context for when to invoke the tool. It could explicitly mention alternatives among siblings, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a tool for name/description manipulation (tool poisoning).
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: tool_name (str): The tool name to analyze or process. tool_description (str): The tool description to analyze or process. tool_source (str): The tool source to analyze or process. has_signature_verification (bool): The has signature verification to analyze or process. has_description_hash (bool): The has description hash to analyze or process. from_trusted_registry (bool): The from trusted registry to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | ||
| tool_description | Yes | ||
| tool_source | No | unknown | |
| has_signature_verification | No | ||
| has_description_hash | No | ||
| from_trusted_registry | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only, stateless, idempotent behavior, rate limits (10/day free, unlimited pro), authentication options, error handling, and data privacy. All claims are specific and beyond the absent 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?
Well-structured sections (Behavior, When to use, Args, Behavioral Transparency) but slightly verbose, with some redundancy (Behavior and Behavioral Transparency overlap). Could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, behavior, usage guidelines, parameters, error handling, rate limits, authentication, privacy. No gaps given the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but parameter descriptions are generic ('to analyze or process') and sometimes misleading (e.g., api_key described as 'to analyze or process' rather than for authentication). Adds minimal value beyond property names.
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 checks for tool poisoning (name/description manipulation), a specific security analysis function. It distinguishes from sibling tools like assess_agent_security and check_prompt_injection by focusing on this niche.
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?
Explicit 'When to use' and 'When NOT to use' sections provide clear context. Advises use for structured analysis/classification and warns against real-time production use without human review, offering strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.4assess_agent_securitycheck_data_leakagecheck_excessive_agencycheck_prompt_injectioncheck_tool_poisoningEach tool targets a distinct security aspect (overall assessment, data leakage, excessive agency, prompt injection, tool poisoning) with clear, non-overlapping descriptions, ensuring an agent can easily distinguish them.
All tool names follow a consistent verb_noun pattern (e.g., check_data_leakage, assess_agent_security) with no mixed conventions or deviations, making navigation predictable.
Five tools is a well-scoped count for a security assessment server, covering key OWASP agentic AI vulnerabilities without being too sparse or overwhelming.
The set covers major OWASP Top 10 areas but lacks tools for supply chain security or model theft. However, the comprehensive assess_agent_security tool partially fills gaps, making the surface reasonably complete.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Agent Orchestrator MCP Server by MEOK AI Labs
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/owasp-agentic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
