Skip to main content
Glama
Sign In
dakera-mcp

dakera-mcp

Official
by Dakera-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Remote

dakera_extract

Extract entities, topics, key phrases, and summaries from text using configurable providers, with GLiNER as the local default.

Instructions

Extract entities, topics, key phrases and a summary from text with the provider chain: extractor_override, then the namespace default, then the server default (GLiNER local). For ad-hoc GLiNER types use dakera_auto_tag. Needs a write key for the namespace (for all namespaces when neither namespace nor agent_id is given).

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": {
      "text": "<text>"
    },
    "name": "dakera_extract"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoen, de, fr, es, it, pt or nl (v0.12+)
textYesText to extract information from
agent_idNo
namespaceNoNamespace whose extractor config applies (default: agent_id's)
extractor_overrideNoProvider for this request only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.11.0
    • addedInput schema / properties / agent_id
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / entity_types
      Removed value: -{
-  "description": "GLiNER entity type labels (e.g. [\"person\", \"org\", \"location\"]). Only used when provider is `gliner`.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
    • changedInput schema / properties / extractor_override / description
      Previous value: -"Per-request provider override — highest priority in the resolution hierarchy. Fields: provider, model, base_url, api_key."New value: +"Provider for this request only"
    • addedInput schema / properties / lang
      Added value: +{
+  "description": "en, de, fr, es, it, pt or nl (v0.12+)",
+  "type": "string"
+}
    • changedInput schema / properties / namespace / description
      Previous value: -"Namespace whose default extractor config is used. If omitted, the server-level default is used."New value: +"Namespace whose extractor config applies (default: agent_id's)"
  2. Addedv0.10.12
  3. Removedv0.10.11
  4. Addedv0.10.8

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the credential requirement (write key for the namespace, expanded scope when neither namespace nor agent_id is given) and the provider fallback chain. It does not describe the shape of the extraction result or any failure modes, 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?

Two dense sentences with no filler; the core action is front-loaded, followed by the provider chain and the auth caveat. The first sentence is long but each clause carries information, so no trimming is warranted beyond minor restructuring.

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 tool with a nested extractor_override object, no output schema and no annotations, the description covers configuration resolution and auth scope well. It leaves the returned extraction structure unexplained, but with no output schema declared that is a secondary gap.

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

Parameters4/5

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

Schema coverage is 80%, so the baseline is 3, but the description adds meaning the schema lacks: the precedence order for extractor_override versus the namespace/server default, and the authorization implication of namespace/agent_id omission. That is genuine value beyond the structured fields.

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 gives a precise verb (Extract) and an explicit resource list (entities, topics, key phrases, summary) from text, and names the sibling/alternative dakera_auto_tag for ad-hoc GLiNER types. An agent can tell this apart from the retrieval-oriented siblings without opening the schema.

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?

It names a concrete alternative ('For ad-hoc GLiNER types use dakera_auto_tag') and explains the provider resolution order (extractor_override → namespace default → server default GLiNER local), which tells the agent when this tool's configuration applies. It stops short of stating when-not to use it versus the search/knowledge_graph siblings.

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

Deploy Server

Other Tools