Skip to main content
Glama
aminehamlouchi

InterLogue

by aminehamlouchi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Brief the reporter

brief

Define the subject, client, product, topic, and angle for a customer case study, then save it and return a question plan. No contact is made.

Instructions

Start here. Brief InterLogue the way an editor briefs a reporter: who the subject is, which client and product the case study is for, the topic, and the angle. The angle decides which questions get asked and what the piece emphasizes; it never changes what the subject is portrayed as having said. Saves the brief and returns a brief_id plus the question plan. Nobody is contacted at this step. Next step: approve_contact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
angleYesThe editor's angle, e.g. "a two-person team getting its Mondays back from manual order entry". Shapes which questions are asked and what is emphasized. Never shapes what the subject is portrayed as having said.
genreNoOnly customer_case_study exists in this build.customer_case_study
topicYesThe subject matter as a noun phrase, e.g. "order entry and fulfillment".
subject_nameYesFull name of the person to interview, e.g. the founder or customer.
subject_roleYesThe subject's role, e.g. "founder" or "head of operations".
subject_phoneYesThe subject's phone number. It is stored only in the brief and approval records and never echoed in full.
client_companyYesWho commissioned the piece (the marketing team's company).
client_productYesThe product the case study is about.
content_neededNoWhat the client needs back.
subject_companyYesThe subject's company.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden and does well: it discloses the side effect (saves the brief), the return shape (brief_id plus question plan), and the safety-relevant fact that no contact occurs. It omits auth/permission requirements and rate limits, so not 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with 'Start here.' Every sentence earns its place: input categories, the angle's semantic constraint, the save/return behavior, the no-contact guarantee, and the next step. No filler.

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 10-parameter, no-output-schema, no-annotation tool, the description compensates well by describing the return value (brief_id, question plan) and the workflow position. It leaves the remaining lifecycle (what approve_contact then triggers) implicit, but that is the sibling's job.

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 100%, so the baseline is 3. The description groups the inputs conceptually (subject, client, product, topic, angle) but adds little beyond what the schema already documents, including the angle semantics which the schema repeats verbatim.

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?

States a specific verb (brief) and resource (InterLogue), enumerates the inputs it captures (subject, client, product, topic, angle), and marks itself as the entry point with 'Start here.' An agent can distinguish it from siblings like approve_contact or draft_piece without opening any schema.

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?

Explicitly tells the agent when to use it ('Start here'), what does not happen ('Nobody is contacted at this step'), and routes to the next tool ('Next step: approve_contact'). This is when/when-not/alternatives in miniature.

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