Sally skill ($0.003/call)
| Name | Required | Description | Default |
|---|---|---|---|
| health | No | If true, the agent personalises using the calling user's saved health context (lab results, CGM, sleep, vitals). Defaults to false (knowledge-only). | |
| message | Yes | ||
| language | No | BCP-47 short code (e.g. 'en', 'id'). Omit for auto-detect from the message. | |
| knowledge | No | Sally's knowledge brain — 'medical' for evidence-based clinical sources, 'tcm' for Traditional Chinese Medicine. | tcm |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / health / descriptionPrevious value: -"If true, the agent personalises with the calling user's mem0, lab results, CGM, sleep, vitals. Defaults to false (knowledge-only)."New value: +"If true, the agent personalises using the calling user's saved health context (lab results, CGM, sleep, vitals). Defaults to false (knowledge-only)."Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a per-call price, and says nothing about how the chat behaves, whether it uses personal health context, what data it accesses, or what side effects might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than genuinely concise. 'Sally skill' adds no information beyond the name, and the only useful content is the pricing note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a one-phrase description, an agent lacks essential context about expected behavior, return format, and use cases. The schema alone is not enough to safely and correctly select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter meaning beyond the input schema. The schema already documents health, language, and knowledge with descriptions; the one required parameter, message, has no description, and the tool description does not compensate for that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only 'Sally skill ($0.003/call)', which essentially restates the tool name without a verb, action, or resource. It does not explain that this is a chat/conversation tool or how it differs from siblings like search_health_knowledge or health_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its alternatives. An agent is given no context for choosing chat_with_sally over analyze_lab_result, lookup_food, or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.