Behavioral intelligence for client-facing professionals. Know who you're walking into.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 11 tools
Most tools target distinct resources and actions, and descriptions aggressively cross-reference to steer the agent (e.g., 'for any read call generate_compass, not get_person/list_people'). However, real overlap remains: complete_profile vs update_profile both set name/profession, and create_person vs batch_create_persons differ mainly by batch size and side effects. These are resolvable but not self-evident from names alone.
Almost everything follows a clean snake_case verb_noun pattern: create_person, list_people, get_person, generate_compass, send_chat_message, update_profile. The only deviation is health_check (noun_verb), which is a minor, conventional exception rather than a mixed convention.
Eleven tools is well within a healthy range and each maps to a real capability: person creation (single/batch), reads, compass generation, chat read/write, and user profile management. No tool feels padded or redundant at the count level.
The person resource has create, batch create, get, and list, but no update_person or delete_person, leaving agents unable to correct or remove a client — a notable lifecycle gap. Chat and user-profile surfaces are complete (get/send, complete/get/update), so the gap is localized but will cause failures on edit/remove requests.
Create up to 10 people (clients) in parallel and generate a Client Compass for each. Use this for re-engaging dormant leads — a name is enough. IMPORTANT: Return the full Start Here coaching for each person (ask_them, know_this, avoid_this) — do not summarize or create tables. Present each person's compass_summary_text and all three Start Here items in full.
| Name | Required | Description | Default |
|---|---|---|---|
| contacts | Yes | Array of 1–10 contacts to profile. First and last name required for each. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals key behaviors: parallel execution, 10-person limit, generation of Client Compass, and a critical instruction not to summarize the coaching output. This is substantial transparency, though it could note side effects or permission requirements.
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 two sentences plus an important note, efficiently conveying purpose, use case, and output instructions. It is front-loaded and every part is useful, though it could be slightly more concise.
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?
Given no output schema, the description thoroughly explains return expectations: 'Return the full Start Here coaching for each person (ask_them, know_this, avoid_this) — do not summarize or create tables.' It also covers input limits and the parallel nature. This is highly complete for a batch creation 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?
Schema coverage is 100%, so baseline is 3. The description adds 'a name is enough' but no additional detail beyond what the schema provides (object structure, required fields, max items). It does not enhance parameter semantics significantly.
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 clearly states what the tool does: 'Create up to 10 people (clients) in parallel and generate a Client Compass for each.' This provides a specific verb, resource, and scope, distinguishing it from sibling tools like create_person (single) and generate_compass (single client).
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?
The description explicitly recommends use 'for re-engaging dormant leads — a name is enough,' giving a clear context. It does not explicitly mention when not to use or name alternatives, but the context from sibling tools and the parallel nature implies its niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete the user's profile (one-time signup). Sets name, profession, and generates a User Compass. Required before creating clients.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth YYYY-MM-DD (optional, improves compass). Do not ask the user for this before calling — proceed with name only. | |
| phone | No | Phone number (optional) | |
| last_name | Yes | Last name (required) | |
| first_name | Yes | First name (required) | |
| profession | Yes | Profession (required) | |
| maiden_name | No | Maiden/birth name (optional) | |
| middle_name | No | Middle name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions generating a User Compass as side effect, but does not disclose idempotency, error states (e.g., calling twice), or security implications. Adequate but not comprehensive.
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?
Two sentences with zero wasted words. Purpose, outcome, and prerequisite are front-loaded. Efficient and clear.
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?
Tool has no output schema, so description should indicate return values or success/failure. Currently omits any mention of what the response contains (e.g., user data, token). Also lacks handling of re-execution. Adequate for basic usage but incomplete for robust agent reasoning.
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?
Schema coverage is 100%, so parameters are documented. Description adds value by summarizing key outputs ('sets name, profession') and noting that 'dob improves compass'. This enriches schema information for agent decision-making.
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?
Description clearly states the tool completes the user's profile as a one-time signup, specifying actions (sets name, profession, generates User Compass) and prerequisite. Distinguishes from sibling 'update_profile' by emphasizing one-time signup nature.
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?
States 'Required before creating clients', providing clear context. Does not explicitly exclude use cases or mention alternatives, but context implies this is a single-use setup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new person (client) to the user's people list. Only call this when the user asks to save or add someone. Never call it to get a Lowdown, a card, or to go deeper: use generate_compass for every read. Requires the user to have a profession set.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth in YYYY-MM-DD format (optional, improves compass accuracy). Do not ask the user for this before calling — proceed with name only and let the engine handle it. | |
| vertical | No | Industry vertical override. Defaults to the user's profession if omitted. | |
| last_name | Yes | Last name (required) | |
| first_name | Yes | First name (required) | |
| key_parties | No | Key parties involved (e.g. spouse, parent, colleague) | |
| middle_name | No | Middle name (optional) | |
| must_haves_avoids | No | Notes on must-haves or things to avoid | |
| is_first_interaction | No | Is this the first interaction with this client? Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a write operation and requires a profession, but it does not cover duplicate handling, permission failures, side effects, or what creation returns.
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?
Front-loaded and compact: four short sentences that each provide routing, exclusion, or prerequisite information. There is no wasted explanation.
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?
For an 8-parameter creation tool with no annotations and no output schema, the description handles routing and prerequisites but omits duplicate-record behavior, creation outcome, and the batch_create_persons alternative. It is adequate but has clear gaps.
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?
Schema description coverage is 100%, so the schema already documents all parameters, including dob and vertical behavior. The description adds only the profession prerequisite and does not add parameter syntax or defaults beyond the schema.
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?
States a specific verb and resource: "Save a new person (client) to the user's people list." It also distinguishes the read path by directing agents to generate_compass, though it does not address the batch_create_persons sibling for multiple-person creation.
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?
Gives explicit when-to-use guidance ("Only call this when the user asks to save or add someone"), explicit when-not guidance, names the alternative for reads (generate_compass), and states the profession-set prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Lowdown on a person from the numbrU engine. Call with depth "card" first (the default): it returns a short card with KNOW, AVOID, and INSTEAD. If the user has described the moment (a listing meeting, a negotiation, a first call), pass it in context so the card fits that moment. When the user asks to go deeper, call again with the same name, dob, vertical, and context and depth "full" for the Deeper Details: how they decide, what earns their trust, the signs to watch for, and how to communicate. IMPORTANT: present the returned output verbatim, exactly as formatted, preserving every heading. Do not summarize, reword, reorder, condense into tables, or describe the sections instead of showing them. The formatting is the product. Get every read from generate_compass only: do not call create_person, list_people, or get_person to get or deepen a read, and do not save the person unless the user asks. In any note you add after the output, refer to the person by first name or "they", never he/she.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth in YYYY-MM-DD format (optional). If not provided, proceed with name only. | |
| name | Yes | Full name of the person | |
| depth | No | card = short card first (default). full = Deeper Details, only when the user asks to go deeper. | card |
| context | No | Optional: the moment the user described, in their words (e.g. 'listing appointment Thursday, first meeting'). | |
| vertical | No | Industry vertical (default: real_estate) | real_estate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses the two-tier depth behavior, that output must be presented verbatim with headings preserved, that the person should not be saved unless asked, and the first-name/they pronoun rule for added notes. It does not state whether the call itself persists a record or has rate/latency characteristics, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and default depth before the escalation rule and formatting constraints. Dense but nearly every sentence is an operative instruction; the verbatim-presentation warning is repeated in several forms, which costs a little trimming.
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?
No output schema exists, and the description compensates by naming the sections each depth returns (KNOW/AVOID/INSTEAD for the card; decision style, trust, warning signs, communication for full). For a five-parameter generative read tool, an agent has everything needed to call it and handle the result.
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?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it explains the card→full progression for depth and that context should capture the user's described moment so the card fits, and it shows that name/dob/vertical/context must be repeated on the second call.
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?
States a specific verb and resource — get a person 'read' from the numbrU engine — and names the exact artifact returned (a card with KNOW, AVOID, INSTEAD). It explicitly distinguishes itself from get_person, create_person, and list_people, so an agent can route correctly without opening another schema.
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?
Gives an explicit sequencing rule: call with depth "card" first, escalate to "full" only when the user asks to go deeper, reusing the same name, dob, vertical, and context. It also states when to supply context (a described moment like a listing meeting) and names the siblings that must not be used to obtain or deepen a read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve chat message history for a specific person (client). Returns messages in reverse chronological order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max messages to return (default: 50) | |
| cursor | No | Pagination cursor from a previous response | |
| person_id | Yes | The UUID of the person |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions reverse chronological order but omits other traits like read-only nature, auth requirements, or pagination details. Adequate but not thorough.
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?
Single sentence, front-loaded with action, no redundant words. Highly concise.
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?
Given no output schema or annotations, description covers basic purpose but lacks details on pagination, error handling, or behavior for missing person_id. Adequate but not comprehensive.
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?
Schema covers all 3 parameters with descriptions (100% coverage). Description does not add new semantic meaning beyond what schema provides.
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?
Description clearly states the action (retrieve), resource (chat message history), and scope (for a specific person), and notes reverse chronological order. Distinguishes from sibling send_chat_message.
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?
No guidance on when to use this tool versus alternatives like send_chat_message, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the authenticated user's profile information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only retrieval operation (no side effects). However, no annotations are provided, and the description does not specify any behavioral details such as required permissions or data freshness.
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?
Single sentence, no wasted words, front-loaded with the core purpose.
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?
For a simple no-parameter tool without an output schema, the description adequately covers what it does. It does not detail the return format, but that is acceptable given the simplicity.
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 input schema has zero parameters, so no parameter semantics are needed. The description adds no extra parameter information, but the baseline for no parameters is 4.
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 clearly states the tool retrieves the authenticated user's profile information, with a specific verb and resource. It distinguishes itself from sibling tools like 'get_person' (which likely retrieves other users) and 'update_profile'.
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?
No explicit guidance on when to use or when not to use, but the description implies it is for the current user's profile. No mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single person (client) by their ID. Returns contact details only, not the Lowdown: for any read, card or "go deeper", call generate_compass.
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes | The UUID of the person to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return scope (contact details only, not Lowdown), but it omits authentication requirements, not-found behavior, and exact return shape.
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?
Two sentences, front-loaded with the core operation and followed by the key return-scope constraint and alternative. Every sentence adds routing or scope information without waste.
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?
For a simple one-parameter read tool with full schema coverage and no output schema, the description gives enough context about return scope and sibling routing. It could still mention not-found or permission behavior, so it is not fully complete.
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?
Schema description coverage is 100%, and the schema already documents person_id as the UUID to retrieve. The description adds no syntax or format detail beyond saying retrieval is by ID, so this is the baseline case where the schema does the heavy lifting.
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 states a specific verb and resource: retrieve a single person (client) by ID. It also distinguishes the tool from generate_compass by clarifying that it returns contact details only, not the Lowdown.
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?
It explicitly says when to use this tool (single person by ID) and when to use the alternative for deeper information: call generate_compass for any read, card, or "go deeper" need. This leaves little ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the numbrU API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only operation ('Check health status'), but does not disclose additional details such as response format or what constitutes healthy status. Adequate for a trivial tool.
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?
Single sentence, front-loaded with the key verb and resource. No wasted words; appropriate length for the tool's simplicity.
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?
Given zero parameters and no output schema, the description is sufficiently complete. There is no missing information that would prevent an agent from using the tool correctly.
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?
There are zero parameters. The description adds minimal meaning beyond the tool name—it specifies the resource ('numbrU API'). Baseline is 4, but the description is only slightly more informative than the title.
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 uses the specific verb 'Check' and the resource 'health status of the numbrU API'. It clearly distinguishes the tool from siblings, none of which are health checks.
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?
No explicit guidance on when to use this tool versus alternatives, but it is a simple health check and the context implies usage for API availability verification. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all people (clients) for the authenticated user. Optionally search by name. Returns contact details only, not the Lowdown: for any read, card or "go deeper", call generate_compass.
| Name | Required | Description | Default |
|---|---|---|---|
| pace | No | Filter by preferred pace (e.g. quick, measured, deliberate) | |
| tone | No | Filter by tone (e.g. confident, collaborative, analytical) | |
| voice | No | Filter by communication voice (e.g. direct, warm, conversational) | |
| search | No | Search by name (partial match, case-insensitive) | |
| archetype | No | Filter by archetype name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden, and it does well: it clarifies the result set is limited to the authenticated user's people and that only contact details are returned. It omits pagination, ordering, and limits, which matters for a list operation.
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?
Three short sentences, front-loaded with the core purpose and scope. The closing routing sentence is slightly jargon-heavy ('the Lowdown', 'card', 'go deeper') but still carries actionable guidance.
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 and no annotations, the description supplies the essential context: scope, return content, and the retrieval alternative. It falls short on result-set behavior such as pagination or ordering, which an agent might need for a list 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?
Schema description coverage is 100%, so all five filter parameters (pace, tone, voice, search, archetype) are already documented in the schema. The description only restates the name-search behavior, adding no syntax or semantic value beyond structured data.
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?
States a specific verb and resource ('Retrieve all people (clients)') and scopes it to the authenticated user. It also explicitly names what it does NOT return ('not the Lowdown') and points to the sibling generate_compass, so an agent can distinguish it from related tools.
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?
Explains the optional search-by-name path and routes 'any read, card or go deeper' requests to generate_compass. It does not mention get_person as the single-record alternative, leaving one obvious sibling comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a chat message about a specific person (client). The AI will respond with tailored advice based on the client's Compass profile.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to send | |
| person_id | Yes | The UUID of the person |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key behavior: the AI will respond with tailored advice based on the client's Compass profile. This adds value beyond a generic 'send' operation. However, it does not mention idempotency, state changes, or potential side effects.
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?
Two sentences covering purpose and behavior with no extraneous details. Efficient and front-loaded.
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?
For a simple two-parameter tool without output schema or annotations, the description adequately covers what the tool does and its unique outcome. Could mention validation of person_id or response format, but these are minor gaps.
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?
Schema coverage is 100% with basic descriptions. The tool description does not add new parameter-level detail beyond what the schema provides. Baseline 3 is appropriate.
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?
Clearly states verb 'Send' and resource 'chat message about a specific person', distinguishing it from sibling tools like get_chat_messages. Also clarifies the context (about a client) and the outcome (AI responds with tailored advice).
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?
Implied usage is clear: use to send a message about a person and receive advice. However, no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives like get_chat_messages for retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the user's profile settings. Can change name, profession, phone, DOB, or custom prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth YYYY-MM-DD | |
| phone | No | Phone number | |
| last_name | No | Last name | |
| first_name | No | First name | |
| profession | No | Profession | |
| maiden_name | No | Maiden/birth name | |
| middle_name | No | Middle name | |
| custom_prompt | No | Custom instructions for AI interactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Update', implying mutation, but does not disclose whether fields are merged or replaced, authentication requirements, idempotency, or side effects.
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?
Two sentences, no fluff, efficient. Every word adds value.
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?
Given 8 optional parameters and no output schema, the description lacks context about partial updates, default behavior, and that it applies to the current user. More detail would be beneficial.
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?
Schema description coverage is 100%, and the description lists the main fields but adds no deeper semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 clearly states the verb 'Update' and the resource 'user's profile settings', listing specific fields that can be changed. This distinguishes it from sibling tools like complete_profile or create_person.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., complete_profile for initial setup). No prerequisites or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_compass2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Optional: the moment the user described, in their words (e.g. 'listing appointment Thursday, first meeting').",
+ "maxLength": 500,
+ "type": "string"
+}Input schema / properties / depthAdded value: +{
+ "default": "card",
+ "description": "card = short card first (default). full = Deeper Details, only when the user asks to go deeper.",
+ "enum": [
+ "card",
+ "full"
+ ],
+ "type": "string"
+}list_people2 fields changedInput schema / properties / archetype / descriptionPrevious value: -"Filter by behavioral archetype"New value: +"Filter by archetype name"Input schema / properties / archetype / enumRemoved value: -[
- "Initiator",
- "Connector",
- "Creator",
- "Operator",
- "Maverick",
- "Guardian",
- "Navigator",
- "Architect",
- "Advocate",
- "Lighthouse",
- "Blueprint",
- "Mentor"
-]batch_create_personscomplete_profilecreate_persongenerate_compassget_chat_messagesget_meget_personhealth_checklist_peoplesend_chat_messageupdate_profileBehavioral read on one speaker in a sales conversation. Big Five standings plus how to use them.
Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
AI-native B2B sales research, ranking, and CRM enrichment.
Add one secure layer between your agents and this server.