Skip to main content
Glama
ukkugh

tenable-identity-exposure-mcp

by ukkugh

tie_search_ad_objects

Search Active Directory objects by name or DN substring, optionally filtered by directory and object class, to locate relevant security objects.

Instructions

Find Active Directory objects whose name or DN contains query.

IMPORTANT: /api/ad-objects has no server-side search. It returns the last known state of every object, cursor-paginated (~1000 per page, roughly 2 MB each on a small forest). Filtering here is therefore CLIENT-SIDE, and only objects within the scanned prefix can match — raise max_scanned to widen the sweep, and read scanned/truncated in the result before concluding that something does not exist.

For deviance investigation prefer tie_deviances / tie_deviances_by_checker, which are filtered server-side.

Args: query: Substring to look for, case-insensitive. Matched against objectId and the naming attributes (cn, name, displayName, sAMAccountName, distinguishedName, userPrincipalName) — not against bulk blobs like ntSecurityDescriptor, which would produce meaningless hits. directory_id: Restrict to one directory (see resource="directories"). object_class: Substring of the objectClass attribute, e.g. "user", "computer", "group", "organizationalUnit". Note this is the LDAP objectClass; the object's own type field is the data source (LDAP or SYSVOL), not the object category. max_results: Stop after this many matches (default 50). max_scanned: Cap on objects fetched while searching (default 5000). timestamp: Optional ISO 8601 UTC point in time; defaults to now. verbose: If False (default), oversized attribute values are dropped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
verboseNo
timestampNo
max_resultsNo
max_scannedNo
directory_idNo
object_classNo
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly: explains the lack of server-side search, describes client-side scanning semantics, warns about pagination (~1000 per page, ~2 MB each), and tells users to inspect `scanned`/`truncated` in results. This goes far beyond a typical tersely-worded tool description.

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

Conciseness5/5

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

Though longer than average, the description's length is justified by the tool's complexity and lack of annotations. The structure is effective: opening purpose, an IMPORTANT behavioral caveat block, a sibling-alternative line, then a cleanly labeled Args list. Every sentence communicates essential operational knowledge, with no filler.

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

Completeness5/5

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

The description covers purpose, behavioral constraints, parameter semantics, defaults, result interpretation (`scanned`/`truncated`), and alternatives. Even without an output schema, the tool's return behavior is adequately conveyed. This is a complete, self-sufficient description for a complex search tool.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate for every parameter. It does: `query` (substring matching, case-insensitive, against specific attributes), `directory_id`, `object_class` (LDAP objectClass vs the object's own `type` field), `max_results`, `max_scanned`, `timestamp`, and `verbose` all receive meaningful semantic explanations beyond the bare schema definitions.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Find Active Directory objects whose name or DN contains `query`.' It clearly distinguishes this from deviance-focused siblings by explicitly naming tie_deviances and tie_deviances_by_checker as the preferred server-side alternatives for deviance investigation.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool versus alternatives: 'For deviance investigation prefer tie_deviances / tie_deviances_by_checker, which are filtered server-side.' It also provides critical usage caveats about client-side filtering, `max_scanned`, and reading `scanned`/`truncated` before concluding an object doesn't exist.

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/ukkugh/tenable-identity-exposure-mcp'

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