Engagemii AI Visibility Data

Pull licensed company records

data_records

Pull full licensed records from the Engagemii dataset (the same 113 columns as a purchased file, in the same order, fingerprinted; add-on cells are empty here; they are filled in data files that buy the add-on and in the free Databricks Marketplace sample, where we hold the data). Metered: every record returned uses one unit of the account's purchased API quota. Returns 25 records by default and at most 100 per call. Larger pulls are available through the REST API at https://api.engagemii.com/api/v1/data/records with the same key. Any returned record whose score is more than 30 days old is queued for a fresh rescore. Requires an Engagemii data API key.

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": "data_records"
  }
}

Input Schema

Name	Required	Description
`limit`	No	records to draw (each costs 1 quota). Default 25, max 100 in-chat.
`scope`	No
`states`	No
`api_key`	No	Your Engagemii data API key (edk_...). Only needed when the key is not already sent as a request header.
`scoreMax`	No
`scoreMin`	No
`industries`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / api_key

Added value: +{
+  "description": "Your Engagemii data API key (edk_...). Only needed when the key is not already sent as a request header.",
+  "type": "string"
+}

First observedSep 23, 2026

TDQS

A3.6/5.0

Behavior5/5

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

Adds a lot beyond the annotations: metered billing (one quota unit per record), default 25 / max 100 per call, the REST escape hatch with the same key, an API key requirement, and the side effect that records with a score older than 30 days are queued for a fresh rescore. The quota consumption and rescore queue are exactly the non-obvious traits an agent needs and the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, which is good, but the rest is a single dense run-on with stacked parentheticals about column parity, add-on cells, and the Marketplace sample that could be trimmed. Several clauses earn their place (quota cost, limits), others are filler around the dataset provenance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema, the definition covers the costly-to-guess parts: auth requirement, per-record quota cost, call-size ceiling, pagination alternative, and data freshness behavior. The main omission is any description of the filter parameters (scope, states, industries, score range).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29% across 7 parameters. The description adds real meaning for limit (per-record quota cost, default 25, max 100 in-chat vs REST) and api_key (edk_ prefix, header fallback), but scope, states, industries, scoreMin and scoreMax are documented nowhere, so the description does not compensate for the coverage gap.

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: 'Pull full licensed records from the Engagemii dataset', and pins down what a record is (113 columns, same order as a purchased file, fingerprinted). It does not name the sibling it is not (dataset_sample, free_kit, search_companies), so differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to the REST API for pulls larger than 100 per call, which is a genuine alternative. But it gives no guidance on when to use this versus search_companies for filtering or dataset_sample for trial data, and no exclusions are stated.

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

All Engagemii AI Visibility Data 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?