Prepare Your Data to Be MCP-Ready

Before an AI client can discover and use the content in your ArcGIS Enterprise organization, that content has to be prepared for MCP. Preparation is a deliberate, two-step process that you—the portal administrator or item owner—control: first you opt an item in by tagging it, and then you describe it well so the MCP tools can find and reason about it. This page explains both steps and shows real examples from the sample deployment.

Why data preparation matters

MCP tools do not see everything in your portal, and they do not guess. They work with exactly the items you expose and the metadata you provide. Two things follow from this:

  • Discovery is opt-in. The Search Portal Content tool—the entry point for almost every MCP workflow—only returns items that are explicitly tagged with mcp. If an item is not tagged, search will not surface it, so an agent has no way to find it on its own. (This governs discovery, not access—see the note in Step 1.)
  • Discovery is driven by text. When an agent searches your portal, it matches the user's natural-language request against each item's title, snippet, description, and tags. A well-described item surfaces for the right prompt; a sparsely described item stays invisible even when it holds exactly the data the user needs.

Preparing your data well is therefore the single highest-leverage thing you can do to make MCP useful in your organization.

The discover → describe → invoke pattern starts with you As described in MCP in ArcGIS Enterprise, every MCP interaction follows a discover → describe → invoke pattern. That pattern can only begin if your items are discoverable (Step 1) and self-describing (Step 2).

Step 1: Tag portal items with mcp

The mcp tag marks an item as discoverable by the MCP server. It identifies the curated subset of content you want AI clients to find through search. Only items carrying this tag are returned by Search Portal Content, and because Search Portal Content is the starting tool for nearly every workflow, the tag is what makes your content discoverable to agents.

How to tag an item

  1. Sign in to your ArcGIS Enterprise portal and open the item page for the content you want to expose.
  2. Open the item's Settings (or edit the item details) and locate the Tags field.
  3. Add a tag with the exact value mcp (lowercase), alongside any other descriptive tags the item already has.
  4. Save your changes. The item is now eligible to be returned by MCP searches.

Examples

The following items in the sample deployment have been tagged with mcp and are therefore discoverable by MCP clients:

  • San Francisco Infrastructure and Natural Features — a feature service whose tags include San Francisco, emergency services, transportation network, and mcp. View item
  • SampleWorldCities — a map service tagged simply SampleWorldCities, MapServer, and mcp. View item

Open either item and inspect its Tags section—you will see the mcp tag listed among the others. Remove that tag, and the item immediately drops out of every MCP search result.

Important: the mcp tag controls discovery, not access

Tagging is a search filter, not a runtime lock. An item that is not tagged mcp will not appear in Search Portal Content results, so an agent cannot discover it on its own. The tag does not, however, block the other tools: if an agent is already given a specific item ID or layer URL—because the user supplied it, or it came up earlier in the conversation—tools such as Describe Item, Describe Layer, and Query Data can still inspect or query that content even when it is untagged. Untagged feature layers in particular cannot be reliably blocked at runtime. The real access boundary is your ArcGIS Enterprise sharing and permission rules—use the mcp tag to make content findable, and rely on sharing and permissions to control who can reach it.

Tip: let the server handle the tag filter The mcp tag filter is injected automatically by the server. When you or an agent build a passthrough search query, do not add tags:"mcp" yourself—doing so is unnecessary and can interfere with results. See Search Portal Content for details.

Step 2: Write rich item metadata so tools can find the right data

Tagging makes an item eligible to be found. Good metadata makes it actually found—and used correctly. When an agent searches your portal, it has nothing to go on but the words in each item's title, snippet, description, and tags. The richer and more accurate that text, the more reliably the right item surfaces for the right prompt, and the better the agent understands what the data contains before it ever queries a single record.

What to include in an item's description

A strong, MCP-ready description does more than name the dataset. Aim to cover:

  • Overview — one or two sentences stating what the dataset is and what it is for.
  • Contents — the layers, tables, or bands the item exposes, and the key fields or attributes in each. This is what lets an agent decide an item can answer a question before calling Describe Layer or Query Data.
  • Geographic coverage — the area the data spans and the coordinate system, so location-based prompts match.
  • Use cases — the kinds of questions or analyses the data supports, phrased in the natural language a user is likely to use.

Fill in the title and snippet with the same care. A descriptive title such as California Geographic and Demographic Data Repository matches far more relevant prompts than an opaque name like cog or Landsat8_scene.

Examples of well-described items

Each of the following items from sample server has been given detailed metadata so that MCP tools can match it to the right request. Open them and read the Description to see the level of detail that works well:

  • SampleWorldCities — describes all three layers (Cities, Continent, World), the key fields on each, the population-class breakdown, the global extent, and concrete use cases. View item
  • California Geographic and Demographic Data Repository — documents ten thematic layers with feature counts and attributes, the NAD83 UTM Zone 12N projection, and six distinct use cases spanning planning, transportation, and environmental analysis. View item
  • Lower Florida Keys aerial imagery (item title cog) — the title alone says nothing, but the description supplies the band structure, 1 m resolution, geographic footprint, and use cases that make it discoverable despite the unhelpful name. View item
  • Landsat 8 scene (item title Landsat8_scene) — documents all 12 bands, the 30 m resolution, the southern Appalachian extent, and analysis use cases such as NDVI and land-surface-temperature computation. View item
  • Find Nearby Reported Safety Issues (a geoprocessing service) — describes both tasks it exposes, their inputs and outputs, and the civic-engagement workflows they support. View item

Note: a vague title can be rescued by a good description Several of the examples above—cog and Landsat8_scene—have unhelpful titles, yet they remain discoverable because their descriptions are thorough. A clear title is still preferable, but a rich description is what does the heavy lifting for MCP discovery. When you can, fix both.

Tip: write for the question, not the catalog Describe your data the way a user would ask for it. If someone might say "show me hospitals and fire stations in San Francisco," make sure the words hospitals, fire stations, and San Francisco actually appear in the item's description—as they do in the San Francisco example above.

Preparation checklist

Before you consider an item MCP-ready, confirm that it:

  • Carries the mcp tag (Step 1).
  • Has a clear, descriptive title and snippet.
  • Has a description covering overview, contents and key fields, geographic coverage, and use cases (Step 2).
  • Is shared appropriately so the intended MCP clients can access it under your organization's permission rules.

When all four are true, the item is ready to be discovered by Search Portal Content and acted on by the rest of the MCP tool catalog.

Once your data is prepared for MCP, refer to the MCP Tool Catalog to understand the available MCP tools. And if you want to know how to expose a custom geoprocessing task as a custom MCP tool, refer to Expose Custom GP Tasks as Custom MCP Tools.