magicsword-mcp
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@magicsword-mcplist critical alerts from the last 24 hours"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
magicsword-mcp
A Model Context Protocol server for MagicSword. Lets users running Claude Desktop, Cursor, or any MCP-aware client manage MagicSword conversationally — list endpoints, query alerts, triage findings, mint enrollment tokens, and preview / commit policy changes.
The server is a thin, opinionated wrapper around the
/api/public/v1/* customer API exposed by the Magic Portal. It runs on
the user's machine, holds an msk_… API key, and speaks MCP over stdio.
Plan gate. The customer API is Enterprise-only. With a pilot-tier key the server returns a clear "this MagicSword org needs the Enterprise plan to use MCP" message; nothing else works until the org is upgraded.
Quick start
Requires Node.js 22+, an installed MCP client, and a MagicSword Enterprise API key from Magic Portal → Settings → API Keys.
Recommended: install and connect your client in one command. Setup prompts for your key privately and lets you choose Claude Desktop, Codex, Claude Code, or Cursor:
npm install -g @magicsword-io/magicsword-mcp && magicsword-mcp configureAlready know your client? Run the matching one-liner:
Client | Install and configure |
Claude Desktop |
|
Cursor |
|
Claude Code |
|
OpenAI Codex |
|
Prefer your client's own registration command? After saving your key locally, these also work without a global server install:
codex mcp add magicsword --env MAGICSWORD_BASE_URL=https://www.magicsword.io -- npx -y @magicsword-io/magicsword-mcp
claude mcp add --scope user --transport stdio magicsword --env MAGICSWORD_BASE_URL=https://www.magicsword.io -- npx -y @magicsword-io/magicsword-mcpThese are also a fallback when automatic registration cannot launch a client's CLI on Windows. Desktop launch still requires Node/npx to be available to that client; the recommended setup uses absolute paths instead.
Install buttons: Cursor and VS Code
First save your API key locally (once per machine):
npm install -g @magicsword-io/magicsword-mcp && magicsword-mcp configure --client manualThen click your client's button and approve its installation prompt:
These buttons register a local npx server pointing at production. They contain
no API key; the server reads ~/.magicsword/mcp.json. They require npx on the
client's PATH. If a desktop app cannot find Node or npx, use the recommended
setup above for absolute launch paths, or copy the absolute command and
args printed by configure --client manual into its configuration.
Manual JSON fallback
After saving your key above, merge this entry into Claude Desktop's
claude_desktop_config.json or Cursor's ~/.cursor/mcp.json, preserving your
other servers:
{
"mcpServers": {
"magicsword": {
"command": "npx",
"args": [
"-y",
"@magicsword-io/magicsword-mcp"
],
"env": {
"MAGICSWORD_BASE_URL": "https://www.magicsword.io"
}
}
}
}For VS Code / Insiders, run MCP: Open User Configuration and merge this
configuration (VS Code uses servers, not mcpServers):
{
"servers": {
"magicsword": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@magicsword-io/magicsword-mcp"
],
"env": {
"MAGICSWORD_BASE_URL": "https://www.magicsword.io"
}
}
}
}Restart your client or start a new session, then ask it to call whoami and
list_endpoints. Both must succeed to verify authentication and read access.
The official MCP Registry identifier is
io.github.magicsword-io/magicsword-mcp. Client-specific details follow below.
Related MCP server: Claude Fleet Monitor
Configure
magicsword-mcp configureSetup asks for an API key with hidden input (mint one in Magic Portal →
Settings → API Keys) and which client to connect: Claude Desktop, Codex,
Claude Code, Cursor, or manual configuration. It saves the key only in
~/.magicsword/mcp.json (mode 600). The Portal defaults to
https://www.magicsword.io, replacing any saved preview origin. A custom
origin requires an explicit --base-url option.
Setup registers the selected client at its standard user-level location,
preserves other servers and settings, and creates a private backup of existing
client configuration. It updates an existing magicsword entry for JSON clients
and Codex. Claude Code requires that name to be available; use its own MCP
commands to remove an old registration before retrying. Codex and Claude Code
registration require their respective CLIs to be installed.
To choose a client directly, or reuse a saved key without prompting:
magicsword-mcp configure --client codex
magicsword-mcp configure --non-interactive --client claude-desktop
magicsword-mcp configure --client cursor --client-config /path/to/mcp.jsonThe launch entry uses absolute Node and installed server paths so desktop apps
can start it without inheriting your terminal's PATH. Re-run setup if you move
your Node installation or install the package under a different Node version.
Manual setup prints a credential-free launch entry for other local stdio MCP
clients. Unattended setup without --client writes only the MagicSword file.
Restart the selected client or start a new session to load magicsword and its
22 tools. Ask it to call whoami and then list_endpoints to verify access;
discovery alone does not verify API-key scopes. Claude Desktop logs are at
~/Library/Logs/Claude/mcp*.log on macOS. Browser-only clients require a remote
MCP transport; this package provides a local stdio server.
If you need a per-client override instead of ~/.magicsword/mcp.json, set
MAGICSWORD_API_KEY and optionally MAGICSWORD_BASE_URL in that MCP host's
environment. Keep API keys out of shared config snippets and screenshots.
Tools
Tool | What it does |
| Returns organization, key id, and scopes. Always call first when troubleshooting. |
| Lists endpoints with optional platform / status / hostname-glob filtering. |
| Fetches one endpoint with OS, policy, compliance, upgrade, heartbeat, and AMSI details. |
| Lists available agent versions and per-platform latest releases. |
| Searches alerts by severity / ack state / since / hostname / MITRE technique. |
| Searches Investigate events by name, filename, path, hash, publisher, computer, or package family, with type/status/policy/endpoint/time filters. |
| Fetches one alert directly with triggering events, metadata, and file context; optionally acknowledges or dismisses it. |
| Lists policies with current version + mode. |
| Shows one policy by id. |
| Lists rules or adds explicit / event-derived rules to a policy by id or name. Avoid explicit flat hash rules for Windows WDAC. |
| Resolves endpoints and previews a policy assignment; |
| Two-step preview/confirm flip with a server-issued one-time confirm token. Safety-critical. |
| Discovers enabled global and organization-owned intel sources and IDs, with platform and pagination filters. |
| Lists private intel feeds or feed items. |
| Creates or updates feeds; deletion requires a preview followed by |
| Edits feed items; deletion requires a preview followed by |
| Adds indicators extracted from reports into a private feed. |
| Lists, attaches, or detaches intel feeds on a policy. |
| Previews upgrades for an endpoint selection; |
| Queues an endpoint check-in command. |
| Mints a one-time agent enrollment token. |
| Returns the install one-liner for macOS / Linux / Windows. No API call. |
Write tools require matching Customer API scopes in Magic Portal, such as
alerts:write, policies:write, endpoints:write, or intel:write.
Event review uses alerts:read; turning selected events into policy rules
uses policies:write.
Tools publish standard MCP safety annotations. Read-only discovery tools are marked read-only and idempotent; enforcement, deletion, policy assignment, rule changes, and agent upgrades are marked destructive so MCP clients can apply appropriate confirmation UX.
Adding and listing policy rules
manage_policy_rules accepts one input source per add: rules for explicit
rules, or event_ids for rules derived from telemetry. Each accepts 1–100 items.
Use policy_id, or policy_name with an optional platform to resolve a name.
The policy must already exist; ambiguous names require an ID or platform.
For example, to block the filenames from issue #5 on a Windows blocklist policy:
{
"action": "add",
"policy_name": "Workstations",
"platform": "windows",
"rules": [
{ "type": "filename", "value": "rustdesk.exe", "status": "blocked" },
{ "type": "filename", "value": "mshta.exe", "status": "blocked" },
{ "type": "filename", "value": "wscript.exe", "status": "blocked" }
]
}Explicit rules use type and value, with optional status (defaults to
blocked). Unknown rule fields are rejected; rule_type / file_name are not
substitutes. Filename and path values must be non-empty strings or supported
value objects. Publisher values require publisherName (or publisher) and a
valid tbsHash (or tbs_hash / certificate_thumbprint). Optional rule metadata
includes name, mode, version bounds, signer/file-attribute references,
package_version, and target_platforms. The Portal validates whether a rule
can be enforced on the resolved policy's platform. Flat Windows WDAC hashes
remain unsupported; use telemetry-derived rules or private intelligence feeds.
For telemetry, use event_ids with top-level status (defaults to allowed)
and an optional type override. Top-level status and type cannot be used
with explicit rules; set those fields on each rule instead.
Adds preserve existing rules and intelligence-source links. Matching customer
rules with a different status are updated; rules already at the requested status
are reported as unchanged duplicates. Feed-owned rules retain their provenance;
unsupported conflicts with a feed rule return an API error. The tool reports
the Portal's actual added_count, updated_count, and duplicate_count, and retains its version
information in structured output. An unchanged duplicate batch reports “No
changes needed.” Unexplained zero changes or malformed responses are errors:
inspect the current rules/version before retrying because the request may have
created a version. Writes are never retried automatically.
For event-derived batches, a count total smaller than the number of unique
requested events is also an error: some events may not have produced rules.
Successful changes and version details remain available in structured output.
To verify the current version's stored rules:
{ "action": "list", "policy_id": "<policy UUID>", "limit": 500, "offset": 0 }List requires an ID and policies:read. It returns stored customer rules and
materialized feed rules for the current version, with total, limit, and
offset. The default page size is 100, maximum 500; increase offset until all
total rows have been read. An empty page does not describe other versions or
indicators that have not been materialized into this version.
Example transcript
User: Show me unack'd critical alerts from the last 24h.
Claude: [calls find_alerts severity=critical acknowledged=false since=...]
→ 3 critical alerts on 2 endpoints. Want me to triage the top one?
User: Yes.
Claude: [calls triage_alert]
→ Evidence chain: cmd.exe spawned by winword.exe with -enc base64.
MITRE T1059.001. Acknowledge with comment "office macro chain — under investigation"?
User: Yes, and extract the IOCs from this report into our SOC feed.
Claude: [calls upsert_customer_intel_items]
→ Upserted 47 indicators into feed 8d6...
User: Show me audited or blocked events from the last day.
Claude: [calls list_events hours=24 status=audited,blocked]
→ 31 events. Here are the file paths, publishers, and hashes.
User: Allow the first 5 on the Workstations policy.
Claude: [calls manage_policy_rules action=add policy_name=Workstations event_ids=[...] status=allowed]
→ Created a new policy version with 5 allowed rules.Investigate events and attach intelligence
Ask “Show audited filename events for image.png from the last week.” The agent
calls list_events with type=filename, status=audited, file_name=image.png,
and hours=168. file_name is an exact, case-sensitive match, including literal
punctuation. For broader discovery, q searches the same seven fields as Portal
Investigate: name, filename, path, hash, publisher, computer, and package family.
It is a case-insensitive literal substring search accepting up to 120 characters,
including Unicode, quotes, commas, parentheses, and Windows backslashes. %, _,
and * are literal characters; wildcard and field-query syntax are not supported.
Control characters are rejected. A blank query applies no text filter.
Filters combine, so type=filename selects filename events rather than all event
types that happen to include a filename. Omit type to search across event types.
For example, “Find events from publisher Contoso, Inc. (R&D)” uses
list_events q="Contoso, Inc. (R&D)". To block a file found in those results,
review the returned IDs and rule context, choose the intended rule type, and call
manage_policy_rules action=add policy_id=... event_ids=["<selected-event-id>"] status=blocked type=filename. Search does not change policies or automatically
block every match. Searching a publisher does not imply blocking that publisher;
the selected rule type determines what is blocked. Event IDs can also derive
other supported rules when appropriate, subject to Portal platform validation.
The default window is 24 hours with statuses audited,blocked; use since for
an explicit lower bound. The window uses the last observation time, falling back
to creation time. Results include file paths, publishers, hashes, computers,
occurrence counts, rule context, and pagination. Use limit and offset for
additional pages. This is normalized event data rather than a raw event log.
For “Attach LOLDrivers intel to my Windows policy”, the workflow is:
list_policies platform=windowsidentifies the policy name and ID.list_intel_sources platform=windowsreturns available source names and IDs. It defaults to enabled sources; useis_enabled=falseto inspect disabled ones. Uselimit(up to 100) andoffsetto discover additional pages.manage_policy_intel_sources action=list policy_id=...shows current attachments.After identifying the intended policy and sources, use
manage_policy_intel_sources action=attach policy_id=... source_ids=[...]. The result reports new attachments and sources already attached separately.List the policy attachments again to verify the result.
Source discovery requires intel:read, policy discovery/attachment listing
requires policies:read, and attachment requires policies:write. Source
visibility does not guarantee premium entitlement; the API checks it when attaching.
Attachments create a policy version and take effect as endpoints receive it.
Configuration sources, in order of precedence
MAGICSWORD_API_KEY/MAGICSWORD_BASE_URLenv vars (set by the MCP host).~/.magicsword/mcp.json(or$MAGICSWORD_CONFIG).Default base URL
https://www.magicsword.io.
Optional transport controls are MAGICSWORD_REQUEST_TIMEOUT_MS (default
30 seconds), MAGICSWORD_RESPONSE_MAX_BYTES (default 4 MiB), and
MAGICSWORD_GET_RETRIES (default 2, maximum 3). Only idempotent GET requests
are retried; write actions are never retried automatically.
Safety notes
flip_to_enforcingis two-step. The first call returns a server preview and one-time confirmation token; you must show the preview to a human and pass the token back to commit. Tokens are short-lived and single-use. This is not MFA or server-verified human approval: the same API key can perform both calls. The MCP host must obtain human approval before committing. A commit response must confirm success for the requested policy and identify its new version; otherwise useshow_policyto verify the outcome before retrying. Success confirms the server policy version change. Endpoint enforcement takes effect through check-in; this response does not confirm endpoint delivery.Intel attachments use enabled sources in batches of at most 60. Capture requests share the API key creator's rate budget with the Portal UI. A 429 response includes retry guidance; wait before submitting another batch. Attachment summaries report newly attached and already-attached counts separately. Invalid or incomplete counts require listing attachments before retrying.
Fleet changes and deletion are explicit. Endpoint upgrades, policy assignments, and private-intel deletion return a no-op preview unless the approved follow-up call includes
confirm=true.Windows WDAC policy edits should not use explicit flat file hashes. Use
manage_policy_ruleswithevent_idswhen approving audit events so the Portal can derive supported path / publisher / filename rules, or useupsert_customer_intel_itemsfor hash, AuthentiHash, page-hash, and TBS intelligence in a private feed.Secrets stay on the user's machine. The MCP server is a local stdio process; the API key is read from
~/.magicsword/mcp.json(mode 600) or an env var passed by the MCP host. Nothing is sent off-machine except the requests to the configuredMAGICSWORD_BASE_URL.Remote Portal URLs must use HTTPS. Plain HTTP is accepted only for localhost development. Configured URLs cannot contain credentials, paths, query strings, or fragments.
Develop
npm install
npm run build
npm test
npm run test:package
npm run release:verify
node dist/index.js --versionTests validate --help, --version, production-default migration, private client
registration, preservation and rollback, configure validation, secret redaction,
modern and legacy MCP startup, focused mutation confirmation, retry and timeout
semantics, response-size bounds, malformed responses, write non-retry behavior,
all 22 tools' HTTP contracts and confirmation flows over modern and legacy
stdio, explicit filename round trips, invalid rule shapes, ambiguous inputs,
actual mutation counts, and npm pack
contents. test:package installs a production-only tarball and
checks the installed CLI and MCP tool discovery; release:verify checks all
release metadata. See docs/RELEASING.md for npm and MCP Registry releases.
An opt-in live policy test is also available after npm run build:
MAGICSWORD_LIVE_TEST=1 MAGICSWORD_TEST_POLICY_ID="<disposable-policy-uuid>" node scripts/live-policy-rules.mjsUse your private saved credentials or MAGICSWORD_API_KEY; do not put keys in
commands or shared logs. This test writes policy versions and requires a
disposable, unassigned Windows audit policy named with the prefix
MCP issue 5 disposable verification, seeded with more than 1,000 baseline rules
with at least one attached intelligence source, and no existing rustdesk.exe,
mshta.exe, or wscript.exe customer rules.
It verifies append behavior, pagination, intelligence-source preservation,
repeat adds, status updates, invalid inputs, and event-derived filenames when
suitable telemetry exists. It also exercises discovery and read tools through
stdio. It prints assertion names/counts only. Remove the disposable policy and
its versions after inspection; the test does not create or delete the fixture.
Set MAGICSWORD_TEST_PROTOCOL=legacy to exercise the legacy live transport.
With the same disposable policy and opt-in environment, run
node scripts/live-demo-tools.mjs to check assignment, upgrade, and enforcement
previews, all three platforms' installer instructions, and a disabled temporary
feed's create/update/upsert/list/item-delete/attach/detach/feed-delete flows.
The feed is removed in finally; the policy fixture still requires manual
cleanup. These checks never commit endpoint assignments, upgrades, or enforcement.
Actual endpoint commands, enrollment tokens, and alert acknowledgements/dismissals
are covered by the local HTTP fixtures.
Available Tools
22 toolsagent_install_instructionsShow the MagicSword agent install one-liner for a platformARead-onlyIdempotent
Returns the install + enroll commands for the MagicSword agent on a given platform. No API call. Useful when the LLM is helping a user onboard a new endpoint and wants to hand them the exact one-liner.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform for install instructions |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the genuinely useful fact that there is 'No API call' -- i.e., this is a static, side-effect-free local generator rather than a server round-trip. It does not state the return shape or whether output varies with account state, so it is a meaningful addition rather than a complete one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler: what it returns is front-loaded, the implementation fact ('No API call') follows, and the usage scenario comes last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description tells the agent what the return contains (install + enroll commands) and that it is static, which is essentially everything needed to call it correctly. It could say slightly more about the exact format of the returned commands, but the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single platform parameter is an enum with its own description, so the schema carries the full burden here. The description only restates 'on a given platform' and adds no syntax, defaults, or behavior for the parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Returns) and a precisely scoped resource (the install + enroll commands for the MagicSword agent on a given platform). An agent can tell this apart from mint_enrollment_token or list_agent_releases without inspecting either schema, because the description names both the payload and the platform scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use context: helping a user onboard a new endpoint and handing them the exact one-liner. That is clear when-to-use guidance. It stops short of naming alternatives (e.g., mint_enrollment_token) or when NOT to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apply_policy_to_endpointsAssign a policy to endpointsADestructive
Resolves either an explicit endpoint_ids list or a hostname_pattern (glob) into a concrete set of endpoints, then previews the concrete assignment. Rerun with confirm=true after human approval to apply it.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true only after a human approves the resolved preview | |
| platform | No | Optional platform filter, applied when resolving hostname_pattern | |
| policy_id | Yes | The policy UUID to assign | |
| endpoint_ids | No | Explicit list of endpoint UUIDs. Mutually exclusive with hostname_pattern. | |
| hostname_pattern | No | Glob pattern (case-insensitive) matched against computer_name. Mutually exclusive with endpoint_ids. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the human-approval gating and the preview-before-apply two-phase contract, which is real behavioral context an agent must honor. It does not say what applying overwrites (e.g., replacing an existing policy assignment) or what the preview returns, so it is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the sequence of operations (resolve/preview, then confirm) is front-loaded. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent mutation with no output schema, the description covers the essential workflow and the safety gate. The remaining gap is the preview result itself — with no output schema, the definition never explains what the resolved endpoint set or preview response looks like, which matters for the approval step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents policy_id, endpoint_ids (mutually exclusive, max 500), hostname_pattern (case-insensitive glob on computer_name), platform, and confirm. The description mostly restates the endpoint_ids/hostname_pattern duality and adds no new syntax or format detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (assign a policy to endpoints) and describes the two-stage mechanism: resolve endpoint_ids/hostname_pattern into a concrete set, preview, then apply. Nothing here overlaps with siblings like flip_to_enforcing or manage_policy_rules, so an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating instructions: the first call previews, and the tool should be rerun with confirm=true only after human approval. It also signals that exactly one of endpoint_ids/hostname_pattern drives the resolution. It stops short of naming an alternative tool or stating when this assignment is preferable to other policy operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_alertsFind MagicSword alertsARead-onlyIdempotent
Search MagicSword alerts by severity, ack state, time window, hostname, or MITRE technique. All filters run server-side before pagination, so total and page counts describe the actual result set. Use this for triage queries like "unack'd critical alerts in the last 24h".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 50, max 200) | |
| since | No | ISO8601 lower bound on created_at (e.g. "2026-05-08T00:00:00Z" or "2026-05-09") | |
| offset | No | Skip this many records before returning | |
| hostname | No | Glob matched case-insensitively against endpoint name, e.g. "prod-*" | |
| severity | No | Restrict to one severity tier | |
| acknowledged | No | true = only acked alerts, false = only unacked, omit = both | |
| mitre_technique | No | Exact MITRE ATT&CK technique or sub-technique, e.g. "T1059" or "T1059.001" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lowered. The description still adds genuine value by disclosing that filters run server-side before pagination, meaning total and page counts reflect the real result set — a behavioral trait not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, all front-loaded: purpose first, then the pagination caveat, then the usage example. No filler; each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 optional params fully documented in the schema, safety covered by annotations, and pagination behavior explained, an agent has enough to call this correctly. No output schema is present, yet the description touches on result counts; the only minor gap is the absence of sibling routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (limit, since, offset, hostname, severity, acknowledged, mitre_technique) is already documented in the schema. The description names those same dimensions but adds no extra format or syntax detail beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('MagicSword alerts') and enumerates the filterable dimensions (severity, ack state, time window, hostname, MITRE technique). It is clearly distinguishable from siblings like list_events or triage_alert, though it never explicitly names what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage context: triage queries such as "unack'd critical alerts in the last 24h". This makes the intended use case clear, but no exclusions or explicit alternatives (e.g. when to prefer triage_alert) are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flip_to_enforcingFlip a policy from audit to enforcingDestructive
Promotes a MagicSword policy from audit to enforcing mode through the Portal server confirmation flow. First call without confirmation_token to get readiness, blockers, endpoint count, and a one-time token. Show the preview to the human. Second call with confirmation_token to commit. Requires policies:write. This is two-step API confirmation, not MFA: the same API key can perform both calls. Human approval must be obtained by the MCP host.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | Policy UUID to flip | |
| confirmation_token | No | Token returned by the preview call. Passing this commits enforcement. | |
| acknowledge_blockers | No | Set true only when the human explicitly accepts preview blockers. Used on the preview call. |
list_agent_releasesList MagicSword agent releasesARead-onlyIdempotent
Lists available MagicSword agent releases and per-platform latest markers before an upgrade is queued. Requires endpoints:read.
| Name | Required | Description | Default |
|---|---|---|---|
| latest | No | Return only the latest release for the selected platform | |
| platform | No | Platform used for latest filtering |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds value beyond that by disclosing the required scope ('Requires endpoints:read') and by summarizing the payload (available releases and per-platform latest markers), though it says nothing about pagination or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads what is returned and appends the prerequisite; there is no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter, read-only listing tool with no output schema and full schema coverage, the description supplies the permission prerequisite and the shape of the result. It is nearly complete, missing only minor detail such as whether both parameters interact (latest requires platform).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'latest' and 'platform' are fully documented in the schema, including the enum values. The description adds no syntax, default, or interaction detail beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists available MagicSword agent releases') plus the scope of what is returned ('per-platform latest markers'), and the phrase 'before an upgrade is queued' implicitly separates this read-only discovery call from the mutating upgrade_endpoints sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'before an upgrade is queued' gives a clear workflow context in which to call this tool, which is genuine when-to-use guidance. It stops short of naming an alternative or stating exclusions, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_customer_intel_feedsList private intelligence feedsARead-onlyIdempotent
Lists private intelligence feeds and, optionally, a page of items for one feed. Requires intel:read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Item/feed page size | |
| offset | No | Pagination offset | |
| feed_id | No | Optional feed UUID. When provided, include feed items. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the auth requirement and the conditional behavior where a feed_id switches the result from a feed list to a feed's items. It does not describe ordering, pagination defaults, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary behavior and followed by the permission prerequisite. No filler and nothing redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-shape burden, and it does indicate that results may be feeds or a page of items. Minor gaps remain around pagination defaults and item-vs-feed response structure, but for a three-parameter read tool this is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each of limit, offset, and feed_id is documented in the schema itself. The description's 'optionally, a page of items for one feed' hints at feed_id's effect, but adds no syntax or boundary detail beyond what the schema already supplies, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Lists) plus resource (private intelligence feeds) with the extra scope of 'optionally, a page of items for one feed'. This clearly separates it from the sibling mutators manage_customer_intel_feed and manage_customer_intel_item, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the required scope ('Requires intel:read'), which is real usage guidance, but never says when to choose this list tool over the manage_* siblings or the upsert tool. Usage is implied by verb/annotation rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_endpointsList MagicSword endpointsARead-onlyIdempotent
Lists endpoints (devices) enrolled in the MagicSword org. Filter by platform (windows/macos/linux), status, or hostname pattern (glob: "*", "?"). All filters run server-side before pagination. Returns up to limit endpoints (default 100, max 500). Use this to find endpoint IDs for other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 100, max 500) | |
| offset | No | Skip this many records before returning (for paging) | |
| status | No | Filter by endpoint lifecycle status | |
| platform | No | Filter by OS platform | |
| hostname_pattern | No | Glob pattern matched case-insensitively against computer_name (e.g. "prod-*", "win-?-db") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is low, yet the description still adds real behavior: filtering happens server-side before pagination and the result is capped at limit (default 100, max 500). It does not describe the returned record shape, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then filters, then pagination, then the recommended use. No filler or repetition of boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list tool with a rich schema and no output schema, the description supplies the pagination behavior, server-side filtering guarantee, and the downstream purpose (retrieving endpoint IDs). Minor residual gap: it does not hint at what fields each listed endpoint contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter, including enums and the glob semantics of hostname_pattern. The description largely restates those enums and the limit default, adding only marginal value over structured data, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Lists endpoints (devices) enrolled in the MagicSword org") and explicitly maps the term endpoint to device. An agent can distinguish it from the singular sibling show_endpoint without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: "Use this to find endpoint IDs for other tools," which tells the agent why to pick it. However, it never names an alternative (e.g. show_endpoint for full detail) or states when not to use it, so the routing guidance is incomplete relative to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_eventsInvestigate MagicSword audit/block eventsRead-onlyIdempotent
Searches normalized Investigate events across name, filename, path, hash, publisher, computer, and package family, with optional type, status, policy, and endpoint filters. For “show filename audit events for image.png”, use type=filename, status=audited, file_name=image.png. Defaults to audited and blocked events over the last 24 hours, based on when they were last observed. Returns file paths, publishers, hashes, endpoint names, occurrence counts, timestamps, and rule context without raw telemetry. Search is read-only. To create rules, review the results and pass selected event IDs to manage_policy_rules with an explicit status and optional rule type. Requires alerts:read.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Case-insensitive literal substring search across name, filename, path, hash, publisher, computer, and package family. Up to 120 characters, including Unicode and punctuation; %, _, and * are literal. Omit type to search across event types. Combine with file_name for an exact filename. | |
| type | No | Comma-separated event types, e.g. process,filepath,hash | |
| hours | No | Lookback window in hours; defaults to 24 | |
| limit | No | ||
| since | No | ISO timestamp lower bound; overrides hours when provided | |
| offset | No | ||
| status | No | Comma-separated statuses, e.g. audited,blocked | |
| platform | No | ||
| file_name | No | Exact, case-sensitive filename, e.g. image.png; punctuation is literal | |
| policy_id | No | ||
| endpoint_id | No |
list_intel_sourcesList available intelligence sourcesRead-onlyIdempotent
Discovers global and organization-owned intelligence sources and their IDs for attaching to a policy. Returns enabled sources by default; is_enabled=false lists disabled sources. Filter by the policy platform. Use list_policies to find the policy ID, then manage_policy_intel_sources action=list to inspect attachments or action=attach with the selected source_ids. Premium sources may require a paid plan. Requires intel:read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| platform | No | ||
| is_enabled | No |
list_policiesList MagicSword policiesARead-onlyIdempotent
Lists policies in the MagicSword org, including each policy's current published version (name, version, status, policy mode). Filter by platform if you only care about windows / macos / linux. The current_version block tells you status (audit/enforcing/disabled) separately from policy_mode (blocklist/strict).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Restrict to one platform |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent, closed-world operation, so the safety burden is covered. The description adds real domain context beyond that: it explains that the current_version block separates status (audit/enforcing/disabled) from policy_mode (blocklist/strict), which is non-obvious semantics an agent could not infer. It does not mention pagination or result-size behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is listed and what each entry holds, then the filter condition, then field interpretation. No filler, though the final sentence is slightly dense and could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully describes the returned current_version block and its two status dimensions, which compensates well. Gaps remain around pagination, total counts, and how to proceed after listing (e.g., show_policy or manage_policy_rules), but the core need is met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single platform parameter is fully documented with an enum in the schema. The description only restates the filtering intent ('if you only care about windows/macos/linux') without adding syntax or edge-case meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (Lists) and resource (policies) plus org scope and enumerates what each entry contains (name, version, status, policy_mode). It is clear enough to distinguish a plural listing from the singular show_policy sibling, but it never names that sibling or explicitly contrasts listing vs. fetching a single policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied: 'Filter by platform if you only care about windows/macos/linux' tells when to use the parameter, not when to use this tool over show_policy, list_events, or other siblings. There is no statement of when-not-to-use or of alternative listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_customer_intel_feedCreate, edit, or delete a private intel feedADestructive
Creates, updates, or deletes private intelligence feeds. Organizations are limited to 3 feeds. Requires intel:write.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Feed name for create/update | |
| action | Yes | Feed operation | |
| confirm | No | Required for delete after a human approves the preview | |
| feed_id | No | Required for update/delete | |
| platforms | No | Platforms this feed applies to | |
| is_enabled | No | Enable/disable matching for this feed | |
| description | No | Optional feed description |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is structured. The description adds value beyond that by disclosing the 3-feed organizational quota and the intel:write permission requirement, both of which affect whether the agent should attempt the call. It stops short of explaining what a delete destroys (feed only vs contained items) or the preview/confirm flow implied by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, followed by the two constraints most likely to block a call. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with full schema coverage and no output schema, the description covers purpose, permission, and quota adequately, and annotations carry the safety profile. The one gap is that the delete preview/confirm workflow and the blast radius of a delete are left to the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the action enum and the confirm flag's preview semantics. The description adds no parameter-level detail beyond that, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb set (creates, updates, deletes) and a clear resource (private intelligence feeds), so the CRUD nature is unambiguous. It does not explicitly name the sibling list_customer_intel_feeds as the read-only alternative, but the action scope separates it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives constraints (3-feed quota, intel:write requirement) but no when-to-use versus when-not guidance and no reference to the sibling list_customer_intel_feeds tool. Usage is implied by the CRUD framing rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_customer_intel_itemEdit or delete a private intel feed itemADestructive
Edits or deletes one item in a private intelligence feed. Requires intel:write.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | Replacement/merge fields for update. Supported fields match upsert_customer_intel_items. | |
| action | Yes | ||
| confirm | No | Required for delete after a human approves the preview | |
| feed_id | Yes | ||
| item_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds the real value of the intel:write authorization requirement, but omits the delete preview/human-approval flow that the confirm parameter implies, and says nothing about reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the action pair is front-loaded and the permission requirement follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with five parameters and no output schema, the definition covers the action and permission but omits the two-step delete flow (preview then confirm) and the merge/replace semantics of the item payload, both of which live only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (action, feed_id, item_id undocumented), but those undocumented parameters are a self-describing enum and two UUIDs with explicit patterns. The description adds nothing parameter-specific, though the remaining gap is small because the schema is structurally rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Edits or deletes one item in a private intelligence feed" gives a specific verb pair and resource, and "one item" implicitly separates it from the plural/bulk siblings (upsert_customer_intel_items, manage_customer_intel_feed). It never names those siblings explicitly, so the differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the prerequisite "Requires intel:write." There is no statement of when to pick this single-item tool over upsert_customer_intel_items or manage_customer_intel_feed, nor when update vs delete applies beyond the enum in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_policy_intel_sourcesList, attach, or detach intel feeds on a policyDestructive
Lists, attaches, or detaches global/customer-owned intel feeds on a policy current version. First use list_policies to find policy_id and list_intel_sources to discover source IDs for that platform. Customer feeds only affect endpoints in that org with the feed attached. Attach/detach changes the policy version; show the selected policy and sources to the user before making the requested change. List requires policies:read; attach/detach require policies:write.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| policy_id | Yes | ||
| source_id | No | Source ID for detach | |
| source_ids | No | 1–60 enabled source IDs for attach; captures share the key creator's rate budget |
manage_policy_rulesList or add policy rulesDestructive
Lists rules stored on the current policy version, including materialized feed rules, or appends/updates explicit or event-derived rules while preserving existing rules and feed links. Use event_ids with status=allowed for “allow all these audit events on my policy”; the Portal will derive supported policy rules when possible. Use list_events with q to find events across supported search fields, then pass only the selected IDs here; search terms are not rule values. Do not add explicit flat file-hash rules for Windows WDAC. Requires policies:read for list and policies:write for add.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional rule type override for event-derived rules | |
| limit | No | ||
| rules | No | Explicit rules to add/update | |
| action | Yes | ||
| offset | No | ||
| status | No | Status for event-derived rules; defaults to allowed | |
| platform | No | Disambiguates policy_name matches | |
| event_ids | No | Telemetry event IDs to turn into rules | |
| policy_id | No | Policy UUID. Required for list; optional for add if policy_name is provided. | |
| policy_name | No | Policy current-version name for add when policy_id is unknown. |
mint_enrollment_tokenMint a MagicSword agent enrollment tokenA
Mints a one-time enrollment token used to register a new MagicSword agent against the org owning the API key. The returned token is bearer-equivalent for enrollment — surface it to the human and instruct them to use it within the TTL. Default TTL is 1 hour; min 5 minutes; max 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl_seconds | No | Time-to-live in seconds (300–86400, default 3600) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write/non-idempotent/non-destructive profile; the description adds meaningful traits: the token is 'one-time', 'bearer-equivalent for enrollment', and must be handed to a human within a TTL. It omits whether repeat calls invalidate prior tokens, auth requirements, or rate limits, keeping it short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose first, then the security-handling instruction, then the TTL bounds. Front-loaded and free of padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter minting tool with full schema coverage and no output schema, the description supplies everything needed to call it correctly and safely, including that the returned value is a bearer-equivalent secret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single ttl_seconds parameter is fully documented with range and default. The description restates the same facts in human units ('default 1 hour; min 5 minutes; max 24 hours'), which aids readability but adds no information 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Mints a one-time enrollment token used to register a new MagicSword agent' — with the scope ('against the org owning the API key'). No sibling tool mints tokens, so the agent can place it immediately against a list of list_*/manage_*/show_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent what to do with the result ('surface it to the human and instruct them to use it within the TTL') and frames the token as a registration artifact, which is real usage context. It stops short of explicit when/when-not guidance, though no alternative sibling exists to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_endpoint_checkinRequest endpoint check-inA
Queues a check-in command for one endpoint. Requires endpoints:write.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Endpoint UUID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose the safety profile (readOnly=false, idempotent=false, destructive=false). The description adds genuinely useful context beyond that: 'Queues' reveals the command is enqueued asynchronously rather than executed immediately, and the explicit 'Requires endpoints:write' scope informs auth needs. It doesn't explain what happens to an already-queued check-in, but the added context is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and scope, followed by the auth requirement. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter queue action, the description covers purpose, asynchrony, and authorization, and there is no output schema to explain away. It is nearly complete, missing only any note on check-in frequency or the effect of repeated requests (consistent with idempotent=false).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single endpoint_id parameter (the schema supplies format and pattern). The description only reinforces 'one endpoint' without adding format or lookup detail, so the schema carries the load and baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Queues') plus the resource ('a check-in command') and scope ('for one endpoint'), so the agent knows exactly what action occurs. It does not name or distinguish from any sibling tool, but no sibling overlaps this check-in action, keeping the gap minor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the required permission ('Requires endpoints:write'), which signals a write-path operation. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no reference to alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_endpointShow a single MagicSword endpointARead-onlyIdempotent
Fetches one endpoint directly by UUID with OS, architecture, policy, compliance, agent version, upgrade state, heartbeat, and AMSI details. Requires endpoints:read.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Endpoint UUID returned by list_endpoints |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the required scope ('Requires endpoints:read') and the breadth of the payload it touches (OS, architecture, policy, compliance, AMSI, heartbeat, upgrade state). It stops short of describing not-found behavior or payload size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler: the retrieval semantics come first and the permission requirement second. Every clause carries information and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the enumerated field list compensates well by telling the agent what data comes back, and the auth scope is disclosed. Minor gaps remain — no error/not-found guidance and no mention of payload richness for very detailed endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already documents itself as an 'Endpoint UUID returned by list_endpoints'. The description only restates 'by UUID', adding no format or provenance detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetches one endpoint') and adds the retrieval key ('directly by UUID'), which cleanly separates it from the sibling list_endpoints. An agent can pick this tool without opening its schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by UUID' — you reach for this when you already hold an endpoint identifier rather than a filter set. However, it never explicitly names list_endpoints as the alternative path or states when-not-to-use, so the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_policyShow a single MagicSword policyARead-onlyIdempotent
Returns the active version + status for one policy by id.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | The policy UUID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, idempotent, read-only, closed-world operation, so the burden is light. The description adds genuine context by specifying the return payload (active version + status), but says nothing about behavior when the id is unknown or about auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero filler, and the resource and return content are front-loaded. Nothing needs trimming or reordering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-record read with annotations covering the safety profile and no output schema, the description is nearly sufficient; the return shape is summarized. Only not-found/error behavior is left unaddressed, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single policy_id carries a UUID format, pattern, and description, so the schema does the heavy lifting. The description's 'by id' merely reinforces what the schema already documents, matching the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the active version + status for one policy') and scopes it to a single record via 'by id', which distinguishes it from list_policies. It stops short of explicitly naming the sibling it differs from, but an agent can tell it apart from the list/management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the single-id framing suggests 'call this when you already have a policy_id'. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as list_policies for enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_alertTriage a single MagicSword alertADestructive
Fetches one alert directly by id and returns its severity, endpoint, MITRE mapping, triggering events, file context, and metadata for analyst review. Optionally acknowledges or dismisses it.
| Name | Required | Description | Default |
|---|---|---|---|
| ack | No | If true, mark the alert acknowledged. Requires alerts:write. | |
| dismiss | No | If true, dismiss the alert instead of acknowledging it. Requires alerts:write. | |
| alert_id | Yes | The alert UUID (returned from find_alerts) | |
| ack_comment | No | Comment to record on acknowledgement (only meaningful with ack: true) | |
| dismiss_reason | No | Reason to record when dismissing the alert |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=true unconditionally, which would suggest an always-destructive write tool; the description usefully clarifies that the base operation is a fetch and that ack/dismiss are opt-in additions. It does not, however, state what dismissing actually does (reversibility, permanence) or that the operation is non-idempotent, which the annotations only imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the primary read behavior and its return fields are front-loaded, and the optional mutation is mentioned last. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the return-value burden by enumerating severity, endpoint, MITRE mapping, triggering events, file context and metadata. Parameter semantics and permissions are fully covered by the schema, so the only remaining gap is behavioral detail about the destructive dismiss path, which annotations partly cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (alert_id, ack, dismiss, ack_comment, dismiss_reason) is documented in the schema, including the alerts:write permission requirement. The description only restates id-based lookup and the optional ack/dismiss pair, adding no syntax or constraint detail beyond the schema — the expected baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetches one alert... returns its severity, endpoint, MITRE mapping...') and lists the payload, so the agent knows exactly what the tool does. 'Directly by id' implicitly separates it from the sibling find_alerts, but the sibling is never named, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: use this when you already hold an alert id ('directly by id') for analyst review, and the ack/dismiss flags are described as optional. There is no explicit guidance on when to acknowledge versus dismiss, nor a named alternative for the case where no id is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upgrade_endpointsQueue MagicSword agent upgradesADestructive
Previews or queues agent upgrades for one endpoint, explicit endpoint IDs, all endpoints on a platform, or endpoints matching a hostname glob. The first call previews the request; rerun with confirm=true after human approval. Requires endpoints:write.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max endpoints to resolve for filters | |
| confirm | No | Set true only after a human approves the preview | |
| platform | No | Optional platform filter | |
| endpoint_id | No | Single endpoint UUID | |
| endpoint_ids | No | Explicit endpoint UUIDs | |
| target_version | No | Target version, or latest by default | |
| hostname_pattern | No | Optional hostname glob resolved server-side | |
| update_all_outdated | No | Skip endpoints already on the target version |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, and the description meaningfully extends them with the mandatory preview-then-confirm cycle and the required endpoints:write permission. It stops short of saying what the upgrade does to affected hosts (agent restart/interruption) or how duplicate queues are avoided across reruns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the preview/confirm contract is front-loaded after the target scope. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, workflow, and authorization for a zero-required-parameter, eight-parameter tool with no output schema; annotations carry the safety profile. Missing only the interaction rules between filters (e.g., platform combined with hostname_pattern) and what the preview returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including confirm, limit, and hostname_pattern is already documented in the schema. The prose only restates the selection modes at a high level and adds no format or precedence detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair ('previews or queues agent upgrades') and enumerates the four target-selection modes, so an agent immediately knows what the tool acts on. No sibling in the list overlaps this upgrade action, so no rival needed to be named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'The first call previews the request; rerun with confirm=true after human approval' is an explicit, actionable invocation workflow with a stated gating condition. It doesn't discuss alternatives, but no sibling tool offers a competing path to queueing upgrades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upsert_customer_intel_itemsAdd or update indicators in a private intel feedA
Bulk upserts up to 100 indicators into a private feed. This is the MCP path for “extract IOCs from this report and add them to MagicSword.” Requires intel:write.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Indicators to upsert | |
| feed_id | Yes | Private feed UUID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation safety profile, and the description adds a permission requirement (intel:write) plus a bulk cap. There is mild unaddressed tension between 'upserts' and idempotentHint=false, but the description does not explicitly claim idempotency, so no contradiction is asserted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then the intent/example and the permission requirement. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no output schema, the description covers the action, scale, intent, and auth. Only the return/partial-failure behavior on a bulk upsert is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema itself carries the rich field-level guidance (filename vs hash usage, WDAC caveat, maxItems), so the description adds no parameter meaning beyond it. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('bulk upserts'), resource (indicators), and target (a private intel feed), with a concrete capacity bound. It is clearly distinguishable from the singular sibling manage_customer_intel_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case ('extract IOCs from this report and add them to MagicSword') and states the required scope (intel:write). It does not explicitly contrast with manage_customer_intel_item, but the 'bulk up to 100' framing implies the batch-vs-single distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiIdentify the MagicSword org and keyARead-onlyIdempotent
Returns the MagicSword organization, API key id, and granted scopes for the configured key. Call this first when troubleshooting access — it answers "who am I and what can this key do?". Useful before any other tool to confirm the key is still valid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond them by disclosing what is returned and framing the tool as a key-validity check. It does not cover failure behavior (e.g. what an invalid or expired key returns), which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return payload, followed by the diagnostic use case. Three short sentences with only slight overlap between the 'troubleshooting access' and 'confirm the key is still valid' framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so precisely (org, key id, scopes). Combined with the annotations covering safety and idempotency, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so per the baseline this scores 4. There is nothing parameter-level to explain, and the description correctly avoids inventing inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns) plus the exact resource contents: organization, API key id, and granted scopes. This is unambiguous and clearly distinguishable from every sibling tool, none of which report identity or key metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit context for use: 'Call this first when troubleshooting access' and 'before any other tool to confirm the key is still valid.' No when-not guidance or named alternative is needed here, since no sibling overlaps in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.3- Changed
list_events5 fields changed- added
Input schema / properties / file_nameAdded value: +{ + "description": "Exact, case-sensitive filename, e.g. image.png; punctuation is literal", + "maxLength": 255, + "minLength": 1, + "type": "string" +} - changed
Input schema / properties / offset / maximumPrevious value: -9007199254740991New value: +1000000 - changed
Input schema / properties / q / descriptionPrevious value: -"Search name, file, hash, path, or computer"New value: +"Case-insensitive literal substring search across name, filename, path, hash, publisher, computer, and package family. Up to 120 characters, including Unicode and punctuation; %, _, and * are literal. Omit type to search across event types. Combine with file_name for an exact filename." - changed
Input schema / properties / q / maxLengthPrevious value: -255New value: +120 - added
Input schema / properties / q / patternAdded value: +"^[^\\u0000-\\u001f\\u007f-\\u009f]*$"
- Added
list_intel_sources - Changed
manage_policy_intel_sources2 fields changed- changed
Input schema / properties / source_ids / descriptionPrevious value: -"One or more source IDs for attach"New value: +"1–60 enabled source IDs for attach; captures share the key creator's rate budget" - changed
Input schema / properties / source_ids / maxItemsPrevious value: -100New value: +60
- Changed
manage_policy_rules11 fields changed- added
Input schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - added
Input schema / properties / event_ids / minItemsAdded value: +1 - changed
Input schema / properties / policy_name / maxLengthPrevious value: -4096New value: +255 - removed
Input schema / properties / rules / items / additionalPropertiesRemoved value: -{} - changed
Input schema / properties / rules / items / descriptionPrevious value: -"Policy rule. Common Windows WDAC shapes: {type:\"filepath\", value:\"%OSDRIVE%\\\\Tools\\\\tool.exe\", status:\"blocked\"}, {type:\"filename\", value:\"tool.exe\", status:\"blocked\"}, or {type:\"publisher\", value:{publisherName, signerName, tbsHash}, status:\"allowed\"}. Do not create explicit type:\"hash\" rules for Windows WDAC; use event_ids or private intel feeds for hash/AuthentiHash/page-hash IOCs."New value: +"Explicit Customer API rule with type, value and optional status/metadata. Filename example: {type:\"filename\", value:\"rustdesk.exe\", status:\"blocked\"}. Windows WDAC flat hash rules are rejected by the Portal; use event_ids or private intelligence feeds." - added
Input schema / properties / rules / items / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "filename", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "filepath", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "path", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "fileattrib", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "team_id", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "signing_id", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "bundle_id", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "app_bundle", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "cdhash", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "hash", + "type": "string" + }, + "value": { + "anyOf": [ + { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64})$", + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "MD5": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64})$", + "type": "string" + }, + "SHA1": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64})$", + "type": "string" + }, + "SHA256": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64})$", + "type": "string" + }, + "hash": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64})$", + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "publisher", + "type": "string" + }, + "value": { + "additionalProperties": false, + "properties": { + "certRuleLevel": { + "enum": [ + "publisher", + "filepublisher", + "pcacertificate", + "leafcertificate" + ], + "type": "string" + }, + "cert_rule_level": { + "enum": [ + "publisher", + "filepublisher", + "pcacertificate", + "leafcertificate" + ], + "type": "string" + }, + "certificate_thumbprint": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64}|[a-f\\d]{96})$", + "type": "string" + }, + "publisher": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "publisherName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "signer": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "signerName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "tbsHash": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64}|[a-f\\d]{96})$", + "type": "string" + }, + "tbs_hash": { + "pattern": "^(?:[a-f\\d]{32}|[a-f\\d]{40}|[a-f\\d]{64}|[a-f\\d]{96})$", + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "browser_extension", + "type": "string" + }, + "value": { + "additionalProperties": false, + "properties": { + "browser": { + "enum": [ + "chrome", + "edge", + "firefox", + "safari" + ], + "type": "string" + }, + "extensionId": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "extension_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "extension_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "version": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "packagefamilyname", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "publisher": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "version": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "package", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "manager": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "version": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "amsi", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "packageFamilyName": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "package_family_name": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "path": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "rule_id": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "value": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + } + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "scr", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "file_attrib_refs": { + "anyOf": [ + { + "items": { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "maxItems": 256, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "linked_signer_id": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "max_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "min_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "mode": { + "anyOf": [ + { + "enum": [ + "user", + "kernel", + "both" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "maxLength": 255, + "minLength": 1, + "type": "string" + }, + "package_version": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "source": { + "description": "The Portal assigns customer API provenance; this cannot override it", + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + "status": { + "description": "Defaults to blocked for explicit rules", + "enum": [ + "allowed", + "blocked", + "disabled", + "prompt" + ], + "type": "string" + }, + "target_platforms": { + "anyOf": [ + { + "items": { + "enum": [ + "windows", + "macos", + "linux" + ], + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "type": { + "const": "asr", + "type": "string" + }, + "value": { + "anyOf": [ + { + "maxLength": 4096, + "minLength": 1, + "type": "string" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + } +] - removed
Input schema / properties / rules / items / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / rules / items / typeRemoved value: -"object" - added
Input schema / properties / rules / minItemsAdded value: +1 - added
Input schema / properties / type / enumAdded value: +[ + "hash", + "filename", + "filepath", + "publisher", + "fileattrib", + "browser_extension", + "packagefamilyname", + "amsi", + "path", + "team_id", + "signing_id", + "cdhash", + "app_bundle", + "bundle_id", + "scr", + "asr", + "package" +] - removed
Input schema / properties / type / maxLengthRemoved value: -4096
21 tool updates
v0.1.1- First observed
agent_install_instructions - First observed
apply_policy_to_endpoints - First observed
find_alerts - First observed
flip_to_enforcing - First observed
list_agent_releases - First observed
list_customer_intel_feeds - First observed
list_endpoints - First observed
list_events - First observed
list_policies - First observed
manage_customer_intel_feed - First observed
manage_customer_intel_item - First observed
manage_policy_intel_sources - First observed
manage_policy_rules - First observed
mint_enrollment_token - First observed
request_endpoint_checkin - First observed
show_endpoint - First observed
show_policy - First observed
triage_alert - First observed
upgrade_endpoints - First observed
upsert_customer_intel_items - First observed
whoami
TDQS
Scored across 21 tools
Tools are organized around distinct resources (endpoints, policies, alerts, events, intel feeds, enrollment) and most boundaries are clear from descriptions. Minor overlap exists between find_alerts and list_events, and between manage_customer_intel_item and upsert_customer_intel_items, but the descriptions differentiate them adequately.
The set predominantly follows a verb_noun snake_case pattern (list_endpoints, show_policy, manage_policy_rules, apply_policy_to_endpoints). A few outliers (whoami, agent_install_instructions, flip_to_enforcing) and the broad 'manage_' verb slightly dilute consistency but remain readable.
At 21 tools the surface is on the heavier side, but the server spans several genuine subdomains (endpoints, policies, alerts, events, intel, enrollment), so each tool broadly earns its place. It sits just above the comfortable range but is defensible for the platform's scope.
The surface covers the core lifecycle: endpoint listing/detail, agent upgrade/check-in/enrollment, policy listing/detail/rule management/application/promotion, alert triage, event listing, and full intel feed/item CRUD. Some gaps remain (e.g., no policy deletion/creation flow, no user or role management), but core analyst and admin workflows are well supported.
Maintenance
Related MCP Connectors
- QuallaaOAuthcom.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Secure and manage MCP servers through the Speakeasy AI Control Plane from your agent.
1242Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceThis MCP server connects Claude Desktop to a Velociraptor instance and local forensic tools. It enables remote endpoint investigation and local evidence analysis through natural language commands.1MIT
- AlicenseNot gradedqualityAmaintenanceEnables Claude Code sessions to query fleet status, focus terminals, and manage sessions programmatically via MCP tools.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to query an organization's device posture, compliance, policies, and software/CVE status through a remote, read-only, OAuth-secured MCP endpoint.MIT
- AlicenseNot gradedqualityAmaintenanceEnables MCP clients such as Claude Code, Claude Desktop, and Cursor to list hosts, read metrics, inspect containers, follow logs, and, when permitted, run commands, restart containers, manage authorized_keys, and edit host lists under per-host policy, Touch ID-backed credentials, deny-lists, rate limits, and an audit log.MIT