Tulina

apollo_conversation

Recorded conversations (calls/video meetings) — transcripts, recordings, participants. BYO key only (all ops): real recorded conversations, and the credit cost is conditional (1 if the conversation has AI insights, 0 otherwise) so it can't be metered against a platform quota up front.

Args by op:

search: conversation_type (video_conference/phone_call), account_id, contact_ids, tag_ids, tracker_ids, organization_ids, date_range ({"start":, "end":} ISO 8601), per_page, page.
get: conversation_id. ⚠️ 1 Apollo credit IF the conversation has AI insights, 0 otherwise — not knowable before the call.
export: start_time + end_time (ISO 8601, GMT) + email (team member to notify). ASYNC — returns export_id; does not wait for completion. Poll with export_status.
export_status: export_id (from export) — returns redirect_url once ready.

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": {
      "op": "<op>"
    },
    "name": "apollo_conversation"
  }
}

Input Schema

Name	Required	Description
`op`	Yes
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`page`	No
`email`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`_run_id`	No	OBLIGATOIRE à 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.
`tag_ids`	No
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`end_time`	No
`per_page`	No
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`export_id`	No
`account_id`	No
`date_range`	No
`start_time`	No
`contact_ids`	No
`tracker_ids`	No
`conversation_id`	No
`organization_ids`	No
`conversation_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided the description carries the full burden, and it delivers meaningful behavior: conditional credit cost that cannot be known before the call, an async export that returns export_id without waiting, and a polling path via export_status. What's missing is safety/mutation posture (whether any op writes anything), auth requirement detail beyond BYO key, and rate limits.

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?

Well front-loaded: purpose, key model and cost caveat come first, then a scannable per-op arg list. Slight redundancy between the upfront credit statement and the repeated ⚠️ note under `get`, but the repetition is defensible since it sits where the decision is made.

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 20-parameter, no-output-schema, no-annotation tool, this covers the essentials an agent needs: op semantics, required identifiers, date formats, and the async polling loop. Gaps are return-shape hints for search (pagination/total) and pruning of irrelevant params per op, which the schema leaves always-optional.

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 only 25% (just the internal _org/_group/_run_id/_project/_instance fields are documented), so the description must compensate, and it largely does: it maps args to each op and adds formats the schema lacks — conversation_type enum values, date_range as ISO 8601 {start,end}, start_time/end_time in GMT, and that email is the team member to notify. A few filter params (tag_ids, contact_ids, tracker_ids, organization_ids) are only listed by name without semantics.

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 opening line names a specific resource (recorded conversations: calls/video meetings) with its contents (transcripts, recordings, participants), and the per-op breakdown gives concrete verbs for search, get, export and export_status. It does not explicitly contrast itself with sibling resources like apollo_search_people or minari_call, so an agent must infer the boundary.

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?

It states a real usage constraint ('BYO key only (all ops)') and explains that get costs 1 credit conditionally, which steers invocation decisions. However, there is no explicit when-to-use-this-vs-alternative guidance against the many apollo_* and other conversation-shaped siblings, and no error/precondition cases beyond the credit note.

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

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?