Skip to main content
Glama
diffbot-mcp

diffbot-mcp

Official

Look Up DQL Ontology

dql_ontology
Read-onlyIdempotent

Look up Knowledge Graph entity types, fields, taxonomies, and enum values to confirm exact field paths and spellings before writing DQL queries, preventing ignored paths and zero-result guesses.

Instructions

Looks up the Knowledge Graph ontology: entity types, their fields, and taxonomy or enum values. Use before raw dql to confirm a field path exists and to get the exact spelling of a value (a guessed path is silently ignored, a guessed value returns zero). Results are ranked best match first. API docs: https://docs.diffbot.com/docs/ontology

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": {
      "action": "<action>"
    },
    "name": "dql_ontology"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoType or composite (fields), or taxonomy/enum name
limitNoMax results; total is always reported
actionYestypes and composites list entity types and nested object types; enums and taxonomies list value-set names; fields lists a type's or composite's fields (needs name); taxonomy or enum lists one value set (needs name); search matches names across everything (needs search)
searchNoCase-insensitive regex filter

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: results are ranked best match first, and invalid field paths fail silently rather than raising an error. It stops short of describing result volume or how the 'total is always reported' interacts with limit, but the core behavioral surprises are disclosed.

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?

Three sentences plus a docs link, front-loaded with purpose, then the decision rule, then result ordering. Each sentence carries distinct information; the documentation URL is the only expendable element and it is clearly demarcated at the end.

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?

The tool has an output schema, so return shape need not be explained, and 100% schema coverage handles parameter detail. What remains — when to call it, what failure looks like if you don't, and how results are ordered — is all present, so nothing an agent needs to invoke it correctly is missing.

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 the action enum documents every mode including its name dependency, so the schema already does the heavy lifting and a baseline 3 applies. The description adds only indirect hints — 'exact spelling of a value' implies the name parameter's role, and 'ranked best match first' implies search ordering — without explaining any parameter beyond what the schema states.

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 a specific verb and resource: 'Looks up the Knowledge Graph ontology,' then enumerates the content scope (entity types, their fields, taxonomy or enum values). That is enough for an agent to separate it from the sibling 'dql' tool, which it names directly as the downstream consumer.

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?

It states an explicit trigger ('Use before raw dql'), the two goals that trigger it (confirm a field path, get exact value spelling), and the cost of skipping it ('a guessed path is silently ignored, a guessed value returns zero'). The alternative tool is named and the condition that selects it is concrete, leaving nothing to inference.

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