Fallax is a phishing simulation and security awareness training platform. Read your results.
Stop the continuous programme from ever simulating against one person, and drop anything already queued for them. Use it for someone on leave, mid-onboarding, or who must not be tested. Putting somebody back into the programme has to be done in Fallax.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The person's email address, as it appears in Fallax. | ||
| reason | No | Why, recorded against their enrolment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it reveals that queued items for the person are dropped, that the exclusion is permanent from the tool's perspective, and that re-adding must happen externally in Fallax. This does not contradict the annotations; the readOnlyHint=false and destructiveHint=false are consistent with a state-changing but non-destructive exclusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences cover the action, the use cases, and the restoration path. No filler or redundant restatement of the title, and the most important behavioral detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no output schema, the description is complete: it states what happens, when to use it, the side effect on queued items, and how to reverse the decision. An agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the schema already explains the email and reason fields. The description adds context about the person being excluded but no additional parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource: it stops the continuous programme from simulating against one person and drops queued items for them. This clearly distinguishes it from sibling tools like pause_programme, which would affect the whole programme rather than a single person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: someone on leave, mid-onboarding, or someone who must not be tested. It does not explicitly name an alternative for programme-wide pauses, but the single-person scope makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Why one person got the simulation they got, when they got it: their security band and score, the rule that chose the lure, and the cadence that chose the moment. Answered from what was recorded at planning time, not recomputed. Use it for 'why did we phish Anna last Tuesday'.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The person's email address, as it appears in Fallax. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals a key behavioral trait beyond annotations: the answer is 'recorded at planning time, not recomputed', meaning the explanation reflects historical state rather than live data. This is valuable context for an agent interpreting results. The annotations already declare readOnly/idempotent, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists what the tool explains, the second adds the historical-source caveat and a concrete usage example. There are no wasted words, and the most important scoping is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input context (a specific person's email via the example), the output content (band, score, rule, cadence), and the temporal caveat (recorded at planning time). With only one parameter and safe read-only annotations, nothing critical is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter (email, minLength, description), so the baseline 3 applies. The description does not add additional parameter-level meaning beyond the schema's note that it is the email as it appears in Fallax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('explain') and a resource ('a send') and enumerates the exact dimensions of the answer: security band and score, the rule that chose the lure, and the cadence that chose the moment. It clearly distinguishes the tool's purpose from siblings like get_campaign or get_breakdowns by focusing on the 'why' and 'when' for a single person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: 'Use it for "why did we phish Anna last Tuesday".' This gives clear context for when to invoke it. It does not explicitly name alternative tools or exclusions, so it stops short of the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same period cut four ways: by department, by template, by send language, and by campaign. This is what answers 'which team is most at risk', 'which lure worked', and 'do our Dutch speakers click more'. Ask for one cut with by, or omit it for all four.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Return a single cut instead of all four. | |
| range | No | Reporting window, by campaign launch date: 30d, 90d, 12m or all. Defaults to 90d. | 90d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context that all four cuts share the same period and that omitting `by` returns all four, but it does not describe pagination, output formatting, or other behavioral caveats. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first defines the resource, the second grounds it in realistic use cases, and the third states the key parameter behavior. It is compact, readable, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with two optional enum parameters, this is nearly complete: it states the grouping dimensions, the default behavior, and the intended use cases. It does not explicitly describe the exact return shape or mention the `range` parameter, and there is no output schema to fill that gap, so some inference is still required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by mapping `by` values to concrete analytic questions, such as department to 'which team is most at risk' and language to Dutch-speaker click behavior. It also clarifies the default of returning all four cuts; the `range` parameter is left to the schema, which documents it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource and scope: it produces breakdowns of the same period by department, template, language, and campaign. It also uses concrete example questions to communicate intent. It does not explicitly differentiate from sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance for the `by` parameter: ask for one cut with `by`, or omit it for all four. It also signals what kinds of questions this tool answers, which helps an agent decide when to use it. It does not mention alternatives or when not to use it, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One campaign in full: which template and landing page it used, which audience and sending domain, its schedule, and its funnel with rates. Accepts either the campaign id or its name.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign | Yes | Campaign id, or the campaign name as shown in Fallax. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about what fields are returned and that either id or name can be used, but it does not describe error behavior, missing-campaign handling, or response format. This is acceptable given the annotations but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence front-loads what 'full' means, and the second covers the input flexibility. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter, read-only tool with rich annotations, the description is largely complete. It lists the return contents and input options. It does not mention pagination or error cases, but given the tool's simplicity and the annotation coverage, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already states 'Campaign id, or the campaign name as shown in Fallax.' The tool description repeats this input flexibility without adding new semantic meaning, so the schema carries the full weight. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('get campaign') and specifies exactly what full campaign information is returned: template, landing page, audience, sending domain, schedule, and funnel rates. This distinguishes it from list_campaigns and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One campaign in full' clearly implies it is for fetching a single campaign rather than listing multiple campaigns, which is an implicit usage cue. It does not explicitly name alternative tools or exclusion conditions, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ISO 27001 A.6.3 audit trail: one row per person per campaign, with their email address, department, the language they were sent, and the timestamps of every interaction. This is the export an auditor asks for. It names individuals, so the workspace must have turned person-level access on.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Reporting window, by campaign launch date: 30d, 90d, 12m or all. Defaults to 90d. | 90d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: it exposes person-level PII, names individuals, and requires person-level access to be turned on. This is useful for an agent assessing privacy and permission implications, though it does not detail failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: one defines the content and row structure, one gives the audit use case, one warns about the person-level access prerequisite. The most distinctive element (audit trail) is front-loaded, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately describes the output shape: one row per person per campaign with key fields. It also covers the main precondition. Minor gaps remain around ordering, pagination, or behavior when person-level access is off, but for a single-optional-parameter tool the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single `range` parameter, including its enum values, default, and meaning relative to campaign launch date. The tool description adds no additional parameter-level semantics, so the schema carries the burden; the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('evidence bundle' / ISO 27001 A.6.3 audit trail) and a concrete shape: one row per person per campaign with email, department, language, and interaction timestamps. This clearly differentiates it from sibling tools like get_breakdowns or get_campaign by positioning it as the auditor-facing export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is the export an auditor asks for, and it names individuals, so person-level access must be enabled. It does not explicitly name alternatives or say when not to use it, but the audit-evidence framing and prerequisite provide strong situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the continuous simulation programme is running, how many people are enrolled, how the workspace's security score is distributed, and what it has queued to send next. This is the 'is our security training actually running' question, and it is the one nobody logs in to check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the informational scope (state, enrollment, score distribution, queue) but not operational details like response format or freshness; compared with the calibration example for get_calls, this warrants a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first densely packing the returned data categories and the second adding a plain-language purpose. Efficient, though the second sentence's final clause ('nobody logs in to check') is stylistic rather than functional, keeping it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-parameter tool with no output schema, the description names all main data categories an agent needs to anticipate the response. It could be improved by mentioning whether the data is real-time or cached and any return packaging, but it is not inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is trivially 100%, so there is no parameter documentation burden. Baseline for zero-parameter tools is 4, and the description wisely says nothing about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with specific verbs and objects: whether the programme is running, number enrolled, security score distribution, and queued next. This clearly distinguishes get_programme_status from sibling tools like get_program_summary, get_setup_status, and get_campaign by focusing on live operational state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the decision this tool answers ('is our security training actually running'), which tells an agent when to select it. It does not mention alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Headline results of the phishing-simulation programme for a period: how many people were tested, and the open, click, credential-submit and report rates, each compared with the previous period of the same length. Start here for questions like 'how are we doing' or 'has our click rate improved'.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Reporting window, by campaign launch date: 30d, 90d, 12m or all. Defaults to 90d. | 90d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that results are compared with the previous period of the same length, which is a meaningful behavioral trait. It does not elaborate on output format or limitations, but the annotations already establish safety and the description adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no filler. The key result content is front-loaded, and the practical use-case examples are placed efficiently at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only, idempotent summary tool, the description plus schema and annotations provide complete call context. The metric list and comparison behavior are clearly stated, and no output schema exists to require further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the sole parameter, including enum values and default. The description's phrase 'for a period' conceptually aligns with the range parameter but adds no new semantic detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it returns headline results of the phishing-simulation programme, enumerating exact metrics (tested count, open/click/credential-submit/report rates) and period-over-period comparison. It also clearly positions itself as the starting point for high-level questions, distinguishing it from siblings like get_breakdowns and get_programme_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives usage context: 'Start here for questions like "how are we doing" or "has our click rate improved"'. This tells the agent when to use it, but it does not name alternatives or state when not to use it, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same rates over time, bucketed by week (30d and 90d windows) or by month (12m and all time), so an assistant can describe or chart the direction of travel rather than a single snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Reporting window, by campaign launch date: 30d, 90d, 12m or all. Defaults to 90d. | 90d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds detail about bucketing and time windows, but discloses no additional behavioral traits such as pagination, rate limits, or response ordering. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core concept ('rates over time') and packs the bucketing detail into a parenthetical. Every phrase earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and robust annotations, the description adequately explains what the tool returns and why it is useful. It does not specify the response shape, and there is no output schema, but the purpose and bucketing behavior are clear enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum and default, so the schema already documents the range parameter. The description adds value by explaining how the range maps to bucketing granularity (week vs. month), enriching the parameter's meaning beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides 'the same rates over time' bucketed by week or month, and explicitly contrasts this with 'a single snapshot'. This makes the tool's purpose specific and distinguishes it from snapshot-style siblings like get_breakdowns, though it does not name any sibling directly or use a leading verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when an assistant needs to describe or chart the direction of travel rather than a snapshot. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this workspace has and has not set up: people in the directory, audiences, templates, landing pages, verified domains, connected mailbox tenants, whether any simulation has actually been delivered, and whether the continuous programme is running. Use it to answer 'are we ready to run a simulation' or to explain why a report is empty.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful contextual scope about what the status includes, but it does not disclose any behavioral caveats such as data freshness, permission requirements, or return format. With the annotations present, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one informative sentence followed by a practical-use sentence, with no wasted words. The long enumerative list makes it a bit dense, but each item adds value and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only status tool, the description is complete enough: it names the covered setup areas, gives concrete use cases, and aligns with the annotations. It does not describe the response shape, but since there is no output schema and this is a simple status getter, that is a minor gap rather than a blocking omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and zero required parameters, with 100% schema description coverage. There is no parameter burden for the description to bear, so the baseline of 4 applies; there is nothing meaningful to add about parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource — workspace setup status — and enumerates the specific components it covers: people, audiences, templates, landing pages, verified domains, mailbox tenants, simulation delivery, and programme running. It is not a tautology and gives the agent a concrete sense of what the tool reports, though it does not explicitly name or differentiate sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use it to answer "are we ready to run a simulation" or to explain why a report is empty.' This tells the agent when the tool is appropriate, but it does not mention when to prefer a sibling such as get_programme_status or get_program_summary, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every simulation campaign in the workspace, newest first, with its status and its funnel (delivered, opened, clicked, submitted, reported). Unlike the reporting tools this includes drafts and scheduled campaigns that have never been launched.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many campaigns to return. Defaults to 25. | |
| status | No | Filter by campaign status. Defaults to all. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly, idempotent, and non-destructive, so the bar for added context is lower. The description adds behavioral detail beyond the schema: results come 'newest first' and cover all statuses including unlaunched drafts and scheduled campaigns. This gives an agent useful expectations about ordering and coverage without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core behavior is front-loaded in the first sentence, and the second sentence provides the differentiating edge case. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description covers the result contents, ordering, and inclusion semantics, which is sufficient for an agent to know what to expect. No critical gaps like pagination or error behavior are needed given the read-only nature and schema docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'limit' and 'status' fully described in the input schema including defaults and ranges. The description does not add any additional parameter-level guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List' 'campaigns'. It states scope ('Every simulation campaign in the workspace'), ordering ('newest first'), and the included fields ('status' and 'funnel'). The contrast with reporting tools distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool against 'reporting tools' and gives the deciding criterion: this tool includes drafts and scheduled campaigns that have never been launched. That is a clear when-to-use signal. However, it does not name specific sibling tools or mention cases where a more targeted tool like get_campaign would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The SaaS applications the customer's own Google or Microsoft tenant says its people actually use, with how many distinct users were seen and whether Fallax ships a lure that impersonates that app. The single best predictor of whether a simulation is plausible, and the right input when suggesting what to simulate next. Returns nothing unless the workspace turned app discovery on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that data comes from the customer's Google or Microsoft tenant, the specific output dimensions, and that it returns nothing unless app discovery is enabled. This is meaningful behavioral context the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover the tool's output, its strategic purpose, and an important empty-result caveat, with no filler. The most relevant identification is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only listing tool, the description covers what the data is, where it comes from, what fields are included, and when it returns nothing. Even without an output schema, an agent has enough to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to clarify. With no parameters, the baseline 4 applies and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines precisely what the tool returns—tenant-discovered SaaS apps, distinct user counts, and lure availability—and frames it as input for deciding what to simulate next. It clearly distinguishes this from sibling tools like get_program_summary or list_campaigns by naming its role in simulation selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly positions itself as 'the single best predictor' and 'the right input when suggesting what to simulate next,' giving strong context for when to call it. It does not name excluded cases or alternative tools, so it stops short of full 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.
Stop the continuous simulation programme and drop everything it had queued. Nothing further will be sent until an owner or admin restarts it in Fallax. Use this when somebody wants simulations to stop: an incident, an outage, a sensitive week. Restarting cannot be done from here.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Why it is being paused, recorded on the programme and shown to admins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool will 'drop everything it had queued', which is a destructive side effect, yet the annotations declare destructiveHint=false. This is an annotation contradiction. While the description does disclose useful stateful behavior, the direct conflict with the safety annotation makes it misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the primary action, and every sentence adds value: the effect, the restart limitation, and the usage trigger. There is no filler or redundant restating of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema control tool, the description is largely complete: it covers what happens, when to use it, and the restart constraint. It does not explicitly state who is allowed to pause, only that restart requires an owner or admin, so a small authorization gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 'reason' parameter is already documented in the schema. The description adds no additional parameter context, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('the continuous simulation programme'), and further clarifies the scope by saying it drops everything queued. This clearly differentiates it from the sibling getter/inspection tools and from exclude_person/explain_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('when somebody wants simulations to stop: an incident, an outage, a sensitive week') and also gives a clear exclusion by noting restarting cannot be done from here. The agent knows both the trigger and the limitation of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
exclude_personexplain_sendget_breakdownsget_campaignget_evidence_bundleget_program_summaryget_programme_statusget_resilience_trendget_setup_statuslist_campaignslist_discovered_appspause_programmeClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
AI-operated. Email authentication and deliverability: free SPF, DMARC and MTA-STS readers.
Public phishing feed: suspicious/confirmed phishing URLs detected hourly. No auth, CC0.
Monitor and manage email authentication (SPF, DKIM, DMARC, MTA-STS, BIMI) for your domains.
Read your own DMARC aggregate and forensic reports: sources, alignment, alerts, CSV export.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but get_programme_status and get_setup_status both report whether the continuous programme is running, and get_program_summary, get_breakdowns, and get_resilience_trend all expose similar rate metrics. Descriptions help clarify the differences, but an agent could still pick the wrong reporting tool for a given question.
All names use a predictable lowercase snake_case verb_noun style with get_, list_, exclude_, pause_, and explain_. The main inconsistency is the program/programme spelling difference between get_program_summary and get_programme_status, and explain_send is a slightly less conventional noun.
12 tools is a well-scoped size for a phishing-simulation insight and safety-control server. Each tool covers a distinct reporting angle or operational action without feeling padded.
The read and analytics surface is thorough, covering summaries, breakdowns, trends, evidence, setup, and individual explanations. However, the operational side is one-directional: exclude_person and pause_programme have no include or resume counterpart, and there is no campaign or person management tooling, leaving explicit dead ends.
