healthsec-mcp

by MichaelEnny

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different security assessment areas (attack types, scoring, compliance, audit, reporting). There is no overlap that would confuse an agent.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., run_fgsm, score_compliance). The naming is descriptive and predictable.
Tool Count5/5
With 10 tools covering adversarial attacks, scoring, compliance, audit, and reporting, the count is well-scoped for its domain. Each tool earns its place without being excessive.
Completeness4/5
The tool surface covers core security assessment workflows (attacks, scoring, reports) but lacks explicit model registration tools; models are assumed pre-registered, which is a minor gap.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the batch cap (100 samples), return metrics, and clarifies a common misconception about plausibility rate. However, it does not state whether the tool modifies the model, requires authentication, or has other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with three sentences, each serving a purpose: stating the action, capping batch, and explaining return values. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no parameter descriptions in the schema, the description omits critical details about seed, epsilon, n_lime_samples, and model registration requirements. This leaves the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only describes the batch parameter (cap) and implicitly mentions epsilon via the attack name. Other parameters (seed, model_handle, n_lime_samples, epsilon) are left unexplained, leaving the agent without sufficient understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a LIME-guided FGSM adversarial attack against a registered model.' This clearly states what the tool does and differentiates it from sibling tools like run_boundary_attack or run_membership_inference.
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 versus alternatives like run_boundary_attack. The description does not mention prerequisites or scenarios where this attack is appropriate.
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?
With no annotations, the description must disclose behaviors. It explains the return value (composite SPS 0-100, deployment recommendation tier, subscore breakdown) and clarifies input meanings (auroc_drop worst-case, compliance_score fraction). However, it omits side effects, idempotency, or state changes, and does not mention authorizations or rate limits.
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 with two paragraphs, front-loaded with the main purpose. It includes necessary detail about auroc_drop and output but could be more structured (e.g., using bullet points) for clarity. Every sentence adds value, though some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 required parameters, no output schema, and no annotations, the description is incomplete. It explains the composite output concept but lacks detailed descriptions of most input parameters, output structure, validation rules, or handling of edge cases. More context is needed for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to explain all 9 parameters. Only auroc_drop and compliance_score are described with specific meaning and constraints. The other 7 parameters (threat_tested, threat_passed, etc.) are merely named in the schema with type but not explained, leaving significant gaps.
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 composes the Security Posture Score from four dimension inputs, listing specific inputs like auroc_drop, threat metrics, audit completeness, etc. It distinguishes from sibling tools by being the composite calculator, contrasting with individual assessment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when all dimension inputs are available but provides no explicit guidance on when to use this tool versus alternatives like assess_attack_coverage or score_compliance. It instructs on the proper format for auroc_drop and compliance_score but lacks when-not-to-use or prerequisite context.
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?
No annotations are provided, so the description must convey behavioral traits. It explains input requirements but does not disclose return format, side effects, error behavior, or whether the tool is read-only. This is adequate but misses critical details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no fluff. The purpose is stated first, followed by parameter requirements. Every word earns its place.
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 input constraints well but lacks any explanation of the output (e.g., what the score represents, data format). Without output schema, this is a notable gap. Examples or return value details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (array of objects with no property definitions). The description adds significant meaning by specifying required fields (id with prefix constraints, status enum, weight). This fully compensates for the 0% schema coverage.
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?
The description clearly states it scores a HIPAA/FHIR compliance checklist, specifying the required fields. However, it does not explicitly differentiate from the sibling 'score_audit_completeness', which may cause confusion.
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 (e.g., score_audit_completeness). Implicitly, it is used for compliance scoring, but no exclusions or context 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 carries the full burden. It discloses the iterative nature, the condition for stopping (prediction flip or max_steps), the batch cap limit (100), and the sampling from same batch. However, it does not specify permissions, side effects, or return format, but for an adversarial attack tool, the disclosed behavior is adequate.
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 non-redundant sentences that front-load the key purpose and behavior. It is concise with no filler, though some minor detail on parameter roles could be added without breaking conciseness.
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 four parameters, no output schema, and no annotations, the description explains the algorithm and constraints but lacks complete parameter descriptions and return value information. It covers the core operation but leaves gaps in parameter semantics, making it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It only explains the 'batch' parameter indirectly (capped at 100) and mentions 'max_steps' but not 'step_size' or 'model_handle'. This leaves two parameters undocumented, providing insufficient semantic 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 runs an iterative decision-boundary attack, describing the process of moving samples toward opposite-predicted-class samples until prediction flips or max_steps exhausted. It also mentions the batch cap, distinguishing it from sibling tools like run_fgsm which use different attack methods.
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 explains the tool's operation and limits but does not explicitly state when to use this attack versus alternatives (e.g., run_fgsm) or when not to use it. Guidelines for context are implied by the algorithm description but lack direct comparison.
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?
No annotations are provided, so the description bears full responsibility. It explains the condition for completeness (all required fields present and not null), which is a key behavioral trait. However, it does not mention whether the tool is read-only, side effects, performance, or authentication requirements, leaving gaps.
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 very concise: two sentences that cover purpose and behavior. No wasted words; every piece adds value. The structure front-loads the purpose, then explains the logic.
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 simplicity (2 parameters, no output schema, no nested objects), the description is nearly complete. It explains scoring logic and default fields. However, it omits the output format (e.g., a score per entry or aggregate), which would be helpful for an agent to interpret returns.
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?
With 0% schema description coverage, the description compensates partially. It clarifies that required_fields defaults to a predefined list when null and defines what constitutes completeness. However, it does not provide details about the audit_log parameter's expected structure, leaving ambiguity.
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: scoring audit-log completeness for non-repudiation. The verb 'score' and resource 'audit-log completeness' are specific. The context of non-repudiation and the list of default required fields differentiate it from sibling tools like assess_attack_coverage or check_rbac.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when assessing completeness for non-repudiation) but does not explicitly state when not to use or provide alternatives. It lacks explicit guidance on preferred scenarios compared to siblings.
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 are provided, so the description fully carries the burden. It discloses that shadow models are trained, pools are capped, returns specific metrics, and that the result is not a population-scale extrapolation. It lacks information on authorization or computational cost, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with key points front-loaded. It is reasonably concise, though it uses backticks for code elements. Every sentence provides useful information, though some details could be condensed without loss.
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 no output schema, the description explains the return value (accuracy/AUROC, privacy-risk tier, direct count) and clarifies no population-scale extrapolation. However, for 7 parameters, only the two pools are well explained; other parameters (seed, n_eval, n_shadow_models, shadow_model_size) lack any explanation in the description, relying on their default values for 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?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description adds value by explaining the roles of member_pool (trains shadow models and supplies eval sample) and nonmember_pool (only supplies eval sample) and the 5,000 sample cap. However, it does not explain seed, n_eval, n_shadow_models, or shadow_model_size beyond their defaults.
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 runs a shadow-model membership-inference attack against a registered model. It uses specific verbs and identifies the resource (model) and attack type, distinguishing it from siblings like run_boundary_attack (adversarial examples) and assess_attack_coverage (coverage assessment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the necessity of both member_pool and nonmember_pool, and mentions the cap of 5,000 samples. It implies usage when evaluating membership leakage for a registered model, but does not explicitly state when not to use or provide alternative tool references. The context is clear enough for an agent to decide.
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 are provided, so the description carries the full burden. It discloses that it returns a record of tool calls with authorization decisions, implying no side effects. Could be more explicit about being read-only, but sufficient for a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two very concise sentences with front-loaded core purpose. Every sentence adds value: 'Return this session's audit trail' and details what is recorded. No wasted words.
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 is simple but lacks details about the return structure (e.g., fields in each entry). Given no output schema, more detail on the audit trail format would improve completeness. However, for a parameterless tool, it adequately conveys the basic function.
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?
No parameters exist, so baseline 4 applies. The description adds no parameter info, which is acceptable since none are needed.
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 returns the session's audit trail and specifies exactly what is recorded (authz-gated tool calls with authorization status). It is a specific verb-resource pair and distinguishes itself from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: get the raw audit log for session. It does not explicitly state when to use it vs alternatives like score_audit_completeness, but the purpose is clear. Lacks explicit when-not or alternative recommendations.
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?
No annotations provided, so description carries full burden. It explains that PARTIAL counts as half-covered, but does not describe the output format, error handling, or any side effects. Some behavioral info is given, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and a bullet-like list of required fields. No unnecessary words, and the main purpose is 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 parameter and no output schema, the description adequately explains input requirements but does not mention what the scoring output looks like. Slightly incomplete, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property definitions (additionalProperties: true), so the description is essential. It specifies that each entry needs 'result' with values 'PASS'/'PARTIAL'/'FAIL' and optional booleans, adding critical meaning 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 scores MITRE ATT&CK-style threat-coverage from per-control test results. The verb 'score' and resource 'threat-coverage' are specific, and it distinguishes from siblings like score_audit_completeness and score_compliance.
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 context on when to use: when you have per-control test results with specific fields. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the non-live nature and required input fields, but lacks details on side effects, rate limits, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words — purpose and key usage constraints are front-loaded.
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?
Provides essential info but lacks description of return value or scoring logic. For a tool with no output schema, this gap reduces completeness.
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 0%. The description adds critical meaning by specifying that each object in probe_results needs 'expected' (ALLOWED/DENIED) and 'status_code', which the schema does not define.
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 scores RBAC enforcement from already-executed probes, distinguishing it from sibling tools that make live calls or perform other analyses.
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 says the tool does not make live HTTP calls and instructs the user to probe the system first and pass results — providing clear when-to-use and context.
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?
No annotations are provided, so the description carries full burden. It discloses key behaviors: sections not run are marked 'not evaluated', deployment recommendation only appears if sps is supplied, never inferred. This is thorough and honest.
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 two paragraphs, front-loaded with purpose, and every sentence provides necessary information without waste. It is well-structured and easy to parse.
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 8 optional parameters and no output schema, the description provides good context for inputs but lacks details on the output format (e.g., JSON, Markdown). While 'structured security report' is mentioned, the agent might need more specifics about the return value.
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 0% and parameters are untyped objects. The description adds meaning by linking parameters to tool outputs (e.g., 'fgsm' from run_fgsm) and explains the special role of 'sps'. However, the mapping from parameter names to tool names is implicit and could be clearer.
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 composes a structured security report from outputs of specific sibling tools, listing them explicitly and explaining how missing sections are handled. This distinguishes it from individual assessment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains to pass raw dicts from any subset of the listed tools. It also clarifies constraints (no silent assumptions, deployment recommendation only with sps). While it doesn't explicitly state when to use alternatives, the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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