Skip to main content
Glama

Metadata MCP Connector

by io.metadata.mcp-server
OverviewDiscussionsAdmin

Find Offer Landing-Page URL

find_offer_url
Read-only

Locate the BEST specific landing-page URL for a marketing offer on a given domain.

                Runs three discovery strategies in parallel:
                  1. Direct path probe — conventional paths per offer_type (e.g. /request-demo, /case-studies, /roi-calculator)
                  2. Sitemap scan      — <loc> entries filtered by offer-type keywords + optional topic
                  3. Footer/body scrape — CTA/nav links matching the offer intent

                Candidates are scored by specificity. Generic hub pages (/resources/, /content/, /library/, homepages)
                are HARD REJECTED — this tool exists precisely to avoid shipping them.

                USE THIS BEFORE create_update_offer WHENEVER offer_type = "Landing Page"
                AND the user did NOT provide an explicit URL.
                Do NOT guess a URL. Do NOT rely on web_search for landing pages — this tool is more reliable.

                USER-PROVIDED URL OVERRIDE (HARD RULE):
                If the user already specified a landing-page URL in their request (e.g. "use
                https://acme.com/demo-fintech" or "point offers at our pricing page"), DO NOT
                call find_offer_url — use the user's URL verbatim in create_update_offer.
                Never overwrite an explicit user-provided URL, even if it looks generic.

                WHEN TO USE:
                - Before every create_update_offer call with offer_type="Landing Page"
                - When you need a specific demo / case-study / whitepaper / ROI calculator / guide URL
                - When web_search returned only generic /resources/ or homepage URLs

                FALLBACK BEHAVIOR:
                - On success: use `offer_url` verbatim in create_update_offer.landingPageUrl
                - On success=false: DO NOT create a Landing Page offer. Switch to offer_type="Lead Gen" instead.

                RETURNS:
                {
                    "success": true,
                    "domain": "snowflake.com",
                    "offer_type": "case_study",
                    "topic": "fintech",
                    "offer_url": "https://www.snowflake.com/customers/square/",
                    "source": "sitemap",
                    "link_text": "Square",
                    "score": 95,
                    "steps_tried": ["direct-probe", "sitemap", "footer-scrape"],
                    "candidate_count": 42
                }

                On failure: { "success": false, "suggestion": "Switch offer_type to 'Lead Gen'..." }

                EXAMPLES:
                - find_offer_url(domain="snowflake.com", offer_type="case_study", topic="fintech")
                - find_offer_url(domain="servicenow.com", offer_type="demo")
                - find_offer_url(domain="mongodb.com", offer_type="roi_calculator")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNoOptional topic keywords to bias scoring (e.g., 'fintech', 'servicenow integration', 'data warehousing'). Improves hit rate when the domain has many offers of the same type.
domainYesCompany website URL or domain. Examples: 'snowflake.com', 'www.servicenow.com'
offer_typeYesType of offer content to locate. Drives which paths are probed and which keywords score higher.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses the three parallel discovery strategies, scoring behavior, hard rejection of generic hubs, failure fallback, and the exact return shape. The readOnlyHint and destructiveHint annotations align with this read-only lookup, and the description adds substantial behavioral detail beyond those annotations.

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-organized with headed sections, bullet lists, an example return payload, and clearly separated rules. There is minor redundancy—such as repeating the user-provided-URL override—but the structure keeps high-value information easy to find.

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?

Despite having no output schema, the description fully explains success and failure responses, return fields, fallback behavior, and invocation examples. No critical operational detail an agent would need in order to call this tool correctly is missing.

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?

The input schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds useful examples and clarifies how offer_type and topic influence the search, but it does not add significant meaning beyond what the schema already states.

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: 'Locate the BEST specific landing-page URL for a marketing offer on a given domain.' It clearly distinguishes this tool from siblings like create_update_offer and web_search by announcing that generic hub pages are hard rejected and that this is a more reliable discovery path.

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 gives explicit when-to-use and when-not-to-use guidance: use before create_update_offer for offer_type='Landing Page' when no URL is provided, and never call it when the user supplied an explicit URL. It even names web_search as an inferior alternative and explains the fallback to offer_type='Lead Gen' on failure.

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

All Metadata MCP Connector toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources