Provides read-only tools for interacting with the Symantec Data Center Security management console, covering server status, assets, alerts, events, policies, reports, roles, users, and syslog.
Click 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., "@Symantec Data Center Security AIops show me the most recent critical alerts from the management console"
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.
Independent audited MCP server, CLI and skill for management status, assets, alerts, events, policies, reports, roles, users and syslog. This initial release exposes 35 read-only tools. MCP and CLI call the same governed functions; API credentials remain in environment variables, TLS verification is on, and every call records a local audit event.
Community-maintained project. Not affiliated with or endorsed by Broadcom or Symantec; product names are their owners’ trademarks.
export SYMANTEC_DCS_URL="..."
export SYMANTEC_DCS_USERNAME="..."
export SYMANTEC_DCS_PASSWORD="..."SYMANTEC_DCS_URL must be the management console HTTPS origin (normally https://host:4443), without a path. Optional SYMANTEC_DCS_CA_BUNDLE points to a trusted CA bundle; SYMANTEC_DCS_TIMEOUT defaults to 30 seconds. Audit state defaults to ~/.symantec-dcs-aiops/ and can be relocated with SYMANTEC_DCS_AIOPS_HOME.
See the operations catalog for the complete tool list, scope and deferred operations.
Related MCP server: Darktrace MCP
uvx --from symantec-dcs-aiops==0.1.0 symantec-dcs-aiops status server
uvx --from symantec-dcs-aiops==0.1.0 symantec-dcs-aiops-mcpUse assets with a sort key to page through inventory; inspect asset-errors, alert-rules, events and policy-violations before making conclusions. See verification for the exact evidence and unverified live behavior. No state-changing operations are exposed.
[READ] Read alert rule details.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The "[READ]" prefix merely restates the readOnlyHint annotation already supplied, so it adds no behavioral information. Nothing is said about what the response contains, whether it errors on an unknown or deleted ID, or whether it covers alert instances or rule definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with no filler, but it is under-specified rather than concise. The bracketed "[READ]" tag duplicates the annotation and occupies space that could have carried disambiguation.
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, no parameter documentation, and a crowded sibling set, the definition leaves an agent unable to determine what entity is fetched or what comes back. For a lookup-by-ID tool this is a substantial 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?
The single parameter has 0% schema description coverage, so the description must compensate and does not: it never clarifies whether alert_id is an alert instance ID or an alert rule ID. This is exactly the distinction the agent most needs before calling the tool.
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 verb+resource ("Read alert rule details") is identifiable, but the description says "alert rule" while the tool is named dcs_alert_details and siblings include both dcs_alerts and dcs_alert_rules, leaving genuine ambiguity about which entity is returned. An agent cannot reliably tell it apart from dcs_alert_rules or dcs_alerts based on this text.
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?
There is no guidance on when to use this instead of dcs_alerts (list alerts) or dcs_alert_rules (alert rule list), nor any prerequisite such as where an alert_id comes from. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List recent alert notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a read-only operation, so the "[READ]" prefix adds nothing beyond structured data. The description does not say what "recent" means, whether results are ordered, or how the single limit parameter bounds the response, leaving real behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single short sentence is front-loaded with the operation type and has zero padding or redundancy. It is efficient, though its brevity edges toward under-specification rather than true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an annotation covering safety and no output schema, the description is minimally adequate. It still leaves "recent" undefined and the limit parameter unexplained, which an agent would need in order 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?
The schema has 0% description coverage and the single parameter (limit, default 100) is never mentioned in the description. With coverage below 50%, the description is expected to compensate, but it adds no semantics such as whether limit caps notifications returned or what the maximum is.
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?
"[READ] List recent alert notifications" states a specific verb (list) and resource (alert notifications), so the operation is unambiguous. However, it gives no differentiation from close siblings such as dcs_alerts, dcs_alert_details, or dcs_alert_stats, so an agent cannot tell which one to pick from the description alone.
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?
There is no guidance on when to use this versus dcs_alerts or dcs_alert_details, and no prerequisites or exclusions. The only hint is the word "recent", which is never defined in terms of a time window or count.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List a bounded page of alert rules.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | Yes | ||
| limit | No | ||
| offset | No | ||
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' prefix merely restates readOnlyHint=true, which the annotations already declare, so it adds no new information. 'Bounded page' hints at pagination, but limit/offset in the schema already convey that; nothing is said about default page size behavior, total counts, or sort semantics.
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?
It is a single front-loaded sentence with no wasted words, which is structurally clean. However, the brevity is under-specification rather than economy, given four undocumented parameters including a required one.
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 0% schema coverage, a required 'sort' parameter of unknown format, no output schema, and only a readOnly annotation, the definition leaves the agent guessing on nearly every invocation detail. The one-line description is far too thin for the tool's actual complexity.
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 0% and all four parameters are bare titles. Critically, 'sort' is required yet the description never states format or allowed values, and limit/offset/filter_text semantics are left entirely unexplained, so the description adds nothing.
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 ('List ... alert rules') plus scope ('a bounded page'), which is enough to distinguish it from dcs_alerts or dcs_alert_stats by the word 'rules'. It does not explicitly call out the sibling it differs from, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternatives such as dcs_alerts (alert instances) or dcs_alert_notifications. The agent must infer from the name alone that this lists rule definitions rather than alert occurrences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List a bounded page of alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | Yes | ||
| limit | No | ||
| offset | No | ||
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read, and "[READ]" merely restates it rather than adding information. Beyond that, only "bounded page" hints at pagination; there is no disclosure of default page size, sort requirements, or result shape, for a tool whose behavioral profile rests almost entirely on a single annotation.
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 front-loaded sentence with no filler, and the read-only marker plus the paging qualifier arrive immediately. It is efficient, though the brevity leans toward under-specification rather than tight editing.
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 four undocumented parameters, a required sort, no output schema, and no annotation beyond readOnlyHint, the description should explain paging and sorting behavior but does not. An agent can guess the intent but cannot call it correctly without experimenting.
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 0% across four parameters, so the description must carry the meaning and it does not. It never mentions that 'sort' is required, what syntax sort accepts, what limit/offset do, or what filter_text matches against.
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 ("List ... alerts") plus a scoping qualifier ("a bounded page"), so the agent knows this is a paginated read of the alerts collection. It does not distinguish itself from adjacent siblings such as dcs_alert_stats, dcs_alert_details, or dcs_alert_rules, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternatives, despite five sibling alert tools that a caller could easily confuse with this one. The word "bounded" hints that pagination is expected, but nothing tells the agent when to pick this over dcs_alert_stats or dcs_alert_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read alert rule totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the "[READ]" prefix merely restates that, adding no behavioral context. The description does not say what the totals aggregate, what time window (if any) applies, or what shape the response takes - and with no output schema, nothing else covers that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of waste, which is structurally sound. But the brevity comes at the cost of specification rather than being genuinely economical - the same length could have named the aggregation or the alternative tool.
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-parameter, read-only stats tool the bar is low, and the read-only annotation plus the empty schema mean an agent can call it safely. Still, with no output schema and no statement of what "totals" contains, the agent cannot predict what it will receive or whether it wants this data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no redundant parameter prose.
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?
"[READ] Read alert rule totals" names a verb (read) and a resource (alert rule totals), so the general intent is inferable. However, "totals" is ambiguous - it could mean the number of rules, per-severity counts, or aggregated firing statistics - and nothing distinguishes it from the adjacent dcs_alert_rules, dcs_alert_details, or the parallel dcs_*_stats 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?
There is no when-to-use guidance at all: no statement of when to call this instead of dcs_alert_rules (raw rules) or dcs_alerts (alert instances). The sibling tool list shows several plausible alternatives, and the description gives the agent nothing to choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read one managed asset.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral content is the literal "[READ]" tag, which duplicates the readOnlyHint=true annotation rather than adding anything. With annotations already stating the safety profile, the description contributes nothing about what is returned, whether missing IDs error, or permission 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?
It is a single short sentence with no wasted wording, so it is concise and front-loaded. But the brevity comes at the cost of under-specification rather than efficiency, so it earns only a middling score.
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 tool with one required, completely undocumented parameter and no output schema, the description should explain the identifier and the returned asset record. Neither is present, so an agent cannot confidently invoke it correctly beyond guessing from the name.
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 0% for the single asset_id parameter, so the description must compensate and does not. It never states that asset_id is a numeric identifier or where such an ID comes from, leaving the only required input undocumented in both places.
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 verb ("Read") and a resource ("asset") and the word "one" hints at single-record retrieval rather than the listing sibling dcs_assets. However, it largely restates the tool name and never explains what a "managed asset" is or what distinguishes this from dcs_asset_history, dcs_asset_tags, or dcs_asset_stats.
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?
No when-to-use guidance is given: it does not say to use dcs_assets for listing and this tool once an asset_id is known, nor does it mention the closely related siblings. The agent must infer the selection rule from the plural/singular naming pattern alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read recent asset error events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safety profile, and the "[READ]" prefix merely restates it rather than adding context. The description does not explain what "recent" means (time window or count), how limit interacts with recency, or whether an empty result means no errors versus no data — all meaningful for interpreting output with no output 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?
A single short sentence with the read-only marker front-loaded — there is no filler or repetition. The terseness is a completeness problem rather than a structural one, so this dimension scores well.
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, no parameter descriptions, and only a readOnlyHint annotation, the description carries the full burden and supplies almost nothing. An agent cannot tell what an error event contains, what the retention window is, or how to page or bound results, making the definition under-specified for a parameterized diagnostic tool.
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 0%, so both parameters rely on the description, which mentions neither asset_id nor limit. The required asset_id and the defaulted limit of 100 are undocumented; only the word "recent" loosely gestures at the limit without clarifying whether it is a count or a time bound.
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 verb and resource ("Read ... asset error events") and tags it as read-only, so the basic operation is identifiable. However, "error events" is undefined — it could mean scan failures, agent connectivity errors, or policy evaluation errors — and nothing distinguishes it from siblings like dcs_events, dcs_asset_history, or dcs_asset_stats.
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?
There is no when-to-use guidance, no mention of alternatives such as dcs_events for the broader event stream, and no stated prerequisites (e.g., whether the asset must exist or have a running agent). The agent must infer the selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read asset change history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description's "[READ]" prefix merely restates it, adding no new behavioral information. Nothing is said about ordering (newest first?), pagination defaults, what a change entry contains, or behavior when the asset has no history or does not exist.
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?
It is a single short clause with no wasted words and the key verb and resource are front-loaded. However, the extreme brevity reflects under-specification rather than disciplined concision, since no substantive information beyond the title is conveyed.
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 history-query tool with no output schema and no parameter descriptions, the description should carry the load on inputs, ordering, and result shape. It instead supplies only a bare purpose statement, leaving the agent without enough information to invoke it confidently.
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 0%, so neither asset_id nor limit is documented anywhere. The description never mentions either parameter, leaving the agent to guess that asset_id identifies the target asset and that limit caps returned entries, and with no stated maximum or default behavior beyond the schema's 100.
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?
"Read asset change history" names a verb and a resource, so the agent can tell it returns history rather than current asset state. But it does not distinguish it from sibling tools like dcs_asset_errors, dcs_asset_stats, or dcs_asset, which all operate on the same asset and could plausibly return similar data.
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?
There is no statement of when to use this tool versus the many asset-related siblings, and no prerequisites or exclusions. The agent must infer that this is for historical change auditing rather than errors, stats, tags, or policies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List policies assigned to an asset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safety profile, and the description's '[READ]' prefix only repeats it. It adds no behavioral context on pagination behavior for the limit parameter, what policy fields are returned, or whether results are truncated.
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?
It is a single front-loaded sentence with no filler. The '[READ]' tag is somewhat redundant against the annotations, but the description is not bloated.
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 schema with no parameter descriptions and no output schema, the description should explain the return shape and the limit semantics. It leaves both undocumented, so an agent cannot fully know what calling it will produce.
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 0%, so both parameters rely on the description, yet it only vaguely implies that asset_id identifies an asset. The 'limit' parameter and its default of 100 are completely unmentioned, and there is no indication where asset_id values come from.
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 and resource ('List policies') plus a scope ('assigned to an asset'), which separates it from the global dcs_policies sibling. It does not name that sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [READ] tag and 'assigned to an asset' scope imply when to use it, but there is no explicit routing against dcs_policies or dcs_policy, no prerequisites, and no exclusions. Usage has to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List a bounded page of assets.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | Yes | ||
| limit | No | ||
| offset | No | ||
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the "[READ]" tag adds nothing new. "Bounded page" is the only behavioral signal, hinting at pagination but not stating default page size, whether more pages exist, or how to detect truncation.
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 front-loaded sentence with no filler and the read-only marker placed first. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.
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 four-parameter list endpoint with no output schema and an undocumented required sort argument, the description leaves too much unknown. An agent can guess it paginates, but not how to sort, how large pages are, or what an asset record 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 description coverage is 0% across four parameters, including a required "sort" whose accepted values are completely unknown. The phrase "bounded page" loosely implies limit/offset but provides no format, range, or sorting syntax, so the description fails to compensate for the coverage gap.
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 and resource ("List ... assets") and adds the pagination qualifier "bounded page". However, it never distinguishes this collection endpoint from siblings such as dcs_asset (single asset detail) or dcs_asset_stats, so an agent must infer the difference from names alone.
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?
There is no guidance on when to use this tool versus dcs_asset, dcs_asset_stats, or dcs_asset_errors. No prerequisites, no exclusions, and no mention of what happens if the result set exceeds the page size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read asset totals and offline counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, and the description does not contradict it. It adds the useful fact that the payload is aggregate counts (totals plus offline) rather than a record list, but says nothing about counting scope, freshness, or failure behavior, and there is no output schema to cover that.
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 short sentence that leads immediately with the read nature and the two data points returned. Nothing in it is redundant or padded.
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-argument, non-destructive read tool, the description plus the readOnlyHint give an agent enough to call it correctly, and it names the returned metrics since no output schema exists. It is slightly short on scope—whether 'offline' is a time-windowed or current-state count—but nothing blocks a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter meaning to convey and the schema is complete by construction. Baseline 4 applies because the description has no semantic gap to fill.
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 ('Read asset totals and offline counts'), which distinguishes it from the listing tool dcs_assets and from the error tool dcs_asset_errors. It does not explicitly name a sibling, but the aggregation framing makes its role recognizable.
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 no when-to-use guidance, no prerequisites, and never points at an alternative such as dcs_assets for per-asset detail or dcs_status for system health. The '[READ]' prefix is a convention hint, not usage guidance, so the choice among stats tools 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.
[READ] Read asset tags.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already tells the agent this is a safe read, and the description only repeats "[READ]." It adds no context on pagination behavior (despite a limit parameter defaulting to 100), what happens if the asset does not exist, or how results are shaped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single short sentence is front-loaded and free of bloat, but the brevity comes from under-specification rather than efficiency. There is no structure to guide the agent beyond a read marker and a resource label.
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?
Even for a simple read tool with a readOnlyHint annotation and no output schema, the definition leaves critical gaps: whether this returns tags for one asset, how limit affects results, and how it differs from the several sibling tag-related tools. It is not sufficient for confident tool selection.
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 0%, so the description must carry the burden for both parameters, yet it explains neither asset_id nor limit. The word "asset" in the description weakly implies asset scoping, but limit and its default/pagination meaning are completely undocumented.
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 "[READ] Read asset tags" essentially restates the tool name (dcs_asset_tags) with a read marker. It does not state the scope (tags attached to a single asset vs. all tags) or distinguish this from sibling tools like dcs_tags or dcs_asset.
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?
There is no when-to-use guidance, no mention of when to prefer dcs_tags or dcs_asset, and no prerequisites stated. An agent must infer usage entirely from the tool name and the required asset_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List a bounded page of security events.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | Yes | ||
| limit | No | ||
| offset | No | ||
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's job is lighter. "Bounded page" adds the useful hint that results are paginated rather than a full dump, but page-size defaults, maximum limits, sort requirement, and result shape are all undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of filler, so nothing is wasted. But it is under-specified rather than concise: for a four-parameter tool with zero schema documentation, one short line is not an appropriate size.
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 and no annotation beyond readOnly, so the description must carry the burden of explaining the required sort argument, filtering, and paging behavior. It does none of these, which is a substantial gap for a list tool whose only mandatory parameter is undefined.
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 0% and the description adds essentially no parameter meaning. "Bounded page" weakly maps onto limit/offset, but the required sort parameter (no enum, no description) and filter_text semantics are completely undocumented, leaving the agent to guess accepted sort keys and filter syntax.
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 and resource ("List ... security events") that clearly separates it from dcs_assets, dcs_alerts and dcs_policies. It does not, however, distinguish itself from the close sibling dcs_event_stats, so an agent must guess whether this returns raw events or aggregates.
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?
There is no when-to-use guidance beyond the "[READ]" tag, and no mention of when to prefer dcs_event_stats, dcs_alerts, or dcs_syslogs. The phrase "bounded page" implies paging but not when a caller should page versus query stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read event counts.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral signal is the "[READ]" prefix, which merely restates the readOnlyHint=true annotation already supplied and adds no new context. Nothing is said about what the counts represent (per-day? per-policy?), whether results are aggregated or grouped, or how the optional filter narrows the set.
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 short sentence with zero padding is easy to parse and front-loaded, but it is concise by omission rather than by discipline. The structural efficiency buys nothing because the content is too thin to act on.
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, no parameter documentation, and no annotation beyond a read-only flag, the description should explain the shape of the returned counts and the filter semantics but does neither. For a stats/aggregation endpoint sitting among 30+ siblings, this leaves the agent under-informed.
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 0%, so the description carries the full burden for the single filter_text parameter, yet it never explains what the text matches (event name, asset, policy, message?) or whether it is a substring or exact match. The default empty string is also unexplained.
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?
"Read event counts" gives a verb (read) and a resource (event counts), so the basic purpose is inferable. However, it does nothing to separate this from the many sibling stats tools (dcs_asset_stats, dcs_alert_stats, dcs_report_stats, dcs_security_group_stats) or from dcs_events, which presumably returns the underlying records rather than aggregates.
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?
There is no guidance on when to pick this tool over dcs_events or the other *_stats siblings, and no statement of prerequisites or exclusions. The agent must guess from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List license inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read, and the "[READ]" tag merely restates it rather than adding information. Nothing is said about result size, pagination behavior, ordering, or whether the inventory is complete versus truncated by the limit parameter.
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?
It is a single short, front-loaded sentence with no filler. But the "[READ]" prefix duplicates the readOnlyHint annotation, so part of the already-minimal text is spent on redundant information rather than useful specifics.
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 and no description of the return shape, yet this is a list tool whose results an agent must interpret. Combined with an undocumented limit parameter and no indication of typical inventory size, the definition leaves too much for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, limit, has 0% schema description coverage, so the schema supplies only a name and a default of 100. The description does not explain what limit constrains, whether it is a page size or a total cap, or what happens when the inventory exceeds it.
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?
"[READ] List license inventory" gives a verb (list) and a resource (license inventory), so the basic purpose is inferable. However, it does not distinguish this from the many other list-style siblings (dcs_assets, dcs_users, dcs_roles, dcs_tags), nor does it clarify what a "license" is in this domain or what the inventory contains.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. With 34 sibling tools in the DCS family, an agent gets no help deciding whether license data is better obtained here or via a related tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List DCS policies with an explicit output cap.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| filter_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read, and the description's only added behavioral claim is 'explicit output cap' — which never states the cap value, whether it is the default of 100, or what happens when more policies exist. It does not contradict the annotations, but it adds almost nothing the agent can act on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded, but under-specification is being mistaken for conciseness. The '[READ]' prefix duplicates the readOnlyHint annotation and consumes space that should have gone to parameter meaning.
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, no annotations beyond readOnly, and zero parameter documentation, the description is the only carrier of meaning — and it supplies none of the missing pieces (filter semantics, cap behavior, return shape). It is not complete enough for an agent to invoke this tool reliably.
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?
Both parameters have 0% schema description coverage, so the description carries the full burden and fails: `filter_text` (what fields it matches, substring vs exact) is never mentioned, and `limit` is only obliquely gestured at via 'output cap'. An agent can only guess what these two inputs do.
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 verb+resource ('List DCS policies') is identifiable, so the core purpose is understandable. However, the definition never distinguishes this tool from the singular sibling `dcs_policy`, and the trailing phrase 'with an explicit output cap' is vague enough that it reads more like a note than a statement of purpose.
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?
There is no when-to-use guidance, no exclusions, and no pointer to alternatives among the many policy-related siblings (`dcs_policy`, `dcs_policy_violations`, `dcs_policy_settings`, `dcs_policy_library`). Usage must be inferred entirely from the word 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read one DCS policy.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read, so the "[READ]" tag and "Read" verb repeat structured data rather than adding to it. Nothing is said about errors for an unknown policy_id, required permissions, or what a policy record looks like, which is the extra context the description should supply for a tool with no output 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?
Five words, front-loaded with the action and the scope, with no wasted phrasing. It is terse rather than padded, though the terseness comes at the cost of the missing semantics noted above.
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 the annotations cover safety, but with no output schema and a fully undocumented parameter the agent still cannot tell what an ID looks like or what the returned policy contains. The definition is under-specified relative to even this low-complexity tool.
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 0%, so the single policy_id parameter is undocumented everywhere. The description does not say what a policy ID is, where to obtain one (e.g., from dcs_policies), or whether it is the numeric policy identifier.
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 ("Read") and a specific resource ("one DCS policy"), and the singular "one" implicitly distinguishes it from the list sibling dcs_policies. What a DCS policy actually contains is never stated, but the core action is unambiguous.
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?
There is no guidance on when to use this tool versus dcs_policies or the related dcs_policy_violations / dcs_policy_settings siblings. The singular reading is only inferable from the name and the word "one".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List library policies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The "[READ]" marker merely restates the readOnlyHint=true annotation, so it adds no behavioral information. Nothing is said about pagination, whether limit is capped, default page size, or what is returned, despite limit being the sole control.
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?
It is a single short sentence with the read tag front-loaded, so there is no wasted wording. However, the brevity is achieved by omission rather than by efficient writing.
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 minimal list tool with no output schema, the description must carry the load and does not: the resource type is undefined, its relation to sibling policy tools is unexplained, and the one parameter is undocumented. An agent could invoke it but not confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (limit) with 0% schema description coverage, and the description adds no meaning to it — no default, no max, no pagination semantics. With a single undocumented parameter the description had a small burden and did not meet it.
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?
"List library policies" gives a verb and a resource, but "library policies" is undefined and the description never distinguishes this from the very similar siblings dcs_policies, dcs_policy, and dcs_policy_settings. An agent cannot tell from this text whether a library policy is a different entity type or a subset.
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?
There is no when-to-use guidance at all: no condition selecting it over dcs_policies or dcs_policy, no prerequisites, no exclusions. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read policy settings.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the "[READ]" prefix merely repeats that signal rather than adding context. The description says nothing about what "settings" comprise, whether the call fails for unknown policy_ids, or what shape the response takes, leaving the behavioral burden entirely on annotations and 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?
The text is a single short sentence with zero filler and the read-only nature front-loaded. However, brevity here crosses into under-specification rather than disciplined conciseness, so it earns only a middling score.
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 tool with no output schema and an undocumented required identifier, the description leaves out nearly everything an agent needs: what settings are returned, how to source the ID, and how it differs from the other policy endpoints. Only the read-only nature is conveyed, and that is already in the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter policy_id has 0% schema description coverage, so the description must compensate and does not. It never says where a policy_id comes from, whether it is required, or what happens if it is invalid, even though the schema marks it required.
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 verb ("Read") and a resource ("policy settings"), but "policy settings" is essentially a restatement of the tool name dcs_policy_settings. It does not distinguish this from siblings like dcs_policy, dcs_policies, or dcs_policy_violations, so an agent cannot tell which of these returns settings versus full policy objects.
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?
There is no guidance on when to use this tool versus the many adjacent policy tools (dcs_policy, dcs_policies, dcs_policy_violations). No prerequisites, no exclusions, and no indication of what a caller gains here that they cannot get elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read policy violations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| policy_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The "[READ]" prefix merely duplicates the readOnlyHint=true annotation, adding no new behavioral information. Nothing is said about pagination defaults, result ordering, scope (single policy vs all), or whether an empty result is possible; with annotations covering only the safety profile, the description should carry more of this burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is technically short, but brevity here reflects under-specification rather than concision. A single four-word fragment plus a redundant tag leaves no room for scope, filtering, or return-value 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, no annotations beyond readOnlyHint, and zero parameter description coverage, the description is the only explanatory surface — and it provides essentially nothing. The agent cannot tell what a call returns or how to interpret policy_id and limit from this definition 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 0%, so the description needs to explain both parameters, yet it mentions neither. The required policy_id (which policy namespace? ID format?) and the limit parameter (default 100, but no pagination semantics) are undocumented beyond their bare titles.
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?
"[READ] Read policy violations" essentially restates the tool name (dcs_policy_violations) with no additional specificity. It does not say what a "policy violation" is in this system, what entity it belongs to, or how it differs from siblings like dcs_policy, dcs_policies, or dcs_asset_policies.
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?
No when-to-use guidance, no prerequisites, and no mention of alternatives among the many policy-related siblings (dcs_policy, dcs_policy_settings, dcs_policy_library, dcs_asset_policies). The agent is left to infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read one report job state.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this a safe read, so the "[READ]" prefix is redundant restatement. Beyond that, the description says nothing about behavior for a nonexistent job_id, whether job state is live or historical, or what fields a job state contains. With annotations covering safety, the description still leaves the substantive behavior undisclosed.
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 short sentence with no filler and the resource stated immediately. It is terse but not padded; the only criticism is that the terseness comes at the cost of information rather than being efficient.
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 lookup with annotations and no output schema, the description should at minimum explain the returned job state and the relationship to dcs_report_jobs. Neither is present, so an agent knows only that the tool reads something called a report job state.
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 0% for the single parameter, so the description must compensate, and it does not: it never mentions job_id, where the ID comes from, or whether it must reference an existing job. The parameter name is largely self-explanatory, which keeps this above a 1, but no meaning is added.
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?
"Read one report job state" gives a verb (read) and a resource (report job), and the word "one" signals singular retrieval, which implicitly contrasts with the plural sibling dcs_report_jobs. However, "state" is vague about what is actually returned, and the description never names the list sibling to make the distinction explicit.
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?
There is no guidance on when to use this tool rather than dcs_report_jobs (list) or dcs_reports. The agent must infer from the tool name that this fetches a single job by ID; no prerequisites or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List report job states.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already establishes that this is a safe read operation, and the "[READ]" tag adds nothing beyond it. Nothing is said about whether results are paginated, ordered, truncated by the limit, or what a "job state" record contains – context an agent would need for a polling/listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is tightly written and front-loaded with the read marker, so there is no wasted wording. However, brevity here reads as under-specification rather than economy – the one sentence carries no usable detail.
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, one entirely undocumented parameter, and no explanation of what a report job state is or how it relates to the other report tools. For a listing endpoint in a dense 34-tool namespace, the definition leaves too much for the agent to infer.
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 0% for the single `limit` parameter, and the description never mentions it. With an undocumented param and no description compensation, the agent cannot tell whether limit caps jobs, pages of jobs, or something else, nor what the default of 100 implies.
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?
"[READ] List report job states" names a verb (list) and a resource (report jobs), but "states" is ambiguous – it could mean job status values, job records, or state transitions. It also gives no signal about how this differs from the singular sibling dcs_report_job or from dcs_reports/dcs_report_stats, so the agent must guess which plural/singular variant to call.
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?
There is no guidance on when to use this tool versus dcs_report_job, dcs_reports, or dcs_report_stats. The only cue is the "[READ]" prefix, which merely restates the read-only annotation rather than describing a selection condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List report definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [READ] tag merely restates the supplied readOnlyHint=true, adding no behavioral context. Nothing is said about pagination, ordering, default limit behavior, or what happens when no reports exist, which is the burden the description should carry for a list endpoint.
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 short line with zero waste and the read-only marker front-loaded, but it is under-specified rather than concise. There is no structure beyond a single fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool this could be adequate, but with no output schema, an undocumented limit parameter, and many closely named report siblings, the description leaves an agent without enough to call it confidently or choose it over alternatives.
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 0% for the single 'limit' parameter, so the schema supplies no meaning at all beyond its name and a default of 100. The description never mentions the parameter, its bounds, or whether it truncates results, leaving the agent to infer its effect.
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 and resource ("List report definitions"), which reads clearly as a read operation over report definitions. It implicitly distinguishes from siblings like dcs_report_jobs and dcs_report_stats by naming "definitions", but it never explicitly contrasts with them, so sibling 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?
There is no when-to-use guidance, no mention of when to reach for dcs_report_jobs or dcs_report_stats instead, and no stated prerequisites. An agent must guess the boundary between listing definitions and listing jobs or stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read report counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description's "[READ]" prefix merely restates that. Beyond the safety hint it discloses nothing — no indication of scope, filters, aggregation window, or shape of the returned counts, which matters since there is no output 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?
It is a single short sentence with no filler and the read nature is front-loaded. However, the extreme brevity crosses into under-specification rather than efficiency — the one sentence does not convey enough to make the tool reliably selectable.
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-parameter, no-output-schema tool, the description is the only place an agent can learn what is actually returned, and it does not say. "Counts" of what, over what period, and in what units remains unknown, leaving the agent to guess before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description could note that the counts are unfiltered/global, but no parameter semantics are needed here.
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?
"Read report counts" names a verb (read) and an object (report counts), so it is not pure tautology, but "counts" is undefined — it does not say whether these are counts of reports, report jobs, or report results. It also does not distinguish itself from siblings such as dcs_reports or dcs_report_jobs, which an agent would naturally consider for the same question.
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?
There is no when-to-use guidance and no mention of the obvious alternatives (dcs_reports for listings, dcs_report_jobs for job records). The agent must infer from the name alone which of the report-related siblings answers its question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read one RBAC role.
| Name | Required | Description | Default |
|---|---|---|---|
| role_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The "[READ]" tag merely restates the readOnlyHint=true annotation already supplied, adding no new behavioral context. Nothing is said about what happens with a nonexistent or unauthorized role_id, nor about error or not-found 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?
A single short sentence with the tag front-loaded; nothing is wasted. However, the brevity borders on under-specification rather than efficient structure.
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 read tool with readOnlyHint covering the safety profile, the essentials are nearly present. The missing piece is the origin/semantics of role_id and error behavior, which an agent needs to call it correctly the first time.
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 0%: role_id is typed integer but has no description, and the tool description does not compensate by explaining where role_id comes from or whether it is the internal or external identifier. With one required parameter fully undocumented, the meaning gap is real.
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?
"Read one RBAC role" gives a specific verb (read) and resource (RBAC role), and the word "one" implicitly separates it from the list sibling dcs_roles. It stops short of explicitly naming that sibling, so differentiation relies on 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?
There is no when-to-use or when-not-to-use guidance and no mention of dcs_roles as the listing alternative. The agent must infer that this is the single-record fetch from the word "one".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List RBAC roles.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the '[READ]' prefix merely restates that without adding context. The description says nothing about result ordering, pagination behavior with the default limit of 100, or whether the list is scoped to the caller's tenant.
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 short, front-loaded sentence with no filler. The only waste is the redundant '[READ]' marker given the readOnlyHint annotation.
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 list endpoint with no output schema, the description should indicate what a role record contains and how the limit affects results. It provides neither, leaving the agent with less information than it needs to call the tool confidently.
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 0% for the single 'limit' parameter, so the description should clarify what it bounds and whether there is a maximum or pagination cursor. It adds no parameter meaning at all, leaving the default of 100 and any cap undocumented.
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 and resource ('List RBAC roles'), which is unambiguous about what the tool returns. It does not distinguish itself from the singular sibling 'dcs_role' or 'dcs_role_users', so an agent must infer that this is the collection-level listing.
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?
No guidance on when to use this versus 'dcs_role' (single role) or 'dcs_role_users'. The '[READ]' tag hints at read-only intent but that is already conveyed by annotations, not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List users assigned to a role.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| role_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' marker merely restates the readOnlyHint=true annotation, adding no new information. The description is silent on pagination behavior despite a 'limit' parameter defaulting to 100, says nothing about whether results are truncated, and gives no indication of return 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?
A single, front-loaded sentence with zero waste. It is arguably under-specified rather than verbose, which keeps it efficient but leaves gaps.
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 list tool with no output schema and two undocumented parameters at 0% coverage, the description should at least explain pagination and what a user record contains. As written, an agent knows only the endpoint's broad intent and must guess at result size and structure.
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 0%, so neither parameter is documented in the schema. The description implies role_id identifies the role, but adds no format or constraint detail, and it says nothing at all about the 'limit' parameter or its default of 100.
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 and resource ('List users assigned to a role'), which is more specific than the bare tool name and clearly delineates it from dcs_users or dcs_role. It does not explicitly name a sibling it contrasts with, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over dcs_users, dcs_role, or dcs_security_groups, nor any stated prerequisites (e.g., needing a valid role_id). The purpose implies the use case but the agent must infer when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read one security group.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the '[READ]' prefix merely restates that. The description adds nothing beyond the annotation: no behavior for an unknown group_id (empty vs error), no permission requirements, and no return shape, even though no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six words, front-loaded with a read marker and the core action. Nothing is wasted, though the brevity reflects under-specification rather than disciplined economy.
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-record lookup with an undocumented required ID parameter and no output schema, the description should say something about the identifier's origin and what is returned. Neither is present, leaving the agent with only the tool name to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (group_id) with 0% description coverage, and the description does not compensate at all — it never mentions the parameter, its type, or how to obtain a valid ID. The agent gets no meaning beyond the property name.
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 name plus description state a specific verb and resource ('Read one security group'), and 'one' weakly implies a single-record fetch. However, it never explicitly contrasts with the sibling dcs_security_groups (plural listing) or dcs_security_group_stats, so the agent must infer the singular/plural distinction from naming alone.
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?
There is no guidance on when to use this versus dcs_security_groups or dcs_security_group_stats. No prerequisites, no mention of where a group_id comes from, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List security groups.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read, and the "[READ]" prefix merely repeats that. Beyond the annotation, nothing is disclosed about pagination behavior, whether the default limit of 100 truncates results, or what fields each security group record contains.
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 short, front-loaded sentence with zero padding, so it is efficient. However, the brevity borders on under-specification rather than true conciseness given that a parameter and the return shape go unaddressed.
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 and no annotation covering returns, so the description is the only place to explain what a listed security group looks like and how paging works, and it does neither. For a collection-list endpoint the definition is too thin to call confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' has 0% schema description coverage and the description does not mention it at all, so an agent gets no meaning for it beyond its name and default of 100. This leaves the only tunable input undocumented in both places.
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 (List) and resource (security groups), so an agent knows exactly what it does. It does not differentiate from siblings such as dcs_security_group (singular) or dcs_security_group_stats, which would be the natural next step.
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?
No when-to-use guidance and no mention of alternatives; the agent must infer from the plural name that this is the collection-listing call versus the singular detail call. There are no prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read security group counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, and '[READ]' merely repeats it. Beyond that, the description says nothing about what the counts represent — total groups only, counts per policy, per tag, or per role — nor anything about auth requirements or result shape, which is exactly the context a count endpoint needs.
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 front-loaded sentence with no filler. The '[READ]' prefix is redundant with the readOnlyHint annotation but costs little, and the statement is not padded with vague 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?
With no output schema and no parameters, the description carries almost the entire burden, yet it never explains what the returned counts are keyed by. The tool is simple enough that an agent can invoke it blindly, but it cannot predict the response structure from this text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is trivially complete.
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 ('Read') and resource ('security group counts'), which distinguishes it in intent from the sibling list/entity tools dcs_security_groups and dcs_security_group. However, it never names those siblings or explicitly contrasts itself, so the differentiation must be inferred from the word 'counts'.
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?
There is no guidance on when to call this versus dcs_security_groups (list) or dcs_security_group (single entity), and no stated preconditions. The agent must guess that this is the lightweight aggregated-count endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List registered servers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [READ] tag merely restates the readOnlyHint=true annotation, adding no new behavioral information. Nothing is said about pagination behavior, the default page size of 100, ordering of results, or what fields a 'registered server' record contains.
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 short sentence with zero padding and the key information front-loaded. Brevity is appropriate here; the shortfall is missing content, not excess wording.
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 low-complexity list tool with no output schema and undocumented parameters, the description should at least state what a returned server record represents and how limit affects results. As written, an agent can call it but cannot reason about its output or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (limit) with 0% schema description coverage, so the description carries the full burden of explaining it — yet it never mentions the parameter, its default of 100, or any maximum value. A single clause on paging limits would have resolved this entirely.
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 pairs a specific verb with a specific resource ('List registered servers') and the [READ] prefix signals the operation class. It does not, however, differentiate this from close siblings such as dcs_assets or dcs_status, so an agent cannot tell what a 'registered server' is versus a managed asset.
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?
There is no when-to-use guidance, no mention of prerequisites, and no pointer to an alternative sibling tool. The agent must infer from the name alone whether this is the right listing endpoint among ~35 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] Read a DCS service status component.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' tag merely duplicates the readOnlyHint=true annotation, so it adds no new behavioral context. Nothing is said about what a status response contains, whether unhealthy states are reported, or how unknown components are handled. It does not contradict the annotations, but it contributes almost nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted wording and the read-only framing is front-loaded. Its brevity is the result of under-specification rather than efficient editing, so it earns only a middling score.
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 tool whose only required input is an undocumented string, the description omits the one thing an agent needs: acceptable component values or a pointer to where they come from. With no output schema, it also leaves the return shape entirely unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'component' parameter has 0% schema description coverage and no enum, so the description was the only place to explain valid values or format. It never does, leaving the agent unable to determine what string to supply.
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 reads as a near-restatement of the tool name 'dcs_status': 'Read a DCS service status component' adds the words 'status component' but never says what a component is or what status data is returned. It also fails to distinguish this tool from the many sibling stats/status-style tools such as dcs_asset_stats or dcs_alert_stats.
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?
There is no when-to-use guidance, no mention of alternatives, and no exclusions. With roughly 35 sibling dcs_* tools, an agent has no basis from the description for choosing dcs_status over dcs_assets, dcs_asset_stats, or similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List syslog destinations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the "[READ]" prefix merely restates that, adding no new information. Nothing is said about pagination, ordering, result volume, or what a syslog destination entry contains, which is the context the annotations do not cover.
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 short, front-loaded sentence with no filler. The only wasted token is the "[READ]" tag, which duplicates an annotation already supplied.
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 no-required-parameter list tool with an output schema absent but low complexity, a terse description is close to adequate. It is still missing return-value shape and the meaning of the default limit, which an agent needs to use results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single "limit" parameter carries only a default of 100. The description says nothing about what limit controls, whether truncation occurs, or how to page beyond it, so it fails to compensate for the schema gap.
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 ("List") and resource ("syslog destinations"), which is enough to separate it from every sibling like dcs_assets or dcs_alerts. It stops short of 5 because "destinations" is never grounded (servers? forwarding targets? config records?), leaving the agent to guess what a returned item represents.
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?
There is no when-to-use guidance, no prerequisites, and no alternatives named. With 34 sibling tools, the agent gets no help deciding between dcs_syslogs and adjacency like dcs_server_registry or dcs_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List policy and asset tags.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already declares this is a safe read, and the description adds nothing beyond restating that with '[READ]'. There is no disclosure of pagination behavior, default-result-size implications (limit defaults to 100), or what a listing returns in the absence of an output 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?
One short, front-loaded sentence with no filler, which is good, but the brevity comes at the cost of specification rather than being genuinely efficient. The '[READ]' prefix duplicates the readOnlyHint annotation without adding 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?
For a listing tool with one undocumented parameter and no output schema, the description should say what is returned and how paging works; it says neither. The only structured support is a single readOnlyHint, leaving the agent guessing about result shape and scope.
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 0% and the single parameter 'limit' is undocumented in both schema and description. The description does not say whether results are paginated, whether limit caps total results, or what the default 100 means in practice, so it fails to compensate for the coverage gap.
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 verb (List) and a resource (policy and asset tags), which is better than a tautology, but the resource is ambiguous: it is unclear whether these are tag definitions, tag assignments, or a union of policy tags and asset tags. The sibling dcs_asset_tags is not acknowledged, so an agent cannot tell the two apart from the description alone.
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?
There is no when-to-use guidance at all — no mention of when to pick dcs_tags over dcs_asset_tags, dcs_policies, or dcs_asset_tags, and no prerequisites or exclusions. The [READ] tag implies a read context but the readOnlyHint annotation already says that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[READ] List management users.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so "[READ]" adds no information. The description discloses nothing beyond that: no indication of result volume, whether the list is paginated or truncated at the limit, or what a "management user" record contains. With annotation coverage this sparse, the description should carry more of the burden than it does.
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 words, front-loaded and free of filler, so nothing is wasteful. But this level of terseness reads as under-specification rather than efficient writing — there is room to add scoping and return-shape detail without bloat.
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 list endpoint with no output schema and an undocumented `limit` parameter, the description should say what comes back and how paging behaves. Neither is present, so an agent knows the tool returns users but not how much of the user set or in what form.
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 0%, so the single optional `limit` parameter is documented nowhere — its default of 100 is only visible as a schema default, with no statement of maximums, paging semantics, or whether omitted means all users. The description does not compensate for this gap at all.
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 verb and resource ("List management users"), which at least tells an agent this returns user records rather than policies or alerts. However, "management users" is undefined — it doesn't clarify whether these are admin/console users, licensed users, or directory accounts, and among ~35 sibling tools there is no differentiation beyond the noun "users".
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 guidance is the "[READ]" tag, which merely restates the readOnlyHint annotation. There is no when-to-use context, no mention of related siblings such as dcs_roles or dcs_role_users, and no exclusions, so the agent must infer placement from the tool list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dcs_alert_detailsdcs_alert_notificationsdcs_alert_rulesdcs_alert_statsdcs_alertsdcs_assetdcs_asset_errorsdcs_asset_historydcs_asset_policiesdcs_asset_statsdcs_asset_tagsdcs_assetsdcs_event_statsdcs_eventsdcs_licensesdcs_policiesdcs_policydcs_policy_librarydcs_policy_settingsdcs_policy_violationsdcs_report_jobdcs_report_jobsdcs_report_statsdcs_reportsdcs_roledcs_role_usersdcs_rolesdcs_security_groupdcs_security_group_statsdcs_security_groupsdcs_server_registrydcs_statusdcs_syslogsdcs_tagsdcs_usersScored across 35 tools
Bare nouns force the agent to infer a singular=read-one / plural=list convention (dcs_policy vs dcs_policies, dcs_role vs dcs_roles), which the terse descriptions only partially clarify. Clusters like dcs_alerts / dcs_alert_rules / dcs_alert_stats / dcs_alert_details / dcs_alert_notifications, and dcs_tags vs dcs_asset_tags, have fuzzy boundaries that invite misselection.
Every tool uses the same dcs_ prefix and snake_case, and the singular/plural convention for get-vs-list is applied consistently across policies, roles, report jobs, and security groups. Minor deviations (dcs_status, dcs_syslogs) and the absence of explicit verbs keep it from a 5.
35 tools is heavy for a single server, and several are marginal variants of the same resource (dcs_policy_settings, dcs_policy_library, dcs_alert_details, dcs_alert_notifications, dcs_report_stats). The domain is broad, but the surface feels padded rather than curated.
Read coverage is genuinely broad — assets, alerts, events, policies, reports, RBAC, security groups, tags, syslog, licenses, users. However, the surface is entirely read-only, with no create/update/delete or policy-assignment operations for any managed resource, which is a notable gap if this is meant to drive an ops workflow rather than pure observability.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Read-only MCP access to authorized Vocci sessions, notes, files, and memory search.
