Behavioral intelligence for client-facing professionals. Know who you're walking into.
Scored across 11 tools
Most tools target distinct resources and actions, but generate_compass overlaps somewhat with create_person, which automatically generates a Client Compass. The intended distinction (generating/regenerating a compass vs. creating a person) isn't fully clear from the descriptions, though the rest of the set is unambiguous.
All tool names follow a consistent snake_case verb_noun pattern—batch_create_persons, complete_profile, get_chat_messages, send_chat_message, etc. There are no mixed conventions or irregular verbs.
11 tools is well within the ideal range and each tool maps to a clear capability: profile setup/update, person CRUD (mostly), compass generation, chat, and health check. No tool feels redundant enough to remove entirely.
The core workflow—complete profile, create clients, generate compasses, retrieve clients, and chat—is covered. Missing update_person and delete_person are minor gaps since the primary use case appears to be creation and engagement rather than management of client records.
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.
Create a new person (client). Generates their Client Compass automatically. 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?
With no annotations provided, the description carries the full burden. It reveals that the tool generates a Client Compass automatically and requires a profession, but it does not disclose error handling (e.g., if the user lacks a profession) or side effects beyond compass generation. It is partially transparent but could be more detailed.
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 extremely concise with two short sentences, no redundant information, and front-loads the core action and key feature. Every word earns its place.
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 the tool has 8 parameters and no output schema, the description is sparse. It does not explain return values, error scenarios, or behavior when optional parameters like 'dob' are omitted. The automatic compass generation is a notable feature but other aspects are left unclear.
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 detailed descriptions for each parameter, so the baseline is 3. The description does not add any additional context beyond what the schema already provides, so it adds limited value.
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 creates a new person (client) and mentions the automatic generation of their Client Compass, which is a unique feature. However, it does not explicitly distinguish from sibling tools like batch_create_persons, which could cause confusion when deciding which to use.
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 specifies a prerequisite (user must have a profession set) but does not provide guidance on when to use this tool over alternatives, nor does it mention when not to use it. This leaves some ambiguity for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a numbrU Compass profile for a person using the Compass engine. Returns personality insights, communication style, and relationship strategies. IMPORTANT: present the returned output verbatim, exactly as formatted, preserving every section and heading (KNOW, DO, DEEPER DETAILS, Strategic Tips, Who They Are, Signals, How to Communicate, Try This First). Do not summarize, reword, reorder, condense into tables, or describe the sections instead of showing them. The formatting is the product.
| 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 | |
| vertical | No | Industry vertical (default: real_estate) | real_estate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: the output must be presented verbatim, preserving all sections and headings. It explicitly warns against summarizing, rewording, reordering, condensing into tables, or describing sections. This goes beyond what annotations (none provided) or schema could convey. It also states the output includes specific sections (KNOW, DO, DEEPER DETAILS, etc.), which is valuable behavioral context. No contradictions with annotations since none exist.
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 well-structured: a clear first sentence stating purpose, followed by a critical usage note. The 'IMPORTANT' section is front-loaded and imperative, making it hard to miss. It's slightly long but every sentence earns its place—the formatting instructions are essential for correct tool invocation. The only minor issue is that the list of sections could be seen as redundant with the output, but it's necessary to emphasize the verbatim requirement.
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 the tool has no output schema, the description compensates by detailing the output structure (sections and headings) and the required handling. It covers the key behavioral requirement (verbatim presentation) that an agent must know. It doesn't explain what happens if dob is missing or how the engine handles edge cases, but the schema already notes dob is optional. For a generation tool with no output schema, this is fairly 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%, so the schema already documents all three parameters (name, dob, vertical) with descriptions. The tool description adds no additional parameter-level meaning beyond what the schema provides. It does mention 'for a person' and 'Compass engine' which contextualizes the name parameter, but that's minimal. Baseline 3 is appropriate given full schema coverage.
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's function: generating a numbrU Compass profile for a person using the Compass engine. It specifies the resource (Compass profile), the action (generate), and the output content (personality insights, communication style, relationship strategies). It is distinguishable from siblings like create_person or complete_profile because it focuses on generating a Compass profile, not creating or updating a person record.
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 provides clear context on when to use this tool: when a Compass profile is needed for a person. It doesn't explicitly name alternatives or exclusions, but the sibling list shows other tools like create_person and complete_profile, and the description's focus on Compass profile generation implies the use case. The 'IMPORTANT' section gives strong guidance on how to handle the output, which is a form of usage guidance. However, it doesn't explicitly say 'use this instead of X when...'.
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, including their Client Compass data.
| 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, so description must convey behavior. States it retrieves data but does not mention error handling, permissions, or side effects. Lacks detail on what 'Client Compass data' entails.
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 concise sentence front-loading key info. No unnecessary words.
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?
Adequate for a simple retrieval tool with one parameter. Covers purpose and key data included. Minor gaps: no mention of error handling or response format.
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 description of person_id. Description adds output context but no additional parameter meaning, so baseline score of 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 'retrieve', resource 'person (client)', and scope 'by ID' and 'including Client Compass data'. Distinguishes from sibling tools like list_people and batch_create_persons.
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: use when needing a single person by ID. No explicit when-not or alternative guidance provided.
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.
| 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 behavioral archetype |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the scope (authenticated user) but fails to mention read-only nature, pagination, ordering, rate limits, or behavior for empty results.
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 a single concise sentence with a clear front-loaded purpose. However, it sacrifices completeness for brevity by not covering the available filters, which is a structural deficiency.
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 five optional parameters, no output schema, and no annotations, the description is insufficient. It does not mention that all filters are optional, return format, pagination, or any behavioral details, leaving major gaps 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 coverage is 100%, so baseline is 3, but the description only mentions the 'search' parameter and ignores 'pace', 'tone', 'voice', and 'archetype'. This omission is misleading and reduces the value added 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?
The description clearly states the tool retrieves all people for the authenticated user, distinguishing it from single-person retrieval tools like get_person. However, it only mentions search by name, omitting four other filtering parameters, so the purpose is not fully specified.
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 such as get_person for a single person or batch_create_persons for creation. No context or exclusion criteria are given.
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.
batch_create_personscomplete_profilecreate_persongenerate_compassget_chat_messagesget_meget_personhealth_checklist_peoplesend_chat_messageupdate_profileSales 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.
Sales intelligence — research companies, qualify prospects, and find contacts.
Add one secure layer between your agents and this server.
