APVISO MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized around specific resources (scans, targets, schedules, findings, quota) and actions (create, get, list, update, delete, verify), making it easy for an agent to select the right one. For example, list_findings and get_report serve complementary but non-overlapping roles for accessing scan results.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as create_scan, get_report, list_targets, update_schedule, and delete_target. This predictability enhances readability and usability for agents, with no deviations or mixed conventions observed.
Tool Count5/5
With 18 tools, the server is well-scoped for its penetration testing domain, covering the full lifecycle from target registration and verification to scanning, reporting, and remediation tracking. Each tool earns its place by addressing a specific need without redundancy, making the count appropriate for the server's purpose.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for penetration testing. It includes target management (create, get, list, delete, verify), scan operations (create, get, list, schedule management), reporting (get_report, list_findings), quota checking, and finding status updates, with no obvious gaps that would hinder agent workflows.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it retrieves instructions and tokens, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or what the output format looks like (e.g., structured data or text). This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the key information (action, resource, scope). There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex verification data. It doesn't explain the return values (e.g., format of tokens or instructions), error handling, or dependencies, leaving gaps that could hinder an agent's ability to use it effectively.
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%, with the single parameter 'targetId' documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain what a target ID is or where to get it). Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 the action ('Get') and the resource ('verification token and step-by-step instructions'), specifying it covers all three verification methods (DNS TXT, file upload, meta tag) for a target. However, it doesn't explicitly differentiate from sibling tools like 'verify_target', which might be a related verification operation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a target ID), exclusions, or how it relates to siblings like 'verify_target' or 'create_target', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool updates a schedule but doesn't disclose critical traits like whether changes are reversible, what happens to existing settings not mentioned, authentication needs, rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key modifiable attributes. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating core action from details).
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?
Given the tool's complexity (9 parameters, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances, leaving gaps for an AI agent to understand full usage. For a tool with this level of detail, more context is needed.
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 schema fully documents all 9 parameters. The description adds marginal value by listing modifiable fields (frequency, timing, model preset, enable/disable), which aligns with some parameters but doesn't provide additional meaning beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 the action ('Update') and resource ('an existing scan schedule'), specifying what can be modified (frequency, timing, model preset, enable/disable). It distinguishes from siblings like 'create_schedule' and 'delete_schedule' by focusing on modification, though it doesn't explicitly contrast with 'update_finding_status' or other update tools.
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 is provided. It doesn't mention prerequisites (e.g., needing an existing schedule ID), when to choose 'update_schedule' over 'create_schedule' or 'delete_schedule', or any constraints like permissions or system state. Usage is implied by the action but lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 that deletion stops future scans, which is useful, but lacks details on permissions needed, whether deletion is reversible, error conditions, or confirmation prompts. For a destructive operation, this is insufficient.
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 concise sentences with zero waste: the first states the action and resource, the second clarifies the behavioral impact. It is front-loaded and efficiently structured.
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 destructive tool with no annotations and no output schema, the description is incomplete. It misses critical context like side effects, error handling, or return values, leaving gaps in understanding the full behavior and outcomes.
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 schema already documents the 'scheduleId' parameter. The description adds no additional meaning beyond implying the ID refers to a scan schedule, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Delete') and resource ('a scan schedule'), and specifies the outcome ('stops all future scheduled scans for this target'). It distinguishes from siblings like 'delete_target' by focusing specifically on schedules rather than targets.
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 'update_schedule' or 'delete_target' is provided. The description implies usage for stopping scans but doesn't mention prerequisites, such as needing an existing schedule ID or confirming deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the tool retrieves details and checks progress, which suggests a read-only operation, but doesn't clarify permissions, rate limits, error handling, or response format. For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and usage. Every sentence adds value: the first specifies what details are retrieved, and the second provides context for when to use it. There's no unnecessary information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is moderately complete. It covers the purpose and basic usage but lacks details on behavioral aspects like response format or error conditions. Without annotations or output schema, the description should do more to compensate, but it's adequate for a simple read operation.
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% description coverage, with 'scanId' documented as 'The scan ID.' The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily.
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 the tool's purpose: 'Get details for a specific scan including status, target, model preset, timestamps, and whether it's a retest.' It specifies the verb ('Get details') and resource ('a specific scan'), and lists the types of details returned. However, it doesn't explicitly differentiate from sibling tools like 'list_scans' or 'get_report', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance with 'Use this to check scan progress,' which implies this tool is for monitoring ongoing scans. However, it doesn't specify when to use this versus alternatives like 'list_scans' for overviews or 'get_report' for completed results, nor does it mention prerequisites or exclusions. The guidance is implied but not explicit.
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 provided, the description carries the full burden of behavioral disclosure. It mentions pagination and verification status, which are useful behavioral traits. However, it doesn't cover other important aspects like authentication requirements, rate limits, error handling, or whether this is a read-only operation (implied but not stated).
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 appropriately concise with two clear sentences that communicate the core functionality and key behavioral aspects (pagination, verification status). It's front-loaded with the main purpose. It could be slightly more structured by separating purpose from behavioral notes, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description provides basic completeness by stating what it returns. However, it lacks details about the return format (e.g., structure of verification status), error conditions, or how to interpret the results, leaving gaps for an AI 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 input schema has 100% description coverage, with clear documentation for both 'page' and 'limit' parameters including defaults and constraints. The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline score of 3.
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 the verb ('List') and resource ('registered targets (domains)'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_scans' or 'list_schedules', which would be needed for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_target' (for a single target) or 'list_scans' (for a different resource). It mentions pagination but doesn't explain when pagination is necessary or how to handle it effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 describes a read operation ('Get details'), which implies it's non-destructive, but doesn't disclose behavioral traits such as authentication requirements, error handling, rate limits, or what happens if the schedule ID is invalid. This leaves gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get details for a specific scan schedule') and lists key attributes without unnecessary words. Every part of the sentence adds value, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with one parameter) and no annotations or output schema, the description is minimally adequate. It covers the purpose and key attributes but lacks details on behavioral aspects and return values, which could be important for an AI agent to use it correctly in 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?
The input schema has 100% description coverage, with the single parameter 'scheduleId' documented as 'The schedule ID.' The description doesn't add any further meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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 the verb ('Get details') and resource ('for a specific scan schedule') with specific attributes mentioned (frequency, next run time, configuration). It distinguishes from siblings like 'list_schedules' by focusing on a single schedule rather than listing multiple, though it doesn't explicitly name alternatives.
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 by specifying 'for a specific scan schedule,' suggesting it should be used when you have a schedule ID and need detailed information. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'list_schedules' or 'update_schedule,' nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 describes what information is returned but doesn't disclose behavioral traits like whether this is a read-only operation, error handling, authentication requirements, or rate limits. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate but lacks completeness. It specifies what details are retrieved but doesn't cover behavioral aspects or usage context, leaving gaps for an agent to understand full operation.
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% (the 'targetId' parameter is fully described in the schema), so the baseline is 3. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints.
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 the verb 'Get' and the resource 'details for a specific target', specifying what information is retrieved (domain, verification status, authentication configuration). It distinguishes from siblings like 'list_targets' (which lists multiple targets) and 'get_scan'/'get_schedule' (different resources), though it doesn't explicitly name alternatives.
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 details for a specific target are needed, but doesn't explicitly state when to use this versus alternatives like 'list_targets' for multiple targets or 'verify_target' for verification actions. No guidance on prerequisites or exclusions is provided.
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 provided, the description carries the full burden of behavioral disclosure. It adds valuable context about the failure condition (targets with associated scans cannot be deleted), which is beyond the input schema. However, it doesn't cover other behavioral aspects like permissions needed, side effects, or error handling, making it only moderately transparent.
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 sentences with zero waste: the first states the purpose, and the second adds critical behavioral context. It is appropriately sized and front-loaded, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with no annotations and no output schema), the description is minimally complete. It covers the main purpose and a key failure condition but lacks details on permissions, return values, or error responses, leaving gaps for an AI 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 input schema has 100% description coverage, with 'targetId' clearly documented. The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline score of 3 without compensating for gaps.
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 the verb ('Delete') and resource ('a target'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'delete_schedule' or 'create_target' beyond the resource name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'This will fail if the target has any associated scans,' which suggests when not to use it. However, it lacks explicit alternatives (e.g., what to do if scans exist) or comparisons to siblings like 'delete_schedule,' leaving room for improvement.
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 the full burden. It discloses pagination behavior and return content (status, target info, timestamps), which is helpful. However, it doesn't mention authentication requirements, rate limits, or error conditions, leaving gaps for a tool that likely interacts with sensitive scan data.
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 a single, well-structured sentence that front-loads the core purpose and efficiently covers filtering and return values. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations and no output schema, the description adequately covers the basics (purpose, filtering, pagination, return content). However, it lacks details on authentication, error handling, or data freshness, which could be important given the context of security scans.
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 schema fully documents parameters. The description adds minimal value by mentioning 'optional filtering by status', which aligns with the 'status' parameter but doesn't provide additional context beyond what the schema already states.
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 the action ('List your scans') and resource ('scans'), distinguishing it from siblings like 'list_findings' or 'list_targets'. However, it doesn't explicitly differentiate from 'get_scan' (singular), which might retrieve a specific scan rather than listing multiple.
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 for listing scans with optional filtering by status, but doesn't specify when to use this versus alternatives like 'get_scan' (for single scans) or 'list_findings' (for scan results). No explicit guidance on prerequisites or exclusions is provided.
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 carries the full burden. It describes the tool as a read operation ('Get') and specifies what information is returned (quota usage details), which is helpful. However, it lacks details on potential errors, rate limits, or authentication needs, leaving behavioral gaps for a mutation-free but critical tool.
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 sentences that are front-loaded and efficient. The first sentence states the purpose with specific details, and the second provides usage guidance. Every word contributes meaning, with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0 parameters, the description is moderately complete. It explains what the tool does and when to use it, but lacks details on return format (e.g., structure of quota data) or error handling. For a read-only tool with simple inputs, this is adequate but has clear gaps, scoring a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose and usage. This meets the baseline of 4 for zero parameters, as it adds value without redundancy.
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 the tool's purpose: 'Get your current quota usage including subscription tier, credits remaining, and billing period dates.' It specifies the verb 'Get' and the resource 'quota usage' with concrete details. However, it doesn't explicitly differentiate from sibling tools like 'get_scan' or 'get_report', which lowers it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to check available scan credits before starting a new scan.' This indicates when to use the tool (before scans) and implies an alternative (not using it could lead to insufficient credits). However, it doesn't explicitly state when not to use it or name specific alternatives, keeping it at a 4.
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 provided, the description carries the full burden. It discloses important behavioral traits: the tier requirement (Business/Enterprise), that scans run automatically, and the recurring nature. However, it doesn't mention potential side effects (e.g., resource consumption, billing implications), error conditions, or what happens if the target becomes unverified.
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 that efficiently convey the core purpose, requirements, and behavior. Every word earns its place with no redundancy or unnecessary elaboration. The structure is front-loaded with the main action followed by important constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the what and basic constraints but lacks information about return values, error cases, or the relationship between frequency parameters (dayOfWeek, dayOfMonth). Given the complexity, it should provide more behavioral 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 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'specified time and frequency' which aligns with frequency/hour/minute parameters but doesn't provide additional semantic context about parameter interactions or dependencies.
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 specific action ('Create a recurring scan schedule'), the resource ('for a verified target'), and distinguishes it from siblings like create_scan (one-time) or create_target (target creation). It explicitly mentions 'recurring' which differentiates it from one-time operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Requires Business or Enterprise tier') and the automatic execution behavior. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like create_scan for one-time scans or update_schedule for modifications.
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 provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('Update') and describes the purpose ('track remediation progress'), but it does not cover critical aspects like permissions needed, whether changes are reversible, error handling, or rate limits. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of only two sentences that directly convey the tool's purpose and usage. Every sentence earns its place without any wasted words, making it efficient 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 the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It covers the basic purpose and usage but lacks details on behavioral traits, error responses, or output expectations. While it meets minimum viability, it does not provide enough context for safe and effective use without additional assumptions.
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 schema description coverage is 100%, so the schema already fully documents both parameters ('findingId' and 'userStatus' with enum values). The description adds minimal value by mentioning the status transitions, but it does not provide additional semantics beyond what the schema specifies, such as format details for 'findingId' or constraints on status changes.
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 specific action ('Update the status of a finding') and resource ('finding'), distinguishing it from siblings like 'list_findings' or 'update_schedule'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 explicitly states when to use this tool ('Use this to track remediation progress') and provides context on the status transitions (e.g., 'open → in_progress → fixed'). However, it does not specify when NOT to use it or mention alternatives like 'list_findings' for checking statuses, which prevents a perfect score.
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 provided, the description carries the full burden of behavioral disclosure. It describes the output format (markdown content with details, evidence, guidance, and PDF URL) and the tool's purpose, but lacks information on potential errors (e.g., invalid scanId), rate limits, authentication needs, or whether it's read-only. It adds some context but misses key operational 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?
The description is appropriately sized and front-loaded, with the first sentence clearly stating the purpose and output. Each subsequent sentence adds value: detailing the report content and PDF URL, then providing usage guidance. There is no wasted text, making it efficient and easy to parse.
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 moderate complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, output format, and usage context, but lacks details on error handling or behavioral constraints. For a read operation with no annotations, it does a good job but could be more thorough about potential issues.
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% description coverage, with 'scanId' documented as 'The scan ID to get the report for'. The description does not add any additional meaning beyond this, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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 specific action ('Get the full penetration test report') and resource ('for a completed scan'), distinguishing it from siblings like 'get_scan' (likely metadata) or 'list_findings' (partial results). It explicitly mentions the comprehensive nature of the output, which helps differentiate its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for a completed scan' and 'for getting comprehensive scan results'), implying it should not be used for ongoing scans or partial data. However, it does not explicitly name alternatives or state when not to use it, such as comparing to 'get_scan' for basic info or 'list_findings' for summaries.
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 provided, the description carries the full burden of behavioral disclosure. It mentions that 'The target must be verified before it can be scanned,' which adds important context about prerequisites. However, it doesn't describe what happens on success/failure, error conditions, or response format, leaving gaps for a mutation tool.
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 perfectly concise with two sentences that each earn their place: the first states the purpose and prerequisite, the second provides essential follow-up guidance. There's zero wasted text and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good context about the verification prerequisite and next steps. However, it doesn't explain what the tool returns or potential error conditions, leaving some gaps in completeness given 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 description coverage is 100%, so the schema already fully documents the single 'domain' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, but since the schema coverage is complete, the 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 states the specific action ('Register a new target domain for scanning') and resource ('target domain'), distinguishing it from sibling tools like 'create_scan' or 'create_schedule' which handle different resources. It provides a complete picture of what the tool does beyond just the creation action.
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 explicitly states when to use this tool ('Register a new target domain for scanning') and provides clear follow-up guidance ('After creating, use get_verification_instructions to see how to verify ownership'). It also implicitly distinguishes from alternatives like 'verify_target' by explaining the verification is a separate step.
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 carries the full burden. It describes the action (verification via three methods) but lacks details on behavioral traits like required permissions, whether it's idempotent, error handling, or what happens after verification. It adds some context (methods) but is incomplete for a mutation tool.
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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose, methods, and prerequisite usage. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with no annotations and no output schema), the description is somewhat complete but has gaps. It explains what the tool does and prerequisites, but lacks details on return values, error cases, or side effects, which are important for a verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (targetId and method with enum). The description adds minimal value by listing the method options (dns_txt, file, meta_tag) but doesn't provide additional semantics beyond the schema's enum. Baseline 3 is appropriate as the schema does the heavy lifting.
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 with a specific verb ('verify ownership') and resource ('a target'), and distinguishes it from siblings by specifying three verification methods. It's not a tautology of the name 'verify_target'.
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 explicitly provides usage guidance by stating when to use this tool (to verify ownership) and when to use an alternative tool ('Use get_verification_instructions first to see the required values'), which is a clear prerequisite and distinguishes it from the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the Business/Enterprise tier requirement (access control) and explains what schedules do (automatically run scans on recurring basis), which are valuable behavioral traits. However, it doesn't mention pagination, sorting, or response format details that would be helpful for a list operation.
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, zero waste. First sentence states purpose, second adds crucial context about what schedules are and tier requirements. Every sentence earns its place with valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description provides good context: what it lists, what schedules are, and tier requirements. It could be more complete by mentioning typical response structure (array of schedule objects) or pagination behavior, but covers the essentials well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool returns and prerequisites.
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 verb 'List' and resource 'scan schedules', specifies the scope 'all your', and distinguishes from siblings like get_schedule (singular) and create_schedule. It explicitly defines what schedules are, adding useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to see all recurring scan schedules) and implicitly distinguishes from get_schedule (single schedule) and create_schedule (creating new). However, it doesn't explicitly state when NOT to use it or name alternatives like list_scans for actual scan results.
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 of behavioral disclosure. It effectively communicates critical behavioral traits: the scan is billable (cost implications), requires target verification (prerequisites), and modelPreset affects cost and depth (performance characteristics). However, it doesn't mention potential side effects like system load or scan duration limits.
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 efficiently structured with front-loaded critical information (cost warning, prerequisites). Every sentence adds value: the first states the purpose, the second covers costs and prerequisites, the third provides usage guidance, and the fourth explains parameter semantics. Zero wasted words.
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?
For a mutation tool with no annotations and no output schema, the description does an excellent job covering costs, prerequisites, and parameter guidance. However, it doesn't describe the return value or what happens after scan initiation (e.g., asynchronous processing, status updates). Given the complexity, a bit more about the operation's nature would be helpful.
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 schema already documents all parameters thoroughly. The description adds some value by explaining modelPreset's impact on cost and thoroughness, but doesn't provide additional semantic context for other parameters beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Start a new penetration test scan') and resource ('scan'), distinguishing it from siblings like create_target (target creation) or get_scan (scan retrieval). It goes beyond the name/title by specifying the nature of the operation.
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 usage guidance: it warns about costs ('creates a billable scan that costs credits'), specifies prerequisites ('target must be verified first'), recommends checking quota ('Check quota with get_quota before starting'), and explains when to use different modelPreset values. It clearly differentiates from alternatives like get_quota or verify_target.
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 full burden and does well by disclosing key behaviors: pagination, description truncation, and filtering capabilities. It doesn't mention rate limits, authentication needs, or error conditions, but covers essential operational traits for a listing tool.
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 with zero waste: first establishes purpose and key behavioral constraints, second explains filtering options. Every word earns its place, and information is front-loaded appropriately for a listing tool.
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?
For a listing tool with no annotations and no output schema, the description provides good context about pagination, truncation, filtering, and alternative tools. It could mention response format or error handling, but covers the essential operational context well given 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the filtering options (severity and status) in context, but doesn't provide additional semantic details beyond what the schema already documents for each parameter.
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 verb ('list') and resource ('findings/vulnerabilities') with specific scope ('for a specific scan'). It distinguishes from sibling 'get_report' by noting that descriptions are truncated here, establishing clear differentiation.
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 guidance is provided: use this tool for paginated listing with truncated descriptions, and use 'get_report' for full details. It also specifies when to use filtering options (by severity or status), creating clear boundaries versus alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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