proofpoint-mcp

Server Quality Checklist

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

Latest release: v1.1.4
Disambiguation5/5
Only one tool exists, so there is no possibility of confusion between tools.
Naming Consistency5/5
Single tool with a clear verb_noun pattern (proofpoint_policy_list), consistent by default.
Tool Count3/5
A single tool is borderline for a policy management domain; it covers listing but lacks other actions.
Completeness2/5
Significant gaps: only list operation exists, missing create, update, delete, or enable/disable for policies.
Average 3.6/5 across 1 of 1 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on August 13, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that events are filtered to those where Proofpoint detected and acted on threats, but it does not disclose default time ranges, pagination, response structure, or other behavioral traits. The absence of any safety hints (e.g., read-only) is notable for a tool that lists events, yet the description offers no reassurance or caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant or irrelevant information. Every word contributes to the overall purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 optional parameters and no output schema or annotations. The description explains the core functionality and the nature of returned events, but it omits details about default behavior (e.g., time window), result format, or how this relates to sibling list tools. Given the absence of structured hints, a more complete description would mention such context, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides; it merely echoes the threat types in prose. Since the schema already documents all parameters with enums and descriptions, the description does not need to compensate, but it also does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('spam, phishing, and malware detection events'), and adds context that it returns events where Proofpoint acted on threats. This distinguishes it from detail/stats tools, though it does not explicitly differentiate from sibling event tools like proofpoint_events_get_details or get_stats. The omission of 'impostor' from the threat types is a minor gap but does not obscure the primary purpose.
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 is provided on when to use this tool vs. alternatives. There is no mention of using proofpoint_events_get_details for single-event details or get_stats for aggregated metrics, nor any exclusions. The description merely states what it does, leaving the agent to infer applicability from the name alone.
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 must carry the full burden of behavioral disclosure. It does reveal that the tool returns both messages and clicks, and both delivered/blocked and permitted/blocked outcomes, which is useful. However, it does not mention read-only status, authentication requirements, pagination, rate limits, or any other behavioral traits that an agent would need to anticipate side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get all threats') and then specifies the scope. It contains no filler or redundant information, making it easy to parse quickly.
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 has no output schema and no annotations, so the description needs to provide enough context. It does explain the return categories, and the schema fully covers parameters. However, it lacks guidance on when to use this aggregate tool versus the dedicated per-type sibling tools, and gives no detail about the response structure or potential errors, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each of the five parameters fully described (format, interval, sinceTime, sinceSeconds, threatStatus). The description adds no additional parameter-level semantics beyond what the schema already provides, so 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 it retrieves all threats (messages and clicks) from the TAP SIEM API, with a specific scope of delivered/blocked messages and permitted/blocked clicks. While it does not name sibling tools, the explicit scope distinguishes it from the per-type tools like proofpoint_tap_get_messages_delivered or proofpoint_tap_get_clicks_blocked, making the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a general usage context ('for a given time window') but provides no guidance on when to prefer this aggregate tool over the more specific sibling tools, nor does it mention any exclusions or alternatives. This leaves the agent without explicit decision support.
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 behavioral disclosure. It does state the returns, but it omits any information about side effects, safety, rate limits, or specific behavior beyond the return values. 'Analyze' implies a read operation, but that is not explicit.
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 with the key action first ('Analyze a URL for threats') and the return values in the second. Every word contributes value, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and the main returns, which is adequate for a simple single-parameter tool with no output schema. However, it lacks usage guidance, any mention of failure modes or edge cases, and does not contextualize the tool among its many siblings, leaving clear gaps.
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% and the 'url' parameter is self-explanatory ('URL to analyze for threats'). The description adds nothing about format, encoding, or constraints on the parameter; it only clarifies the output, which is not parameter semantics. 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 uses the specific verb 'Analyze' with the resource 'URL', and clearly states the output (threat classification, risk score, campaigns). It is unambiguous about the core purpose, though it does not explicitly differentiate from sibling tools like proofpoint_url_decode, which also handles URLs.
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 is provided on when to use this tool versus alternatives such as proofpoint_url_decode or other threat-analysis tools. The description does not mention any exclusions, prerequisites, or preference rules, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output fields (sender, recipient, subject, reason), which is useful, but it does not mention pagination behavior, that it is a read-only operation, or any side effects or prerequisites. For a simple list tool, this provides moderate transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that lead with the action ('List quarantined messages') and immediately clarify the response contents. Every word contributes to the core understanding, with no filler or redundancy.
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 tool with 8 parameters, no output schema, and no annotations, the description gives the essential purpose and return fields but omits important context like pagination defaults, the fact that all parameters are optional, and that without filters it lists all quarantined messages. It is adequate but leaves notable gaps for a full operational understanding.
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?
All 8 parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description adds no additional meaning about how parameters affect results; it merely mentions output fields. Thus it does not elevate above the schema-only baseline.
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 a specific verb and resource ('List quarantined messages') and enumerates returned fields (sender, recipient, subject, reason). It does not explicitly differentiate from the sibling proofpoint_quarantine_search, leaving slight ambiguity about when to use list vs search.
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 is given on when to use this tool versus alternatives like proofpoint_quarantine_search, release, or delete. The description only states what it does, omitting any context on which actions are appropriate or when to favor it over siblings.
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 must carry the full burden of behavioral disclosure. It states the output concept (volume over time, disposition breakdown) but does not mention side effects, auth requirements, rate limits, or data availability. For a read-only report, the lack of any statements about safety or operational behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero redundant words. Every phrase adds information: 'mail flow report', 'email volume over time', 'breakdown by disposition'. It is an appropriately sized, efficient description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema) and lack of annotations, the description provides the core concept but lacks detail on return format, filtering, or how this report relates to other reports. With no output schema, the description should be richer in describing expected results, but it only gives a high-level summary. It is adequate for simple use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (window and granularity) with 100% coverage, so the baseline is 3. The description does not add extra semantics beyond the schema, such as how to choose a window or granularity, or what the defaults mean. It does reference 'over time' which loosely maps to granularity, but no additional value is provided.
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 identifies the tool as 'Get mail flow report' and specifies the resource (email volume over time) and the breakdown by disposition. It distinguishes itself from sibling report tools by focusing on mail flow vs. organization, threat, or executive summaries, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description: if you need email volume over time with disposition breakdown, use this tool. However, there is no explicit guidance on when to use this over other report tools, nor any mention of exclusions or prerequisites. The absence of alternatives or when-not-to-use leaves the agent to infer.
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?
There are no annotations provided, so the description carries full burden. It states the output includes counts and trends but does not disclose whether the operation is read-only safe, rate limits, or what 'trends' actually contains. Minimal behavioral insight beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with front-loaded purpose and no redundancy. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core output (breakdown by type, counts, trends) but lacks usage guidance and return format details. No output schema, so some ambiguity about 'trends' remains. Sufficient for the simple parameter set but not fully comprehensive.
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 covers 100% of parameters with descriptions and enums. The description does not add extra meaning beyond the schema, so baseline 3 applies.
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') and resource ('threat summary report'), and specifies the breakdown by threat types. This clearly differentiates it from sibling report tools like org_summary or mail_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other report tools (e.g., org_summary, executive_summary). It doesn't state prerequisites or exclusions, so the agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the output content (malware family names, descriptions, associated campaigns), which is useful. However, it does not disclose any other behavioral traits, such as default time range when no parameters are provided, whether the operation is read-only (though implied by 'List'), or any rate limits or specific response structure. It adds basic transparency but is 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?
The description is two short sentences, front-loaded with the primary action ('List known threat families') and includes a brief, useful note on return content. There is no wasted text or redundancy with the schema, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional params and no output schema, the description provides the core purpose and return value, but it lacks important contextual details, such as how time filtering works, what happens if no time params are supplied, and when to choose this over sibling threat tools. Given the presence of many related tools, a bit more context would improve completeness.
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 baseline is 3. The description adds no additional parameter semantics beyond the schema—it does not explain how interval or sinceTime affect the results, nor does it clarify the meaning of the interval values. The description's mention of return content does not directly aid parameter understanding, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List known threat families tracked by Proofpoint.' It identifies what the tool returns (malware family names, descriptions, and associated campaigns), which clarifies its scope. However, it does not explicitly distinguish itself from sibling tools like proofpoint_tap_get_all_threats or proofpoint_threat_get_campaign, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical scenarios, prerequisites, or exclusions. There is no comparison to other threat-related tools, leaving the agent to infer usage context from the name and description alone.
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 must fully disclose behavior. It fails to mention that the search is read-only or what the output looks like, nor does it discuss required permissions or limitations. The phrase 'find and remediate' might imply the tool itself remediates, which is misleading—it likely only searches, with remediation occurring in a separate step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately states the primary action ('Search for messages across mailboxes') and the intended use. It is front-loaded with the verb and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 optional parameters, no output schema, and no annotations, the description leaves out critical context: what a successful search returns, whether at least one parameter is required, and any constraints on the search (e.g., date range). The description provides a use case but is not sufficient for an agent to reliably know what to expect or how to construct a valid search.
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 baseline is 3. The description does not add any meaning beyond the schema; it doesn't explain how parameters interact or provide search examples. Since the schema already documents each parameter well, the description's lack of parameter guidance is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for messages across mailboxes, with a specific purpose of threat response and remediation. It mentions 'search & destroy / auto-pull operations,' which provides context that distinguishes it from sibling tools like proofpoint_smart_search_trace or proofpoint_tap_get_messages_delivered, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear use case: 'Used for search & destroy / auto-pull operations to find and remediate delivered threats.' It gives context for when to use this tool, but it doesn't explicitly state when not to use it or mention specific alternatives, so it falls short of a full 5.
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, the description must disclose behavioral traits. It states the report returns ranked users, but does not disclose whether this is a read-only safe operation, whether it requires special permissions, or any rate limit implications. The lack of side-effect/safety information 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the tool's core purpose. Every sentence adds value without extra fluff.
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?
Despite missing annotations and output schema, the description adequately explains the tool's purpose and return value. The parameters are well-documented in the schema. However, the lack of explicit behavioral context (e.g., pagination expectations) prevents a perfect score.
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?
All three parameters have full schema descriptions (100% coverage), so the schema already documents their meaning. The description adds no additional parameter semantics, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the Very Attacked People (VAP) report and explains what it returns (users most attacked, ranked by attack index). However, it does not directly compare against sibling tools like proofpoint_people_get_top_clickers, so it falls short of full differentiation.
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 phrase 'Useful for identifying high-risk users' provides clear context for when to use the tool, but there is no explicit guidance on when not to use it or which alternative to choose, making it only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action (get headers) without mentioning permissions, error handling, retention limits, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes meaning and it is appropriately brief for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately conveys the primary intent. However, it lacks context on how this differs from similar smart search tools and does not mention the response format beyond 'headers', leaving minor gaps.
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, so the schema already fully explains message_id. The description adds little beyond restating that a specific message is needed, warranting the baseline score.
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') and resource ('full email headers') with a clear qualifier ('for a specific message'), distinguishing it from siblings like get_message or trace.
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 is provided on when to use this tool over siblings such as proofpoint_smart_search_get_message or trace. The description implies its use but offers no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully lists the content returned (headers, processing log, delivery details) but does not explicitly state that the operation is read-only, nor does it address error conditions or response format. The word 'Get' implies a safe read, but more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose without extraneous detail. Every word earns its place.
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?
The description gives a reasonable overview of the returned information for a simple single-parameter lookup. However, without an output schema, it could benefit from clarifying whether the returned object includes status fields or how missing messages are handled. Still, for a simple tool, it is largely 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?
The schema already provides 100% description coverage for message_id ('The Proofpoint internal message ID'), so the description adds no additional parameter semantics. 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 clearly states 'Get detailed information about a specific message including headers, processing log, and delivery details,' specifying the verb (get), resource (detailed message info), and scope (specific message). It implies a broader scope than sibling proofpoint_smart_search_get_headers but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like proofpoint_smart_search_get_headers or proofpoint_smart_search_trace. There is no mention of alternatives or exclusions, leaving the agent to infer usage from the name alone.
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 must bear the full burden. It clarifies the meaning of "blocked" but does not disclose any behavioral details such as response format, pagination, time window constraints, or relationship to other TAP data. It essentially restates the tool's name without adding operational expectations.
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 with no redundant filler. The description immediately states the tool's purpose and provides a clarifying definition, earning its place without excessive length.
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 description is minimal and lacks important context for a tool with no output schema and no annotations. It does not mention that time-based parameters are available (though optional), what the result set looks like, or how this tool relates to other TAP threat and message tools. An agent might not know if this is the right tool without deeper investigation.
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 all four parameters are already well-documented. The description adds no further parameter context beyond what the schema provides, which aligns with the baseline score of 3.
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: "Get blocked clicks on threat URLs" specifically indicates the resource (threat URLs) and the filtered state (blocked). This differentiates from the sibling tool proofpoint_tap_get_clicks_permitted, which handles the opposite outcome.
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 tool is used when you need information about clicks that were prevented from reaching malicious destinations, but it does not explicitly state when to use it versus alternatives like proofpoint_tap_get_clicks_permitted. No exclusions or context comparisons 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 must carry the full burden. It clarifies what 'blocked' means (quarantined/rejected) but fails to mention time window constraints, filtering options, or response format, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, directly get to the point. The first sentence states the core action and the second adds valuable clarification without redundancy.
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 output schema, the description should describe returned data or provide context on tool behavior. It does not mention response structure, potential errors, or constraints like the 1-hour limit on sinceSeconds. Inadequate for a tool with 4 optional parameters.
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?
All parameters have schema descriptions, yielding a baseline of 3. The tool description adds no extra meaning about how interval, sinceTime, sinceSeconds, or threatStatus interact, so it does not exceed the 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?
The description clearly identifies the tool's function: retrieving messages blocked because they contained threats. It distinguishes from the sibling proofpoint_tap_get_messages_delivered by explicitly stating 'blocked' and further clarifies that these messages were quarantined or rejected before reaching the recipient.
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 use case for blocked messages but does not explicitly contrast with alternatives like delivered messages or clicks blocked. No when-not-to-use guidance is provided, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output includes encrypted message status and recipient access, but does not mention safety, pagination behavior, date-range filtering implications, or any prerequisites. The absence of any side-effect documentation or read-only indication leaves a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no unnecessary words. It effectively conveys the core function and output highlights without bloat.
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 core purpose and output are adequately described, but the lack of an output schema and annotations means more context would be helpful. It does not explain how filters interact, default date ranges, or how encrypted messages relate to DLP incidents. However, for a simple listing tool, it provides sufficient baseline context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but it does not need to because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists messages encrypted by Proofpoint Email Encryption, using a specific verb and resource. It distinguishes itself from sibling tools like proofpoint_dlp_list_incidents by focusing on encrypted messages rather than incidents.
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 intended use case (listing encrypted messages) is implied but no explicit alternatives or when-not-to-use guidance is provided. There is no mention of when to prefer this tool over other listing tools like proofpoint_dlp_list_incidents or quarantine list tools.
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 present, so the description carries the burden. It discloses that it returns messages with policy violations and sensitive data detections, but does not mention pagination, default date ranges, or response structure, leaving some behavior unexplored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first states the action and target, the second adds relevant detail. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return format and behavior more. It is vague about what fields are returned and how filters interact. Adequate for a basic list, but incomplete for a production 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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'DLP incidents', and further clarifies that it returns messages triggered DLP rules. This differentiates from sibling tools like get_incident and list_encrypted by scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the purpose is clear, there is no mention of using get_incident for a single incident or list_encrypted for encrypted messages, leaving the agent to infer usage.
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, the description carries the full burden of behavioral disclosure. It only mentions that the tool returns counts, but omits important operational constraints such as the limited time window (sinceSeconds max 3600) and how the parameters interact. This leaves the agent without knowledge of applicable limits or 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?
The description is a single sentence that is front-loaded with the action and result, containing no filler or redundant wording. Every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward stats tool, the description clearly states the output categories and time-period context, but it does not mention the time-window limitation (e.g., maximum 1 hour via sinceSeconds) or any other behavioral constraints. Given the lack of annotations and output schema, some gaps remain in completeness.
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?
Since all parameters are documented in the schema (100% coverage), the baseline is 3. The description adds only the generic phrase 'over a time period', which does not explain how interval, sinceTime, and sinceSeconds relate to each other or the enforced maximum range. It meets but does not exceed the 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?
The description clearly states the verb ('get') and resource ('detection event statistics'), and it enumerates the returned metrics (spam, phishing, malware, impostor counts). This specificity distinguishes it from sibling event tools like proofpoint_events_list or proofpoint_events_get_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 for obtaining aggregate detection counts but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or context about preferring this over list/detail endpoints. It conveys a clear but implicit use case, matching the 'implied usage' tier.
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 for behavioral disclosure. It states the output contents but does not explicitly confirm that the operation is read-only, does not mention any permissions or rate limits, and does not explain the effect of the 'includeCampaignForensics' parameter. The verb 'Get' and 'Returns' imply read-only behavior, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and lists the return types. Every word contributes; no filler or redundancy.
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 read-only tool with two parameters and no output schema, the description covers the core purpose and return contents. However, it lacks context on when to use this versus the other forensics and threat tools, and it does not explain the effect of the optional parameter on the returned evidence. The schema fills the parameter gap, but the broader tool ecosystem context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('threat_id' and 'includeCampaignForensics'), so the schema already provides parameter semantics. The tool description adds no additional parameter context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves forensic evidence for a specific threat and lists the types of evidence returned (behavioral analysis, network activity, file modifications). It distinguishes from sibling tools like proofpoint_forensics_get_campaign by focusing on a single threat rather than a campaign, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when forensic evidence for a specific threat is needed, but it provides no explicit guidance on when to choose this over sibling tools such as proofpoint_forensics_get_campaign or proofpoint_threat_get_by_id. There are no exclusions or alternative recommendations.
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, the description carries the full burden of behavioral disclosure. While it indicates a read operation ('Get') and describes the return value, it does not explicitly state that the tool is read-only, nor does it mention pagination, default parameters, or output structure. This leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no unnecessary words. Every sentence adds meaningful context about the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and indicates the type of output, but with no output schema and no annotations, it lacks details about the response format, sorting, or pagination behavior. It is adequate but not fully complete for a report tool with optional parameters.
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 each parameter (page, size, window) having a description including defaults and allowed values. The tool description adds no extra parameter-specific meaning beyond the schema, so the baseline of 3 applies.
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 and resource ('Get top clickers report') and clarifies the output ('Returns users who clicked on the most threat URLs'). It clearly communicates the tool's function, though it does not explicitly differentiate from sibling people-related tools like proofpoint_people_get_vap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: it identifies users who may need additional security training, implying when the report would be useful. However, it does not mention alternative tools or provide explicit exclusion criteria, so it falls short of a full 5.
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 behavioral disclosure. It only offers a high-level definition of the output data, but does not mention output format, pagination, required authentication, rate limits, or any side effects. This is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no filler. Every word adds value, defining the action and the specific meaning of 'permitted'.
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 has moderate complexity with four optional parameters, no output schema, and no annotations. The description is adequate for a basic understanding but lacks information about the response structure, how parameters combine (e.g., interval vs sinceTime), and any relationship to sibling tools. It is minimally viable but leaves gaps for an agent to fully use the 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?
The input schema provides 100% description coverage for all four parameters, each with clear meaning (e.g., interval, sinceTime, sinceSeconds, threatStatus). The description adds no additional parameter information beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('permitted clicks on threat URLs'). It adds a clarifying clause defining permitted clicks as 'clicks that were allowed through to the destination', which explicitly distinguishes it from the sibling tool proofpoint_tap_get_clicks_blocked.
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 defining what 'permitted' means, but it does not explicitly state when to use this tool versus alternatives like proofpoint_tap_get_clicks_blocked or when not to use it. No conditions, prerequisites, or exclusions 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 must disclose behavioral traits. It states it lists policies but does not mention that it is a read-only operation, any potential side effects, or rate limits. The safe read nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the main action and output. Every word adds value with no redundancy.
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 list tool with one optional parameter and no output schema, the description adequately covers purpose and return fields. It lacks details on pagination or ordering, but given the tool's simplicity, the information is largely complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'type', which already fully documents its purpose and enum values. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists email security policies and specifies the return fields (names, types, enabled status). It uses a specific verb and resource, and context from sibling tools confirms it is distinct from policy retrieval and route listing.
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 does not explicitly guide when to use this tool versus alternatives like proofpoint_policy_get or proofpoint_policy_list_routes. Usage is implicit from the listing nature, but no direct comparison or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation title. The annotation title says 'Release quarantined message (reversible)', while the description says 'Irreversible delivery but message itself is preserved.' This is a direct contradiction. Per instructions, this scores 1 and is flagged as annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the HIGH-IMPACT warning. Every sentence provides critical information: the action, irreversibility, potential maliciousness, and user confirmation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with annotations (destructiveHint=true), the description covers the key risks and required confirmation. It lacks details about return values or prerequisites, but given the simple scope and available annotations, it is reasonably complete.
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 only parameter (message_id) is already fully described in the schema as 'The quarantined message ID to release.' Schema coverage is 100%, so the description does not add extra semantic meaning beyond the warning that it is high-impact. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Release a quarantined message, delivering it to the intended recipient.' It uses a specific verb ('release') and resource ('quarantined message'), and is distinguishable from sibling tools like quarantine_delete or quarantine_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Confirm with the user before invoking' and warns of high impact, giving clear context for when to use it. It does not explicitly mention when not to use it or compare to alternatives, but the confirmation guidance is a strong usage guideline.
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 behavior disclosure. It mentions the fields searched but does not reveal pagination behavior, return format, or any other behavioral characteristics. For a search tool, it is minimally transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states what the tool does without any fluff or redundancy. It earns its place efficiently.
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 search tool with a fully described schema, the description is adequate. It clearly defines the search scope and aligns with the required parameters. However, no output schema exists, so a note about return data (e.g., quarantined message list) would improve completeness, but it is not strictly necessary.
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 are already well documented. The description adds value by naming the specific fields (sender, recipient, subject) that the query searches, but does not clarify additional parameters like startDate/endDate or pagination. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('quarantine') with clear scoping across sender, recipient, and subject fields. This distinguishes it from sibling tools like proofpoint_quarantine_list, release, and delete, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (searching quarantined items by keyword), but it does not explicitly contrast it with alternatives like proofpoint_quarantine_list, nor does it provide exclusions or conditions. Usage context is present but not fully 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions that the tool 'returns' metrics, but does not disclose side effects, required permissions, rate limits, or any other behavioral traits. As a read-only report it is likely safe, but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the purpose and the key output metrics without any redundant words. Every component earns its place.
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 tool with one optional parameter and no output schema, the description is mostly complete: it explains what the tool does and what metrics are returned. It lacks explicit usage context and behavioral details, but the simplicity of the tool mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of the single parameter 'window', including its enum values and default, so the description adds no additional parameter semantics. The baseline of 3 applies because the schema already provides the necessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('organization security summary'), and enumerates the returned metrics (total messages processed, threats blocked, quarantined, delivered). This distinguishes it from sibling report tools like threat_summary and mail_flow, which focus on different aspects.
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 used for obtaining an organization-level security summary, but it provides no explicit guidance on when to choose this tool over the many sibling report tools (e.g., threat_summary, mail_flow, executive_summary) or any exclusions.
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 for behavioral disclosure. It explains what the tool does (traces messages, tracks delivery status and history), which is transparent about its read-only nature implicitly. However, it does not mention pagination, rate limits, or any constraints or side effects beyond the basic behavior. For a search-style tool, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long and front-loaded with the primary action ('Trace messages through the Proofpoint mail flow'). Every sentence contributes meaningful information: the first states the core purpose, the second lists search dimensions and the outcome. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (9 optional parameters, no output schema, no annotations), the description covers the essential context: what is traced, how to search, and what information is tracked. The schema handles parameter details, and the description adds the 'mail flow' and 'processing history' context. It could benefit from noting that all parameters are optional or that at least one search criterion is needed, but it remains largely complete for a read-oriented search 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?
The input schema has 100% coverage for all nine parameters, so the baseline for parameter semantics is 3. The description adds minimal value by listing some searchable fields (sender, recipient, subject, message ID) that map exactly to schema properties, but it does not explain combination logic, date range usage, or API syntax. It neither improves nor degrades the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: tracing messages through Proofpoint mail flow and searching by sender, recipient, subject, or message ID. It uses a specific verb ('trace') and names the resource, which conveys the core purpose. However, it does not explicitly differentiate this from sibling tools like proofpoint_smart_search_get_message or proofpoint_events_list, so it misses the highest bar for sibling distinction.
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 usage scenario: when you need to trace message delivery status and processing history. It provides context but no explicit guidance on when to use this tool versus alternatives, and it does not state any prerequisites or exclusions. Sibling tools like proofpoint_smart_search_get_message are not referenced, so the usage guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'List' and phrase 'Shows how mail is routed' indicate a read-only operation, which is transparent. However, it does not mention pagination behavior (though page/per_page are in the schema) or what data is returned for each route, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action verb 'List' and the resource. Every sentence contributes meaning: the first states the direct action, and the second clarifies the broader purpose. There is no redundant or extraneous text.
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 list tool with only pagination parameters, the description adequately conveys the core functionality and purpose. However, since there is no output schema, it would be beneficial to mention what information is included in the returned routes (e.g., route names, destinations). The lack of such details makes the description minimally sufficient but not fully complete.
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 'page' and 'per_page' already described in the input schema. The tool description adds no additional parameter-specific meaning beyond what the schema provides. Baseline of 3 is appropriate because the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List email routing rules/routes.' It adds a clarifying second sentence, 'Shows how mail is routed based on policy configuration,' which provides context beyond the tool's name. It is distinguishable from sibling tool 'proofpoint_policy_list' by focusing on routes.
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 one needs to view email routing rules, but it does not explicitly state when to use this tool versus alternatives like 'proofpoint_policy_list' or 'proofpoint_policy_get.' No exclusions or comparisons to sibling tools are provided, so the guidance remains 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?
With no annotations, the description carries full burden for behavioral disclosure. It does say what is returned (URLs, IPs, domains, file hashes), but it omits critical details such as the requirement to provide either a campaign_id or time range, pagination behavior, and potential access requirements. This is a notable gap for a tool with all optional parameters.
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 sentence description with the primary action and resource front-loaded. Every sentence provides useful information without redundancy or filler, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with four optional parameters and no output schema, the description gives the core purpose and return types, which is adequate baseline. However, it lacks explicit guidance on parameter interdependencies, output structure, and potential limits, so the agent may face ambiguity in real use.
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%, providing a baseline of 3. The description adds semantic value by clarifying the tool works 'for a specific campaign or time range,' which indicates the relationship between campaign_id, interval, and sinceTime. This helps an agent understand how to set parameters, so I score above 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?
The description clearly states the tool's verb and resource: 'Get indicators of compromise (IOCs)' with scope 'for a specific campaign or time range.' This distinguishes it from sibling tools like proofpoint_threat_get_campaign and proofpoint_tap_get_all_threats, which focus on other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need IOCs for a campaign or time range) but does not explicitly address alternatives or exclusionary conditions. No mention of when not to use it or how it compares to similar threat-related tools, so guidance is only implied.
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?
There are no annotations, so the description carries the full burden. It discloses the nature of the response content (matched rules, sensitive data types, metadata), which is useful. However, it does not explicitly state that this is a read-only operation or mention potential error conditions or authorization requirements, though the 'Get' verb implicitly suggests read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource, followed by the specific data categories. No redundant or extraneous words are used.
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?
The tool has one parameter, no output schema, and no annotations. The description sufficiently explains the purpose and gives an overview of return content. While it could be more exhaustive about the response structure, it covers the essential parts for a simple get operation. Given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter (incident_id) with 'The DLP incident ID.' The description adds no additional parameter semantics beyond what the schema already provides, keeping the score at the baseline of 3.
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 the specific verb 'Get' with a clear resource: 'detailed information about a specific DLP incident.' It further specifies the content (matched rules, sensitive data types, message metadata), which clearly distinguishes it from sibling tools like proofpoint_dlp_list_incidents that list incidents rather than fetch details for a specific one.
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 phrase 'specific DLP incident' implies that this tool is for when you already have an incident ID and need detailed information, as opposed to listing incidents. However, it does not explicitly state when to use this over alternatives or mention prerequisites like needing an incident ID from a list operation.
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 of behavioral disclosure. It indicates this is a read operation ('Get') and describes the kind of data returned ('full threat analysis and message metadata'), but it does not explicitly state that it is read-only, mention any permissions or rate limits, or describe error conditions. While the verb implies non-destructive behavior, the description could add more transparency about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no fluff or redundancy. Every word adds value: 'Get detailed information about a specific detection event, including full threat analysis and message metadata.' This is appropriately sized for the tool's simplicity.
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 tool with one parameter and no output schema, the description is fairly complete. It states the purpose and gives a sense of the return content ('full threat analysis and message metadata'). It does not explain return format or error handling, but given the low complexity and the mention of what is included, it is adequate. The description could be more explicit about what 'detailed information' encompasses, but it does not leave major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (event_id) with a description ('The event ID to look up'). Schema coverage is 100%, so the baseline is 3. The tool description adds minimal meaning beyond the schema: it clarifies that the event is a 'detection event' and implies the ID references that event. However, it does not provide details about the ID format or where to find it, so it does not meaningfully enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific detection event.' It uses a specific verb ('Get') and resource ('detailed information about a specific detection event'), and mentions content ('full threat analysis and message metadata'). This distinguishes it from sibling tools like proofpoint_events_list (which lists events) and proofpoint_events_get_stats (which gets statistics).
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: use this when you need details for a specific detection event, as opposed to listing events or getting stats. However, it does not explicitly provide guidance on when to use this tool versus alternatives, nor does it mention any exclusion scenarios. The context is clear from the tool name and description, but explicit alternatives are not named.
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?
Without annotations, the description carries the transparency burden. It explicitly discloses the destructive action and its impact—'removes delivered messages from user mailboxes'—which is crucial for a mutation tool. It could add more about reversibility or permissions, but the core warning is present.
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, front-loaded with the action and warning, no waste. The description is efficiently structured and easily scannable.
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 destructive tool with no annotations, the description clearly communicates the operation and impact. It lacks some context (e.g., reversibility, prerequisites, post-pull behavior), but given the simple parameter set and clear warning, it is adequately complete.
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%, and the description adds no parameter-specific information. The schema already defines message_ids and reason clearly, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Auto-pull (search & destroy) messages from mailboxes' and explicitly notes it is a destructive operation that removes delivered messages. This distinguishes it from read-only sibling tools like proofpoint_forensics_search_messages.
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 destructive tool versus alternatives such as search_messages or quarantine_delete. It gives a warning but no use-case context or exclusions.
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 for disclosing behavior. It clearly indicates a read-only operation and specifies the output (risk score and attack details), but it omits nuances such as how the time window affects results or any prerequisites. It does not contradict any annotations, but the disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point without any wasted words or redundant details.
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 tool with 2 parameters and no output schema, the description adequately covers the main purpose and return value ('risk score and attack details'). It could be more complete by elaborating on what constitutes 'attack details,' but the high schema coverage compensates, making it sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as both 'email' and 'window' parameters have descriptions in the input schema. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('risk score and attack details for a specific user by email address'). This distinctly differentiates it from sibling tools like proofpoint_people_get_vap and proofpoint_people_get_top_clickers.
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?
No explicit when-to-use guidance is provided, nor are alternatives or exclusions mentioned. The intended use is implied—retrieving risk for a specific user—but there is no comparison to other people-related tools or scenarios where this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates a read-only operation via 'Show' but does not disclose additional behavioral details such as response format, required authentication, or interpretation of credentials status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's purpose without redundancy.
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?
The tool is a simple status-checking operation with no parameters and no output schema. The description covers its function but leaves ambiguity about the exact structure of the returned credential status and domain list. Given the simplicity, it is mostly 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?
The tool has zero parameters, so the schema is trivially complete. The description doesn't need to add parameter details.
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 the verb 'Show' with explicit objects 'credentials status' and 'available domains', clearly stating the tool's function. It distinguishes from sibling tools which focus on policies, events, URLs, etc.
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 is provided regarding when to use this tool versus alternatives. It doesn't mention use cases, prerequisites, or exclusions.
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 of behavioral disclosure. It does disclose a key behavioral nuance: these are messages that reached the recipient's mailbox despite containing threats, indicating a read-only query. However, it lacks details on authentication needs, default time ranges, pagination, or potential hazards. This is adequate but not rich, warranting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that state the core purpose and a clarifying elaboration. Every word earns its place, and the most important information is front-loaded. No redundancies or filler exist.
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 read-only list tool with no output schema and no annotations, the description provides only the basic purpose but omits details such as whether a time interval is required, how results are ordered, or how to combine parameters. While the schema documents parameters, additional context about tool behavior would improve completeness. This is adequate but not fully complete, earning a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, including an enum for threatStatus, so the schema already explains each parameter. The description adds no semantic value beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets messages delivered containing threats, which are messages that reached the recipient's mailbox despite containing identified threats. This specific verb-resource combination distinguishes it from sibling tools like proofpoint_tap_get_messages_blocked and proofpoint_tap_get_clicks_permitted, making its purpose unambiguous.
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 implies when to use this tool by explicitly defining the scope: messages that reached the mailbox despite threats. This contrasts with the likely use of proofpoint_tap_get_messages_blocked. However, it does not explicitly mention alternatives or exclusions, so it falls short of 'explicit when/when-not' guidance, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns aggregated behavioral analysis, implying a read operation, but does not detail permissions, potential result size, or how threats without evidence are handled.
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 efficient sentences, front-loaded with the main action, no redundant information, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get tool with no output schema, the description provides a high-level overview of the return value (aggregated behavioral analysis) sufficient for basic usage, but lacks detail on result structure or pagination. Still, the tool is relatively simple, so completeness is good but not perfect.
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 clear description for campaign_id. The tool description adds no additional nuance beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves forensic evidence for all threats in a campaign and returns aggregated behavioral analysis, distinguishing it from the single-threat sibling tool proofpoint_forensics_get_threat.
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 phrase 'for all threats in a campaign' and 'across all associated threats' explicitly establishes the tool's scope for campaign-level forensics, though it does not name alternatives or exclusions, so some inference is still required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions the tool returns detailed information including rules, conditions, and actions, which is a read-only operation. It does not disclose potential errors, auth requirements, or rate limits, but for a simple getter this is acceptable; adds some value 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?
One concise sentence that immediately states the action and object. No 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?
Given the tool has a single parameter and no output schema, the description adequately covers the purpose and return content (rules, conditions, actions). It might have noted error scenarios, but overall complete for a simple GET operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter policy_id with a clear description, giving 100% coverage. The tool description adds no additional detail beyond saying 'specific policy,' so it meets the baseline but does not enrich further.
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?
Description clearly states the tool retrieves details for a specific policy, listing the main components (rules, conditions, actions). The verb 'Get' and resource 'specific policy' distinguishes it from sibling proofpoint_policy_list.
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 implies this tool is for fetching details of a single policy by ID, which is clear in the context of a list tool sibling. It does not explicitly mention alternatives or exclusions, so it's clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It adds value by stating the return fields (threat type, classification, indicators), but it does not describe error behavior, rate limits, or explicitly confirm read-only semantics beyond the verb 'Get'. 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?
The description is two short sentences that are front-loaded with the primary action and then provide helpful return details. Every word 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.
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 lookup tool with no output schema, the description is nearly complete. It explains both the purpose and the return values. It does not cover error conditions or edge cases, but those are not critical for such a simple tool, so it misses a perfect 5 only slightly.
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 already provides a full description of the single parameter threat_id, including format (SHA256 hash or Proofpoint threat ID). The description merely repeats 'threat ID' without adding further semantics, so it does not go beyond the schema, matching the baseline for 100% schema 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 a specific verb ('Get'), a resource ('detailed information about a specific threat'), and the key identifier ('by its threat ID'). It also lists the return contents (threat type, classification, indicators), which distinguishes it from sibling tools like campaign lookups or IOC list 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 implies the usage context: when you have a threat ID and want details about that specific threat. It is clear and direct, though it does not explicitly mention alternatives or when not to use it, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does state what the tool returns (actors, malware families, techniques, associated messages), which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention error behavior, permissions, or side effects. This is adequate for a simple get tool but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first states the action and object, the second lists the return content. Every word earns its place, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with no output schema, the description is nearly complete. It explains what the tool does and what the response includes. It lacks minor details like whether the return is paginated (especially for 'associated messages') but overall provides enough context for correct invocation.
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 already provides 100% coverage for the single parameter with a clear description ('The campaign ID to look up'). The description's phrase 'by campaign ID' adds no new semantic detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and resource ('specific threat campaign'), with a clear identifier ('campaign ID'). It also lists the returned data categories (actors, malware families, techniques, messages), which clearly distinguishes it from sibling tools like generic threat lookups or forensic campaign retrieval.
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 implies when to use this tool: when you have a campaign ID and need campaign details. It provides clear context but does not explicitly mention alternatives or exclusions, so it scores a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the purpose and confirms it is a reversal operation, but does not specify any limitations (e.g., only works on Proofpoint's urldefense format), error behavior, or whether it requires special permissions. This is a minor gap for a simple non-destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and every sentence adds value. The first states the action and result; the second provides useful background on why Proofpoint rewrites URLs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without an output schema, the description adequately conveys the input, the process, and the expected output ('original URLs'). It could be slightly more explicit about the return format, but given the low complexity, it is sufficiently complete to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'urls' parameter with a clear description and an example. The tool description adds no additional parameter semantics beyond restating that it decodes 'one or more' URLs, which is already implied by the array type. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('decode'), the resource ('Proofpoint URL Defense rewritten URLs'), and the result ('back to the original URLs'). It also explains the context (Proofpoint rewrites URLs for click-time protection), which distinguishes it from sibling tools like proofpoint_url_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (when you have Proofpoint-encoded URLs and want the originals) and explains the mechanism ('reverses that encoding'). While it does not explicitly name alternatives or exclusions, the use case is unambiguous for a simple decode operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It openly describes the report contents, but it does not explicitly mention read-only behavior, permissions required, or any operational constraints. The 'Get' verb implies a safe read operation, but the description could still offer more explicit transparency about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise, and front-loaded with the primary action. Every sentence adds value: the first states the purpose, the second defines the audience, and the third lists key contents. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with a single optional parameter and no output schema. The description adequately covers the purpose, audience, and key content areas, leaving no significant gaps for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'window' with an enum and default value, so schema coverage is 100%. The description adds no additional insight into the parameter beyond what the schema already provides, meeting the baseline expectation.
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' with the resource 'executive summary report', clearly stating what the tool does. It also differentiates from sibling report tools by describing the content as high-level security posture suitable for management reporting, including threat trends, top targeted users, and effectiveness metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is 'suitable for management reporting', indicating when this report is appropriate. However, it does not explicitly name alternative tool or exclusions among the many report siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses that the tool is a non-essential discovery aid with no side effects, and that tools are callable regardless. It doesn't detail error conditions, but for a help tool this is sufficient.
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?
Three short sentences that are front-loaded with the action, then output, then usage caveat. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help/discovery tool with a single well-documented parameter and no output schema, the description covers purpose, output, and usage context. The agent knows exactly what to expect.
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 already provides 100% coverage, including descriptions for each enum value. The description adds no extra semantic details about the 'domain' parameter, simply referring to 'the selected domain.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Discover available Proofpoint tools by domain' and specifies it 'Returns tool names and descriptions for the selected domain.' This distinguishes it from sibling operation tools as a discovery/navigation aid.
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?
It explicitly states when not to use it as a prerequisite: 'All tools are callable at any time — this is a help/discovery aid, not a prerequisite.' It implies the use case of exploring available tools in a chosen domain, but doesn't name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by adding critical behavioral details: 'IRREVERSIBLE,' 'cannot be undone,' 'remove the message from quarantine storage,' and the need for user confirmation. This enriches the destructiveHint annotation and provides actionable safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with a warning, and every sentence contributes essential information. There is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple one-parameter destructive operation with annotations already covering safety indicators, the description is fully sufficient. It explains the irreversible nature, the storage impact, and the required user confirmation, which are the key contextual elements for such a 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?
The input schema fully describes the only parameter (message_id) with 100% coverage. The tool description does not add further semantic detail about the parameter, so it does not exceed the schema's 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?
The description clearly states the tool's function: 'Permanently delete a quarantined message.' The verb 'delete' and resource 'quarantined message' are specific, and it distinguishes from sibling tools like proofpoint_quarantine_list, proofpoint_quarantine_search, and proofpoint_quarantine_release.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by warning 'DESTRUCTIVE — IRREVERSIBLE' and instructing 'Confirm with the user before invoking.' It does not explicitly name alternatives (e.g., proofpoint_quarantine_release for non-destructive recovery), but the destructive nature makes the when-to-use context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![proofpoint-mcp MCP server](https://glama.ai/mcp/servers/wyre-technology/proofpoint-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wyre-technology/proofpoint-mcp)

Score Badge

Copy to your README.md:

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

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