Behavioral intelligence for client-facing professionals. Know who you're walking into.
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.
Average 3.6/5 across 11 of 11 tools scored. Lowest: 2.6/5.
Most tools have distinct purposes (create, retrieve, chat). However, generate_compass overlaps with the automatic compass generation in create_person and batch_create_persons, potentially causing confusion about when to use it separately.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_person, get_chat_messages, update_profile). The naming is predictable and clear, with no mixing of conventions.
11 tools is appropriate for a client management system with profile, chat, and compass features. The scope is well-defined and each tool serves a clear function without unnecessary bloat.
The tool set supports create, read, and search operations for people, but lacks update and delete functionality. Also, there is no explicit tool to update a client's compass after creation, and chat management is limited to send and retrieve without edit/delete.
batch_create_personsBatch Create PersonsAInspectCreate 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_profileComplete ProfileAInspectComplete 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_personCreate PersonAInspectCreate 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_compassGenerate CompassCInspectGenerate 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it 'returns' data but doesn't clarify if it has side effects, authorization needs, or error handling.
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-loads purpose and results. Concise but could include slightly more detail without being verbose.
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 and no annotations. Description does not address prerequisites, typical use cases, or how it differs from similar siblings like 'create_person' or 'complete_profile'.
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% and parameters are well-documented in schema. Description adds no additional parameter semantics.
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 it generates a Compass profile for a person and lists what it returns (personality insights, communication style, relationship strategies). However, it does not differentiate from siblings like '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?
No guidance on when to use this tool vs alternatives. Does not mention when not to use or any prerequisites.
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 MessagesAInspectRetrieve 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.
get_meGet Current UserAInspectRetrieve 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.
get_personGet PersonAInspectRetrieve 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.
health_checkHealth CheckAInspectCheck 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.
list_peopleList PeopleCInspectRetrieve 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_chat_messageSend Chat MessageAInspectSend 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_profileUpdate ProfileBInspectUpdate 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.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.