wealthbox-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct resource-action pair, with standard CRUD verbs and clear resource prefixes. The only potential overlap is between health and getMe, but their descriptions clearly differentiate a connectivity check from profile retrieval. The generic request tool does not create ambiguity as it serves as a catch-all.
Naming Consistency4/5
The vast majority of tools follow the wealthbox.<resource>.<action> pattern with consistent snake_case CRUD verbs. Minor deviations include wealthbox.getMe, listUsers, listTeams, and request, plus camelCase actions like addMember/deleteMember, which break the pattern slightly but remain predictable.
Tool Count3/5
With 51 tools, this server is clearly on the heavy side, but the count is justified by the broad CRM domain covering over 10 entities with full CRUD operations. It may be overwhelming for agents, yet each tool serves a distinct purpose and no redundant tools exist.
Completeness4/5
Core entities (contacts, tasks, events, opportunities, projects) have complete CRUD coverage. Minor gaps exist, such as missing delete for notes, missing update for workflows, and limited operations for comments and templates, but these can be worked around with the generic request tool and do not severely hinder common workflows.
Average 3.1/5 across 51 of 51 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but "Delete event" only implies a destructive action. It does not disclose reversibility, side effects, permission requirements, or consequences for associated data, leaving the agent without critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. Concision should distill necessary information, not omit it. A single tautological sentence is not effective structure for a delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations, no output schema, and a single undocumented parameter, the description is completely inadequate. An agent cannot infer behavior, safety, expected return values, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' (type number) with zero description coverage. The description adds no information about what the id references (event ID? external ID?), its format, or how it is used, so it entirely fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Delete event" is a tautology of the tool name wealthbox.events.delete. It states the obvious without adding any specific scope, prerequisites, or distinguishing details beyond what the name already conveys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 events.update, events.list, or other delete tools. There is no context about prerequisites, alternatives, or scenarios where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Create workflow,' which conveys no behavioral traits such as required permissions, idempotency, effects on existing workflows, or expected response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the cost of specificity. It provides no more information than the tool's name, so the forced brevity is under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested object parameter, no output schema, and no annotations, this description is critically incomplete. An agent cannot determine how to invoke this tool correctly or what a successful creation entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'body' with no description and additionalProperties: true, resulting in 0% schema coverage. The description does not mention the body parameter at all or explain what fields it should contain, leaving the agent with no guidance for constructing a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create workflow' merely restates the tool name wealthbox.workflows.create without adding any detail about what a workflow is or what creating one involves. This is a tautology rather than an informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or relationships to sibling tools like workflows.list or workflowTemplates.list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention return data format, pagination behavior, default limits, or how the filters interact. Listing parameter names without explaining their meaning adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the query parameter list is redundant with the schema and not front-loaded with the most important usage guidance. It is under-specified rather than concisely informative, as the list does not earn its place by adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations, no output schema, and a nested query object with ten parameters. The description is severely inadequate: it fails to explain filter semantics, pagination, or return values, leaving an agent without critical information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides the parameter names, but with 0% description coverage, the description must explain what each parameter does (e.g., date formats, filtering logic). It merely repeats the names from the schema, providing no semantic value beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List events' as a verb+resource, indicating a collection-returning operation. It also enumerates query parameters, which implies filtering capability and distinguishes it from a single-resource 'get' operation. However, it does not explicitly differentiate from sibling tools beyond the obvious list-vs-get contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives like wealthbox.events.get or wealthbox.events.create. It simply says 'List events' with no context about typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely restates the destructive action without mentioning irreversibility, cascading effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it under-specifies the tool's behavior. It's more a label than a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, this simple delete tool still requires more context (e.g., side effects, error conditions, or whether it's soft/hard delete). The description is insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the 'id' parameter. The agent receives no information about what the id refers to or how it should be obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete workflow' clearly states the action (delete) and resource (workflow), distinguishing it from sibling operations like list or get. However, it lacks any additional context such as permanence or scoping, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any prerequisites. The description is purely operational with no context on workflow lifecycle or conditions for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only says 'Complete a workflow step' without explaining side effects (e.g., status change, irreversibility), permissions, or what happens on success or failure. This is a critical gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is concise, but it is under-specified. It omits essential context and feels incomplete rather than efficiently structured. It is not a tautology, so it avoids a 1, but the brevity is not justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and minimal parameter details, the description is not complete enough for an agent to use the tool correctly. It covers only the basic action and none of the surrounding context (e.g., effects, expected inputs, return values).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it does not. The only parameter 'id' is unexplained—no indication of what it identifies, how to find it, or any constraints. The description adds no meaning beyond the schema's property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Complete') and the resource ('a workflow step'), making the primary purpose understandable. However, it does not explicitly distinguish this from the sibling tool wealthbox.workflowSteps.revert, which also operates on workflow steps, so it misses the distinction needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like wealthbox.workflowSteps.revert. The description does not mention prerequisites, context, or criteria for selection, leaving the agent without direction on choosing this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the obvious. It does not reveal whether deletion is permanent, what side effects occur, or if authorization is required, making it inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but it is under-specified rather than concise. It omits critical information and reads as a tautology of the tool name, failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description still proves incomplete. It lacks any context about the deletion behavior, expected id format, or what happens to associated data, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with 0% description coverage, and the description does not compensate by explaining that id refers to the task ID. The word 'Delete task' adds no meaning beyond the schema, leaving the parameter's context implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete task' uses a specific verb (delete) and resource (task), clearly indicating the tool's purpose. It differentiates from sibling tools like tasks.list or tasks.update, though it doesn't explicitly distinguish from other resource-specific delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., tasks.update for modifications). No prerequisites, idempotency, or context are mentioned, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It fails to mention side effects, permissions, data modifications, or reversibility. The phrase 'Revert a workflow step' offers no insight into what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It is front-loaded with the core action but lacks essential details for correct usage. This is not appropriately sized; it is simply too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is inadequate. It does not explain the parameter, the context of a revert operation, or the expected outcome, leaving the agent without a complete basis for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single numeric 'id' parameter with no description, and the tool description does not clarify what the id refers to or how it should be used. With 0% schema description coverage, the description fails to compensate for missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Revert a workflow step' clearly identifies the action (revert) and the resource (workflow step), distinguishing it from the sibling 'wealthbox.workflowSteps.complete'. It is specific and unambiguous, though it doesn't elaborate on what reverting entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of the workflow step lifecycle, prerequisites, or exclusions. The description simply states the action without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It fails to mention whether updates are partial or full replacements, how the 'body' parameter interacts with individual fields, whether special permissions are required, or what the response contains. The phrase 'pass raw body' hints at an alternative input method but does not explain its behavior or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and is front-loaded with the primary action. There is no fluff or redundancy. However, its brevity contributes to the lack of critical information, so it is concise but not optimally structured for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, a nested body object, no output schema, and no annotations. The description provides almost no additional context: it does not explain return values, parameter semantics, or how to structure a raw body. This is far from sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'raw body' without explaining how it relates to the other parameters (id, name, status, due_date, description). No parameter meanings, formats, or constraints are given, leaving the agent to guess for all six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update project by id') and the resource ('project'), which is specific and distinguishes it from sibling tools like create, get, list, or delete. The addition of 'You can also pass raw body' hints at an extra capability, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, when a raw body should be used instead of structured fields, or any exclusion scenarios. The description implies use when updating an existing project, but gives no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the tool 'supports method, path, body, and query,' but does not disclose that it can perform arbitrary, potentially destructive operations (e.g., DELETE or PATCH) or explain authentication, rate limits, or error behavior. The agent is left unaware of the risks of using this raw API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that is front-loaded with the tool's purpose. It avoids unnecessary words and is easy to parse. However, the extreme brevity borders on under-specification, though conciseness is technically about efficient wording, not completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic API request tool with no annotations, no output schema, and only partial schema descriptions, this description is severely incomplete. It fails to explain what the tool returns, how responses are structured, how to handle errors, or what conventions to follow for the path/body/query. The agent would be largely guessing when invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely lists parameter names (method, path, body, query) without adding any semantic meaning. The schema already provides some details (e.g., path must start with /v1, method enum), but the description does not explain how to construct paths or format the body/query. With schema description coverage at only 25%, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a generic Wealthbox API request tool, with a specific verb ('request') and resource ('Wealthbox API'). It lists the supported parameter types (method, path, body, query), which helps distinguish it from the many specific sibling tools for contacts, tasks, events, etc. However, it does not explicitly state that this is a raw fallback for endpoints without dedicated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many specific sibling tools. The description does not mention preferring dedicated endpoints (e.g., wealthbox.contacts.create) or using this generic tool only when no specific tool exists. Given the wide array of siblings, the lack of explicit usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. 'Delete contact' only states the action and does not mention irreversibility, permission requirements, or potential cascading effects on related data. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with no redundant content. It is front-loaded and easy to parse. While slightly under-specified, it remains efficient for a simple tool, though it could include minimal context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with no annotations and no output schema, the description is insufficient. It does not convey important context such as irreversibility, permissions, or the impact of deleting a contact, leaving the agent with incomplete information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'id' parameter of type number with no description, and schema description coverage is 0%. The description does not explain what 'id' refers to or any format constraints. The parameter's purpose is implied by the tool name, but the description adds no explicit semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete contact' clearly states the action (delete) and the resource (contact). It is specific and not a tautology, but it does not distinguish itself from other delete tools such as wealthbox.events.delete or wealthbox.tasks.delete, though the resource name provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like update or other delete tools. There are no prerequisites, exclusions, or context about selecting this over a similar sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states the verb 'delete' but does not indicate whether the operation is permanent, soft delete, requires confirmation, or has cascading effects. For a destructive tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, making it front-loaded and easy to parse. However, it is almost too terse, lacking necessary context that could be provided without adding fluff. Still, as a standalone phrase, it is appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description must provide operational context. It fails to cover critical details such as permanence, idempotency, related data effects, or error scenarios. The tool is a destructive operation, yet the description is a bare statement, leaving the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a required 'id' parameter with 0% description coverage. The description does not mention the parameter or explain that the id identifies the opportunity to delete. Since schema coverage is low, the description should compensate, but it provides no parameter-related meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('opportunity'), which distinguishes it from sibling tools targeting other resources. However, it is terse and provides no additional context about the operation's scope, making it slightly less informative than a more descriptive purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or contrast with other delete tools (e.g., permanent removal versus other operations). The description provides no contextual direction for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the entire burden of behavioral disclosure. It only says 'Create project' with an example, offering no details about side effects, required permissions, potential errors, or return values. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the action first ('Create project') and then provides a small illustrative example. Every word earns its place, with no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a nested object, no output schema, and no annotations, the description is largely incomplete. It lacks details about required fields, date formats, status options, and response behavior. The minimal example does not sufficiently cover the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% schema description coverage, but the description includes an example showing 'name' and 'description' fields, which adds some semantic meaning. However, it does not explain 'status', 'due_date', or the nested 'body' object, so it only partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a project, which is a specific verb and resource. It does not explicitly distinguish from siblings like projects.update or projects.delete, but the create action is unambiguous among the list of project tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, whether to use update for modifications, or any other context that would help an agent decide between create and other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose return format, pagination defaults, or side effects beyond the word 'retrieve'. Listing query params is helpful but does not explain their behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, containing only one sentence and a parameter list. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list endpoint with no output schema and no annotations, the description is minimal. It lacks explanation of what the activity stream contains, default behavior, or constraints on the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameter names already present in the schema but does not add semantic meaning (e.g., date formats, pagination limits). Schema coverage is 0%, so the description fails to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve activity stream' with a specific verb and resource. It is clear and distinguishes from sibling list tools by naming the activity stream resource, though it does not elaborate on what an activity stream is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the basic read operation ('List') and provides no information about return format, pagination, rate limits, or other behavioral traits, making it minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no fluff or redundancy, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the generic nature of the tool, the description is incomplete. It does not clarify what 'members' means, what the response structure looks like, or how different category types might behave, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'type' parameter at all, and schema description coverage is 0%. The schema's enum values are self-explanatory, but the description fails to add any contextual meaning beyond what the schema already provides, so it does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List members of a customizable category' clearly states the action (list) and the resource (members of a category). It is specific enough to convey the tool's function, though it does not explicitly distinguish it from sibling list tools like tags.list or customFields.list which might serve similar purposes for specific categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on how to choose between this and similar list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists query parameter names without explaining pagination behavior, response format, date semantics, or authentication requirements. This leaves critical operational behaviors undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the purpose and lists parameters. It is free of fluff and easily scannable, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, output schema, or parameter descriptions. The description only provides parameter names, leaving an agent without sufficient information to construct the query object, interpret date values, or understand pagination behavior. This is notably incomplete for a list operation with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining each parameter. It repeats the names (updated_since, updated_before, page, per_page) but gives no meaning, format, defaults, or constraints. This adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List notes'), clearly indicating a collection-list operation. It distinguishes from sibling tools like notes.get, notes.create, and notes.update, which are single-item or mutation operations. The resource name 'notes' disambiguates from other list tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any selection criteria, filtering scope, or situations where notes.get or other list tools would be more appropriate. An agent is left without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List comments' and the query params, but does not disclose whether this is a read-only operation, how pagination behaves, what default page size is, or what happens when resource_id is given without resource_type. No significant behavioral traits beyond the basic listing action are revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the main action front-loaded in the first sentence. The second sentence lists query parameters without superfluous text. No filler or redundancy, making it appropriately sized. It could be slightly improved with examples or formatting, but it remains clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is too minimal. It lacks critical context such as return format, pagination defaults, acceptable resource_type values, and any system-wide behavior like whether all comments are included by default. For a list operation with optional filters, more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must compensate for parameter meaning. It enumerates the parameter names (resource_id, resource_type, etc.), but these names already exist in the schema and the description adds no extra semantics. It does not explain valid resource_type values, date formats for updated_since/updated_before, or how filtering interacts with pagination. Thus, it only marginally helps beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists comments and optionally filters by resource. It is specific about the resource (comments) and distinguishes from sibling list tools for other resources. However, it doesn't explicitly scope whether it lists all comments globally or within a workspace, which leaves slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing comments and mentions optional resource filtering, but does not provide explicit guidance on when to use this tool versus alternatives like notes.list or tasks.list. There are no exclusions or alternative tool references, so the usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the ability to provide a raw body, which is a useful behavioral hint, but it does not disclose output, potential errors, required fields, or side effects. The raw body capability is already described in the input schema, so the description adds limited transparency beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. It front-loads the purpose with 'Create contact' and immediately gives a practical example. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, nested objects, no output schema, and no annotations, the description is severely inadequate. It only explains the simplest case (first/last name) and does not address any of the complexity, such as arrays of emails/phones/addresses, the use of type for Person/Company, or what the API returns. An agent cannot reliably invoke this tool beyond trivial examples based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate for undocumented parameters. It provides a concrete example for first_name and last_name, which is helpful, but it does not clarify nested objects like tags, emails, phones, or addresses, nor does it explain how the raw body interacts with other parameters beyond what the schema already states. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create contact', which is a specific verb+resource action. The example with first_name and last_name clarifies the expected input, distinguishing it from sibling tools like contacts.update or contacts.delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 relative to alternatives such as contacts.update or other create tools. It implies usage for creating a contact but does not state any exclusions, prerequisites, or context in which an alternative might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure, but it only says 'Create opportunity' without detailing side effects, permissions, idempotency, or what happens on success. There is no information about authentication, rate limits, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence and an example JSON object. Every part contributes to understanding the tool's purpose and basic payload structure, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, a nested body object), lack of annotations, and no output schema, the description is woefully incomplete. It fails to explain the body parameter, the relationship between top-level fields and body, or any return behavior, leaving major gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its eight parameters, and the description's example only illustrates four of them (name, pipeline_id, stage_id, amount). It does not explain the body parameter or other fields, leaving significant ambiguity about how to structure a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Create' and resource 'opportunity', making it explicit that this creates a new opportunity. The example with 'new deal' reinforces the resource type and distinguishes it from sibling tools like opportunities.update or opportunities.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Create opportunity' and providing a concrete example, but it does not explicitly compare with alternatives or state when not to use it. The example serves as basic usage guidance, but there is no mention of conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses only that an opportunity is updated by id, but fails to mention whether updates are partial or full replacements, permissions required, side effects, or behavior when the id does not exist. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and adding a note about the raw body option. Every word earns its place, making it concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no schema descriptions, no annotations, no output schema), this description is completely inadequate. It does not explain update semantics, parameter usage, or expected behavior, leaving the agent without critical information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It only clarifies the purpose of 'id' and 'body' (raw body), leaving the other seven parameters (e.g., stage_id, pipeline_id, primary_contact_id) without any semantic context beyond their names. This is insufficient for a tool with nine parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 target resource ('opportunity by id'), which distinguishes it from sibling tools like create, get, list, and delete. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or when to prefer the raw body approach over individual fields. It merely states the obvious function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. 'Delete project' does not mention whether the deletion is permanent, what side effects occur, any required permissions, or the response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Delete project') and front-loaded, with no wasted words. However, it is arguably under-specified for the task, although it is appropriate in length for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description lacks essential behavioral context such as irreversibility or error conditions. Given the absence of annotations, a more complete description is needed to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' (number) with no description, and schema description coverage is 0%. The description adds no information about what the id refers to or any constraints. It simply repeats the resource name, providing no added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete project' uses the specific verb 'Delete' and identifies the resource 'project', distinguishing it from sibling delete tools for events, tasks, contacts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling delete tools (e.g., wealthbox.tasks.delete, wealthbox.events.delete). The usage is implied only by the resource name in the description, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get project by id' and does not mention return format, error handling, permissions, or side effects, leaving the agent without expectations beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler words, earning points for brevity and front-loading. It is somewhat under-specified, but that is a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the very simple tool (one parameter, no output schema), a short description is acceptable, but the lack of any mention of the return value or potential error conditions makes it incomplete for an agent that must infer behavior solely from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has no schema description (0% coverage), and the description merely repeats that the project is fetched 'by id' without explaining the id's format, meaning, or requiredness beyond the schema's type declaration. This adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get), resource (project), and qualifier (by id), distinguishing it from sibling list/create/update/delete tools. It is unambiguous but minimal, lacking broader context that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (when you have a project ID), but it does not explicitly state when to use this vs alternatives like projects.list. No exclusions or alternative tool names are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states 'Get event by id.' It implies a read-only operation but does not disclose return format, error behavior (e.g., missing id), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, directly front-loaded with the action and resource. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema and no annotations, the description is minimally adequate but leaves out return payload structure and edge-case behavior, though the complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' (number) with no description. The tool description merely says 'by id,' which is redundant with the parameter name and adds no semantic detail about format, type constraints, or usage beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get event by id' uses a specific verb ('Get'), names the resource ('event'), and specifies the retrieval scope ('by id'), making it clear this is a single-record fetch as opposed to list/create/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives like list or search. There is no mention of when a by-id lookup is appropriate or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Delete member from a household,' which is nearly identical to the tool name and does not explain irreversibility, side effects, or any required permissions. The destructive nature is implied by 'delete' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is direct and front-loaded. Every word contributes to the core meaning, and there is no waste or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a two-parameter delete, the description is still incomplete. It lacks parameter semantics, usage guidance, and any behavioral context. The lack of annotations and output schema further increases the burden, which the description does not meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter details. While the parameter names 'household_id' and 'id' offer some hint, 'id' is ambiguous (member ID? contact ID?) and the description does not clarify. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') with a clear resource ('member') and location ('household'), which directly distinguishes it from sibling tools like wealthbox.households.addMember. While terse, it fully conveys the tool's primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It neither mentions prerequisites, exclusions, nor related operations. The description simply states the action without contextualizing it among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the parameter focus ('by id') and does not mention return format, error behavior, permissions, or any other operational traits, which is a significant gap for a tool that is otherwise opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words, efficiently conveying the core purpose without redundancy. It is front-loaded and immediately understandable, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no annotations, and no output schema, the description is extremely sparse. It does not describe the return value, behavior for invalid ids, or any usage context, leaving the agent with insufficient information to fully understand the tool's behavior. This is a minimal but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented id parameter. However, it merely says 'by id', which adds no meaning beyond the schema's property name and type. No explanation of the id's meaning, format, or constraints is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get task by id' uses a specific verb and resource, clearly indicating a single-task retrieval. It distinguishes from sibling tools like tasks.list, tasks.create, tasks.update, and tasks.delete through the 'by id' qualifier, which implies a targeted fetch by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative retrieval or list operations. The description offers no context for selecting this tool, no prerequisites, and no exclusions, leaving the agent without direction on optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get', which implies a read-only operation, but does not disclose response format, error handling, authentication requirements, or whether the full workflow object (including steps) is returned. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase 'Get workflow by id' with no fluff or redundant information. It is front-loaded and appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should at least clarify what the tool returns (e.g., full workflow details, steps). It does not, and it also fails to mention error cases or relationship to other workflow tools. For a one-parameter tool, it is minimal but still leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'id' parameter of type number with 0% schema description coverage. The description's 'by id' merely restates the parameter name and adds no information about the id's origin, format, or constraints. It does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get workflow by id' specifies the action (get), the resource (workflow), and the scoping parameter (by id). This clearly differentiates it from sibling tools like workflows.list (no id) and workflows.create/delete, as well as workflowTemplates.get which targets a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no usage guidance beyond stating the operation. It does not mention when to prefer this over workflows.list, how to obtain the id, or any exclusions/alternatives. The phrase 'by id' implies the need for an id but provides no context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only says 'List', which implies a read-only action, but it does not disclose pagination, permissions, response format, or any potential side effects. This is minimal beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. No words are wasted, making it highly efficient for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate but lacks context about what contact roles are and what the response shape is. It does not fully compensate for the missing output schema and domain context, but it is not completely inadequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters that do not exist, and it adds no contradictory or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List contact roles' clearly states the action (list) and the resource (contact roles). It differentiates from sibling tools by naming a unique resource, though it does not explain what contact roles are.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Create task' without disclosing side effects, permissions, required fields, or response behavior. The example hints at payload structure but does not clarify what happens on success or how the raw body is processed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the action, plus a concrete example. No fluff, but it is under-specified. The structure is acceptable for such a short text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, a nested body object, no annotations, and no output schema, the description is grossly incomplete. It does not explain how to construct a valid request or what the response will be, leaving the agent without essential context for a complex create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, and the description adds only a simple example with title and due_date. It mentions 'raw body' but does not explain the semantics of other parameters like category_id, assigned_to_team_id, or how body relates to the individual fields. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create task' with a specific verb and resource, and the example reinforces the action. It is easily distinguishable from sibling tools like tasks.update, tasks.delete, and tasks.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by the directive 'Create task,' but it does not provide explicit context or alternatives. There is no mention of when to use this vs. the generic 'request' tool or other task operations, though for a create action the intent is fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'raw body' as an option, but does not explain whether updates are partial or full replacements, require an existing task, or what side effects occur. This lacks essential mutation transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action. The second sentence about raw body is somewhat vague and may not be essential, but overall the text is efficient and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no parameter descriptions, no annotations, and no output schema, this description is too thin to guide an agent reliably. It lacks update semantics, parameter constraints, and return-value expectations, making it a minimal placeholder rather than a complete tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains 'id' and hints at 'raw body' (corresponding to the 'body' property). The other six parameters (title, due_date, category_id, description, assigned_to_team_id, assigned_to_user_id) have no semantics provided, and 'raw body' is vague about format or precedence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update task') and the required identifier ('by id'), which distinguishes it from sibling tools like create, get, delete, and list. The additional note about raw body hints at advanced usage but doesn't obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing task via its id, giving a clear general context. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., create or delete) and no exclusions or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the action with no additional behavioral details such as return value on not-found, permissions, or error handling. It does not go beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording, appropriate for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is adequate but lacks explicit return-value or error behavior; there is no output schema or annotations to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'by id' clause adds minimal context that the single `id` parameter identifies the workflow template, but the schema already declares it as a required number with no further semantics. With 0% schema description coverage, more compensation is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get workflow template by id' clearly specifies the action (get), resource (workflow template), and scope (by id), distinguishing it from siblings like wealthbox.workflowTemplates.list and wealthbox.workflows.get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as wealthbox.workflowTemplates.list or wealthbox.workflows.get. Usage is only implied by the tool name and verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get contact by id' without explaining what is returned, whether the contact might not exist, or any authentication or permissions requirements. It adds no information beyond what the tool name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence: 'Get contact by id'. It is front-loaded, contains no filler, and every word earns its place. This is ideal conciseness for a simple CRUD get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally adequate for a simple one-parameter get tool. However, it does not mention the return format, error behavior, or any prerequisites. Given there are no annotations and no output schema, the agent is left without potentially important context about what happens on a successful or failed lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'id' parameter. The description's 'by id' does clarify that the id is the lookup key for the contact, but this is largely redundant given the tool name and schema property. For a single obvious number parameter, the minimal clarification is sufficient, but it does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get contact by id' uses a specific verb ('get') and resource ('contact') with a clear scope ('by id'). It cleanly distinguishes from siblings like contacts.list, contacts.create, contacts.update, and contacts.delete, which all have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it is for retrieving a single contact when the id is known, nor does it contrast with contacts.list for batch retrieval. The usage context is only implied by the phrase 'by id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'Create event' with an example, without disclosing side effects, permission requirements, idempotency, or error behavior. For a mutating operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact example, front-loaded and free of extraneous content. Every element earns its place, though the inline JSON could be slightly more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, a nested body object, and no output schema or annotations, the description is far too minimal. It does not explain return values, required fields, validation rules, or how the additional properties in body are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides an example covering title, starts_at, and ends_at with format hints, but leaves 4 other parameters (body, location, category_id, description) unexplained. The additionalProperties body also lacks guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create event' with a specific verb and resource, distinguishing it from sibling tools like delete, update, and list. The example adds contextual clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'create', but the description does not explicitly state when to use this tool versus alternatives (e.g., update) or mention any prerequisites. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states 'Update event by id' and mentions 'raw body'. It fails to describe consequences of updating (e.g., whether it overwrites or merges), required permissions, error handling for non-existent ids, or the format of the response. For a mutation tool, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the core action, and every clause adds value. The 'raw body' note is a unique addition that earns its place. No fluff or redundant repetition of schema info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations, yet the description is only two sentences. It inadequately covers the full parameter semantics, return values, error cases, or operation details. For a tool of this complexity, the description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning for 'id' (the event identifier) and 'body' (raw JSON object for arbitrary fields), but leaves the other six parameters (title, starts_at, ends_at, location, category_id, description) without semantic explanation. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update event by id' clearly states a specific action (update) on a specific resource (event) with a required identifier (by id), distinguishing it from create, delete, or list operations. It also mentions the 'raw body' option, adding uniqueness. This fully clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for updating an existing event by its id, and the 'raw body' note suggests flexibility for partial updates. However, it does not explicitly state when to use this tool over alternatives like create or delete, nor does it mention prerequisites or exclusions. The usage context is clear but implicit, not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states 'List projects' which implies a read-only operation, but it does not describe response format, pagination behavior, rate limits, default ordering, or other side effects. This is minimal transparency beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'List projects,' and every element (the parameter list) is relevant and non-redundant. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a list tool with 8 query parameters, no output schema, and no annotations, the description is too sparse. It fails to explain that all parameters are optional, how pagination works, what the default response contains, or the behavior when no filters are applied. The agent must infer too much, making the tool description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It merely enumerates parameter names already present in the schema without explaining their meaning, value formats, or valid options. For example, 'due_after' could be a date filter but its format is unspecified, and 'status' has no permitted values. The description adds little semantic value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'projects', clearly distinguishing it from singular 'get', mutation tools, and other resources. The query parameter list further confirms its role as a collection-fetching operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool fetches projects and lists filter options, but it does not explicitly compare with alternatives like 'get' or state exclusions. Usage guidance is implied by the 'list' verb rather than explicitly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to disclose safety traits, and the description does not state that this is a read-only operation, what the response contains, or any pagination/ordering behavior. As a minimal list description, it does not expose behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action 'List tags' and appends the optional filter, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides the core action and filter. However, it lacks information about the return payload, any default behavior, or how document_type affects results, leaving noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter document_type with an enum, and the description mentions it as an optional filter, which adds some meaning. However, the wording 'optionally by document_type' is ambiguous about whether it filters or groups tags, and it does not explain the significance of the enum values Contact/Note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'tags', making its purpose clear. It also mentions the optional document_type filter, adding scope. No sibling tool has 'tags' in the name, so it is easily distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It lacks any mention of prerequisites, use cases, or excluded scenarios. The description simply states what it does without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description carries the full burden but only lists query parameters. It does not disclose return format, default pagination behavior, whether the list is ordered, or any access restrictions. The bare parameter list is not sufficient behavioral transparency for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core purpose ('List tasks') and then packs the parameter list. No wasted words; every element adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description provides the essential filter and pagination parameters, which is sufficient for basic invocation. But it lacks guidance on output shape, default page size, ordering, and when to choose this over sibling list tools. Given the absence of annotations and output schema, the description is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions and coverage is 0%, so the description's enumeration of query parameters adds value by indicating which fields are supported. It also provides the date format for due_date (YYYY-MM-DD) and clarifies completed is boolean. However, most parameters are just named without deeper meaning, leaving ambiguity about their exact semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List tasks', a clear verb+resource pairing that distinguishes it from sibling tools like wealthbox.tasks.get (singular) and tasks.create/update/delete. It immediately conveys the tool's function as a collection-fetching operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that tasks.get is for a single task, nor does it explain when filtering versus pagination might be appropriate. The description simply states what it does without contextualizing against the broader toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It omits any details about authorization, return format, pagination, or potential side effects, revealing only the bare action of listing user groups.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words long with zero filler, front-loading the verb and resource. Every word earns its place, making it maximally concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a simple resource, the description is minimally viable but leaves gaps. It does not explain what a user group is, what the response contains, or whether authentication is needed, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters since there are none, and it does not contradict or undermine the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List user groups' uses a specific verb + resource structure, clearly identifying the action and target. It distinguishes from siblings like listUsers and listTeams by naming the 'user groups' resource explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no exclusions, and no mention of related list tools. It simply states the action without any contextual direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'List workflows' and enumerates query parameters, with no mention of the read-only nature, response format, pagination defaults, or any side effects. Since no annotations are provided, the description carries the full burden of behavioral disclosure and fails to address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence to state the action and a compact list for parameters. It front-loads the core purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's nested query object with six optional parameters and no output schema, the description is incomplete. It does not describe the response structure, default pagination behavior, or parameter details. The minimal information provided is insufficient for an agent to know what the tool returns or how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the query parameter names (status, template_id, updated_since, updated_before, page, per_page) but does not provide any additional semantics beyond the schema's property names. It does not explain expected value formats, allowed values, or how parameters interact. With schema description coverage at 0%, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List workflows,' which clearly identifies the action (listing) and the resource (workflows). This distinguishes it from sibling tools like workflows.get, create, and delete, as well as other entity list tools. However, it lacks additional context about what constitutes a workflow or the scope of the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides query parameters that imply filtering and pagination use cases, but it does not explicitly state when to use this tool versus alternatives such as workflows.get or other list tools. No exclusions or alternative recommendations are mentioned, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists query parameters and an example, without mentioning pagination defaults, whether inactive contacts are included, filter matching semantics, response format, or authentication needs. This is a significant gap for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with a front-loaded main purpose, a compact parameter list, and a helpful example. Every element serves a clear function, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists all parameters but omits important behavioral context such as default page size, maximum per_page, whether inactive contacts are returned by default, and how to fetch all contacts. With no output schema and no annotations, these details are necessary for correct use, leaving the description incomplete for a list tool with a nested query object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists all query parameters in a compact line and illustrates the structure with an example. It adds the enum values for 'type' but does not explain semantics like partial matching or how filters combine (AND/OR). The schema already provides types and enums, so the description gives marginal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List contacts' with a clear verb and resource. It lists the query parameters and provides an example, which distinguishes it from sibling tools like contacts.get, create, update, and delete. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for listing/searching contacts through the query parameters, but it does not explicitly state when to use it vs. alternative tools such as contacts.get. There are no exclusions or mentions of alternative tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'get', implying a read operation, but omits what the response contains, how missing IDs are handled, or any access prerequisites. This is a minimal disclosure that barely adds value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the action and resource with no filler. However, it is so terse that it lacks important context, but for a simple get operation, this level of brevity is adequate and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description should explain the tool's behavior and return value. It does not. An agent cannot know what shape the note takes, whether the operation is read-only, or what happens if the ID doesn't exist. The description is incomplete despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required numeric 'id' parameter with no description (0% coverage). The description's 'by id' only restates the parameter name without explaining the ID's meaning, format, or how it is used. It adds no substantial semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get note by id' clearly states the action (get), the resource (note), and the scope (by id). It unambiguously differentiates this tool from siblings like notes.list, notes.create, and notes.update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you have a specific note ID and need that exact note. It doesn't explicitly mention alternatives, but the 'by id' phrase inherently signals the intended use case versus list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the update is partial or full, whether it overwrites existing content, permission requirements, rate limits, or side effects. The 'raw body' option is mentioned but its behavior is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences. The first states the purpose and the second gives parameter options. There is no irrelevant information, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a nested body object, this sparse description leaves important gaps. It does not explain what a 'raw body' should contain, what the tool returns, or error conditions. The description is too minimal for a tool with such an open-ended parameter like body.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning by stating that content can be passed directly or via a raw body, mapping to the schema's content and body properties. However, it does not clarify what 'raw body' entails, and with 0% schema description coverage, the ambiguity around the body object (additionalProperties: true) is not resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Update note content by id,' clearly stating the action (update) and target (note content) with the unique identifier. This distinguishes the tool from sibling note tools like list, get, and create, and the wording is specific to the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers usage guidance by explaining that you can pass {content} directly or a raw body, but it does not explicitly state when to use this tool versus alternatives like create or the generic wealthbox.request tool. It implies usage for updating existing notes but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but 'Get opportunity by id' does not mention return format, error behavior, permissions, or any side effects. It is a bare statement with no added context, leaving the agent guessing about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, unambiguous sentence that is front-loaded and free of any fluff. It efficiently communicates the core action without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally sufficient for an agent to attempt the call. However, it lacks details about the return value or potential errors, so it is not fully complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'id' parameter, and the description only says 'by id', which merely restates the parameter name. No additional meaning or constraints are provided, so it fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get opportunity by id' clearly uses the verb 'Get' with the resource 'opportunity' and the scope 'by id'. It distinguishes itself from sibling tools like 'opportunities.list' and other resource-specific getters by specifying the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: users should call this tool when they have a specific opportunity id and need that single record. However, there is no explicit guidance about when not to use it or alternatives like 'list', so it falls short of a 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only states 'List opportunities' and enumerates query parameters. It does not mention return format, pagination behavior, defaults, or any side effects; the absence of an output schema makes this gap more significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with a single clear sentence followed by a compact parameter list. Every word serves a purpose and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns and any pagination or filtering nuances. It only lists parameter names, leaving the agent without information on response structure or default behavior, which is inadequate for a list endpoint with many filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description enumerates all query parameter names, which helps the agent know what filters are available. However, it adds no meaning beyond the names already visible in the schema, leaving formats and semantics (e.g., date strings) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'List opportunities,' using a specific verb and resource. This clearly distinguishes it from sibling tools like opportunities.get, create, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' and the list of query parameters imply this tool is for querying multiple opportunities with optional filters. However, there is no explicit guidance about when to prefer this over opportunities.get or any other alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden. It mentions 'Query params: page, per_page', indicating pagination behavior, which is useful. However, it does not disclose the response format, default per_page value, or explicitly confirm read-only semantics, relying on the verb 'List' to imply safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main purpose is front-loaded, and the query parameters are listed succinctly, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should describe what the response contains (e.g., a list of workflow template objects) and any pagination details. It only mentions the input parameters, leaving the agent without expectations for the output or behavior like default limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names 'page' and 'per_page' as query parameters, adding context that they are query string parameters rather than body fields. However, it does not explain their meaning or constraints (e.g., defaults, maximums), leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List workflow templates' with a clear verb and resource, effectively distinguishing it from sibling tools like wealthbox.workflowTemplates.get (retrieve a single template) and wealthbox.workflows.list (list workflows, not templates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 when to use list vs get, or any edge cases like pagination defaults. The tool name alone implies the use case, but the description does not explicitly state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It simply states 'List custom fields' with no information on return format, pagination, ordering, or side effects. While a 'list' operation is generally read-only, the absence of explicit safety or completeness guarantees leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, 'List custom fields', with no redundant content. It is maximally concise and front-loaded, stating the action and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, straightforward list operation, the description is minimally viable. However, it lacks any detail about the expected output shape or whether the list is complete, which could be relevant for an agent without prior context. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is complete. Per the rubric, 0 parameters warrant a baseline of 4, and there is nothing for the description to add beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'custom fields' clearly. It distinguishes from sibling list tools by naming a unique resource, leaving no ambiguity about what entity is being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It offers no context about typical use cases or exclusions, such as whether it should be used for retrieving custom fields for a specific object vs. other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Add member to a household,' which is a write operation, but does not disclose side effects, required permissions, behavior on duplicate members, or error conditions. The mention of 'raw body' hints at passthrough behavior but is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the core purpose, and includes a concise usage hint. Every word earns its place; no filler or redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters including a nested body object and an enum, but no output schema or annotations. The description covers the basic operation and parameter relationship, but does not explain return values, possible errors, or the meaning of 'id' (e.g., contact ID vs member ID). It is adequate for a simple CRUD-like operation but leaves several contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly clarifies the relationship between parameters by stating 'Provide household_id and either id+title or raw body,' which is not evident from the schema alone. This explains the required household_id and the exclusive alternative between id+title and body, adding useful semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add member to a household') with a clear verb+resource structure. It distinguishes itself from the sibling tool 'wealthbox.households.deleteMember' by indicating addition rather than removal. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It gives a brief invocation hint ('Provide household_id and either id+title or raw body') but never references alternative tools or scenarios where another tool would be more appropriate. No when-to-use or when-not-to-use information is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only mentions the need for id and changed fields and the option to pass a raw body, without explaining update semantics (partial vs full replacement), response structure, or side effects. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, with the purpose stated first. Every sentence adds some guidance, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters including nested objects and no output schema, yet the description provides only minimal invocation guidance. It lacks details about response format, error handling, and the interaction between 'body' and the structured fields, making it incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies the required 'id' and the concept of 'changed fields', and notes the 'raw body' option, but doesn't explain individual parameters like type or the structure of emails/phones/addresses beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update contact' which clearly identifies the action and resource, distinguishing it from sibling tools like create, get, and delete. It also specifies that an id is required, reinforcing the update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Provide id and changed fields', establishing when to use the tool (existing contact, modification). It doesn't explicitly mention alternatives or exclusions, but the context is clear for an update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the scope (all users accessible) but omits typical list behaviors such as pagination, ordering, active/inactive status, or response structure. The agent does not know if the list is complete, sorted, or includes disabled users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without any redundancy. It is front-loaded with the verb and resource, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple list operation, the description adequately conveys the core action and scope. However, without an output schema, it does not explain the returned data structure (e.g., user fields, whether the list is paginated). This is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is effectively 100%. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description adds no parameter details because none exist, but there is nothing to clarify beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and the resource 'all users accessible to the authenticated account'. This distinguishes it from sibling list tools by specifying the resource (users) and scope (accessible to the account). The title and name align, and no ambiguity exists about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like listTeams or userGroups.list. It does not mention use cases, contrasts with other list tools, or state any prerequisites or exclusions. The description is purely declarative without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It clearly states the mutation intent ('Create note') and gives an example of the payload, but it does not mention permissions, reversibility, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence plus a JSON example—with no unnecessary words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema, the description is adequate but minimal. The example helps clarify the request structure, but the lack of usage guidelines and behavioral details makes it only partially complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers most parameters with descriptions (67% coverage). The description adds a concrete example showing the structure for content and linked_to, which enhances clarity, but the body parameter is only briefly described and the example does not add much beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and resource 'note', clearly distinguishing it from sibling tools like notes.list, notes.get, and notes.update. The intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (creating a note) through the tool name and verb, but provides no explicit guidance on when to choose this over alternatives, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the transparency burden. It discloses the endpoint and what it verifies, which is helpful, but it does not describe the return format, success/failure behavior, or side effects (expected to be none). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of unnecessary words. It conveys the essential information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 largely sufficient. It could add a note about expected results (e.g., success indicates valid token), but it is complete enough for a health check utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. Per the rubric, a baseline of 4 is appropriate; no parameter descriptions are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a health check that verifies token and connectivity by hitting a specific endpoint (/v1/me). It is distinct from data operation siblings and unambiguously describes its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as a diagnostic step to verify token and connectivity before other API calls, but it does not explicitly state when to use it versus alternatives like wealthbox.getMe or wealthbox.request. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it lists all teams and scopes to the authenticated account, implying a read-only operation. However, it doesn't mention pagination, return format, or any side effects. For a list operation this is acceptable but not exhaustive, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the essential purpose without any filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 sufficiently conveys what the tool does. It could benefit from mentioning the return structure, but for a straightforward list operation, the current description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description doesn't need to explain parameters, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List,' identifies the resource 'teams,' and scopes to 'the authenticated account.' It clearly differentiates from siblings like contacts.list or tasks.list by explicitly naming teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context for use: retrieving all teams in the authenticated account. However, it doesn't explicitly mention when not to use it or alternatives, but since there is no other team-related sibling tool, the guidance is sufficient for the user to know when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. The verb 'Retrieve' and the phrase 'authenticated user' clearly indicate a safe read operation with no side effects, providing adequate transparency for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It front-loads the action and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, this description is complete. It clearly explains what the tool does and who it applies to, which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('login profile information'), and the scope ('for the authenticated user'). It is specific and distinguishes this from sibling tools like listUsers which list all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it is for the authenticated user, implying when to use it. However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wealthbox-mcp MCP server](https://glama.ai/mcp/servers/rhyeal/wealthbox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rhyeal/wealthbox-mcp)

Score Badge

Copy to your README.md:

[![wealthbox-mcp MCP server](https://glama.ai/mcp/servers/rhyeal/wealthbox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rhyeal/wealthbox-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rhyeal/wealthbox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server