Skip to main content
Glama

Sasha, Neural Partners Chief of Staff

Book a Neural Labs discovery call

book_discovery

Returns a link to the Neural Partners contact page, pre-filled with a summary of the conversation. Nothing is submitted or booked by this tool: the message is sent only if a person opens the link, reviews it and presses send. Email addresses and phone numbers are removed from the summary. An optional message is answered by Sasha before the summary is written. Sasha, Neural Partners' AI agent on Claude, can be wrong. Prices are starting points only. Chats are kept up to 90 days. She never books or submits anything.

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": "book_discovery"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageNoOptional. A last message for Sasha before the handoff, in plain text.
conversation_idNoThe conversation_id an earlier call returned. Omitted, a new conversation starts. Earlier turns are kept server-side, so only the new message is sent.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent only on a result with isError: true.
linksNoThe Neural Partners pages Sasha's reply pointed at, as absolute URLs. Only pages on the Neural Partners site are ever listed. Empty when she pointed at none.
replyNoSasha's reply, on its own. The disclosure is never part of it.
degradedNoTrue when the reply is a stand-in because Sasha ran out of time; the same message can be sent again.
disclosureNoPresent on the first reply of a conversation: what the person should know about Sasha. Also sent as its own first content block.
contact_urlNoThe /contact-us/ link a person opens and sends. Carries only a summary parameter.
offer_handoffNoTrue on the reply where Sasha offers to pass the conversation to the Neural Partners team.
conversation_idYesContinues this conversation on a later call.
summary_includedNoFalse when the link carries no summary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

The description goes well beyond the annotations, disclosing that nothing is submitted until a human opens and sends the link, that email addresses and phone numbers are stripped from the summary, that an optional message is answered by Sasha before the summary is written, that chats persist up to 90 days, and that Sasha and the listed prices may be inaccurate. These are exactly the operational caveats an agent needs and none are available in the structured fields.

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?

The core behavior, the fact that nothing is submitted, and the PII redaction all come in the first three sentences, so it is well front-loaded. The closing lines about Sasha's accuracy, price caveats, and 90-day retention are slightly staccato but each carries a distinct warning, so nothing is clearly wasted.

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 two-parameter tool with an output schema, an annotation set, and full schema coverage, the description covers the safety profile, retention, redaction, and accuracy caveats thoroughly. The remaining gap is routing guidance relative to the two sibling tools, which is a usage-guideline issue rather than a missing behavior.

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 already 100%, so the baseline is 3, and the description earns an extra point by explaining the ordering semantics of 'message': it is answered by Sasha before the summary is written, which tells the agent the message shapes both the reply and the handoff summary. The conversation_id behavior is left entirely to the schema, but that schema text is sufficient.

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 first sentence names a specific verb and resource: it returns a link to the Neural Partners contact page pre-filled with a conversation summary. That is clear and concrete. It doesn't explicitly contrast itself with the sibling 'ask_sasha' or 'pricing_discovery', so the agent must infer from 'before the handoff' that this is the terminal step rather than the Q&A step.

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 tool is a handoff that produces a contact link and does not itself book anything, so an agent can infer it should be called when the user wants to reach a human. There is no explicit 'use this instead of ask_sasha when…' or 'do not call if…' guidance, and no prerequisites are listed despite two similar siblings existing.

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