Skip to main content
Glama
Sign In
Djinni MCP

Djinni MCP

by Kiri7z
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_history

Read-only

Reads prior dates, summaries, drafts, and exclusions for shortlisted job IDs so you can reuse historical context without treating it as a current activity check.

Instructions

Read previous dates/summaries/drafts and explicit exclusions for shortlisted numeric IDs. Historical text is context, not a current activity check.

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": {
      "job_ids": "<job_ids>"
    },
    "name": "get_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idsYes

Output Schema

NameRequiredDescriptionDefault
itemsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description only needs to add context. It does contribute the useful framing that returned text is historical context rather than current activity, but it says nothing about ordering, behavior for IDs with no history, or how excluded entries are surfaced. With an output schema present, return-shape details are legitimately omitted.

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 short sentences with the operation front-loaded and no filler; the caveat sentence is worth its space. The slash-delimited enumeration ('dates/summaries/drafts') is compact but slightly cryptic.

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 single-parameter read tool with annotations and an output schema, the definition covers what is fetched and how to interpret it. The remaining gaps are edge-case behavior for missing history and the source of valid IDs, which are minor at this complexity level.

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 0%, so the description must carry parameter meaning, and it partially does by specifying 'shortlisted numeric IDs', which is more informative than the schema's bare digit pattern and array bounds. It still leaves unclear whether the IDs come from search_jobs results and what happens when an ID is not shortlisted or has no history.

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?

The description gives a concrete verb ('Read') and enumerates the resource contents: previous dates, summaries, drafts, and explicit exclusions, scoped to job IDs. It implicitly distinguishes itself from the current-state sibling get_job via the 'historical text is context, not a current activity check' clause, though it never names that sibling outright.

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?

Usage is implied rather than stated: the 'context, not a current activity check' line hints that this is the lookup for past context as opposed to a live status call, which points away from get_job. There is no explicit when-to-use/when-not-to-use statement and no mention of prerequisites such as the ID needing to be shortlisted first.

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