Skip to main content
Glama

openie_triples

Extract subject-predicate-object triples from text with source character spans for knowledge graph construction. Supports English (CoreNLP or spaCy) and Chinese.

Instructions

Open Information Extraction: (subject, predicate, object) triples.

Engine priority for English (engine may force one):

  1. corenlp - the canonical Stanford CoreNLP OpenIE via a local CoreNLP server (env CORENLP_URL, default localhost:9000) when it is up;

  2. spacy - dependency-parse rules (confidence 0.6).

Chinese: naive (noun, verb, noun) pattern mining over jieba POS (confidence 0.35 - draft quality by design). CoreNLP's OpenIE is English-focused. Every triple carries the source character span and is a candidate for downstream KG normalization - not a fact.

Input Schema

NameRequiredDescriptionDefault
langNoauto
textYes
engineNoauto

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: it discloses the env dependency (CORENLP_URL, default localhost:9000), engine fallback order, per-engine confidence levels, the deliberate draft quality of Chinese output, and a caveat that triples are candidates rather than facts. It omits anything about input size limits or latency, which keeps it from a 5.

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?

The one-line purpose is front-loaded and the numbered engine priority is scannable. It is longer than most definitions, but nearly every clause adds selection-relevant information about engines and output quality.

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?

An output schema exists, so return values need not be explained, and the description focuses on the right things: engine selection, language behavior, confidence calibration and the candidate-not-fact caveat. Only the accepted values for lang and the meaning of 'auto' remain undocumented.

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 coverage is 0%, so the description must compensate. It elaborates the engine parameter well (corenlp vs spacy behavior) and explains language handling for English and Chinese, but never states what values 'lang' accepts or what 'auto' resolves to for either parameter.

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: open information extraction producing (subject, predicate, object) triples. That is clearly distinguishable from the structural siblings like dependency_parse, ner and noun_phrases, and the parenthetical names the exact output shape.

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 concrete selection logic: try corenlp first when the local server is up, otherwise fall back to spacy dependency rules, and use naive jieba mining for Chinese. It does not explicitly say when to prefer this tool over dependency_parse or ner, so the when-not side is implicit, but the engine-choice guidance is unusually specific.

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