LobbyStack

Add knowledge

add_knowledge

Teaches the receptionist something it can use to answer callers. For type faq, send question and answer. For type text, send title and content, for example a policy or a price list. Write it as a fact about the business, not as an instruction to the receptionist.

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": {
      "type": "<type>"
    },
    "name": "add_knowledge"
  }
}

Input Schema

Name	Required	Description
`type`	Yes	faq for a question and answer, text for anything else.
`title`	No	For text: a short title.
`answer`	No	For faq: the answer.
`content`	No	For text: the information itself.
`question`	No	For faq: the question callers ask.
`idempotency_key`	No	Optional. A unique value you choose, such as a UUID. Retrying with the same value within 24 hours returns the first result instead of creating a duplicate.

Output Schema

Name	Required	Description
`id`	Yes	Stable identifier (UUID).
`tags`	Yes	Your own labels for the entry.
`type`	Yes
`title`	Yes	The entry's title, or an FAQ's question.
`active`	Yes	Whether the receptionist answers from it.
`content`	Yes	The entry's text, or an FAQ's answer.
`agent_id`	Yes	The one agent that answers from it. Null when every agent does.
`priority`	Yes	Entries with higher numbers come first when the receptionist picks the entries it keeps ready on every call. Defaults to 0.
`created_at`	Yes	ISO 8601 timestamp in UTC.
`updated_at`	Yes	ISO 8601 timestamp in UTC.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's job is to add context: it does say the content becomes something the receptionist can answer callers with, which conveys persistence and effect. However, it says nothing about when the entry goes live, how edits/deletions happen afterward, or duplicate handling beyond the schema's idempotency_key field.

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?

Three short sentences, front-loaded with the purpose before the type-specific field mapping and the style rule. Nothing is padding, though the field-mapping sentence partially duplicates schema descriptions and the purpose sentence could be tighter.

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?

With an output schema present, return values need no explanation, and annotations cover the safety profile; the description supplies the purpose, the per-type field recipe, and the writing-style constraint. What is missing is lifecycle context — whether entries are immediately live and how they are later corrected or removed — which matters for a tool that feeds customer-facing answers.

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 per-field mapping in the description ('For type text, send title and content') largely restates what the schema already documents. The one genuine value-add is the content-style rule — 'Write it as a fact about the business, not as an instruction to the receptionist' — plus the illustrative 'policy or a price list', which shape input quality but do not change field meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 description states a concrete effect — teaching the 'receptionist' facts it will use when answering callers — and enumerates the two supported content shapes (faq, text). An agent can tell this creates knowledge-base entries rather than contacts or appointments. It never names a sibling, but none of the listed siblings overlap with this resource, so differentiation is effectively implicit.

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 through the two type branches ('For type faq, send question and answer. For type text, send title and content'), which tells the agent how to populate the shape but not when to choose this tool over another route or how to decide between faq and text beyond one line. There is no when-not-to-use guidance or mention of prerequisites.

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

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