Metadata MCP Connector

Discover Metadata features to try

discover_features

Read-onlyIdempotent

Show which Metadata features this account already uses and which it has not tried yet, with personal recommendations and an example request for each. Read-only, and always about the account this connection is working in. Use when the user asks what else Metadata can do, what they are missing or have not tried, or for feature recommendations. Each feature has a status: in_use, tried, not_used, needs_connection (a channel or CRM must be connected first), not_in_plan (the account's plan or the user's permissions rule it out; never recommend these) or unknown (could not be read; do not call it unused). Usage comes from the account's platform records (basis platform) or, for features that leave no platform record, only from calls through Metadata's MCP connectors (basis mcp): for those, not_used means no such call, so never tell the user they have not used it in the Metadata app. why_for_you is specific to this account only when personal is true. Present the picks as short cards (name, what it does, why it fits them, the example request) and offer to run one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "discover_features"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many recommendations to return, 1 to 12.
`domain`	No	Optional area to focus on. Omit for every area.
`include_inventory`	No	Include the status of every feature, not only the picks.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent, but the description adds substantial unseen context: the six status values and their meaning, the basis distinction (platform records vs. MCP connector calls) with an explicit warning not to tell users they haven't used an mcp-basis feature, and the caveat that why_for_you is account-specific only when personal is true.

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?

Purpose and trigger conditions are front-loaded, then the status semantics follow. It is on the long side with some dense clauses (the basis sentence in particular), but nearly every sentence carries actionable constraint information rather than filler.

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?

An output schema exists, so return shape needn't be explained, yet the description still covers what an agent needs to interpret results correctly: status meanings, recommendation eligibility rules, and how to present picks as cards with an offer to run one.

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?

Schema description coverage is 100% and all three parameters (limit, domain, include_inventory) are documented in the schema itself. The description adds no parameter-level guidance beyond implying a 'picks' subset, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: shows which Metadata features the account uses vs. has not tried, plus recommendations and example requests. It is clearly distinguishable from CRUD siblings, though it does not explicitly contrast with the nearby get_metadata_capabilities tool, leaving slight ambiguity about which to pick for a capabilities lookup.

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?

Gives explicit triggering conditions: 'Use when the user asks what else Metadata can do, what they are missing or have not tried, or for feature recommendations.' It also states negative guidance in the output semantics ('never recommend these' for not_in_plan). No named alternative sibling, so it stops short of a 5.

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 tools Inspect

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

Need Help?