knowbe4-mcp

Server Quality Checklist

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

Latest release: v1.1.5
Disambiguation5/5
Each tool targets a distinct resource (campaigns, security tests, recipients, training, groups, users, reporting) with clear specificity. Tools like phishing_security_tests_list vs phishing_campaign_tests are differentiated by scope (all tests vs per-campaign), and the naming plus descriptions make boundaries clear.
Naming Consistency5/5
All tools follow a consistent knowbe4_<domain>_<resource>_<action> pattern. The hierarchy is predictable: domain prefixes (phishing, training, users, groups, reporting) followed by singular/plural resource nouns and consistent verbs (list, get, members). The only minor deviation is the utility tools (navigate, back, status) which break the pattern but are intentional.
Tool Count4/5
30 tools is on the heavy side, but KnowBe4 is a broad platform covering phishing, training, users, groups, reporting, and account data. Each tool covers a genuinely distinct resource that an agent would query. It leans toward the upper edge of reasonable scope, though several reporting summary tools aggregate data that could be computed from existing list tools, suggesting some redundancy.
Completeness4/5
The surface covers the primary KnowBe4 domains well: phishing campaigns/tests/recipients, training, users, groups, store purchases, and policies. However, the toolset is entirely read-only — there are no create, update, or delete tools for any resource, which means agents cannot trigger phishing simulations, enroll users, or modify campaigns. This limits it to a querying/analysis server.
Average 3.3/5 across 30 of 30 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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 full burden for behavioral disclosure. It says it verifies credentials are configured, implying a read-only check, but does not state whether it makes network calls, whether it can fail/hang when credentials are invalid, what 'status' results look like, or any side effects. For a credential-verification tool, clarity on failure behavior is important and absent.
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 two concise sentences with no filler or repetition. Each sentence earns its place — one states the primary output, the second clarifies the credential-verification behavior. Efficiently written.
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?
No annotations, no output schema, zero parameters. For a status/diagnostics tool, the description does not specify the output format (e.g., what statuses are possible, what 'available domains' looks like in the response). A richer description covering the return values would materially help an agent interpret results.
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 tool takes zero parameters, so there is nothing to document. The baseline for 0 parameters is 4 — the description appropriately describes what the tool does without needing param-specific detail. No gap here since there are no params to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it shows 'credentials status and available domains' and verifies API credentials are configured. The verb 'show' plus 'credentials status' gives some indication of purpose, but it's ambiguous about what exactly is returned. Among 31 sibling tools focused on listings/getters of credentials-related resources, this tool's distinct purpose (a status/diagnostics check) is implied but not clearly differentiated — it reads more like a health-check utility.
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?
There is no guidance on when to use this tool versus the numerous listing/get tools among siblings. It does not explain whether it should be called before other operations to validate credentials, or what circumstances warrant invoking it. The 'verifies API credentials are configured' hint suggests a pre-flight check role, but this is not made 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?
The description is transparent that this is a no-op that does nothing — that's honest behavioral disclosure. No annotations are provided, but the description carries the necessary burden by explicitly stating the tool performs no operation. It does not describe return values or error behavior, but for a no-op tool that's less critical.
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 sentence and extremely concise — zero waste. It front-loads the key fact ('No-op tool') immediately. It's not verbose enough to lose points for verbosity, though one might argue the second sentence 'All tools are always available' adds marginal value at best.
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 no-op tool with no parameters and no output schema, the description is arguably sufficient — there's simply not much to explain. It discloses it does nothing and rationalizes its existence via backwards compatibility. It could be more complete by stating that callers should use the real siblings instead, but given the tool's trivial nature, this is adequate.
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 tool has 0 parameters, so there's nothing to document. The schema is empty (100% coverage is trivially satisfied), and with no parameters there's no semantic burden on the description. The 'no-op' designation resolves any ambiguity about what calling with zero args would do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's a 'No-op tool for backwards compatibility,' which does explain that the tool does nothing functionally. However, it fails to state what the tool does in terms of a verb+resource — it explicitly says it does nothing. The purpose is clear in that it's a placeholder, but it's essentially a self-referential explanation rather than describing an action.
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 says 'All tools are always available,' which obliquely implies this tool is redundant. But there's no explicit guidance on when to use this tool vs the sibling tools, no statement about when NOT to use it, and no alternative named. An agent could reasonably wonder whether to call this tool at all.
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 behavioral burden. It states this is a list/read operation, but provides no detail on pagination behavior, return format, or whether this is safe/idempotent. The pagination defaults are buried in the schema rather than the description.
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?
A single concise sentence that captures the core function. No filler or redundancy. Could arguably mention pagination or the distinction from the sibling list tool, but the core message is delivered efficiently.
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?
With no annotations, no output schema, and multiple closely-related sibling tools (knowbe4_phishing_security_tests_list, knowbe4_phishing_campaigns_get), the description under-explains. It doesn't clarify what a PST is, when to use this vs. the broader list, or what return data looks like.
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 each parameter is documented. The description adds the campaign-scoping semantic (PSTs belonging to a specific campaign) which isn't fully expressed in the schema's 'The phishing campaign ID' line. This is baseline-3 territory given high schema coverage, with the description adding modest extra meaning about campaign linkage.
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?
Clear verb+resource: 'List all Phishing Security Tests (PSTs) for a specific campaign.' It distinguishes itself from the sibling tool knowbe4_phishing_security_tests_list by scoping to a specific campaign via campaign_id. However, it doesn't explicitly differentiate itself textually from that sibling.
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 vs. knowbe4_phishing_security_tests_list (which lists all PSTs) or other reporting tools. The campaign-scoping intent is implied by the name and description but not explicitly stated as a when-to/alternatives note.
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 behavioral burden. It mentions 'including acknowledgment status' which adds some return-content context, but doesn't disclose anything about authentication requirements, data freshness, error conditions, or what the full response looks like.
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?
A single efficient sentence that states the core purpose plus a useful detail. No wasted words, though it front-loads well enough and is 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?
For a simple single-parameter get tool with no output schema, the description is reasonably complete. However, with zero annotations and no return structure info, it leaves the agent guessing about the exact response format. It's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'policy_id' parameter described as 'The policy ID'. The description adds minimal meaning beyond the schema—nothing about how to obtain the ID (e.g., from the list tool) or ID format specifics. Per the rubric, 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 states a specific verb+resource action ('Get detailed information about a specific policy by ID') and adds the useful 'including acknowledgment status' detail. It's clear and distinguishable from the sibling knowbe4_policies_list tool, though it doesn't explicitly differentiate itself from the list counterpart.
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 get-by-ID tool vs knowbe4_policies_list. It's implicit that you'd use this when you need a single policy's details, but no explicit context, prerequisites, or exclusion guidance is provided.
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 at all, the description carries the full burden of behavioral disclosure. It states this is a list/read operation (which is safe), but doesn't describe pagination behavior beyond what the schema already covers, rate limits, authentication requirements, or what happens if there are no policies. It adds minimal context beyond the obvious 'returns policy info'.
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 covers purpose and key returned fields. It's front-loaded and wastes no words. Could arguably be scored 5, but there's a small opportunity to mention pagination or the distinction from the get variant, so a slight deduction is warranted.
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?
This is a straightforward list tool with 0 required parameters and no output schema. The description covers the essential purpose and return fields adequately. However, for a paginated list tool it doesn't explain return structure for the empty case or page exhaustion, and with no annotations there's a gap on what constitutes the complete response. Given the low complexity of the tool, this is minimally viable though not rich.
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 (page, per_page) with reasonable descriptions including defaults and max. The tool description itself adds no parameter information beyond what the schema provides. Baseline 3 is appropriate since 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 states a specific verb+resource ('List all security policies') and details the returned fields (policy names, status, acknowledgment requirements). It's clear about the core function, though it doesn't explicitly distinguish itself from sibling tools beyond the obvious (e.g., knowbe4_policies_get is the detail grabber, this is the list view). The purpose is well-understood.
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?
There is no guidance on when to use this tool vs alternatives. It doesn't mention that knowbe4_policies_get exists for fetching a single policy's detail, nor does it explain any context like whether this lists all organization-wide policies or just accessible ones. No exclusions or alternative references are made.
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 of disclosing behavioral traits. It states this is a read/list operation but provides no detail on pagination behavior, ordering, what fields each purchase record includes, caching, or any access requirements. The parenthetical about ModStore content adds some context, but the description mostly restates the obvious.
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?
Two short sentences, zero waste. The description is efficient and front-loaded with the core action. It could arguably be condensed, but it is appropriately sized for a simple listing tool and no sentence is extraneous.
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 tool is a simple listing operation with full schema coverage and a get-counterpart tool exists (store_purchases_get). However, the description doesn't note the relationship to knowbe4_store_purchases_get or clarify what fields/return shape the list provides, and there's no output schema to fill that gap. For a straightforward list endpoint this is minimally adequate but not rich.
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 both parameters (page, per_page) described in the input schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 applies. No compensation needed but also no added value.
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' with the resource 'store purchases' and adds scope ('training content bought from the KnowBe4 ModStore'). It clarifies what is shown ('purchased modules and content'). While it doesn't explicitly distinguish from siblings, the resource is specific enough and distinct from the other knowbe4 list tools, most of which target phishing/training campaigns or users.
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 gives no guidance on when to use this tool versus alternatives. It doesn't differentiate from knowbe4_store_purchases_get (the singular counterpart), nor does it explain when querying store purchases would be appropriate versus training enrollments or training campaigns. There is no explicit context or exclusions provided.
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 of behavioral disclosure. It's a read/list operation (implied by 'List'), which the agent would infer, but beyond that it doesn't describe pagination behavior implications, rate limits, default sort order, or whether disabled/archived campaigns are included. 'All training campaigns' is somewhat ambiguous about scope filtering.
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 conveys purpose and return data in minimal words. No wasted content, though it could function with slightly more usage guidance while remaining tight.
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 simple paginated list tool with 100% schema coverage and no output schema, the description covers the basics (what it returns). However, lacking annotations and usage guidance, and with limited behavioral disclosure, a slightly more complete treatment would benefit an agent choosing between the many training/phishing tool siblings. It's adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (page, per_page) are documented in the schema with defaults and max. The description lists return fields but doesn't add parameter semantics beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't add meaningful parameter context.
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 ('all training campaigns'), and enumerates what fields are returned. It distinguishes from siblings like phishing_campaigns_list by specifying 'training' campaigns. However, it doesn't explicitly contrast with the sibling knowbe4_training_campaigns_get, though the plural 'list' vs 'get' distinction is implicit in names.
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 vs. alternatives such as training_campaigns_get, enrollments_list, or reporting_training_summary. There are no exclusion criteria or context on which sibling tools serve related but distinct use cases. The only hint is the return fields, but no explicit when/when-not guidance.
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 behavioral burden. It doesn't disclose pagination behavior, whether member nesting occurs, performance implications, or what happens for a large group. It states it returns user details but doesn't describe the shape or confirm it's a read-only safe operation. For a GET-style tool with zero annotations, more disclosure is expected.
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, zero waste. The description is tightly scoped and immediately front-loads the core action and result. Every word contributes meaning.
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 simple parameterized list tool with no output schema and full schema description coverage, this is mostly adequate but could note pagination behavior more explicitly. With no annotations and no output schema, the description could add a bit more on return format or scaling caveats. It's serviceable but slightly thin for a member-fetch across potentially large groups.
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 three parameters (page, group_id, per_page). The description adds minimal value beyond the schema—it doesn't explain pagination interactions or limits. Baseline 3 is appropriate since the schema carries the heavy lifting and the description confirms the output is user details.
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), resource (members of a specific group), and the output (returns user details for each member). It distinguishes reasonably from siblings like knowbe4_groups_get (which gets group info, not members) and knowbe4_groups_list (which lists groups). However, it doesn't explicitly disambiguate from knowing member-related tools, though the group-scoped target makes intent clear.
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 vs alternatives like knowbe4_groups_get or knowbe4_users_list. It doesn't mention prerequisites (e.g., needing a valid group_id, the relationship to groups_list/get), nor does it say when NOT to use it. The context of retrieving members of a specific group is implied but no exclusions or alternative recommendations are provided.
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 responsibility for behavioral disclosure. The description says 'risk score history over time' but doesn't disclose return structure, whether this is a read-only operation, whether it requires permissions, how many data points are returned, or what the time-series looks like. With zero annotation coverage and no output schema, this leaves the agent guessing about behavior.
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?
Two concise sentences with no filler. The first gives the purpose, the second offers a contextual use case. Tight and readable, though it could front-load more critical behavioral info if any existed.
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?
This is a time-series/multi-result tool (pagination parameters suggest many data points) with no annotations, no output schema, and only basic parameter coverage. The description doesn't explain what the returned history contains (data points, timestamps, risk bands), how far back the history goes, or how pagination interacts with time. For a relatively complex reporting tool, this is under-specified.
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% — all three parameters (page, group_id, per_page) are documented in the schema with descriptions. The description adds minimal param value ('group' context), so baseline 3 is appropriate. It doesn't explain pagination implications or how risk score history is bucketed over time, but it doesn't need to since the schema already covers the parameters.
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 specifies a clear verb+resource: 'Get a group's risk score history over time.' It names the resource (group) and the specific data (risk score history). It partially distinguishes from siblings (e.g., knowbe4_account_risk_score_history, knowbe4_users_risk_score_history) by explicitly scoping to 'a group,' but doesn't reference those siblings by name.
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 adds a usage context: 'Useful for comparing security posture across departments or teams.' This gives an implicit sense of when to use it, but there are no explicit when/when-not instructions or named alternatives. Since sibling risk score history tools exist (account, users, groups), the lack of explicit differentiation is a gap, though the 'comparing across departments' framing helps.
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 states what data is returned but says nothing about read-only status, pagination behavior, error conditions (e.g., what happens when recipient_id doesn't belong to the pst_id), authentication requirements, or whether the data is filtered or aggregated. For a read operation with zero annotation coverage, this is a notable 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, focused sentence that conveys the purpose and output in ~15 words. It's efficient and front-loaded with the key action and resource. No wasted words or redundant phrasing, though it could arguably be slightly more informative.
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?
The tool has no annotations and no output schema, so the description serves as the sole source of behavioral information. The description explains the return fields (click time, open time, reported status) which is useful, but it's incomplete for a tool that fetches detailed results. It doesn't mention additional fields that might be present, or clarify relationships to the sibling 'recipients' list tool, leaving the agent to guess whether this returns richer data than the list endpoint. Adequate but with clear gaps for a detail-fetch 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 coverage is 100%, with both parameters (pst_id and recipient_id) already described in the input schema. The description adds context about what combining these parameters yields (the recipient's detailed PST result) but doesn't add detail beyond what the schema provides regarding parameter formats or constraints. Baseline 3 is appropriate since the schema already documents both parameters well.
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 uses a specific verb ('Get') plus resource ('specific recipient's detailed result for a PST') and enumerates the data fields returned (click time, open time, reported status). It's clear in what it does. However, it doesn't explicitly differentiate from sibling tools like knowbe4_phishing_security_test_recipients or knowbe4_phishing_security_test_get, though the singular 'specific recipient' vs plural recipients is implicitly distinguishing.
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 usage context (getting a single recipient's detailed result within a PST) is implied by the description and the presence of pst_id + recipient_id parameters. However, there's no explicit when-to-use guidance or differentiation from the siblings knowbe4_phishing_security_test_recipients (which presumably lists all recipients) or knowbe4_phishing_security_test_get (which gets the PST itself). No exclusions or caveats are stated.
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. The description only mentions it retrieves risk score history but doesn't disclose pagination behavior details, response structure, whether there's a time range constraint, or whether the data is aggregated over users. For a read/retrieval tool with zero annotation coverage, this leaves a meaningful transparency 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 two sentences with zero wasted words. It front-loads the purpose clearly and adds one contextual usage note. This is efficient and well-sized for a simple paginated list tool.
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 tool is simple (2 params, no output schema, no nested objects) so the description doesn't need to be extensive. However, with no annotations, no output schema, and a meaningfully differentiated sibling set (user-level and group-level risk score history), the description could do slightly more to clarify the account-level scope and what distinguishes this from the other risk score history tools.
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 both parameters (page, per_page) documented with types, defaults, and bounds in the schema. The description adds no parameter-specific meaning beyond what's in the schema, but given full coverage, the baseline of 3 is appropriate. The description does not clarify how pagination interacts with risk score history data.
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 states a specific verb+resource: 'Get the account-level risk score history over time.' It clearly identifies the resource (account-level risk score history) and the temporal scope (over time). It distinguishes from siblings like knowbe4_users_risk_score_history and knowbe4_groups_risk_score_history through the 'account-level' qualifier, though it doesn't explicitly name those 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 notes it's 'Useful for tracking overall security posture improvement,' which provides some context for when to invoke it. However, it doesn't explicitly state when NOT to use it or name alternative tools (such as the per-user or per-group risk score history variants). The usage guidance is implied rather than explicit.
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 for behavioral disclosure. It mentions the associated security tests inclusion, which is useful. However, it doesn't disclose return format, error behavior for invalid IDs, or whether this returns nested test details or just references. For a GET/details tool with zero annotations, more transparency is needed.
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?
Single sentence, no wasted words, front-loaded with the primary action. The inclusion of 'including all associated security tests' adds value in one clause. 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?
For a single-parameter GET tool with 100% schema coverage, this is near-complete. The missing element is the ambiguity with knowbe4_phishing_campaign_tests (which likely also fetches tests for a campaign) — the description doesn't clarify the difference between these two seemingly overlapping tools, which could lead an agent to invoke the wrong one.
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 single parameter campaign_id is documented in the schema as 'The phishing campaign ID.' The description mentions ID but adds no value beyond the schema since schema already fully covers it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Get detailed information about a specific phishing campaign by ID.' It distinguishes from siblings like knowbe4_phishing_campaigns_list (which lists campaigns) by clarifying this is per-ID detail retrieval. However, it doesn't explicitly contrast with the closely named sibling knowbe4_phishing_campaign_tests, which could create ambiguity about which covers tests vs campaign details.
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 a specific campaign ID is known and needed for details ('by ID'), which frames when to use it. It doesn't explicitly state when-not-to-use or name alternatives like the list tool for browsing, leaving the distinction implicit rather than explicit.
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 indicates this is a read/list operation implicitly but doesn't reveal pagination behavior beyond what the params imply, rate-limit considerations, or whether it returns only a subset/has filtering constraints. For a list operation with zero annotation support, more disclosure is needed.
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?
A single, information-dense sentence that states the purpose and enumerates return fields. No waste words. Slightly short on usage context, but for a simple list tool this is appropriately concise.
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?
This is a simple filtered-list tool with 2 fully-documented params and no output schema. The description lists the fields returned, which helps. However, with no annotations and no output schema, a bit more behavioral context (what fields map to what, whether empty results are returned, etc.) would raise completeness. For its simplicity, it's adequate but not rich.
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 both parameters (page, per_page) are fully documented in the schema. The description adds the fact that pagination controls result volumes but doesn't add meaning beyond what the schema already provides. Baseline 3 is appropriate when 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 states a specific verb+resource ('List all phishing simulation campaigns') and enumerates the returned fields (names, status, creation dates, security test counts). It clearly distinguishes from siblings like knowbe4_phishing_campaigns_get (singular retrieval) and knowbe4_reporting_phishing_summary (reporting aggregate). Loses a point for not explicitly contrasting with the sibling that also lists campaigns at a different granularity.
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 ('List all... campaigns') but does not explicitly state when to use this versus alternatives like knowbe4_phishing_campaigns_get or knowbe4_phishing_security_tests_list. Common context (this is the overview-level listing for campaigns) is implied but not stated as 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 the full burden of behavioral disclosure. The description notes it 'Shows which users clicked, opened, reported, or were otherwise affected' — giving some return-content preview. However, it doesn't disclose pagination behavior, whether this is a read-only safe operation, rate limits, or required permissions. For a read tool with zero annotation coverage, more context would be expected.
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 compact two-sentence definition with minimal waste. It efficiently communicates the tool's purpose and output nature without unnecessary elaboration. Could arguably be slightly more explicit about usage context, but it's appropriately sized for its scope.
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 100% schema coverage, the description does its job of clarifying purpose. However, no output schema exists, so the description doesn't explain return formatting or result structure beyond 'which users clicked, opened, reported'. The tool has 29 siblings in a large KnowBe4 API surface, so more disambiguation detail would help selection.
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 documents all 3 parameters well (pst_id, page, per_page each have descriptions). The description adds nothing about parameters beyond what the schema provides, which is why baseline 3 applies. The behavioral description of what results show (clicked/opened/reported) adds value in understanding what the data represents.
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 is clear: 'Get recipient-level results for a specific PST' uses a specific verb+resource pattern. It distinguishes itself from sibling 'knowbe4_phishing_security_test_get' (which is a singular test details endpoint, vs this listing recipients). The mention of clicked/opened/reported adds specificity about what recipient data includes.
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 context (recipient-level results for a PST) which distinguishes it from campaign-level tools, but it doesn't explicitly state when to use this vs sibling 'knowbe4_phishing_security_test_recipient' (which appears to be a singular version of the same). No explicit when-to-use or when-not-to-use guidance is given.
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 does not mention pagination behavior beyond the schema, whether the history returns all events or date-filtered ranges, time window/limits, or what the response structure looks like. As a read-only history tool with zero annotation coverage, more behavioral context would be expected.
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 compact two-sentence structure with no wasted words. The second sentence provides a genuine use-case hint. It's appropriately sized for a single-resource history tool.
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 and no annotations, the description should explain return value shape and behavioral nuances. It doesn't disclose what a 'risk score history' entry looks like, how much history is retained, or whether ordering is implied. Acceptable for a simple history read but could do more given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents user_id, page, and per_page. The description adds no parameter-specific meaning beyond what the schema provides, but it does clarify the user_id's purpose ('specific user') in prose. Baseline 3 is appropriate given full 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 the verb (Get), resource (a specific user's risk score history), and dimension (over time). It distinguishes from siblings like knowbe4_groups_risk_score_history (which is per-group) and knowbe4_account_risk_score_history (which is per-account), though it doesn't explicitly name them. The phrase 'specific user's' makes the scope clear.
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 gives a use case ('tracking individual improvement in security awareness') but does not explicitly state when NOT to use it or name alternative tools. For example, it doesn't note that account-level or group-level risk score history is available via sibling tools. The context is implied rather than explicit.
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. While 'get a summary' implies a read-only operation, the description doesn't disclose whether pagination is required for full data (despite the page/per_page params), what the response format looks like, or any rate-limit or data-completeness caveats. For a reporting tool with pagination parameters, the behavior around data completeness across pages is relevant but undocumented.
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?
Single sentence, zero waste, front-loads the core purpose. Efficiently conveys the aggregates being returned. No redundant information.
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 tool is relatively simple (2 optional parameters, no output schema, no nested objects), so the description covers the core functionality adequately. However, without annotations and without any return-format description, the agent has limited understanding of what the 'summary' actually contains beyond the three named metrics. Given the simplicity of the tool, this is adequate but not exemplary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters (page, per_page) are already documented with defaults and max values in the schema. The description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate since the schema handles 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), the resource (training campaigns summary), and the specific data returned (total enrollments, completion counts, completion rate). It's distinguishable from siblings like knowbe4_training_campaigns_list (which lists campaigns individually) and knowbe4_reporting_phishing_summary (which covers phishing). While it doesn't explicitly name alternatives, the specific resource+metric (completion rate) makes the aggregation purpose clear.
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 this is for aggregate training reporting across all campaigns, contrasting with per-campaign tools like knowbe4_training_campaigns_get. However, it doesn't explicitly state when to choose this vs. the sibling reporting tools (phishing_summary, risk_overview) or the campaign list tools. The pagination parameters hint at when to use this for large datasets, but no explicit guidance on when this aggregation is appropriate vs. alternatives.
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 disclosure. It indicates this is a read/retrieval operation ('Get detailed information'), which correctly signals a safe, non-destructive action. It does not describe pagination, response format, or error behavior (e.g., 404 for nonexistent group), but for a simple read-by-ID tool, the safety profile is adequately conveyed.
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 states the purpose and the key returned fields in under 20 words. No filler or repetition. Could arguably note the tool contrasts with the list variant, but as written it is appropriately compact.
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 single-parameter read tool with full schema coverage and no output schema, the description is reasonably complete. It names the key return values (risk score, member count) which helps the agent understand result composition. However, it doesn't clarify how this differs from knowbe4_groups_members (which presumably returns just members), and given the large sibling set, slightly more differentiation context would help.
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 coverage is 100% with a single group_id parameter described as 'The group ID to retrieve,' which is clear. The description adds minimal extra meaning beyond 'retrieve by ID' — it doesn't clarify the ID format (numeric confirmed by schema type) or whether this is a global or account-scoped ID, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('detailed information about a specific KnowBe4 group'), and key fields ('risk score and member count'). It differentiates from siblings by noting it retrieves by ID, versus knowbe4_groups_list which presumably lists groups. However, it doesn't explicitly name alternatives or contrast against knowbe4_groups_members.
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 ID') which helps distinguish from list operations, but provides no explicit when-to-use guidance or exclusions. An agent can infer this is the targeted single-record lookup counterpart to knowbe4_groups_list, but no alternatives are named and no use cases are described.
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. 'Get' implies a read operation, but the description doesn't clarify what data fields are returned, any pagination behavior (unlikely for a single item), whether authorization is required, or what happens if the ID doesn't exist. For a single-resource get operation this is minimal disclosure.
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?
A single sentence that states exactly what the tool does with zero waste. Nothing to trim.
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 simple single-ID get operation with one required parameter fully documented in the schema and no output schema needed, the description is largely adequate. However, without annotations, a bit more detail on what the returned object contains would strengthen it. Still, for its simplicity level, it's close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single parameter purchase_id is described as 'The store purchase ID' in the schema itself. With just one parameter fully documented in the schema, the description doesn't need to add much. The description doesn't add extra semantic detail, but baseline 3-4 is appropriate given full coverage and a single trivial parameter.
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 uses a specific verb ('Get') and specifies the resource ('store purchase by ID'). It's clear it retrieves details about a single purchase. However, it doesn't distinguish from the sibling tool 'know4_store_purchases_list', which is the obvious plural counterpart, though the 'by ID' phrasing and 'specific' imply the singular detail-retrieval nature.
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 the tool is for retrieving one specific purchase ('specific store purchase by ID'), which contrasts it with the list tool. However, it doesn't explicitly state when to use this vs. the list sibling or provide any when-not-to-use guidance.
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 behavioral disclosure burden. It states this is a 'get' (read) operation implicitly, but doesn't explicitly confirm it's read-only, doesn't mention authentication requirements, error behavior (e.g., 404 for invalid ID), or rate limits. For a tool with zero annotation coverage, more disclosure is expected.
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?
Single sentence, front-loaded with the verb and purpose, zero wasted words. The description is appropriately compact for a simple single-parameter get tool.
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 is simple (1 param, no nested objects), the description covers the basic purpose. However, with no annotations and no output schema, the description could usefully note that no output schema exists and clarify what fields the response includes beyond module progress and completion date. It's adequate for the simplicity level but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description adds value by stating the parameter (enrollment ID) corresponds to a 'specific training enrollment' and clarifying what the retrieved data addresses. With schema fully covering the parameter, baseline is 3, and the description's context about what the ID refers to elevates it slightly.
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 uses a specific verb ('Get detailed information') with an explicit resource ('a specific training enrollment by ID'), and specifies what the returned data includes ('module progress and completion date'). It clearly distinguishes from the sibling 'list' tool, though it doesn't emphasize the contrast explicitly.
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 this is for retrieving a single enrollment by ID, contrasting with the sibling 'list' tool for retrieving all enrollments. However, there's no explicit when-to-use vs when-not-to-use guidance or mention of prerequisites (e.g., needing a valid enrollment ID obtained from the list call first).
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 correctly identifies this as a read operation ('List') but doesn't disclose pagination behavior, potential volume of results, or anything about the return format. For a list tool, this is modest but acceptable — the read-only nature is implied by 'List'.
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 conveys the core purpose with zero filler. It avoids redundancy with the schema. Could arguably add sibling differentiation or usage context, but the brevity itself is a strength.
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 straightforward list tool with no output schema and two well-documented parameters, the description covers the essentials. It tells the agent what data it returns (enrollments, users, modules, completion status). It's adequate but not rich — it doesn't mention typical use cases like identifying incomplete training or reconciling against campaigns, which could help agent decision-making.
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%, meaning both parameters (page, per_page) are already documented in the schema. The description adds no additional meaning about these parameters beyond what the schema provides. Baseline 3 is appropriate since 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 uses a specific verb ('List') with a clear resource ('training enrollments') and explains what the list contains ('which users are enrolled in which training modules and their completion status'). It's clear and functional. However, it doesn't explicitly distinguish from sibling tools like knowbe4_training_campaigns_list or knowbe4_training_enrollments_get, though the focus on enrollments vs campaigns is reasonably inferable.
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 context (listing enrollments with completion status), which is clear enough. However, it doesn't explicitly state when to prefer this over alternatives like knowbe4_training_enrollments_get (single enrollment) or knowbe4_reporting_training_summary (aggregate view). No when-to-use or when-not-to-use guidance 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 full disclosure burden. However, this is a read/list operation by nature ('List'), which is transparent. The description clearly states what is returned (names, counts, risk scores). It doesn't mention pagination behavior explicitly, though the schema parameters (page, per_page) cover that. For a simple read list operation, this is adequate but not rich—it doesn't disclose limits, ordering, or whether risk scores are current or historical, though 'current' is 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?
One sentence with zero waste—states the action and return contents efficiently. The sentence is front-loaded with the action verb and resource. Slightly notes it could benefit from a caveat about pagination to earn a 5, but for a simple list tool this is appropriately concise.
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 filtered, paginated list tool with no output schema and no annotations, the description covers the core: what it lists and what each result includes. The pagination parameters are in the schema. Given the tool's low complexity, this is adequately complete. It could mention that 'all' requires pagination or that risk scores accompany each group, but it already states risk scores are included. A 4 is appropriate given low complexity—no output schema exists but the return values are named in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (page, per_page) documented in the input schema. The description adds no additional parameter semantics beyond what the schema provides. Per the rubric, with >80% coverage the baseline is 3, and the description doesn't elevate beyond that since it doesn't clarify interaction between pagination and the 'all' claim (e.g., whether 'all' requires iterating pages).
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?
Clear verb+resource ('List all KnowBe4 groups') with a specific scope stated explicitly ('all'). The description also names return fields (names, member counts, risk scores). It differentiates from siblings like knowbe4_groups_get (single group) and knowbe4_groups_members (members of a group), which are clearly distinct operations. The distinction is implicit through the 'all' qualifier rather than explicitly naming alternatives, keeping it at 4.
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 states the tool lists ALL groups with no filtering, which implies when to use it (when you need the full group catalog). It does not explicitly exclude alternatives or name when NOT to use it (e.g., when you need a single group's detail via knowbe4_groups_get, or members via knowbe4_groups_members). The sibling names provide context but the description itself offers no direct comparison guidance.
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 burden. It's a GET/read operation which is reasonably obvious from 'Get', and it discloses what data is returned (modules, enrollments, completion stats). It doesn't state auth requirements, pagination, or error behavior, but for a simple read-by-ID tool this is relatively adequate.
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?
A single well-formed sentence that conveys purpose and key data returned. Zero wasted words, front-loaded with the core action.
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 single-parameter read tool with 100% schema coverage and no output schema, this is mostly adequate. The description names the returned content areas (modules, enrollments, completion stats) which gives the agent a sense of what to expect. It could benefit from noting error conditions (e.g., invalid/unknown campaign ID) but this is a minor gap for a simple read 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% for the single parameter (campaign_id). The description adds that the result includes modules, enrollments, and completion statistics but doesn't elaborate on the campaign_id parameter format beyond what the schema states. Baseline 3 is appropriate given full 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?
Clear verb+resource: 'Get detailed information about a specific training campaign by ID'. It lists what's included (modules, enrollments, completion statistics), which helps distinguish from the sibling knowbe4_training_campaigns_list (list vs get-by-ID). However, the sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving a single campaign when you have its ID, contrasting with the list tool. But there's no explicit statement of when to use this vs knowbe4_training_campaigns_get for phishing or knowbe4_training_enrollments_list. Usage context is implied rather than stated.
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 burden. It discloses that results are paginated and lists the returned fields (email, name, risk score, department), which is helpful. However, it doesn't disclose whether this is a read-only operation, any rate limits, or what happens with no results. The pagination and field disclosure add moderate value but leave gaps.
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 at two sentences and front-loads the core purpose. The mention of returned fields is useful and the pagination note is relevant. No wasted words. Could arguably add a third sentence on usage boundaries but remains efficient.
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?
This is a straightforward listing tool with all 4 parameters fully documented in the schema and no output schema required. The description covers the core purpose, filtering options, pagination behavior, and returned fields. For a list operation of this simplicity, this is reasonably complete, though it could mention how it differs from the user-get and groups-members siblings.
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 all 4 parameters documented in the schema itself, so the baseline is 3. The description adds little beyond the schema - it mentions filtering by status or group (mapping to status and group_id params) but doesn't add format details, default behaviors beyond what schema notes, or interaction between params like whether status and group_id can combine. Schema does the heavy lifting here.
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 states a specific verb+resource ('List KnowBe4 users') with clear scope (optional filtering by status or group). It's distinct from sibling tools which target training, phishing, or group-specific operations. However, it doesn't explicitly differentiate itself from knowbe4_groups_members or knowbe4_users_get, though the listing vs. single/get distinction is implicit.
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 mentions optional filtering by status or group, giving some context for when these filters apply. However, it doesn't explicitly state when to prefer this over alternatives like knowbe4_groups_members or knowbe4_users_get, nor does it note any pagination usage patterns like how to iterate through pages.
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 behavioral burden. It describes read operations (subscription, seats, admin, risk score), which clearly implies a read-only inquiry. However, it doesn't disclose whether admin details require special authentication, what the response format looks like, or any rate-limit considerations. The read nature is evident, so a mid-range score is appropriate.
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 sentence that efficiently lists the key data points returned. It's front-loaded with the action and resource, then enumerates the specific content. No wasted words, though it could arguably be slightly more structured by separating the account summary from the risk score component.
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 account overview tool, the description adequately covers the scope of returned data. With no output schema and no annotations, the description enumerates the main data categories (subscription, seats, admin, risk score), which is the primary gap-filling needed. However, it doesn't clarify whether the 'current risk score' overlaps with or differs from the dedicated knowbe4_account_risk_score_history sibling, leaving slight ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, which per the rubric gives a baseline of 4. With no input schema to document, the description's listing of return content (subscription level, seats, admin details, risk score) effectively serves as the semantic documentation. Nothing more is needed since there are no inputs to explain.
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 resource ('KnowBe4 account information'), and lists specific content types: subscription level, number of seats, admin details, and current risk score. This distinguishes it from sibling tools that focus on specific sub-areas like phishing campaigns, training, or users. It's a clear account-level overview tool, differentiated from the more specific data-access 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 this is the account-level overview tool versus the more specific sibling tools (users, campaigns, groups), but it doesn't explicitly state when to use this over alternatives like knowbe4_account_risk_score_history or knowbe4_reporting_risk_overview. There's no explicit guidance on when this is the right choice versus when to use a more specific sibling.
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 discloses what the response includes (phish-prone percentage, clicked/opened/reported counts), which is helpful return-behavior context. However, it doesn't mention auth requirements, pagination, or potential error cases. For a read-only GET operation, the disclosure is adequate but not rich.
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. The first sentence states the purpose and the second lists key return values. Front-loaded with the core verb+resource.
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 single-parameter, read-only GET with 100% schema coverage and a return-value listing in the description, the description is reasonably complete. It tells the agent what the response contains, which compensates for the absence of an output schema. It could mention authentication requirements but that's likely uniform across the KnowBe4 tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the single pst_id parameter. The description adds context that the ID identifies the specific test for which detailed results are returned, but doesn't explain where the ID comes from or its format constraints beyond the schema's type. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb+resource clearly: 'Get detailed results for a specific Phishing Security Test (PST) by ID.' It distinguishes from the sibling knowbe4_phishing_security_tests_list (which is the list variant). However, it doesn't explicitly contrast with the sibling, and the distinction between this and knowbe4_phishing_campaign_tests is only implied.
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 use when you have a specific PST ID and need detailed results, contrasting with the list tool. However, it doesn't explicitly state when NOT to use it or mention the source of the pst_id (e.g., obtained from the list operation). No explicit alternatives are named.
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 behavioral burden. It states the output components (risk score, trend, highest-risk groups) which gives a reasonable preview. However, it doesn't clarify whether the 'highest-risk groups' output returns full group details requiring separate lookups, or how the trend is computed/time-bounded. For a read-only reporting tool this is acceptable but not rich.
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?
Single sentence, front-loaded with the verb and resource, enumerates the three output components, and contains zero filler. 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?
As a no-input reporting tool with no output schema, the description gives a solid picture of what's returned (risk score, trend, highest-risk groups). It's reasonably complete for an overview tool, though it could add detail on sort order of groups or the time window for the trend, which would help an agent set expectations for downstream processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there's no parameter semantics burden on the description. The description adequately sets expectations that no inputs are needed and that the tool returns account-level overview data.
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 uses a specific verb ('Get') with a clear resource ('account risk posture') and enumerates the specific outputs: current risk score, recent risk score trend, and highest-risk groups. This distinguishes it from sibling tools like account risk score history and per-group risk score history, which focus on different scopes.
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 this is for a high-level account-wide risk overview, which is supported by the mention of 'account risk posture' and 'highest-risk groups'. However, it doesn't explicitly explain when to choose this over sibling tools like knowbe4_account_risk_score_history or knowbe4_groups_risk_score_history, which offer related but different scopes.
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 disclosure burden. It describes what data is returned but doesn't disclose behavioral details like what happens for a non-existent/invalid user ID, whether this is a read-only operation, permission requirements, or response format. It is a 'get' operation which implies non-destructive read, but with zero annotations the burden is on the description to say so explicitly.
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?
A single, efficient sentence that packs the key purpose and data fields without waste. It doesn't list every returned field but summarizes the most important ones. Well-sized for its purpose.
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 simple single-ID lookup tool with full schema coverage and clear sibling distinction, the description is largely sufficient. It lists key returned data elements which helps an agent know what to expect. Minor gaps: no mention of error handling for invalid IDs and no explicit read-only claim since annotations are absent, but these are minor for a simple get 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% (the single user_id param is documented with 'The user ID to retrieve'). The description confirms the ID-based lookup purpose but doesn't add meaning beyond the schema since the schema already covers the single parameter adequately. Baseline 3 applies given full coverage.
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 (get), the resource (specific KnowBe4 user by ID), and provides specific detail fields (risk score, phish-prone percentage, training status, group memberships). It distinguishes from siblings like knowbe4_users_list (which lists users) and knowbe4_users_risk_score_history (which is history-focused).
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 this is for retrieving a single user's details as opposed to the list endpoint (knowbe4_users_list), but it doesn't explicitly state when to choose this vs alternatives or mention any exclusions. The context is reasonably clear given the sibling naming, but there's no explicit guidance about when-not-to-use or preferred alternatives for different needs.
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 explicitly confirms the tool is non-destructive and non-required ('a help/discovery aid, not a prerequisite'). The clear statement that all tools are callable independently tells the agent this tool has no side effects or state implications. This is good transparency for a non-mutating discovery 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, zero waste. It states the purpose, the output, and a critical behavioral clarification in a compact form. Every sentence earns its place, and the most important clarification (not a prerequisite) is front-and-center.
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 simple discovery tool with one well-documented enum parameter and no output schema, the description is appropriately complete. It covers what the tool does, what it returns, and clarifies its optional nature. No output schema exists, but the description adequately signals the return type (tool names and descriptions).
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 domain parameter is fully documented with an enum and per-value explanations in the schema itself. The description does not add parameter-level detail beyond the schema, so baseline 3 is appropriate given full 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 states a specific purpose: 'Discover available KnowBe4 tools by domain' and explains it returns tool names and descriptions for the selected domain. It clearly distinguishes itself from sibling tools which are actual data operations. It doesn't explicitly name a sibling but its role as a help/discovery aid is clear enough to differentiate it from the 30+ data 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 clearly states the tool's role as a 'help/discovery aid, not a prerequisite' and clarifies that 'all tools are callable at any time.' This gives the agent clear guidance that this is optional navigation, not a required step. It doesn't list exclusions but provides sufficient context on when to use it (discovery) versus when not (actual operations).
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 burden. It discloses the returned data types (status, phish-prone percentage, recipient counts), which is useful. However, it does not disclose pagination behavior (default page/per_page), data volume expectations, or whether any subset goes 'all' (the 'all' may effectively be limited by pagination). It's a read/list operation with clear return intent, though somewhat thin on behavioral detail.
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?
Single, efficient sentence that states the resource, scope, and return fields. Zero filler words. Front-loaded with the core action and resource.
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 list/read tool with fully documented parameters, the description is reasonably complete. It names the key return fields and scope. Minor gaps: no mention of pagination defaults being in the schema (covered there), no note about result ordering, and no sibling-contrast guidance. But no output schema is present, so some return-context clarification is useful—which it provides. Adequate for a filter-free listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both page and per_page fully documented in schema). The description doesn't add per-parameter detail, but with full schema coverage the baseline is 3. The description's 'all' phrasing connects to the scrolling behavior of page/per_page, adding slight context over the raw schema. Minor extra value over baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'List all Phishing Security Tests (PSTs) across all campaigns.' It specifies scope (all campaigns), distinguishes from siblings like knowbe4_phishing_security_test_get (single) and knowbe4_phishing_campaign_tests (per-campaign).
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?
It states a broad 'across all campaigns' scope, which implies these are the tests aggregated across campaigns, helpful when you want the full PST picture rather than per-campaign. However, it does not explicitly contrast with sibling tools like knowbe4_phishing_campaign_tests (tests for a specific campaign) or when to choose one over the other. Usage context is implied but not made explicit with alternatives.
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 behavioral disclosure burden. It appropriately indicates this is a read/aggregation operation (fetch + compute statistics). However, it doesn't disclose that pagination params could lead to partial aggregation across pages if many PSTs exist, nor does it describe the output format. The behavior described is consistent and non-misleading, but lacks depth on edge cases.
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. The first sentence states purpose and deliverables; the second explains the implementation approach. Every clause earns its place with no redundant filler.
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 summary/aggregation tool with no output schema and only 2 fully-documented parameters, this description is reasonably complete. It clearly names the computed metrics and the source data. A minor gap: it doesn't warn about pagination affecting aggregate completeness when PST count exceeds per_page, which is a genuine edge case for a tool explicitly labeled as computing 'all' summary statistics.
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 both parameters (page, per_page) are fully documented in the schema. The description doesn't add parameter-level semantics beyond 'Fetches all PSTs', but with full schema coverage the baseline of 3 is appropriate. The description implies pagination matters for aggregation completeness, but doesn't explicitly explain that per_page lower than total PSTs could skew summary statistics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get a summary') with a clear resource ('all phishing security tests') and explicitly lists the outputs (phish-prone percentage, total tests, aggregate click/open/report rates). It distinguishes itself from siblings: while knowbe4_phishing_security_tests_list and knowbe4_phishing_security_test_get retrieve individual test data, this tool aggregates across all PSTs into summary statistics. Sibling names like 'list' and 'get' are clearly differentiated from 'summary'.
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 clearly states the tool fetches all PSTs and computes summary statistics, giving an agent enough context to know this is for aggregate reporting rather than per-test retrieval. However, it doesn't explicitly name alternative tools like knowbe4_phishing_security_tests_list for per-test detail, or state when NOT to use it, so it falls just short of an explicit when/when-not contrast.
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:

[![knowbe4-mcp MCP server](https://glama.ai/mcp/servers/WYRE-AI/knowbe4-mcp/badges/card.svg)](https://glama.ai/mcp/servers/WYRE-AI/knowbe4-mcp)

Score Badge

Copy to your README.md:

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

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