Skip to main content
Glama
monitoringartist

LogicMonitor MCP Server

by monitoringartist
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

generate_website_link

Read-only

Generate a shareable URL for any LogicMonitor website monitor, preserving the full folder hierarchy for easy access in Slack, tickets, or documentation.

Instructions

Generate a direct direct URL/link/weburl for a LogicMonitor (LM) website monitor with full hierarchy path for easy sharing and navigation.

What this does: Creates shareable URL that opens specific website monitor in LogicMonitor UI, preserving the full folder hierarchy path. Link works for anyone with access to the LogicMonitor portal.

Returns: Complete URL in format: https://mycompany.logicmonitor.com/santaba/uiv4/websites/treeNodes#websiteGroups-{groupId1},websiteGroups-{groupId2},...,websites-{websiteId}

When to use:

  • Share website monitor with team (Slack/email/tickets)

  • Create documentation with direct links

  • Build custom dashboards/reports with LM links

  • Reference in incident tickets

  • Bookmark frequently accessed monitors

Required parameters:

  • websiteId: Website monitor ID (from "list_websites" or "search_websites")

Common use cases:

Share in Slack/Teams: "Production API health check is failing: View Monitor"

Incident ticket documentation: "INC-12345: Website monitor showing SSL certificate expiring in 7 days. See: {generated-url}"

Runbook links: "If homepage monitoring alerts, check: {generated-url-for-homepage-monitor}"

Custom reporting: Build report that includes clickable links to each website monitor for quick access.

Link structure explained: The URL includes complete folder path (websiteGroups) so when clicked, the UI shows:

  • Full breadcrumb navigation (e.g., "All Website Monitors > Production > External APIs > Homepage Check")

  • Website monitor details page

  • Recent check history and availability

  • Current status and response times

Why use generated links:

  • Shareable: Send exact monitor to teammates

  • Bookmarkable: Save frequent monitors for quick access

  • Integration-friendly: Use in external tools, tickets, wikis

  • Context-preserving: Shows full folder hierarchy when opened

Workflow example:

Access requirements: Link recipients must:

  • Have LogicMonitor user account

  • Have permissions to view website monitors

  • Have access to specific website monitor (based on access groups)

Best practices:

  • Use in incident documentation for traceability

  • Include in runbooks for quick troubleshooting access

  • Add to monitoring dashboards for drill-down capability

  • Share with stakeholders who have LM access

Related tools: "list_websites" (find website), "get_website" (verify details), "generate_dashboard_link" (for dashboards), "generate_resource_link" (for resources/devices), "generate_alert_link" (for alerts).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
websiteIdYesThe ID of the website monitor to generate a link for

Tool Definition Quality

A4.6/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=true, and the description confirms this by explaining it creates a shareable URL without modifying anything. It adds context about access requirements and what the link shows.

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 well-structured with bold headers and sections, but it is verbose with some redundancy (multiple use case examples). Good separation of concerns.

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?

Given low complexity (1 parameter, no output schema), the description is thorough: it explains the return format, workflow, access requirements, best practices, and dependencies (list_websites).

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%, baseline 3. The description adds meaning by stating the source of websiteId (from list_websites or search_websites), which provides useful context beyond the schema description.

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 generates a direct URL for a LogicMonitor website monitor with full hierarchy path. It distinguishes from sibling tools by specifying the scope (website monitors) and listing related tools.

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 provides explicit when to use (sharing, documentation, dashboards) and includes common use cases, access requirements, and best practices. It also references related tools.

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

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