Selenios

Search interview transcripts

search_meeting_transcripts

Read-onlyIdempotent

Search what was said in interviews: returns the interviews whose transcript or title contains any of the given words or phrases, with the matching excerpts (speaker and second); titleMatch is true when the title matched. Examples: "who mentioned Kubernetes?", "in which interview did they talk about salary?". The match is literal, case- and accent-insensitive, not semantic. Interviews are transcribed in the language they were held in, so one call accepts up to 12 terms: synonyms and translations together (e.g. "salary", "compensation", "salario", "sueldo", "salário"). A term with several words matches an entry that says all of them, in any order. Can be narrowed by job position, candidate or date range. It reads the 300 most recently added interviews that match the filters, and scanLimitReached: true means older interviews were not searched. Only processed transcripts are searched, not interviews in progress. The results contain only the interviews that matched, not every interview of a period.

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": {
      "terms": "<terms>"
    },
    "name": "search_meeting_transcripts"
  }
}

Input Schema

Name	Required	Description
`to`	No	Only interviews on or before this date (ISO 8601)
`from`	No	Only interviews on or after this date (ISO 8601)
`limit`	No	Interviews to return (default 10)
`terms`	Yes	Words or short phrases; an entry matches when it says ANY of them. Include synonyms and translations.
`candidateId`	No	Only interviews of this candidate
`jobDescriptionId`	No	Only interviews of this job position

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare read-only/idempotent safety; the description adds substantial behavior an agent could not otherwise know: literal case- and accent-insensitive matching (not semantic), language-specific transcription, a 300-interview recency cap with the scanLimitReached signal, and that only processed transcripts are covered. These are exactly the operational caveats that change how a caller should phrase a query or interpret a result.

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?

Front-loaded with purpose and return shape, then matching rules, then filters, then the recency caveat — a sensible order. It runs long for a search tool, and the closing sentence ('The results contain only the interviews that matched, not every interview of a period') largely restates the opening.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does it: matching excerpts with speaker and second, titleMatch, and scanLimitReached. Combined with match semantics and the truncated-scan caveat, an agent has everything needed to call it and interpret the response without follow-up questions.

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 baseline is 3, but the description adds genuine meaning beyond the schema: why up to 12 terms exist (synonyms and translations mixed), and the non-obvious rule that a multi-word term requires all words in any order, whereas multiple terms are OR'd. It does not add anything about limit, from/to formats, or the ID filters beyond what the schema states.

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?

Names a specific verb and resource ('Search what was said in interviews') and immediately defines the return shape ('the interviews whose transcript or title contains any of the given words or phrases, with the matching excerpts'). This clearly separates it from get_meeting_transcript, which would fetch one transcript rather than search across many.

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?

Provides concrete example questions ('who mentioned Kubernetes?', 'in which interview did they talk about salary?') and states what the tool can be narrowed by (job position, candidate, date range), which implies when to reach for it. It never names a sibling alternative or an explicit 'do not use this for X' exclusion, so it stops short of full routing guidance.

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

All Selenios 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?