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. So are files: images, media
                and PDFs are never an offer page (the page with the form is), so a report or guide a site only
                links as a PDF answers success=false rather than the document.

                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.9/5.0
Behavior5/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false, and the description builds on that by detailing the three parallel strategies (direct probe, sitemap scan, footer scrape), the hard rejection of generic hub pages, images/PDFs, and the specificity scoring behavior. It also explains the success and failure response semantics. No contradiction with annotations is present.

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?

The description is long but every section earns its place: strategies, rejection rules, hard override, when-to-use, fallback behavior, return examples. It is front-loaded with the core purpose, and the use of clear headers and an example JSON return makes scanning easy. The verbosity is justified by the number of edge cases it resolves.

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?

With no output schema, the description compensates by showing both success and failure return shapes, including fields like source, score, and suggestion. It covers all necessary decision paths: when to reuse the URL verbatim, when to switch offer_type, and what to avoid. There are no critical gaps for an agent selecting or invoking this tool.

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 covers 100% of parameters, so the baseline is 3. The description adds value by tying offer_type to the direct-path probe logic, topic to 'bias scoring', and domain examples to expected input forms. It also gives three explicit call examples that make the parameter interplay concrete, going slightly beyond the schema's field 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 opens with 'Locate the BEST specific landing-page URL for a marketing offer on a given domain' — a specific verb, resource, and intent. It goes on to explain what makes the result 'best' via scoring and rejection rules, clearly distinguishing it from generic URL finders and from create_update_offer, which it explicitly references as a sibling step.

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 'WHEN TO USE' and 'HARD RULE' sections give explicit, decision-ready guidance: call before create_update_offer when offer_type is 'Landing Page' and no user URL is provided, skip entirely when the user supplied a URL, and never guess. It also states when not to rely on web_search and what to do on failure (switch to Lead Gen). This leaves no ambiguity about when and when not to invoke.

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