Skip to main content
Glama
OctopusDeploy

Octopus Deploy MCP Server

Official

Search the Octopus audit log

find_events
Read-onlyIdempotent

Search the Octopus Deploy audit log to find deployments, releases, modifications, user logins, and other recorded actions. Filter by user, project, environment, date range, and more.

Instructions

Search the Octopus Deploy audit log (also called the Events log) — every meaningful action recorded against a space: deployments, release creations, modifications, user logins, machine registrations, variable edits, tenant changes, and so on.

Modes (the mode arg):

  • search (default) — query the audit log. Requires spaceName. Supports rich filtering by user, project, environment, tenant, document type, date range, category, group, and agent.

  • listCategories — enumerate every event category (e.g. DeploymentSucceeded).

  • listGroups — enumerate event groups (e.g. Created, Modified, Deleted, Deployment). Each group lists the categories inside it.

  • listAgents — enumerate user-agent strings recorded by the audit subsystem.

  • listDocumentTypes — enumerate entity-prefix metadata (Projects-, Releases-, ...).

Search modes (within mode='search', picked by argument shape):

  • eventId → fetch that single event. Mutually exclusive with list and pagination filters; excludeDifference is still honoured.

  • otherwise → list events matching the filters, paginated.

Performance tip: the per-event ChangeDetails field (the before/after diff for Modified events) is by far the heaviest payload field. Pass excludeDifference: true whenever scanning many events; fetch a single event without the flag when you need the diff.

Filter semantics:

  • regarding — AND semantics: event must reference EVERY listed document ID.

  • regardingAny — OR semantics: event must reference ANY listed document ID.

  • All other multi-value filters (users, projects, environments, tenants, eventCategories, eventGroups, ...) are OR semantics within the field.

  • from (inclusive) and to (exclusive) accept ISO 8601 datetimes.

Permissions: requires EventView on the calling user's space scope. The server filters results further based on per-document permissions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoWhat to return. Defaults to 'search' (the audit log itself). Metadata modes enumerate valid filter values: listCategories returns every event category (e.g. DeploymentSucceeded, ReleaseCreated); listGroups returns category groupings (Created/Modified/Deleted/Deployment/Interruption/...); listAgents returns the user-agent strings seen by the audit subsystem; listDocumentTypes returns entity-prefix metadata (Projects-, Releases-, ...). Use a metadata mode first when you need to construct an eventCategories/eventGroups/documentTypes filter and don't know the valid values. Metadata modes ignore every other argument.
spaceNameNoSpace name. Required for mode='search'. Ignored by metadata modes (they are server-wide).
eventIdNoFetch a single event by ID (form 'Events-NNN'). Mutually exclusive with list and pagination filters (regarding, regardingAny, users, projects, environments, tenants, projectGroups, eventCategories, eventGroups, eventAgents, documentTypes, tags, from, to, skip, take). Compatible with excludeDifference (still honoured) and includeInternalEvents (no-op for single fetches).
regardingNoDocument IDs the event must relate to. AND semantics: event must reference EVERY id listed. Use regardingAny for OR semantics.
regardingAnyNoDocument IDs the event may relate to. OR semantics: event references ANY id listed.
usersNoUser IDs who triggered the event (OR semantics within the list).
projectsNoProject IDs the event relates to (OR semantics).
environmentsNoEnvironment IDs the event relates to (OR semantics).
tenantsNoTenant IDs the event relates to (OR semantics).
projectGroupsNoProject group IDs. Events for any project inside these groups are included.
eventCategoriesNoEvent category names, e.g. ['DeploymentSucceeded','DeploymentFailed']. Use mode='listCategories' to discover the full set.
eventGroupsNoEvent group names, e.g. ['Created','Modified','Deleted','Deployment','Interruption']. Each group is expanded server-side to the categories it contains. Use mode='listGroups' to discover the full set.
eventAgentsNoUser-agent strings of the clients that triggered the events. Use mode='listAgents' to discover the values present in this instance.
documentTypesNoDocument type prefixes, e.g. ['Projects-','Releases-']. Use mode='listDocumentTypes' to discover the full set.
tagsNoCanonical tenant tag IDs of the form 'TagSetName/TagName'. Filters events whose related tenants carry these tags.
fromNoISO 8601 datetime. Inclusive lower bound on Occurred (Occurred >= from).
toNoISO 8601 datetime. Exclusive upper bound on Occurred (Occurred < to).
includeInternalEventsNoDefault true. Set false to suppress per-target MachineAdded / MachineDeleted / MachineDeploymentRelatedPropertyWasUpdated noise that floods machine-heavy instances.
excludeDifferenceNoSet true to omit the ChangeDetails field (the before/after diff). ChangeDetails is by far the heaviest field per event — recommended for any scan of more than a few events.
skipNoPagination offset (search mode only).
takeNoPagination page size (search mode only). Server default is 30.
Behavior5/5

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

Annotations already mark the tool as read-only, destructive-false, idempotent. The description adds substantial behavior: mode behavior, mutual exclusivity of eventId with list filters, filter semantics, and performance impact of ChangeDetails. No contradictions.

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 long but well-structured with sections, bold headings, and bullet points. It is front-loaded with purpose and every sentence adds value for a complex tool with 21 parameters. Could be slightly more concise but appropriate for the complexity.

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

Completeness4/5

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

Given 21 parameters and no output schema, the description covers modes, filter semantics, performance tips, permissions, and mutual exclusions. It lacks explicit return structure details but provides enough for an agent to use correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining filter semantics (AND/OR), performance implications, and mutual exclusivity, which go beyond the individual parameter descriptions.

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 clearly states the tool searches the Octopus Deploy audit log, listing specific action types (deployments, releases, etc.). It distinguishes itself from sibling tools like find_releases and list_projects by focusing on the events log.

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

Usage Guidelines4/5

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

The description provides detailed usage guidance: when to use search vs metadata modes, performance tips (excludeDifference), filter semantics (AND/OR), and permissions. It does not explicitly compare to alternatives but gives enough context to decide when to use this tool.

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/OctopusDeploy/mcp-server'

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