Skip to main content
Glama

ise_dc_view_tacacs_authentication

View TACACS authentication records and filter by address, profile, status, and identity store to troubleshoot authentication issues.

Instructions

[Report] TACACS Authentication: This provides details of all the TACACS authentication records Filterable columns include: REMOTE_ADDRESS, SELECTED_AUTHORIZATION_PROFILE, DESTINATION_IP_ADDRESS, STATUS, DEVICE_TYPE, LOCATION, IDENTITY_STORE, DEVICE_IPV6.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows (default 100, max 10000).
order_byNoColumn to sort by (prefix '-' for descending).
days_backNoOnly rows from the last N days (uses the view's time column).
filter_opNoEQ=exact, CONTAINS/LIKE=substring, GT/LT/GTE/LTE=compare.EQ
deploymentNoTarget ISE deployment: name ('RADIUS Only'), slug ('radius-only'), or number ('1' or 'Deployment 1'). Omit to use the only/default deployment. Call ise_list_deployments to see the choices.
filter_valueNoValue to match for the filter column.
filter_columnNoColumn to filter on (case-insensitive).
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It identifies this as a read-only report ('[Report]'), which is good, but it doesn't disclose pagination behavior, what the output format looks like (no output schema), whether records have a time window or are historical, or how the 'all' records are defined given there's a days_back filter parameter. The description is essentially a label plus a column list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loads the purpose with '[Report] TACACS Authentication'. The column list is useful but presented as a single run-on sentence. It's reasonably concise with no wasted words, though it lacks structural organization (e.g., paragraph breaks for purpose vs. capabilities).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a report-style tool with 7 parameters, no annotations, and no output schema, the description should provide more context. It doesn't explain the report's scope, time frame, what 'all records' means, the meaning/purpose of each filterable column, or what the response looks like. The existence of sibling TACACS views (authorization, accounting, command accounting) with no differentiation leaves the agent guessing which report fits the task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with all 7 parameters having descriptions in the input schema (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column). The description adds the list of filterable columns (REMOTE_ADDRESS, SELECTED_AUTHORIZATION_PROFILE, etc.), which is useful for choosing filter_column values. However, the description does not add insight beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states '[Report] TACACS Authentication' and that it provides details of all TACACS authentication records, listing filterable columns. It uses a specific verb+resource construction and differentiates somewhat from siblings (the tacacs_authorization, tacacs_accounting variants). However, it doesn't explicitly distinguish from the sibling ise_openapi_tacacs_authentication_list or clarify the 'dc_view' vs 'openapi' distinction, which weakens sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance or mention of alternatives. The filters are listed but there is no statement about when this report view is appropriate versus other TACACS reporting tools like ise_dc_view_tacacs_authorization/accounting. The 'deployment' parameter references calling ise_list_deployments, but no broader usage context is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheOtherBrad/cisco-ise-mcp'

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