Skip to main content
Glama

minari_call

Calls made and received in Minari, with AI summaries and objections.

Covers ALL sources (CSV imports and CRM-synced contacts alike), unlike minari_list.

"get" deliberately OMITS the transcript and reports transcript_utterances instead — a 45-minute call would otherwise bury the summary and objections you asked for. Use "transcript" for the text.

Search two different ways: search matches the contact (name, company, phone number); transcript_search matches what was SAID. Transcript search is a literal substring match, words AND-ed, never semantic and never translated — so a French call will not match English terms. Each row carries language; re-issue in that language (or scope with language="fr") to search across locales. Both need 3+ characters.

"recording" returns availability and size, NOT the audio — an MP3 has no useful form in a tool result. For something a human can open, a call carries public_call_link, a shareable page needing no key — but it is null when the company has external call sharing switched off, so check it rather than promising someone a link.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "minari_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNo"list" browses; "get" is one call without its transcript; "transcript" is the text; "recording" reports whether audio exists (it never returns audio bytes — see above).list
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
cursorNo"list" only — `next_cursor` from a previous response. RE-SEND YOUR FILTERS WITH IT: the cursor is a position (`started_at` + call id), not a saved query, so a cursor on its own pages the whole journal and silently drops your filters. Pages are fixed at 50 and cannot be enlarged.
searchNo"list" only — contact name, company or phone (3+ chars).
statusNo"list" only — one or more call statuses. "meeting-booked" is a FILTER-only value: it is how you ask for calls that led to a meeting, but a returned row never carries it as its `status` (rows use the other eight, plus a `meeting_booked` boolean).
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
call_idNoREQUIRED by "get", "transcript" and "recording".
list_idNo"list" only — filter by list id(s).
user_idNo"list" only — filter by team member id(s), from `minari_user`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
end_dateNo"list" only — ISO 8601, calls started at or before.
languageNo"list" only — ISO 639-1 of the AI content, e.g. "fr".
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
directionNo"list" only — omit to get both directions.
contact_idNo"list" only — filter to one contact.
start_dateNo"list" only — ISO 8601, calls started at or after.
min_durationNo"list" only — minimum duration in seconds.
max_utterancesNo"transcript" only — cap on returned lines (default 200). The response states the true total and whether it was truncated.
transcript_searchNo"list" only — what was said (3+ chars).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/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 mostly discharges it: it discloses transcript truncation via `transcript_utterances`/`max_utterances`, that transcript search is literal substring AND-ed matching that is never semantic and never translated, the 3-character floor, and that `public_call_link` is null when external sharing is off. Gaps remain: pagination (fixed 50-row pages, cursor re-send requirement) and the org/project scoping tokens live only in the schema, so the narrative does not cover list-result shaping.

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?

Four short paragraphs, each front-loaded with its topic (scope, transcript omission, search modes, recording/link). Every sentence carries a non-obvious fact — the rationale for omitting transcripts or not returning audio bytes is real information, not padding.

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 4-op, 20-parameter tool with an output schema, the description covers the decisions an agent would otherwise get wrong (which op, which search mode, what recording does not return, the null-link condition). It omits list pagination behavior and org/project scoping context, which are variables an agent must still read from the schema.

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 100%, so 3 is the floor, and the description earns an increment by explaining the semantic difference between `search` and `transcript_search`, why `language` matters for cross-locale searching, and why `call_id` is needed for three of the four ops. It does not restate schema text verbatim; it explains intent.

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 opening sentence names the resource (calls in Minari) and the payload it returns (AI summaries and objections), and immediately contrasts scope with the sibling `minari_list` ("Covers ALL sources ... unlike `minari_list`"). The four ops are then made concrete in prose rather than left to the enum.

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?

Explicit routing for every op: "get" omits the transcript by design, use "transcript" for the text; `search` matches the contact while `transcript_search` matches what was said; "recording" gives availability, and `public_call_link` is the human-openable alternative. Alternatives and the conditions that select them are stated, not inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources