Skip to main content
Glama
mcpAD

mcpAD

Find Recently Created

find_recently_created
Read-only

Find Active Directory objects created within a specified number of days, optionally filtering by object class or scoping results to a base OU.

Instructions

Find objects whose whenCreated is within the last days days (default 7).

Pass object_class (e.g. "user", "group", "computer") to restrict to one object type, and base (a DN) to scope to an OU.

Input Schema

NameRequiredDescriptionDefault
baseNo
daysNo
limitNo
domainNo
object_classNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the meaningful detail that results are keyed on the LDAP whenCreated attribute and that the window defaults to 7 days. It says nothing about the effect of `limit` (default 100), truncation behavior, or whether `domain` falls back to a default — gaps for a query that can silently return partial results.

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

Conciseness5/5

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

Two short sentences plus one clarifying sentence, no filler. The core predicate and the non-obvious 7-day default are front-loaded, with the optional narrowing parameters after.

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

Completeness3/5

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

An output schema exists, so return values need no explanation. However, for a 5-parameter read with no schema descriptions, the omission of `limit` and `domain` leaves the agent guessing about result caps and domain resolution.

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

Parameters3/5

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

Schema description coverage is 0% with 5 parameters, so the description must carry the semantics. It does explain days (with default), object_class (with example values), and base (as a DN), but leaves `limit` and `domain` entirely undocumented. Partial compensation puts it at the baseline rather than below.

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?

States a specific verb (find), a specific resource (objects), and a precise predicate — the whenCreated attribute within the last `days` days. That attribute-level predicate is exactly what separates it from the sibling find_recently_modified and from generic listings like find_users or search_ldap.

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

Usage Guidelines3/5

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

The description gives narrowing instructions ('pass object_class to restrict to one type', 'pass base to scope to an OU'), which is implied how-to-use guidance. It never states when to choose this over find_recently_modified or search_ldap, nor offers any exclusion conditions.

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