Skip to main content
Glama
GaneshR-dev

oracle-hcm-mcp

by GaneshR-dev

hcm_list_notifications

Read-only

List business process notifications with optional filters by status or assignee to find relevant approvals and alerts.

Instructions

List business process notifications. Optional status/assignee filters (richer BP filters).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
limitNo
offsetNo
statusNoe.g. OPEN
assigneeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior3/5

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

The readOnlyHint annotation already signals a safe read operation, and the description's 'List' wording is consistent. It adds modest context by scoping the list to business process notifications, but does not describe ordering, pagination, or whether status/assignee values are exact or partial.

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

Conciseness4/5

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

The description is short and front-loaded with the verb+resource in the first sentence. The parenthetical 'richer BP filters' is slightly ambiguous, but the overall length is appropriate.

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?

With no output schema, the description does not explain what returned notifications look like, what filtering semantics are, or how pagination works. Given the noisy sibling list, more explicit differentiation and return context would be needed for reliable tool selection.

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

Parameters2/5

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

With only 20% schema description coverage and five parameters, the description needed to compensate but only names status and assignee as optional filters. It never clarifies q, limit, offset, valid status values, or assignee syntax, and 'richer BP filters' is vague.

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 states a concrete action ('List') and resource ('business process notifications'), so the core purpose is clear. It doesn't explicitly differentiate itself from siblings like hcm_get_notification or hcm_list_pending_approvals, which keeps it 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.

Usage Guidelines2/5

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 hcm_get_notification, hcm_list_pending_approvals, or hcm_bulk_approve_notifications. The only usage hint is 'optional status/assignee filters,' which addresses parameter filtering rather than tool-selection context.

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

Deploy Server

Other Tools