client-compass
Server Details
Behavioral intelligence for client-facing professionals. Know who you're walking into.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- marcus160365/numbru-mcp-server
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 11 of 11 tools scored.
Tools are mostly distinct, but there is some overlap between 'batch_create_persons' and 'create_person', and 'generate_compass' might be confused with the automatic compass generation in person creation. Descriptions help disambiguate.
All tools follow a consistent verb_noun pattern with snake_case, such as 'create_person', 'get_me', 'send_chat_message', etc. Naming is predictable and easy to use.
With 11 tools, the set is well-scoped for the domain of client and compass management. Each tool serves a clear purpose without unnecessary bloat.
The set covers core workflows (user profile, client creation/retrieval, messaging) but lacks update or delete operations for persons, which could be a gap in maintaining client records.
Available Tools
11 toolsbatch_create_personsBatch Create PersonsAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Includes important behavioral note about returning full Start Here coaching without summarization or tables, and implies parallel execution. Lacks disclosure of rate limits 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?
Three sentences: main function, use case, behavioral directive. Every sentence is essential and the most critical information (output format) is called out with IMPORTANT.
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, but description specifies the expected output (full coaching for each person). Lacks details on return structure, error handling, or how results are returned, but sufficient for agent to invoke 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?
Schema coverage is 100%, so baseline is 3. Description adds that only a name is required and confirms the array limit of 10, but does not provide additional meaning beyond what the schema already describes.
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 the tool creates up to 10 people in parallel and generates a Client Compass for each, with a specific use case of re-engaging dormant leads. Distinguishes it from siblings like 'create_person' by mentioning batch and parallel operation.
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?
Explicitly suggests using for re-engaging dormant leads and notes that a name is enough, but does not mention when not to use or compare to alternatives like 'complete_profile' or 'generate_compass'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
complete_profileComplete ProfileAInspect
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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions generating a User Compass and being one-time, but lacks details on idempotency, auth, side effects, or if calling again overwrites.
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 efficient sentences front-loading purpose and requirement. No fluff, every sentence 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?
Missing return value explanation (generates User Compass but no output schema or description of response). Does not explicitly state this is for the authenticated user, which could be ambiguous given sibling person creation tools.
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 good parameter descriptions. The main description adds only that it sets name and profession, not enhancing beyond schema. Baseline 3 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 'Complete', resource 'user's profile', and context 'one-time signup'. Distinguishes from siblings like update_profile and create_person by emphasizing it's a setup step.
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?
Explicitly says 'Required before creating clients', giving a clear usage context. However, does not contrast with related tools like update_profile or generate_compass.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_personCreate PersonAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses automatic Client Compass generation and profession requirement, but omits details like idempotency, error handling, or rate limits. Moderate disclosure for a creation 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?
Two sentences are concise and front-loaded. Consider adding structured parameter highlights for clarity, but current form is efficient and covers key points.
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?
Covers main behavior and parameter guidance, but lacks output description (e.g., returns created person), error scenarios, and constraints beyond profession. With no output schema, the description could better round out the tool's behavior.
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?
All 8 parameters have schema descriptions. The tool description adds value beyond schema, e.g., dob states 'do not ask the user', vertical mentions default, key_parties clarifies purpose. No parameter left undocumented.
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 states 'Create a new person (client)' with specific verb and resource. It also mentions automatic generation of Client Compass, distinguishing it from siblings like batch_create_persons (bulk) and update_profile (modification).
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?
Clearly indicates when to create a person. Implicitly contrasts with batch_create_persons for multiple and update_profile for edits. However, lacks explicit 'when not to use' or alternative tool references, and no guidance on vertical override scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_compassGenerate CompassBInspect
Generate a numbrU Compass profile for a person using the Compass engine. Returns personality insights, communication style, and relationship strategies.
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only describes the output without mentioning side effects, idempotency, permissions, or whether this is a read-only operation. The tool likely creates or computes data, but this is not clarified.
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 sentence with a follow-up on returns, front-loading the primary action. It is concise but could be slightly more structured to separate action from output. Still, minimal 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?
The description covers the high-level purpose and outputs, but with no output schema, more detail on the return structure would be beneficial. The parameters are well-covered by the schema. Overall, adequate but with 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 input schema already documents all parameters with descriptions. The tool description does not add any additional information beyond what the schema provides, earning a baseline score of 3.
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 'Generate' and the resource 'numbrU Compass profile', with specific outputs listed: personality insights, communication style, and relationship strategies. It is distinct from all sibling tools, which focus on person CRUD, messaging, and basic operations.
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. While the sibling list contains no other Compass-related tools, the description does not provide any context about prerequisites, when not to use, or comparisons to similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chat_messagesGet Chat MessagesBInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions reverse chronological order but omits details about pagination (cursor), error handling (invalid person_id), message structure, or whether messages include metadata like timestamps. This leaves important behavioral gaps.
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, front-loaded with the verb 'retrieve', and contains no unnecessary words. Every phrase adds value, making it efficiently scannable.
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 absence of an output schema, the description should explain return values. It only says 'returns messages' without detailing fields like text, timestamp, or sender. Pagination using cursor is not explained, which is essential for correct usage with three parameters.
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 the description need not repeat parameter details. It adds minimal extra meaning by linking 'specific person' to person_id and 'reverse chronological' to the implicit sort. However, it does not explain cursor semantics or the default limit behavior beyond what the schema already 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?
The description clearly states the tool retrieves chat message history for a specific person and specifies the sort order as reverse chronological. This is distinct from siblings like send_chat_message or list_people, making the purpose unambiguous.
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 implies when to use (need chat history for a person) but provides no explicit comparison with alternatives or conditions. There is no mention of when not to use or which sibling tool might be better for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_meGet Current UserAInspect
Retrieve the authenticated user's profile information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool retrieves profile information, implying it is read-only and safe. However, it does not explicitly disclose behavioral traits like authentication requirements or potential side effects. The description is adequate but not 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 a single sentence with no fluff. It is concise and front-loaded, immediately conveying the tool's 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?
Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It explains the what but lacks details on the return value format or any caveats. However, for a basic getter, this is likely sufficient.
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, so the baseline score is 4 per guidelines. The description adds no parameter information beyond what the schema already provides, which is sufficient given the lack of parameters.
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 specifies the verb 'retrieve' and the resource 'authenticated user's profile'. It distinguishes itself from sibling tools like 'get_person' which likely gets a specific person by ID, and 'list_people' which lists multiple people.
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' or 'list_people'. There is no mention of prerequisites or context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_personGet PersonBInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It mentions including 'Client Compass data' but does not disclose any behavioral traits such as error handling, permissions, or side effects. Minimal transparency.
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?
A single sentence of 16 words, front-loaded with the key action and resource. Every word is necessary; no filler or redundancy.
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 single-parameter retrieval tool with no output schema, the description is generally adequate. However, it could mention what happens if the person is not found. The mention of Client Compass data hints at additional context but leaves unclarified.
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 provides full coverage (100%) for the single parameter person_id. The description adds no additional meaning beyond what the schema already states, so baseline 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?
The description explicitly states 'Retrieve a single person (client) by their ID' with a specific verb and resource, clearly distinguishing from siblings like list_people (multiple) and batch_create_persons (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?
No guidance on when to use this tool versus alternatives like list_people or how it relates to other tools. The description lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkHealth CheckAInspect
Check the health status of the numbrU API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It only says 'check health status', implying a read-only operation, but does not describe what the response contains (e.g., JSON with status code, uptime, or database connectivity). This is insufficient for an agent to understand the return value 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?
The description is a single, concise sentence that captures the tool's essence with no unnecessary words. It is well 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?
Given no output schema and no annotations, the description should explain what the health check returns. It does not, leaving the agent to guess. For a simple tool, this is adequate but not complete; e.g., knowing whether it returns a simple status or detailed metrics would improve usability.
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 tool has zero parameters, and the input schema is empty with 100% coverage (vacuously). The description does not need to add parameter meaning since none exist. Baseline for 0 params 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's purpose: 'Check the health status of the numbrU API'. It uses a specific verb and resource, and distinguishes itself from sibling tools that perform other actions like creating persons or sending messages.
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. For example, it could be used for initial API readiness checks, but no context is given. Sibling tools vary widely, but no exclusions or recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_peopleList PeopleAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must fully cover behavior. It only mentions retrieval and optional search, but omits details on pagination, sorting, rate limits, or that it is a read-only operation with no 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?
The description is two sentences, 14 words, with no wasted words. It front-loads the core action and resource, then adds the optional search filter. Highly efficient.
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 list tool with 5 parameters and no output schema, the description should explain pagination, ordering, and default behavior. It only covers name search. The sibling tools suggest a richer people context, so more completeness is expected.
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 parameters are well-documented in the schema. The tool description adds no extra meaning beyond mentioning the 'search' parameter, but does not highlight other filters (pace, tone, etc.), missing an opportunity to clarify their combined usage.
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 'Retrieve' and resource 'all people (clients)' with a specific scope 'for the authenticated user'. It naturally distinguishes from siblings like get_person (single) and create_person (create).
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 implies usage for listing all people with optional name search, but does not explicitly state when to use this tool versus alternatives like get_person or search tools. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_chat_messageSend Chat MessageAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions sending a message and receiving AI advice. It lacks disclosure of side effects (e.g., message storage), required permissions, rate limits, or response timing (immediate vs async). For a tool with no annotations, this is a significant gap.
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, direct, and contains no filler. Every sentence 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?
The description explains the core function and AI response, but does not specify return format, error cases, or prerequisites (e.g., if the person must exist or if the profile must be complete). Given the tool's simplicity and lack of output schema, it is minimally adequate but could be more 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?
The input schema provides descriptions for both parameters (message and person_id). The description adds context that the message is about the person and that the AI uses the person's profile, enhancing the schema's meaning.
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 'Send' and the resource 'chat message', with specific context about it being about a person and receiving tailored AI advice. This distinguishes it from sibling tools like get_chat_messages and 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?
The description implies when to use (when wanting to send a message about a person and get advice), but does not explicitly provide when-not-to-use scenarios or alternative tools. The context from sibling tool names provides some differentiation, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_profileUpdate ProfileBInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Update', implying mutation, but lacks details on authentication, side effects, or behavior with omitted fields.
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 concise with two sentences and no unnecessary words, making it easy to parse.
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?
While the description covers the basic purpose, it lacks behavioral details and usage context. Given the tool's complexity (8 optional parameters, no output schema), more information would improve completeness.
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 covers all 8 parameters with descriptions (100% coverage). The description enumerates categories (name, profession, etc.) but adds no new semantic meaning beyond what the schema already 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?
The description clearly states the action ('Update') and the resource ('user's profile settings'), listing specific fields. It distinguishes itself from sibling tools like create_person and batch_create_persons, though it doesn't explicitly address overlaps with complete_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?
The description provides no guidance on when to use this tool versus alternatives (e.g., complete_profile), nor does it mention prerequisites or context for updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!