Skip to main content
Glama
Sign In

DirectIQ

by com.directiq.mcp
OverviewDiscussionsAdmin

directiq_read_request

Read-onlyIdempotent

Issue an authenticated GET request to any DirectIQ endpoint and return the JSON response. Prefer a dedicated directiq_* tool when one exists; use this for read operations without one, found with directiq_list_endpoints (e.g. segments for a contact, email client reports). Full request/response schemas for each group are in the DirectIQ API docs at https://rest.directiq.com/{group}/swagger/index.html (core, contacts, subscription).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group": "<group>",
      "path": "<path>"
    },
    "name": "directiq_read_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesEndpoint path within the group, e.g. '/contact/list' or '/email/send'
groupYesDirectIQ API group: core, contacts, or subscription
queryNoOptional query parameters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / query / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: authentication is handled, the payload is JSON, and per-group request/response schemas live in the linked swagger docs. It stops short of covering error behavior for invalid paths or pagination of large collections.

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?

Three sentences, front-loaded with the core action and followed by the routing rule and the docs pointer; each sentence carries distinct information. The swagger URL sentence is slightly heavy but earns its place for a generic passthrough tool.

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 free-form passthrough with a fully documented three-parameter schema and no output schema, the description supplies the missing pieces an agent needs: which group values exist, how to find valid paths, and where the per-endpoint schemas live. Only failure modes and response-size behavior are unaddressed.

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%, with path, group enum, and query all documented inline, so the baseline is 3. The description adds only the enumeration of group values and example path shapes, which largely duplicate the schema rather than clarifying query encoding or path templating rules.

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?

States a specific verb and resource: 'Issue an authenticated GET request to any DirectIQ endpoint and return the JSON response.' It also positions itself against the dedicated directiq_* tools, so an agent can tell whether this is the generic escape hatch or a purpose-built operation.

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?

Explicitly gives the selection rule: prefer a dedicated directiq_* tool when one exists, and use this for read operations without one. It further explains how to discover eligible endpoints (directiq_list_endpoints) and gives concrete examples (segments for a contact, email client reports), leaving little to inference.

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

All DirectIQ 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