monarch-mcp2

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Tools are grouped by domain prefix (e.g., accounts_, budget_), making them clearly distinct by area. However, within domains like budget_, there are many similar 'set_' tools (e.g., set_budget_amount, set_budget_group_amount) that could cause minor confusion, though entity names help differentiate.
Naming Consistency5/5
All tools follow a consistent <domain>_<action>_<entity> pattern in snake_case. No mixed naming conventions, abbreviations, or irregular verbs are present.
Tool Count3/5
With 125 tools, the set is very large. While the Monarch Money API is extensive, this count feels bloated and may overwhelm agents. Many tools are very specific (e.g., budget_set_*), suggesting bundled operations could reduce the count.
Completeness4/5
The tool set covers all major domains (accounts, budgets, categories, goals, investments, transactions, etc.) with CRUD operations for key entities. Some areas like cashflow are read-only, which is acceptable, but overall the surface is comprehensive.
Average 2.5/5 across 125 of 125 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 19, 2026
- 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?
Annotations already indicate read-only, idempotent, and non-destructive behavior, but the description adds no additional behavioral context, such as prerequisites or data scope.
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?
While extremely concise, the description is under-specified and fails to convey necessary information. Conciseness does not compensate for lack of substance.
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 three parameters and multiple sibling tools, the description is severely incomplete. It does not explain what a household is, what data is returned, or how to use the parameters effectively.
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 description does not mention any of the three parameters (fields, output_mode, session_path). Schema descriptions cover 67% of parameters, but the description adds no value beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get household' is a tautology, merely restating the title and tool name. It does not specify what aspects of the household are retrieved or the scope of the data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling tools like household_get_current_user or household_get_household_member. The description lacks context for appropriate invocation.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context (e.g., what fields are returned, authentication needs, or side effects), so it provides minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short (two words), the description is under-specified and omits essential information. True conciseness would include critical details about usage and parameters.
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 description is entirely insufficient for a tool with 4 parameters and no output schema. It does not describe return values, data shape, or any contextual information needed 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?
Schema description coverage is 50%: parameters goal_id and session_path lack descriptions. The description does not explain or add meaning to any parameters. It fails to compensate for the missing schema descriptions, leaving agents uncertain about how to use goal_id and session_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get goal' is a tautology that restates the tool name and title. It does not specify what kind of goal, what information is returned, or differentiate it from sibling tools like goals_list_goals or goals_get_goal_budget_amounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 goals_list_goals for listing multiple goals or goals_get_goal_budget_amounts for budget-specific data. The description lacks any context about appropriate use cases.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context (e.g., whether it returns summary vs. detailed data, or if it includes historical data).
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?
Extremely short but under-specified. Not concise in a helpful way—lacks necessary detail to guide usage.
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, no output schema, and low schema coverage, the description is vastly incomplete. It does not help the agent understand what data is returned or how to filter/hone results.
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 only 25% (2/8 params have descriptions). The tool description does not explain any parameters, failing to compensate for the gap.
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?
Description 'Get portfolio.' restates the name without adding specificity. It does not clarify scope (e.g., all accounts vs. a single portfolio) or differentiate from sibling tools like investments_list_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., investments_get_holding, investments_list_holdings). Missing context about prerequisites or typical use cases.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context, such as side effects, authentication needs, or rate limits, beyond what the annotations provide. It does not contradict but also does not enhance transparency.
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 brief at two words, but this brevity sacrifices necessary information. It is not appropriately front-loaded with key details; instead, it is under-specified and fails to earn its place in a minimal definition.
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 an output schema, the description should explain what the tool returns (e.g., security details). It does not, leaving the agent without critical context needed to interpret the response. The description is incomplete for a simple get operation.
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 description provides no information about any of the four parameters. With only 50% schema description coverage, the tool relies on the description to compensate, but it offers no explanation for parameters like security_id or session_path that lack schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get security' is a tautology of the tool's name and title. It does not specify what a 'security' is in this context or what exactly is retrieved, failing to provide a clear purpose beyond what is already evident from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its siblings such as investments_get_holding, investments_get_portfolio, or investments_search_securities. An explicit differentiation or context of use is entirely absent.
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?
The description adds no behavioral insights beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It fails to disclose details such as that it returns balances for specified accounts at a single date, or any constraints like the maximum date range. No contradiction with annotations.
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 one-sentence description is overly terse, bordering on useless. It lacks structure and essential detail, achieving brevity at the expense of 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?
Given the tool has 5 parameters, no output schema, and operates within a complex domain (account balances), the description is critically incomplete. It omits what data is returned, how filtering works, and the meaning of 'historical'.
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 only 40% of parameters having descriptions in the schema, the tool description must compensate but does not. It offers no additional meaning for parameters like 'filters' or 'balance_date', leaving the agent to infer from names alone.
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 'Get historical balances' is a tautology of the tool name and title. It fails to specify that it retrieves account balances at a past date, nor does it distinguish from sibling tools like accounts_get_account_history or accounts_get_net_worth_breakdown which also deal with historical financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, scenarios, or exclusions, leaving the agent without context for correct 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond that. It does not mention date range behavior or output characteristics.
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 but fails to be useful. It sacrifices all informative content for brevity, making it insufficient for an agent.
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 6 parameters, no output schema, and many sibling tools, the description is completely inadequate. It omits essential context about return values, date range semantics, and goal identification.
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 only 33%, and the description provides no additional meaning for any parameters. Required parameters like goal_id, start_month, and end_month lack any explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the same as the title and name, offering no additional clarity. It is a tautology that does not distinguish this tool from siblings like goals_get_goal or goals_set_goal_budget_amount.
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. With many goal-related siblings, the agent has no context to decide which tool 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral information, such as what budget data is returned or how it interacts with budgets. It provides minimal added value.
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 but not concise in a helpful way. It lacks structure and front-loading of key information. The single word 'budget' could be more meaningful if expanded.
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 4 parameters, no output schema, and siblings with similar names, the description is incomplete. It does not specify what the tool returns, how to use the month parameter, or any important notes. For a simple get operation, more context is needed.
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 4 parameters with 50% description coverage (fields and output_mode have descriptions, but month, which is required, lacks a description in both schema and tool description). The description does not explain any parameter meanings, so it fails to compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get budget' is a tautology that merely restates the tool name. It does not specify what kind of budget data is retrieved or distinguish it from sibling tools like budget_get_budget_category or budget_get_budget_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 budget_list_budget_months or budget_get_budget_category. The description lacks any context regarding prerequisites or appropriate scenarios.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows the tool is safe and non-mutating. However, the description adds no further behavioral context, such as the shape or aggregation of the summary, or any side effects. The description is essentially redundant with the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is far too concise for a tool with 6 parameters and a complex nested filter object. While conciseness is valued, this amount of under-specification harms usability more than it benefits brevity.
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—6 parameters, a nested filter object with multiple fields, required date range, and no output schema—the description is woefully incomplete. It does not explain what the summary contains, how it aggregates data, or how it relates to other recurring tools.
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 only 33% schema description coverage (only 'fields' and 'output_mode' have descriptions), the description should compensate by explaining the purpose of key parameters like start_date, end_date, and filters. It does none of this, leaving the agent to infer meaning solely from the parameter names.
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 'Get recurring summary' is extremely vague and barely adds value over the tool name. It does not specify what kind of summary (e.g., aggregated recurring transaction data) or how it differs from similar tools like recurring_get_recurring_stream, recurring_list_recurring_streams, or recurring_list_recurring_occurrences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 context is given about prerequisites, typical use cases, or exclusions. The sibling tools in the recurring group have more descriptive names, but the description fails to differentiate.
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?
While annotations already declare destructiveHint=true, the description adds only vague language ('may delete, clear, reset, or otherwise remove data') without specifying what data is affected (e.g., budget amounts, categories, rollover settings) or the scope (single month? all categories?).
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?
Two short sentences, but the first is redundant with the name and the second is vague. Lacks front-loading of critical information such as required parameters or effect.
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 destructive tool with 8 parameters and no output schema, the description fails to explain the tool's effect, required inputs, or how optional parameters influence behavior. Completely inadequate for reliable agent 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?
Schema coverage is only 25% (2 of 8 parameters have descriptions). The description provides no parameter information, leaving agents without guidance on the required 'month' parameter or optional ones like 'overwrite_existing'.
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 'Reset budget' is almost tautological with the tool name. It does not differentiate from sibling 'budget_clear_budget', and the vague elaboration adds no specificity about what exactly is reset or how it differs from similar operations.
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 on when to use this tool versus alternatives like budget_clear_budget or budget_create_budget. No context about prerequisites (e.g., budget existence) or exclusions.
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?
Annotations provide readOnlyHint, idempotentHint, and destructiveHint=false, which already indicate safe, idempotent read behavior. The description adds no additional behavioral context (e.g., pagination, return format), so it meets the baseline but does not enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is too brief; it is under-specification rather than concise. The description provides almost no information and does not justify its brevity with sufficient context elsewhere.
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 7 parameters, 2 required, and no output schema, the description is grossly incomplete. It does not explain the purpose of date ranges, the filtering options in RecurringFilterInput, or the output shape. Critical context is missing.
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 29%, leaving most parameters undocumented. The description does not mention any parameters or explain their roles, especially the required start_date and end_date. The description fails to compensate for the low schema coverage.
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?
Description 'List recurring occurrences' is vague and essentially restates the tool name without specifying what constitutes a 'recurring occurrence' or how it differs from sibling tools like 'recurring_list_recurring_streams'. The resource is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no context on required parameters like start_date and end_date, and no mention of prerequisites or use cases.
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 adds minimal behavioral context beyond what annotations provide. It only states it may create or update data, which is already implied by readOnlyHint=false. It does not describe the effect on split data, prerequisites, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, making it concise, but it sacrifices necessary detail. It consists of two brief statements with no structure beyond the opening. While no unnecessary text, it is too sparse to be effective.
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 an operation that modifies transaction splits, the description fails to explain what unsplitting accomplishes, the required state of the transaction, or the return value. With 4 parameters and no output schema, the description is severely incomplete.
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 tool description adds no parameter-level information. The schema partially describes fields and output_mode, but the required parameter transaction_id is undocumented. The description should clarify the role of transaction_id but fails to do so.
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 merely restates the tool name ('Unsplit transaction') without explaining what unsplitting entails or distinguishing it from other transaction modification tools like transactions_update_transaction or transactions_update_transaction_splits. The purpose is vague and essentially tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 transactions_update_transaction_splits or transactions_delete_transaction. No usage context, prerequisites, or conditions are mentioned.
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?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description adds no behavioral context. It does not disclose what data is returned, whether pagination occurs, or any other behavioral trait beyond what annotations already provide.
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 (four words) but this is under-specification, not conciseness. Key details like return shape, parameter roles, and usage context are missing, making it minimally useful.
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 no output schema and four parameters, the description provides no information about what the tool returns (e.g., list of transactions, balance summaries, or raw data). It is inadequate for an agent to correctly understand the tool's function and output.
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 50%, with account_id and session_path lacking descriptions. The description does not explain these parameters or clarify how they affect the 'history' output, failing to compensate for the schema's gaps.
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 'Get account history' is almost a tautology, simply restating the name and title. It does not distinguish this tool from siblings like accounts_get_historical_balances or accounts_get_account, leaving ambiguity about what 'history' entails (e.g., transactions, balance changes).
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 on when to use this tool versus alternatives. With siblings covering specific account data, historical balances, and net worth, the lack of usage context forces the agent to guess.
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 adds no behavioral information beyond what annotations already provide (readOnlyHint, idempotentHint, etc.). It does not explain what the breakdown entails, such as the grouping behavior or the meaning of 'breakdown', thus adding minimal value.
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 vague sentence that essentially repeats the title. While concise, it is under-specified and does not earn its place; useful information is missing.
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, nested filter input, enums, no output schema), the description is severely inadequate. It does not explain what the breakdown contains, how grouping works, or what the output shape is, leaving agents without crucial context.
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% (two parameters have descriptions). The tool description does not elaborate on any of the 8 parameters, including the required direction, start_date, end_date, or optional filters/group_by. With low schema coverage, the description fails to compensate.
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 'Get cashflow breakdown' is a tautology that restates the tool name. It fails to clarify what 'breakdown' means (e.g., by category, merchant, period) and does not distinguish it from sibling tools like cashflow_get_cashflow_summary or cashflow_get_cashflow_trends.
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 sibling tools include summary and trends variants, but the description offers no context on differences or when this breakdown is appropriate.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context, such as what data is returned or side effects. It does not contradict annotations.
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 (one sentence) but under-specified. It fails to provide essential information, making it ineffective rather than efficiently concise.
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?
Despite the tool having no output schema, the description does not explain what 'current user' means or what data is returned. Combined with the sparse description, the context is incomplete for a simple retrieval 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?
Schema coverage is 67% (2 of 3 parameters have descriptions in the schema). The description adds no meaning beyond the schema. The session_path parameter lacks any description in both schema and description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current user' is a tautology of the title 'Household Get Current User'. It does not specify what 'current user' refers to in the household context, nor does it distinguish from sibling tools like household_get_household or household_update_current_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 lacks any context about the intended use case or when it 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?
Annotations already indicate readOnlyHint, destructiveHint false, etc. Description adds no behavioral details (e.g., what data is returned, required permissions). Relies entirely on annotations which are present but no extra context.
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?
Extremely short (two words) but not effectively concise as it omits essential information. It fails to earn its place by adding value beyond the name.
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 no output schema, 4 parameters, and complex domain (investments), the description is critically incomplete. It provides no information about return values, pagination, or what constitutes a 'holding'.
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 50% (fields and output_mode have descriptions, holding_id and session_path do not). Description does not clarify any parameters, especially the required holding_id, leaving ambiguity for the agent.
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?
Description is essentially a tautology ('Get holding'). It restates the name without specifying what a holding is or distinguishing from sibling tools like investments_list_holdings or investments_get_holding_performance.
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 on when to use this tool vs alternatives such as investments_list_holdings or investments_get_holding_performance. No context about prerequisites or typical use cases.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, etc., but the description adds no further behavioral context (e.g., data freshness, rate limits). It does not contradict annotations.
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?
Extremely concise (two words) but under-specified. Key information is absent, making it ineffective.
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?
Complete lack of information on output format, filter usage, grouping behavior, and return structure. For a complex tool with 8+ parameters and no output schema, the description is drastically incomplete.
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?
Only 25% of parameters have descriptions in the schema, and the tool description adds no parameter explanations. The agent must rely on parameter names alone, which is insufficient given the complexity of filters and grouping.
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 'Get report data' is too vague. It does not specify what kind of report data or how it differs from related tools like reports_get_saved_report. The purpose is ambiguous.
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 on when to use this tool versus alternatives, such as reports_list_saved_reports or reports_get_saved_report. No prerequisites or context for 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds no behavioral context such as pagination, rate limits, or what actions are performed. It does not contradict annotations, but provides no added value.
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?
While concise (one sentence), the description is under-specified and wastes the opportunity to provide key information. It is not effectively structured or front-loaded.
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 has 7 parameters, a nested filter object with over 20 fields, no output schema, and many sibling tools, the description is completely inadequate. It provides no actionable context for correct usage.
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 coverage is low (29%), with only fields and output_mode having descriptions. The description fails to explain any parameters, not compensating for the weak schema. The complex TransactionFilterInput is entirely undocumented in the description.
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?
Description simply restates the name 'List transactions' without any differentiation from sibling tools like accounts_list_accounts or categories_list_categories. It fails to specify what kind of transactions, any scoping, or distinguishing features.
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 on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, implying a safe write operation. However, the description adds the vague 'may create or update' without clarifying the exact behavior, authorization needs, or side effects. Beyond the annotations, the description offers minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too short to be effective; it omits essential context. The second sentence 'This may create or update Monarch data' adds confusion rather than value. A more structured, front-loaded description would better serve the agent.
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 output schema, low schema coverage), the description is vastly incomplete. It leaves the agent without understanding return values, required parameter relationships, or the difference between creation and update scenarios. The description fails to compensate for missing structured information.
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?
With schema description coverage at only 22%, the description fails to explain the purpose or constraints of most parameters. It does not describe any parameter semantics beyond what is in the schema. The agent likely cannot infer correct usage for parameters like 'fields', 'balance', 'owner_user_id' etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create manual account' which identifies the action and resource, but the additional phrase 'This may create or update Monarch data' introduces ambiguity about whether this tool can also update existing accounts, which conflicts with the sibling tool 'accounts_update_account'. The purpose is partially clear but lacks precision.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives like 'accounts_update_account', nor does it explain prerequisites or consequences. The agent receives no context for tool 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context beyond what annotations provide, thus offering no extra value.
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 at two words, but it is under-informative. It sacrifices necessary detail for brevity, making it less useful for an agent.
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 4 parameters, no output schema, and only 50% schema coverage, the description is highly incomplete. It does not cover return values, behavior, or any context needed 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 description does not explain any parameters. Schema coverage is only 50%, with undocumented parameters like 'path' and 'include_token'. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Load session' states the verb 'load' and resource 'session', so the basic purpose is clear. However, it does not differentiate from sibling tools like auth_create_session or auth_save_session, which could also involve session management.
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 on when to use this tool versus alternatives. No context about prerequisites or typical use cases is provided.
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 adds no behavioral context beyond what annotations already provide (readOnlyHint, idempotentHint). It does not describe output shape, data scope, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the expense of necessary detail. A single sentence with no structure or partitioning of 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?
Given the tool's complexity (7 parameters, no output schema, multiple siblings), the description is severely incomplete. It does not explain what trends entail, available intervals, filtering options, or output modes.
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 only 29%, but the description provides no parameter details. It fails to compensate for the low coverage, leaving agents without guidance on parameters like filters, interval, or output_mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get cashflow trends,' which provides a verb and resource but is vague. It does not distinguish from sibling tools like cashflow_get_cashflow_breakdown or cashflow_get_cashflow_summary.
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 on when to use this tool versus siblings or alternatives. The description lacks context about use cases 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?
The description adds no behavioral context beyond what annotations already provide (read-only, idempotent, non-destructive). It does not disclose ordering, pagination, filtering, or return structure. With annotations covering safety, the description still fails to add any value.
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 it does not earn its place as it adds no information beyond the title. It is underspecified rather than efficiently concise.
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 operation with no output schema, the description should explain the return shape or behavior. It does not. Given the tool's simplicity and sibling context, the description is incomplete.
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 reference any of the three parameters (fields, output_mode, session_path). Schema coverage is 67%, but the description adds no additional meaning or hints about how to use the parameters effectively.
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 'List category groups.' is a tautology that merely restates the tool title without adding any specificity about what category groups are or how they relate to categories. It does not distinguish from siblings like 'categories_list_categories' or 'categories_get_category_group' beyond the resource name.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., when to list categories vs. category groups, or when to get a single group). There is no mention of prerequisites or 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. However, the description adds no additional behavioral context such as what data is returned, any rate limits, or authentication requirements. The lack of an output schema increases the need for description disclosure, which is absent.
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 but lacks substance. It does not contain any information that is not already evident from the tool's name and annotations. Effective conciseness would require meaningful content, which is missing.
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 6 parameters, no output schema, and no description of what 'holding performance' entails, the description is completely inadequate. An agent cannot infer required inputs, expected outputs, or how performance is calculated.
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?
With only 33% schema description coverage, the description adds no value for the parameters. It does not explain the purpose or format of 'start_date', 'end_date', 'holding_id', etc. The 'fields' and 'output_mode' parameters are described in the schema but the description ignores them entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'holding performance', but it merely paraphrases the tool name without providing distinguishing details. Sibling tools like investments_get_holding and investments_get_portfolio exist, but the description does not clarify what 'performance' specifically means or how it differs from these 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?
No usage guidelines are provided. There is no indication of when to use this tool versus alternatives, no prerequisites, and no context about typical use cases.
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?
Annotations already indicate readOnlyHint=false, so the description's statement 'may create or update' adds no new behavioral insight. No additional effects (e.g., idempotency, side effects on existing budgets) are disclosed beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise, but it is overly minimal given the tool's complexity. It lacks substance needed for effective agent usage, so while brief, it is not appropriately informative.
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 high parameter count, low schema coverage, absence of output schema, and many sibling tools, the description is severely incomplete. It does not cover return values, parameter details, or usage context, leaving the agent with insufficient information.
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?
With schema description coverage at only 25%, the description does not compensate by explaining any of the 8 parameters. It provides no meaning beyond the bare schema names, which is insufficient for an agent to correctly set parameters like 'fields', 'session_path', or 'apply_to_future'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Set budget amount' which matches the tool name and title, but it fails to differentiate from sibling tools like budget_set_budget_group_amount. The phrase 'create or update Monarch data' adds minimal context and does not specify which budget entity is being set (e.g., monthly category budget).
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 budget_set_budget_group_amount or budget_create_budget. The description lacks any context for selection, leaving the agent without 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'may create or update Monarch data,' which is consistent but doesn't disclose any additional behavioral traits such as side effects, authorization requirements, or what 'flex budget' implies. Minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but lacks essential detail. It is concise but at the cost of completeness, making it barely adequate.
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 has 7 parameters, no output schema, low schema description coverage, and no sibling differentiation, the description is severely incomplete. It fails to provide sufficient context 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?
Schema description coverage is only 29% (2 of 7 parameters have descriptions in the schema). The tool description does not mention any parameters or their meanings, leaving the agent to infer from parameter names alone, which is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set flex budget amount' which is a verb+resource pair, but it does not explain what a 'flex budget amount' is nor how it differs from other budget-setting tools like budget_set_budget_amount or budget_set_budget_group_amount. It is adequate but vague.
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 sibling budget tools, no prerequisites, and no context on scenarios where setting a flex budget is appropriate. It merely states what it does.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false. The description adds no additional behavioral context, but does not contradict annotations. With annotations present, the bar is lower; however, the description does not provide extra useful behavioral details.
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?
At 4 words, the description is extremely minimal but fails to provide necessary information. It is under-specified for a tool with 6 parameters and no output schema, making it inefficient rather than concise.
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 description is too brief to be complete. Given the tool's complexity (6 parameters, no output schema), it does not explain what the net worth breakdown contains, how filters work, or what output format to expect. The description leaves the agent with significant uncertainty.
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 only 33% (2 out of 6 parameters have descriptions). The description 'Get net worth breakdown' adds no meaning to parameters like filters, start_date, timeframe, or session_path. With low coverage, the description must compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get net worth breakdown' clearly identifies the action (get) and resource (net worth breakdown), but lacks specificity about what the breakdown includes. It does not distinguish it from the sibling tool 'accounts_get_net_worth_performance'.
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 accounts_get_net_worth_performance or other tools. There is no context on prerequisites or typical use cases.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate safe, idempotent read behavior. The description adds no behavioral context beyond the annotations, but does not contradict them.
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?
Extremely concise but under-specified. A single sentence of two words lacks critical information, crossing from conciseness into inadequacy.
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 is insufficient for the tool's role in a report ecosystem. No output schema, so return format is unknown. Sibling tools exist for related operations, but this description offers no context to differentiate or guide usage.
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 50% (fields and output_mode have descriptions, report_id and session_path do not). The description adds no parameter meaning, failing to compensate for the schema gaps.
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 'Get saved report' is nearly tautological with the tool name. It does not distinguish from sibling tools like reports_list_saved_reports (list) or reports_get_report_data (get data for a report), and provides no specific verb+resource detail beyond the name.
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 guidelines on when to use this tool versus alternatives like reports_get_report_data. No context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no behavioral traits beyond the annotations, such as listing all saved reports or noting any limitations.
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 too brief, consisting of a single sentence that adds no value. While concise, it lacks necessary details and appears under-specified.
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 3 optional parameters and no output schema, the description is incomplete. It does not explain the scope of the listing (e.g., all reports, user-specific) or the behavior of parameters like session_path.
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 high description coverage (67%) with meaningful descriptions for fields and output_mode. The description does not add parameter semantics beyond the schema, so it meets the baseline of 3.
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 restates the title ('List saved reports.') without adding any new information, making it essentially a tautology. It fails to differentiate from sibling tools like reports_get_saved_report or reports_get_report_data.
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 retrieving a single saved report or fetching report data. There are no exclusions or context for typical use cases.
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 adds that the tool 'may create or update' data, which is consistent with annotations (readOnlyHint=false). However, it does not disclose potential side effects, permission requirements, error conditions, or the nature of the update. Minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded, but it sacrifices clarity for brevity. It is concise but not sufficiently informative, earning a middle score.
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 an output schema, the presence of sibling tools, and four parameters, the description is grossly inadequate. It does not explain the tool's role in authentication, how to use the 'path' or 'session' parameters, or what the return value looks like. The agent cannot effectively invoke this tool based on this description alone.
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 tool description provides no parameter-level information. With 50% schema description coverage, the description should compensate but doesn't explain what 'path' or the 'session' object fields represent. The agent must rely solely on the schema, which lacks descriptions for critical parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Save session' which identifies a specific verb and resource, but fails to clarify what a session is in this context or how it differs from sibling tools like auth_create_session and auth_load_session. The mention of 'Monarch data' is confusing and doesn't align with the auth prefix.
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 on when to use this tool versus auth_create_session or auth_load_session. The description provides no context for appropriate usage scenarios or prerequisites, leaving the agent without decision support.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read operation. The description does not add behavioral context beyond that, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but it is too minimal for the complexity of the tool. It sacrifices informativeness 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 6 parameters, no output schema, and no explanation of return values or behavior. The description is insufficient for an agent to understand the tool's full functionality.
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 33% (2 of 6 parameters have descriptions). The description provides no explanation for parameters, failing to compensate for the low schema coverage.
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 'Get cashflow summary' is a vague verb+resource. It does not specify what the summary includes or how it differs from sibling tools like cashflow_get_cashflow_breakdown or cashflow_get_cashflow_trends.
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. The sibling tools suggest related functionality, but the description offers no context 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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover safety but not behavior. The description adds no additional behavioral context (e.g., return format, filtering).
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?
Extremely concise (4 words) but lacks essential details, making it under-specified rather than efficiently succinct. Not front-loaded with critical 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 4 parameters, no output schema, and annotations present, the description is too sparse to be complete. It omits return values, parameter interactions, and usage context.
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 50% (2 of 4 parameters described). The description does not mention any parameters or add meaning beyond the schema, failing to compensate for undocumented parameters like session_path and include_disabled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves the category catalog, but it lacks specificity compared to sibling tools like categories_list_categories. 'Catalog' is ambiguous and does not differentiate scope or structure.
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 on when to use this tool versus alternatives such as categories_get_category or categories_list_categories. Missing context for appropriate 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'This may create or update Monarch data,' which is largely redundant with the annotations. It omits behavioral details like side effects, required permissions, or return value behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but the second sentence is vague and not actionable. It could be restructured to front-load the primary action and provide more useful constraints.
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 tool with 9 parameters, 3 required, and no output schema, the description is severely incomplete. It fails to explain what a contribution is, how the goal and account parameters relate, or what the tool returns.
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 only 22% schema description coverage, the description should compensate but adds no parameter details. The schema provides some descriptions (e.g., for 'fields' and 'output_mode'), but the description does not enhance understanding or usage of the 9 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Contribute to goal' indicates a verb-resource action, but it is vague and does not specify what 'contribute' entails (e.g., adding funds, recording progress). It fails to differentiate from sibling tools like goals_create_goal or goals_update_goal.
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 goals_create_goal or goals_withdraw_from_goal. There is no mention of prerequisites or contextual constraints.
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?
Annotations indicate non-read-only behavior. The description adds 'This may create or update Monarch data,' which provides some transparency about side effects, but it lacks specifics on what exactly is created or updated and does not disclose potential consequences like overwriting existing links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at two sentences, which is concise but under-informative. It could include essential parameter details or usage context without becoming verbose.
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 (7 parameters, no output schema, low schema coverage) and the existence of sibling tools, the description is far from complete. It fails to explain the linking operation, parameter effects, return behavior, or when to use this tool over others.
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?
With only 29% schema description coverage and no parameter explanations in the description, the tool leaves seven parameters (including required ones like goal_id and account_id) completely unexplained. The description adds zero value to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Link goal account balance,' which is a verb+resource combination, but is vague and does not distinguish from sibling tools like 'goals_unlink_goal_account' or explain the linking concept. The added warning about creating or updating data provides minimal clarity.
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 prerequisites, context, or comparison to related tools such as 'goals_contribute_to_goal' or 'goals_withdraw_from_goal.'
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description does not add behavioral context beyond what is structured. It does not mention any specific behavior like return format or limitations.
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 (4 words), but this is under-specification rather than efficient conciseness. It omits essential information, making it insufficiently informative.
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?
Without an output schema, the description should explain return values, but it does not. It also does not address any edge cases or provide context about household member data. The tool is simple but the description leaves significant 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?
Schema description coverage is 50% (only 'fields' and 'output_mode' have descriptions). The tool description adds no parameter information, leaving 'member_id' and 'session_path' undocumented. It fails to compensate for the incomplete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get household member' states the verb and resource, but it is a near-tautology of the tool name. It lacks specificity and does not distinguish from sibling tools like 'household_list_household_members' or 'household_get_household'.
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, prerequisites, or how it compares to alternative tools (e.g., for listing or getting household info). The description offers no usage context.
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?
The annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds no additional behavioral context. It fails to add value beyond the 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) but lacks sufficient detail to be informative. It borders on underspecification, offering minimal value despite being brief.
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, but without an output schema, the description should explain what preferences are returned. It does not, leaving the agent without a complete picture of the tool's behavior.
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 coverage is 67%, with two of three parameters described. The description does not mention any parameters, nor does it explain the undocumented 'session_path' parameter, leaving gaps in understanding.
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 the tool retrieves household preferences with a specific verb and resource, making the purpose clear. However, it does not distinguish this from sibling tools like household_get_household or household_update_household_preferences, leaving potential ambiguity.
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 lacks context on its read-only nature, prerequisites, or any exclusions, leaving the agent without 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no further behavioral context, such as what the returned merchant object contains or any side effects. Given the annotations, the description misses the opportunity to clarify return structure.
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?
At two words, the description is excessively brief, sacrificing informativeness for conciseness. While brevity is valued, this level of underspecification hinders understanding.
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?
Without an output schema and with only a minimal description, the agent has no information about the structure of the returned merchant object. Given the complexity of the parameters and the presence of sibling tools, the description is incomplete.
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 50%, with 'merchant_id' and 'session_path' lacking descriptions. The tool description does not compensate by explaining these parameters. The agent must rely on schema alone, which is insufficient for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get merchant.' clearly indicates that the tool retrieves a merchant resource, but it fails to distinguish from sibling 'merchants_list_merchants', which also retrieves merchant data but multiple. The purpose is clear but could be more specific about scope.
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 'merchants_list_merchants' or 'merchants_update_merchant'. The agent is left to infer usage context from the name alone.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond what annotations provide. It does not mention side effects, authorization needs, or what the settings represent.
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, but it is under-specification, not conciseness. With three parameters and no output schema, more detail is needed. The single sentence adds minimal value.
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 output schema and incomplete parameter documentation, the description is incomplete. It does not explain what receipt settings are or what the tool returns, leaving the agent with insufficient context.
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 67% (two of three parameters documented in schema). The description adds no parameter-specific information. For the undocumented session_path parameter, the description offers no help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get receipt settings' has a verb and resource, but it is a tautology of the tool name and title. It does not explain what 'receipt settings' are or differentiate from siblings like receipts_update_receipt_settings or receipts_get_receipt.
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 context, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context (e.g., no side effects, no mention of required permissions). With annotations, the bar is lower, but the description contributes minimal value beyond what is already structured.
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 ('Get transaction.'), but it is also under-specified and adds no information beyond the title. While not verbose, it sacrifices clarity and utility for brevity.
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 has 5 parameters (1 required), no output schema, and moderate complexity, the description is grossly incomplete. It fails to explain parameter usage, return values, or any contextual details. Annotations provide safety info, but the description does not fill remaining gaps.
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 40% (fields and output_mode have descriptions). The tool's description does not explain any parameter semantics, such as the format of transaction_id, the meaning of session_path, or the effect of redirect_posted. It adds no value 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 states the verb 'Get' and resource 'transaction', clearly indicating retrieval of a single transaction. It distinguishes from sibling tools like transactions_list_transactions (list) and transactions_update_transaction (update). However, it does not specify what is returned or the scope beyond the title.
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 on when to use this tool versus alternatives such as transactions_list_transactions or transactions_get_transaction_splits. There is no mention of prerequisites, 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?
The description says 'may create or update Monarch data,' but this is vague. Annotations indicate non-read-only and non-destructive, but the description does not disclose important behavioral traits such as idempotency, side effects (e.g., overwriting existing budget), permissions required, or whether it triggers downstream effects like rollovers. The 'openWorldHint' true suggests additional side effects, but these are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices clarity. It could be restructured to include key information without increasing length significantly. The title 'Budget Create Budget' is redundant.
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 4 parameters (1 required), no output schema, and many sibling tools, the description is insufficient. It does not explain what a budget is, the creation process, return values, or error conditions. The user cannot determine whether the tool is appropriate without additional context.
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 description coverage is 50% (fields and output_mode have descriptions, month and session_path do not). The description adds no parameter-specific meaning; it only says 'Create budget.' The 'month' parameter is essential but only has a title 'Month' with no format or constraints explained. The 'session_path' parameter is completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create budget' which identifies the action, and the required 'month' parameter suggests creating a budget for a specific month. However, it does not clarify if this creates a new budget record or updates an existing one, and it fails to distinguish from sibling tools like 'budget_set_budget_amount' or 'budget_get_budget'. The phrase 'may create or update Monarch data' adds ambiguity.
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 sibling tools include many budget-related actions (set amounts, get budget, reset budget, etc.), but the description does not specify scenarios or prerequisites. For example, it does not clarify whether creating a budget requires a month to exist or what happens if it already exists.
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?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, which the description does not contradict. The description adds no behavioral context beyond what annotations provide, such as error handling or output format, but it is not misleading.
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 brief (two words), but fails to include essential details. Conciseness should be efficient, not sparse; this is under-specified rather than optimally concise.
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 an output schema and the moderate parameter count (5, with 2 required), the description should provide more context about return values and parameter usage. The current description leaves significant gaps for the agent to fill.
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 40% coverage (fields and output_mode have descriptions), but the description adds nothing about the required parameters month and category_id. The lack of explanation for these fields means the agent must infer their formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get budget category' is minimal but conveys a specific verb and resource. However, it does not differentiate this tool from siblings like budget_get_budget or categories_get_category, leaving ambiguity about what a 'budget category' is in this context.
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 or exclusions, leaving the agent to infer usage from the name alone.
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?
Annotations already indicate destructiveHint=true, and the description echoes this with 'may delete, clear, reset, or otherwise remove data'. However, it lacks specificity about what exactly is removed, which rollovers are affected, and whether parameters like category_id scope 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two short sentences), but the second sentence is redundant and vague. It is front-loaded but could be more informative without increasing length.
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 7 parameters, no output schema, and destructive nature, the description fails to provide sufficient context. It does not explain how parameters interact, what returns are expected, or how this differs from sibling tools.
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 description adds no value to the input schema. With only 29% schema description coverage, the required parameter 'month' and key parameters like 'category_id' have no explanation in the description. The tool's core behavior is left vague.
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 'Reset budget rollover', clearly indicating the action and resource. It differentiates from siblings like 'budget_reset_budget' which resets the entire budget, but does not elaborate on what exactly 'reset' means, leaving some ambiguity.
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 explicit guidance on when to use this tool versus alternatives like 'budget_set_budget_rollover' or 'budget_reset_budget'. The description implies use for resetting rollovers but does not provide usage context or exclusions.
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?
Annotations already indicate it's not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it 'may create or update Monarch data,' which confirms the mutation behavior. This adds some value beyond annotations but doesn't disclose specific side effects or authorization needs.
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 vague sentence. While concise, it lacks important details and is not well-structured (no bullet points, no parameter breakdown).
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 high parameter count (11), no output schema, and minimal description, the tool definition is severely incomplete. It does not explain what rollover does, how parameters interact, or what the result looks like.
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?
With 11 parameters and only 18% schema description coverage, the description provides no explanation of any parameters. It fails to add meaning beyond the input schema, leaving the agent to infer parameter semantics from names alone.
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 that the tool sets budget category rollover and may create or update data. It distinguishes itself from sibling tools like budget_set_budget_group_rollover by focusing on category-level rollover, but it doesn't define 'rollover' itself.
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 (e.g., budget_reset_budget_rollover, budget_set_budget_group_rollover). No context about prerequisites or typical use cases is provided.
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 annotations already declare destructiveHint=true, so the description merely restates that fact without adding new behavioral insights. No mention of side effects, required permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the second sentence is vague and adds noise without value. It could be improved by being more precise rather than adding redundant qualifiers.
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 destructive tool with 5 parameters and no output schema, the description is woefully inadequate. It fails to explain what happens to categories within the group, the effect of move_to_group_id, or the behavior of other parameters.
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 only 40%, and the description adds no explanation for any parameter. Critical parameters like group_id and move_to_group_id are left completely undocumented.
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 'Delete category group' which is a specific verb+resource. It distinguishes from siblings like 'categories_remove_category' as it targets a group, not an individual category. However, the additional vague phrase 'This may delete, clear, reset, or otherwise remove data' adds confusion without clarifying what actually happens.
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 on when to use this tool vs alternatives, no prerequisites mentioned. The description is purely operational and does not provide context for appropriate 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds 'This may delete, clear, reset, or otherwise remove data,' which is vague and does not clarify the specific behavior (e.g., whether transactions are moved or deleted). It fails to disclose side effects beyond the obvious destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), but the second sentence is vague and wastes words. It could be more concise by removing the redundant phrasing and instead focusing on key behavior or parameters. It is not efficiently 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 the tool has 5 parameters, one required, and no output schema, the description is incomplete. It does not explain the core action (permanent removal? moving transactions?), and it ignores important context like the role of move_to_category_id. The description fails to provide a complete understanding for an 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?
Schema coverage is 40%, with only fields and output_mode having descriptions. The description does not mention any parameters, so it provides no additional meaning for undocumented parameters like category_id and move_to_category_id. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove category,' which clearly identifies the action and resource. However, the second sentence 'This may delete, clear, reset, or otherwise remove data' is confusing and ambiguous, detracting from clarity. The tool is distinguishable from siblings like categories_delete_category_group, but the description does not explicitly differentiate it.
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 prerequisites, when not to use it, or what to use instead (e.g., deactivating via categories_reactivate_category). The parameter move_to_category_id suggests an important workflow, but it is not explained.
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?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds 'may create or update,' which is vague and could imply creation despite the tool name. No additional behavior (e.g., auth needs, reversibility) is disclosed.
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 (one sentence), which is concise and front-loaded. However, it sacrifices useful detail. It is well-structured for brevity but could be improved by adding more structured information without increasing length significantly.
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 six parameters, a required group_id, no output schema, and the complexity of category group management, the description is highly incomplete. It does not explain what a category group is, what the parameters do, what the return value looks like, or how this tool fits into the broader workflow. The agent would be severely underinformed.
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 33%, meaning only 'fields' and 'output_mode' have descriptions. The tool description does not explain any parameter beyond what the schema provides. For parameters like 'group_id', 'name', and 'type', the agent must infer meaning from context; the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update category group,' which is a clear verb+resource. However, it adds 'This may create or update Monarch data,' creating ambiguity since there is a separate 'categories_create_category_group' sibling tool. The agent might be confused whether this tool can create groups or should only update existing ones.
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 its siblings, such as 'categories_create_category_group' or 'categories_delete_category_group'. The agent receives no context about prerequisites, typical use cases, or when not to use this 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?
Annotations show non-read-only and non-destructive, but the description only adds 'may create or update Monarch data', a generic statement that does not explain the specific state change (e.g., setting an 'archived' flag). No mention of reversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), but the second sentence is vague and unhelpful. It could be restructured to prioritize the effect of archiving over the generic data creation/update statement.
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 four parameters, no output schema, and similar sibling tools, the description is incomplete. It lacks explanation of return values, the effect on the goal's state, and parameter details beyond what the schema provides.
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 reference any parameters. Although schema description coverage is 50% (fields and output_mode have descriptions), the required goal_id lacks explanation. The description should clarify that goal_id identifies the goal to archive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Archive goal', a specific verb+resource, but does not clarify what archiving means (e.g., marking as inactive) versus deleting or restoring. The vague second sentence about creating/updating data adds confusion and fails to distinguish this tool from siblings like goals_delete_goal.
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 goals_delete_goal or goals_restore_goal. Prerequisites (e.g., goal must exist, cannot already be archived) are omitted.
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?
Annotation already indicates readOnlyHint=false. Description adds minimal context ('may create or update') but is vague and doesn't disclose side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient but second sentence is vague. Could be more precise without extra 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 12 parameters and no output schema, the description is too sparse. Lacks explanation of return values, creation behavior, or parameter relationships.
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 17%, leaving most parameters undocumented. Description provides no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create goal' but adds vague 'may create or update Monarch data' which confuses the purpose. Does not distinguish from goals_update_goal.
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 on when to use this tool vs alternatives. Does not specify 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is safe and non-destructive. The description adds no additional behavioral context (e.g., pagination, default output, filtering behavior) beyond what annotations provide.
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?
At two words, the description is extremely concise but under-informative. It lacks essential structure such as a usage note or parameter hints. Conciseness should not come at the cost of 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 tool with 4 parameters (0 required) and no output schema, the description 'List goals' is grossly incomplete. It omits details about what is returned, how the parameters affect behavior, and how to handle common use cases like including archived goals.
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 50%, meaning two of four parameters have descriptions. The description 'List goals' does not explain any parameter semantics or provide examples. It fails to clarify how parameters like include_archived or output_mode affect results, leaving the agent to rely solely on 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 'List goals,' identifying the verb (list) and resource (goals). This distinguishes it from sibling tools like goals_get_goal (single) or goals_archive_goal (action). However, it lacks specificity about scope (all goals, active only) and does not mention the include_archived parameter.
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 on when to use this tool versus alternatives. Sibling tools include goals_get_goal for individual goals and goals_list_goal_events for events, but the description does not differentiate or provide selection criteria.
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?
Annotations indicate readOnlyHint=false, so the description's note 'may create or update Monarch data' adds minimal value. Additional behavioral details (e.g., side effects on goal progress, account balances, or budget) are absent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but at the cost of completeness. The second sentence is vague ('This may create or update Monarch data') and does not earn its place. A balance of brevity and informativeness is missing.
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 output schema, many sibling tools), the description is severely incomplete. It fails to explain return values, necessary preconditions, or the effect on related entities. Agents cannot make informed decisions to invoke this tool from the description alone.
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 low (22%), but the description provides no information about any of the 9 parameters. Parameters like goal_id, account_id, amount, date, notes, include_in_budget are left unexplained, forcing the agent to rely solely on parameter names.
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 'Withdraw from goal'. The verb is specific, but it does not differentiate from sibling tools like 'goals_contribute_to_goal' or 'goals_delete_goal'. However, the purpose is directly understandable.
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 on when to use this tool versus alternatives. No prerequisites, conditions, or context for proper invocation are provided. The description lacks instructions on when a withdrawal 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?
Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds 'may create or update Monarch data' but does not clarify the conditions for creation vs. update, nor disclose side effects like overwriting fields or permission requirements. The description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the primary action. However, the second sentence is non-essential and potentially confusing. It could be improved by removing ambiguity or adding structured 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?
With 7 parameters, no output schema, and only minimal annotations, the description is insufficient. It does not explain what a manual holding is, how updates are applied (additive vs. full replacement), or what the agent should expect as a result. More context is needed for reliable tool selection and 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?
Schema description coverage is only 29% (2 of 7 parameters have descriptions). The tool description does not explain the meaning or usage of any parameters (e.g., quantity, cost_basis, security_type). It fails to compensate for the low schema coverage, leaving key parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update manual holding', which identifies a specific verb and resource, distinguishing it from sibling create and delete tools. However, it adds ambiguity by saying 'This may create or update Monarch data', conflicting with the tool's name and potentially misleading the agent about its primary purpose.
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 (e.g., investments_create_manual_holding). The description does not state prerequisites, consequences, or relative positioning among siblings, leaving the agent to infer usage 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?
Annotations already declare destructiveHint=true. The description adds vague terms like 'may delete, clear, reset' which could mislead about the operation's side effects. It fails to explain the key behavior of optionally moving data to another merchant via move_to_merchant_id, which is a critical behavioral trait beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains unnecessary vagueness in the second sentence. It is not front-loaded with the most important information (like the move-to option). While concise, it sacrifices clarity.
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 five parameters, no output schema, and a missing explanation of the move_to_merchant_id functionality, the description is incomplete. It does not prepare the agent for optional behaviors or return values, leaving significant gaps in understanding.
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 only 40%, and the description adds no additional meaning for any parameter. It does not mention the important move_to_merchant_id parameter, which allows reassigning data instead of deleting. The parameter descriptions in the schema are minimal, so the description should compensate but 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 states 'Delete merchant' which is a clear verb+resource pair. However, the following phrase 'This may delete, clear, reset, or otherwise remove data' introduces ambiguity about the exact action, lowering the score from 5. It distinguishes well from sibling tools like get and update.
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 merchants_update_merchant or merchants_get_merchant. There is no mention of prerequisites, conditions for deletion, or the optional move_to_merchant_id parameter that affects 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?
Annotations already provide readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context such as pagination, sorting, or filtering behavior. The description is essentially empty beyond the name.
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 (three words) but at the expense of necessary information. It is not front-loaded with useful details and is insufficient for a tool with seven parameters.
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 seven parameters and no output schema, the description is far from complete. It does not explain pagination, sorting, output modes, or the scope of the list. Annotations provide some context but are not enough.
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 only 29%, with only the 'fields' parameter having a description. The description 'List merchants' adds no meaning to the six undocumented parameters. It fails to 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 merchants' clearly conveys a specific verb and resource. It is unambiguous but does not differentiate from sibling tools like merchants_get_merchant or other list 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 on when to use this tool versus alternatives. No exclusions or context provided. The description is too minimal for effective decision-making.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover safety and behavior. The description adds no additional behavioral context, but given the rich annotations, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words), but it is under-specified. It does not earn its place as it omits crucial information; conciseness is not justified by quality.
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 4 parameters, no output schema, and numerous sibling tools, the description is far too minimal. It does not explain return values, behavior, or how it differs from similar tools, leading to an incomplete specification.
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 any parameters. Schema coverage is 50% (fields and output_mode have descriptions, but receipt_id and session_path lack them). The description fails to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get receipt' clearly states the verb and resource, but is very brief and does not differentiate from sibling tools like 'receipts_list_receipts' or 'receipts_get_receipt_settings'. It is functional but lacks specificity.
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. No context on prerequisites, constraints, or explicit when-to-use/when-not-to-use information 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context, such as what happens if the stream isn't found or whether it returns raw data. However, it does not contradict annotations. Given annotations, the description is minimally adequate.
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?
Extremely short (3 words), but at the cost of informativeness. The description is under-specified and does not effectively use the space to convey important details.
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 5 parameters, no output schema, and many sibling tools, the description is highly incomplete. It fails to explain what a recurring stream is, what data is returned, or how to handle the parameters. This is insufficient for effective agent 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?
Schema description coverage is 40% (only fields and output_mode have descriptions). The tool description provides no parameter details, failing to compensate for the missing descriptions of recurring_id, session_path, and include_liabilities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recurring stream' provides a verb and resource, but it is vague. It does not distinguish this tool from siblings like 'recurring_list_recurring_streams' or 'recurring_get_recurring_summary'. The required parameter 'recurring_id' implies it fetches a single stream, but the description doesn't clarify.
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 on when to use this tool vs alternatives. The sibling list includes other recurring stream operations, but the description gives no context about using 'get' vs 'list' or 'summary'. An agent would lack direction.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat that. However, the description adds no additional behavioral context (e.g., pagination, sorting, or what fields are returned by default). It is adequate given annotations but still minimal.
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 only three words, which is concise but under-specified. While it avoids tautology, it does not add enough value to earn its place; it is too brief to be helpful.
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 has 6 parameters including a complex RecurringFilterInput, output modes, and flags, the description is entirely insufficient. It does not mention filtering capabilities, output modes, or default behavior. Annotations provide some context but the description is not complete enough.
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 33% (only 'fields' and 'output_mode' have descriptions). The description does not explain the purpose of filters, session_path, include_pending, include_liabilities, or the RecurringFilterInput structure. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List recurring streams' clearly states the verb and resource, but it is generic. Among sibling tools like 'recurring_get_recurring_stream' and 'recurring_get_recurring_summary', it does not differentiate itself beyond the word 'list'. The purpose is clear but lacks 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 about when to use this tool versus other recurring tools like 'recurring_get_recurring_stream' or 'recurring_get_recurring_summary'. There is no mention of filters, output modes, or typical use cases.
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?
Annotations indicate readOnlyHint=false and openWorldHint=true. The description adds that it 'may create or update Monarch data', which is vague and does not clarify specific side effects, data scope, or permissions needed. More detail is required.
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 short (two sentences) and front-loaded with the action. However, the phrase 'may create or update' is somewhat redundant and could be more precise. Still efficient overall.
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 8 parameters, no output schema, and limited annotations, the description is too minimal. It does not explain what a recurring stream is, which parameters are most important, or the outcome of the update. More context is needed for effective tool 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 description does not explain any parameters. Schema coverage is only 25% (fields and output_mode have descriptions). The description fails to add meaning for the remaining six parameters, leaving the agent without clarity on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update recurring stream' which is a clear verb+resource, but it adds 'may create or update Monarch data' which blurs the distinction with the sibling create tool. It does not differentiate from recurring_create_recurring_stream.
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 creating or removing recurring streams. Sibling tools exist for creation and removal, but the description offers no contextual usage advice.
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?
Annotations indicate readOnlyHint=false, so it's a write operation. The description adds 'may create or update' which is ambiguous—does it create a new report or update an existing one? No further disclosure of side effects, permissions, or behavior is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise, but it lacks necessary information. It is not verbose, but its brevity leads to incompleteness.
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 7 parameters including a complex nested object (filters) and no output schema. The description does not explain what the tool returns, how filters work, or the effect of output_mode. This is insufficient for 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?
Schema description coverage is only 29% (2 of 7 parameters have descriptions). The tool description does not explain any parameter's meaning or usage. The schema itself provides minimal descriptions; the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create saved report' which is a specific verb+resource, but it does not distinguish from the sibling tool 'reports_update_saved_report'. The added phrase 'This may create or update Monarch data' is ambiguous, blurring the purpose.
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 reports_update_saved_report or reports_get_saved_report. The description does not mention context, 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'may create or update' but does not explain behavioral traits beyond what annotations provide, such as idempotency or side effects. With annotations carrying the burden, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short at 10 words, but the phrase 'may create or update' is ambiguous and could be misleading. It is not optimally concise because it introduces unnecessary confusion. Could be improved by stating 'Create a new tag' to avoid ambiguity.
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?
No output schema, yet the description does not mention what is returned. It does not explain the effect on 'Monarch data' or how to interpret results. For a creation tool, this is incomplete. The context signals indicate complexity; the description fails to provide a complete picture.
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 40% (name and color lack descriptions). The tool description does not mention any parameter details. It adds no meaning beyond the schema for the required parameters. Low coverage requires compensation, which is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create tag' which is a clear verb+resource, but adds 'This may create or update Monarch data' which introduces ambiguity about whether it can also update. This could confuse the agent, especially given sibling tags_update_tag. The purpose is somewhat clear but lacks specificity.
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 on when to use this tool versus alternatives like tags_update_tag. The description does not mention prerequisites or context. The agent has no information to decide between create and update.
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 annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds 'may delete, clear, reset, or otherwise remove data,' which is vague and doesn't clarify whether deletion is permanent or if related data (e.g., attachments) is affected. No mention of required permissions or irreversible consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices clarity for brevity. It front-loads the purpose but then adds confusing qualifiers. Could be improved by removing the vague 'may' list.
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 output schema, incomplete parameter documentation, and no behavioral details beyond annotations, the description is insufficient for an agent to fully understand the tool's effect, response, and 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?
Schema description coverage is only 50%, with transaction_id and session_path lacking descriptions. The tool description does not explain any parameter semantics. An agent cannot infer from the description alone how to properly fill in required or optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete transaction', which clearly identifies the core action. However, it then adds 'This may delete, clear, reset, or otherwise remove data,' introducing ambiguity about the exact effect. The name and title already indicate deletion, so the extra wording diminishes clarity.
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 transactions_update_transaction or transactions_unsplit_transaction. The description does not mention prerequisites, side effects, or context-sensitive 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?
Annotations declare readOnlyHint true, but the description adds no behavioral details beyond that. It doesn't mention that the tool returns a file or any side effects, leaving the agent guessing about the exact behavior.
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 under-specified. It consists of only three words, which is too brief to be helpful. Conciseness should not come at the cost of necessary detail.
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 complexity of 5 parameters, no output schema, and multiple sibling tools, the description fails to provide complete context. It does not explain the return shape, the meaning of parameters, or how the tool differs from related ones.
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 description adds no information about parameters. With only 40% schema description coverage, the description should compensate for missing parameter documentation, 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 states the verb 'download' and resource 'transaction attachment.' However, it does not clarify what 'download' entails (e.g., file content vs. URL), and it fails to distinguish from the sibling tool 'transactions_get_transaction_attachment.'
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 usage guidelines are provided. The description gives no context on when to use this tool over alternatives like 'get_transaction_attachment' or 'upload_transaction_attachment.'
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?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds no behavioral context beyond what annotations provide. It does not mention what the tool returns or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, which is not wasteful but also not informative. It could be longer to add necessary context without becoming verbose.
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, the description should explain return values. It does not. The tool has 4 parameters and is read-only, but the description gives no indication of what the agent can expect, making it incomplete.
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 50%, with session_path undocumented. The description adds no parameter information. It fails to compensate for missing schema details, leaving agents unclear about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transaction attachment' specifies a verb and resource, but is vague. It does not clarify whether it retrieves metadata, content, or a URL, leaving ambiguity with sibling tools like transactions_download_transaction_attachment.
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 on when to use this tool versus alternatives like list or download. No prerequisites or context provided. The description is purely a tautology of the title.
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 adds only 'This may create or update Monarch data,' which is already implied by readOnlyHint=false annotations. No additional behavioral traits (e.g., session management, token handling) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is too vague for a tool with 8 parameters and authentication semantics. Conciseness comes at the cost of 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 description fails to cover the authentication flow, return behavior, or the function of critical parameters. For a tool with no output schema and high parameter count, this is severely incomplete.
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 only 25% schema description coverage, the description does not explain the purpose of key parameters like email, password, mfa_code, or session_path. The agent must rely on parameter names alone.
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 'Create session' with a clear verb and resource. However, it does not differentiate from sibling tools like auth_load_session and auth_save_session, which could confuse the agent on which tool to use.
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, nor any prerequisites or authentication flow context. The agent is left to infer usage from the name alone.
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?
Annotations already indicate non-read-only and open world behavior. The description adds 'may create or update', but does not elaborate on side effects, permissions, or reversibility. With annotations present, the description could add more value but doesn't.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, which is efficient for simplicity. However, it is too sparse to be judged as well-structured; it lacks essential details, so conciseness comes at the cost of 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?
With 8 parameters, no output schema, and a complex financial domain (budget rollover), this minimal description is inadequate. It does not explain the concept of rollover, expected inputs, or the effect of changes, making it insufficient for correct tool usage.
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 low (25%). The description does not explain critical parameters like category_group_id, enabled, rollover_type, or starting_balance. It fails to compensate for the under-documented schema, leaving parameter meanings unclear.
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 the verb 'set' and resource 'budget group rollover', and adds that it may create or update data, making the purpose clear. However, it does not differentiate from siblings like budget_set_budget_category_rollover or budget_reset_budget_rollover, which have similar names and purposes.
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 lacks context on prerequisites, typical scenarios, or exclusions, leaving the agent without decision support.
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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds 'may create or update' but doesn't clarify side effects like balance updates, authorization needs, or idempotency. Beyond annotations, it provides little behavioral context.
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?
Extremely concise (one sentence) but at the expense of usability. Lacks structure and important details like parameter guidance or response format. Every sentence does not earn its place due to under-specification.
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 12 parameters, 5 required, no output schema, and sparse annotations, the description is too brief. It doesn't cover common use cases, return values, or error conditions. Incomplete for a create tool of this complexity.
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 has 12 parameters with only 17% description coverage (fields and output_mode have descriptions). The tool description does not explain any parameters, missing the opportunity to clarify common optional fields like notes, goal_id, or should_update_balance. For low coverage, description should compensate but fails.
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 'Create transaction' which is a specific verb+resource. However, it adds ambiguity with 'This may create or update Monarch data.' Since the tool name is create and there is a separate update tool, this could mislead. Still, the primary purpose is clear.
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 on when to use this tool vs. alternatives like update_transaction. No when-not-to-use or prerequisites provided. The description is too minimal to guide 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond these, such as what data is returned or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, but this brevity sacrifices informativeness. It is appropriately sized for a simple tool but lacks essential details.
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 is incomplete for a tool with 4 parameters, especially with no output schema. It does not cover return values, parameter relationships, or usage examples, leaving significant gaps despite available annotations.
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 50% (fields and output_mode have descriptions, but account_id and session_path do not). The description does not explain any parameters, missing an opportunity to compensate for the schema gaps.
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 'Get account,' which clearly indicates the action and resource. However, it does not differentiate from sibling tools like accounts_get_account_history or accounts_get_historical_balances, which also retrieve account-related data.
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 or when not to use this tool compared to alternatives. There is no mention of prerequisites, context, or exclusions.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral context such as how performance is calculated or what data is aggregated, but it does not contradict annotations. With annotations covering safety, a mid-range score 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but this is not a virtue when it sacrifices clarity and completeness. It lacks structure and front-loading of key 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?
With 7 parameters, no output schema, and a complex financial metric, the description is woefully incomplete. It does not explain what 'performance' means, what the tool returns, or how filters and date ranges affect the output.
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 29%, meaning most parameters lack description. The tool description does not explain any parameters or their roles. For example, start_date, end_date, and filters are not mentioned, so the description adds no value beyond the schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get net worth performance' provides a verb and resource, but 'performance' is vague and does not distinguish clearly from sibling tools like accounts_get_net_worth_breakdown or accounts_get_historical_balances. It lacks specificity on whether it returns returns, growth rates, or other metrics.
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. The description does not mention filtering by accounts, date ranges, or any context that would help the agent decide when to invoke 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. However, the description does not add any behavioral context beyond that, such as mention of pagination, filtering capabilities, or the output_mode parameter which controls data shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words), which is acceptable for a simple operation but lacks structure. Given the presence of multiple parameters and options, a few more sentences would improve clarity without being verbose.
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 4 parameters including optional filters and output modes, yet the description provides no context on how to use these or what the result looks like. No output schema exists, so the description should compensate, but it does not.
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 50% (fields and output_mode have descriptions; filters and session_path do not). The description 'List accounts' adds no explanation of any parameter, leaving the agent to rely solely on the schema without additional context.
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 accounts, which is a specific verb+resource. However, it lacks any details about scope (e.g., all accounts, filtered accounts) and does not distinguish from sibling tools like accounts_get_account, though no sibling directly conflicts.
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 accounts_get_account for a single account or other list tools. The description is too brief to convey appropriate usage 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the behavioral profile is covered. The description adds no extra behavioral context (e.g., rate limits, pagination, response structure). Given annotations, a score of 3 is appropriate; the description meets the minimum but adds no value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, which is extremely concise but under-specified. It lacks necessary context for a tool with 5 parameters. While front-loaded, it does not earn its place by providing useful information beyond the title.
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 5 parameters, no output schema, and only 40% schema coverage, the description is too sparse. It does not explain what holdings are listed, how account_ids or include_hidden_holdings affect results, or what output_mode does. Annotations cover safety but not functional completeness.
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 coverage is 40% (only fields and output_mode have descriptions). The description 'List holdings' does not explain any parameter. Parameters account_ids, session_path, and include_hidden_holdings are left completely undocumented by both schema and description. The description fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List holdings' specifies a verb and resource, which is clear but vague. It distinguishes from 'get_holding' (single) and 'create_manual_holding' etc., but does not specify scope (e.g., all holdings, per account, filtering). The purpose is understood but not nuanced.
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 usage guidelines are provided. The description does not state when to use this tool vs alternatives like investments_get_holding or investments_get_portfolio. The agent must infer context from sibling names alone.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, which inform the agent that the tool is safe, idempotent, and returns results from an open world. The description adds no further behavioral context (e.g., pagination, result format, likelihood of empty results). With annotations covering the core safety traits, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), but this brevity comes at the cost of substance. It lacks front-loaded key information about scope, parameters, or output. A description should be as short as possible but not shorter; this one is under-specified.
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 has 6 parameters, no output schema, and moderate schema descriptions, the description is grossly incomplete. It does not clarify what constitutes a 'security', how search results are ordered (though a parameter hints at popularity), or what fields are returned. The agent cannot reliably determine how to invoke or interpret results from this description alone.
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 33% (2 of 6 parameters have descriptions). The tool description 'Search securities' adds no additional meaning for the undocumented parameters like 'limit', 'query', 'order_by_popularity', and 'session_path'. It fails to compensate for the low coverage, leaving the agent without guidance on how to use these parameters effectively.
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 'Search securities' clearly states the verb (search) and resource (securities), which is specific enough to distinguish it from sibling tools like 'investments_get_security' that retrieve a single security. However, it does not elaborate on what aspects are searchable (e.g., name, ticker), which would improve clarity further.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'investments_get_security' or 'investments_list_holdings'. It lacks any context about prerequisites or typical use cases.
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?
Annotations already indicate destructiveHint=true. The description adds 'This may delete, clear, reset, or otherwise remove data,' which is redundant and vague—it does not clarify specifics like irreversibility, permission requirements, or side effects. The description adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and clear. The second sentence 'This may delete, clear, reset, or otherwise remove data' is redundant and adds unnecessary length without substance. Overall, it is short but could be improved by removing the filler.
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 destructive tool with 4 parameters and no output schema, the description is insufficient. It does not explain what happens after deletion (e.g., return value, confirmation), prerequisites, or constraints. Sibling tools exist (e.g., receipts_unmatch_receipt, receipts_update_receipt) but no guidance is provided for context.
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 50%, but the description does not explain any parameters. It omits details about 'receipt_id', 'fields', 'output_mode', and 'session_path', leaving the agent without guidance on how to use them. The description fails to compensate for the missing schema descriptions.
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 'Delete receipt,' which identifies the action and resource. However, it does not distinguish from sibling tools like 'delete_transaction' or 'delete_merchant,' and the additional vague sentence 'This may delete, clear, reset, or otherwise remove data' introduces ambiguity without improving clarity.
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 context on when to use this tool versus alternatives, such as receipts_get_receipt or receipts_update_receipt. There are no explicit conditions, prerequisites, or exclusions to guide the agent.
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?
Description says 'may create or update Monarch data', matching annotations (non-readOnly, non-destructive). Adds minimal context beyond annotations but doesn't detail side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short with two sentences; concise but the second sentence is vague and adds little value.
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 complexity (5 params, no output schema, sibling tools), the description is too minimal; doesn't explain matching process or return value.
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 coverage is 40% (only fields and output_mode have descriptions). Description does not explain parameters like receipt_id or transaction_id, failing to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Match receipt' which is clear but vague; distinguishes from siblings like unmatch, but doesn't specify that it links a receipt to a transaction.
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 on when to use this tool versus alternatives (e.g., upload/update/unmatch); agent must infer from 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?
Annotations indicate a non-destructive, non-idempotent mutation. The description adds 'may create or update Monarch data,' hinting at side effects but lacks detail on conditions or outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two clauses) but lacks structure. It is concise but at the expense of necessary detail.
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 13 parameters, no output schema, and low schema coverage, the one-sentence description is wildly incomplete for effective use.
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?
With only 15% schema coverage, the description provides no parameter explanations. It does not compensate for the many undocumented optional fields.
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 'Update receipt' clearly states the action and resource. It distinguishes from receipt siblings like delete, get, and list.
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 on when to use this tool versus alternatives like upload, match, or unmatch. The description does not specify prerequisites or exclusions.
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?
Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds that it 'may create or update Monarch data,' which is consistent with openWorldHint but lacks detail on side effects, permissions, or reversibility. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and concise, but it lacks structure. Key information about the tool's effect and parameters is missing, making it cryptic rather than clear.
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 5 parameters, no output schema, and sparse annotations, the description is incomplete. It does not explain what receipt settings are, how they are updated, or what values are allowed for parameters like 'auto_categorize'. An agent would struggle to invoke this 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 only 40% (2 of 5 parameters have descriptions). The tool description does not explain any of the parameters, leaving agents to guess the purpose of 'session_path', 'auto_categorize', and 'update_transaction_notes'. No parameter-level information is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update receipt settings' which is a clear verb+resource, but it does not differentiate from sibling tools like receipts_update_receipt. The phrase 'may create or update Monarch data' adds vague context but doesn't specify what settings are affected.
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, no when-not-to-use instructions, and no mention of prerequisites or context. The description is purely functional.
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?
Annotations already indicate not readonly and not destructive; the description adds 'This may create or update Monarch data' which gives a vague behavioral hint. However, it omits critical details like file size limits, accepted formats, or exactly what data is created/updated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (2 sentences), which is concise but misses essential details. It is front-loaded but at the cost of completeness.
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 6 parameters, 1 required, and no output schema, the description is insufficient. It does not explain what the tool returns or its side effects beyond a vague 'create or update' statement.
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?
Only 2 of 6 parameters have descriptions in the schema (fields, output_mode); the description does not clarify the purpose of file_path, filename, content_type, or session_path. With 33% schema coverage, the description fails to compensate.
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 'Upload receipt' which clearly identifies the action and resource. It distinguishes from siblings by implying a creation/update action, but lacks specifics on what the upload entails (e.g., attachment to a transaction).
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 on when to use this tool versus alternatives like receipts_match_receipt or receipts_update_receipt. The description does not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description's claim 'This may delete, clear, reset, or otherwise remove data' merely restates destructiveness without adding specific behavioral context. It fails to explain what actually happens (e.g., deletes the stream permanently, closes it, or removes occurrences). No extra insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the primary purpose. However, the second sentence is vague and redundant given the destructiveHint annotation. It is concise but not efficiently informative; it could be replaced with more specific details.
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 output schema, 4 parameters, and a destructive action, the description is incomplete. It does not describe return values, confirmation, or side effects (e.g., impact on occurrences or summaries). The agent lacks sufficient information to safely invoke 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?
Schema description coverage is 50%, with two parameters (recurring_id, session_path) lacking descriptions. The tool description does not explain any parameters; it only mentions the action. Thus, it adds no meaning beyond the schema, and the undocumented parameters remain ambiguous.
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: 'Remove recurring stream.' It specifies the resource (recurring stream) and the verb (remove), distinguishing it from sibling tools like get, create, or update. However, the added elaboration 'This may delete, clear, reset, or otherwise remove data' is vague and does not precisely define what removal entails, slightly reducing clarity.
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. For example, it does not indicate prerequisites (e.g., must exist) or contrast with 'recurring_update_recurring_stream' for modifying vs removing. The sibling list implies context, but the description itself lacks any usage 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?
The description only states it may create or update Monarch data, which is vague and potentially misleading for a reorder operation. Annotations indicate it is not read-only and not destructive, but the description adds little useful behavioral context and does not clarify side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at two sentences. The first sentence is concise but the second sentence seems extraneous and potentially inaccurate. It could be improved by being more focused.
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, no output schema, and moderate complexity, the description is insufficient. It does not explain the outcome, return format, or error conditions, leaving the agent with minimal understanding of how to use it 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 only 40%, and the description does not explain the meaning of key parameters like 'order' (e.g., whether it is a 0-based index) or 'tag_id'. The schema describes 'fields' and 'output_mode', but the description adds no value to the required 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 tool reorders a tag, which is the core action. However, the second sentence about creating or updating Monarch data introduces confusion because reordering typically does not create data. The name and title are consistent.
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 tags_update_tag or other reorder tools. There is no mention of prerequisites like the tag existing or how to determine the new order.
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?
Annotations already indicate readOnlyHint=false (write operation). The description adds that it may create or update 'Monarch data,' hinting at broader side effects, but this is vague and lacks specifics on what data is affected. With annotations present, the description provides some additional context but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise. However, the second sentence ('This may create or update Monarch data') is vague and could be considered wasteful as it does not clearly add value. The first sentence is clear but could be expanded to include essential usage guidelines.
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 (1 required), no output schema, and low schema description coverage, the description is incomplete. It fails to explain what updating a tag entails, what each parameter does, or the expected outcome. The description leaves significant gaps for an 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?
Schema description coverage is only 33%, yet the description does not explain any parameters such as tag_id, name, or color. It adds no meaning beyond the schema, failing to compensate for the low coverage. Essential parameter roles are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update tag' which clearly indicates the verb and resource. However, the addition 'This may create or update Monarch data' introduces ambiguity about whether the tool can create tags, which is contradictory to the tool's name and sibling tools like tags_create_tag. This reduces clarity.
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 tags_create_tag or tags_delete_tag. There is no mention of prerequisites or context for use.
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?
The description notes that the tool 'may create or update Monarch data', hinting at non-destructive but potentially creative behavior. However, it does not specify conditions under which creation occurs or other side effects. Annotations are sparse, so the description adds some value but is insufficiently detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, just one sentence. While brevity is good, it omits essential info. It is not overly verbose, but it's under-specified for 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 13 parameters, no output schema, and limited annotations, the description is severely lacking. It fails to explain what fields can be updated, return value, or constraints. It is not complete enough for effective tool selection and 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?
Schema description coverage is only 15% (only 'fields' has a description). The tool description does not explain any parameters, leaving agents to rely solely on parameter names and types, which may be ambiguous. It adds minimal value 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 'Update account', which identifies both the verb and the resource. It is straightforward and matches the tool's name and title, though it does not differentiate from sibling tools like create or 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?
No guidance on when to use this tool versus alternatives (e.g., accounts_create_manual_account). There is no mention of prerequisites or scenarios where this tool is appropriate or not.
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?
The description aligns with annotations (destructiveHint=true) by mentioning potential data removal. However, it adds minimal context beyond what annotations already indicate, and the openWorldHint is not explained.
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 brief (one sentence) and gets to the point. However, the brevity sacrifices necessary detail.
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 5 parameters, no output schema, and a destructive action, the description is insufficient. It doesn't explain the meaning of 'confirm', what fields do, or the implications of openWorldHint=true.
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 40% (2 of 5 parameters have descriptions). The tool description does not explain any parameters or their roles, leaving agents to rely on the schema alone, which is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (clear) and resource (budget), but fails to distinguish from sibling tools like budget_reset_budget. The wording 'may delete, clear, reset, or otherwise remove data' is vague and does not clarify what clearing a budget entails compared to resetting.
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 on when to use this tool versus alternatives (e.g., budget_reset_budget, budget_delete_budget). No context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) provide a safety profile, reducing the need for behavioral details. The description adds nothing beyond these annotations, but also does not contradict them. For a read-only tool, this is minimally adequate.
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?
Extremely concise but at the expense of completeness. Four words do not provide enough context for a tool with 5 parameters. The description is under-specified, not efficiently concise.
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 5 parameters, 2 required, and no output schema. The description does not explain what the return data looks like, how the months are filtered, or any edge cases. An agent would be uncertain about the output format and behavior without additional context.
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 40%, leaving start_month and end_month undocumented. The tool description does not mention parameters or compensate for missing schema descriptions. The agent must infer usage from parameter names alone, which is insufficient for complex date formatting.
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: 'List budget months.' It is a verb+resource pattern. However, it does not differentiate from sibling list tools or specify what constitutes a 'budget month' (e.g., months with budget data vs all months in a range).
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 usage guidelines provided. The description does not indicate when to use this tool vs other budget tools or how to set the date range behavior. The agent receives no contextual cues about 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'This may create or update Monarch data,' which is vague and doesn't specify what gets created/updated, permissions needed, or side effects. Minimal added value beyond annotations.
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 sentence, very concise. It could be front-loaded with more critical information, but it avoids verbosity. Every word earns its place, though more structure would be beneficial.
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, no output schema, and moderate annotations, the description is too brief. It lacks context about return values, behavior on different inputs, and how it fits into the broader budgeting workflow.
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 40% schema description coverage and 5 parameters, the description adds no meaning beyond the schema. It does not explain the variability enum values or the purpose of required parameters like category_group_id, leaving the agent without clarity.
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 'Set budget group variability' with a specific verb and resource. It clearly indicates the action, but does not explicitly differentiate from sibling tools like budget_set_budget_category_variability, relying on the name for disambiguation.
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 budget_set_budget_group_amount or budget_set_budget_group_rollover. There is no mention of prerequisites or conditions for use.
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?
Annotations already indicate not read-only and not destructive. The description adds 'may create or update Monarch data', which aligns with non-idempotent behavior. However, it doesn't disclose specific side effects or error conditions.
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?
Two concise sentences with no obvious filler. The behavioral note is useful, but the description could be slightly more informative without becoming verbose.
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 6 parameters and no output schema, the description fails to explain what flex rollover settings are, the meaning of key parameters, or the expected response. This leaves the agent with significant gaps.
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?
With only 33% schema coverage, the description provides no additional meaning for parameters like 'enabled', 'start_month', 'starting_balance'. The schema's descriptions for 'fields' and 'output_mode' are already there, so the description adds no 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 states the verb 'Set' and resource 'flex rollover settings', and distinguishes from sibling tool 'budget_get_flex_rollover_settings' via name. However, it does not explain what flex rollover settings are, limiting clarity.
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 on when to use this tool versus alternatives like budget_get_flex_rollover_settings. There is no mention of prerequisites or context for use.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which sufficiently indicate this is a safe, read-only operation. The description does not add any additional behavioral context beyond what the annotations provide, so no extra value is added.
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 (one sentence), but it is under-specified. It does not earn its place by providing valuable context; it merely restates the obvious from the tool name. A more informative description would be appropriate.
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 4 parameters, no output schema, and the description is minimal, the tool lacks sufficient context for an agent to use it correctly. Important details like the return value shape, error conditions, or usage notes are missing.
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 50%, with some parameters (fields, output_mode) having descriptions in the schema. However, the tool description 'Get category.' provides no information about any parameters, such as the required category_id. The description fails to add meaning 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 'Get category.' clearly indicates the verb and resource (get a single category). It distinguishes from sibling tools like categories_list_categories or categories_get_category_catalog because those have distinct names and purposes. However, it doesn't explicitly state that it retrieves a category by ID, which is implied by the required category_id parameter.
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 categories_list_categories (which retrieves all categories) or categories_get_category_group. The description lacks context for selection.
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?
Annotations already indicate this is a modifying operation (readOnlyHint=false) and not destructive. The description adds the vague warning that it 'may create or update Monarch data,' which provides some additional context beyond annotations, but it is not specific about what data might be created or the conditions under which creation occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise but at the expense of necessary detail. Given the tool has 6 parameters and no output schema, the description is too brief to be adequately informative. Front-loading is acceptable but the content is insufficient.
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 6 parameters, no output schema, and low schema coverage. The description fails to explain the return value, the effect of parameters like 'output_mode', or how the reordering operation works. It is incomplete relative to the tool's complexity.
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?
With only 33% schema description coverage, the description should compensate by explaining key parameters like 'order', 'category_id', and 'group_id'. However, the description contains no parameter explanations at all, leaving the agent to infer meaning solely from parameter names, which is insufficient.
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 verb 'Reorder' and the resource 'category', but lacks specificity about the scope of reordering (e.g., within a group) and does not differentiate from the sibling tool 'categories_reorder_category_group'. The addition of 'This may create or update Monarch data' slightly muddles the purpose but does not make it misleading.
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 like 'categories_reorder_category_group' or other category modification tools. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds 'This may create or update Monarch data,' which is consistent but adds little beyond annotations. No disclosure of side effects or permission needs.
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 concise at two sentences, front-loading the core action. However, it sacrifices helpful 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 5 parameters, no output schema, and requires reordering logic. The description is too minimal to provide complete guidance; it omits return behavior, ordering semantics, and impact on data.
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 only 40% schema description coverage, the tool description adds no parameter information. It does not explain how 'order' works or provide context beyond what the schema already offers.
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 ('Reorder category group') and distinguishes it from siblings like 'categories_reorder_category' by specifying 'category group'. However, it could be more specific about what reordering 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 (e.g., 'categories_reorder_category' for groups). No context on prerequisites or scenarios.
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?
Annotations already declare readOnlyHint false and destructiveHint false. The description adds 'This may create or update Monarch data', hinting at an upsert behavior which is not captured by annotations. However, it lacks specifics on side effects, authorization, or reversibility.
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 at two sentences. It front-loads the purpose, but the second sentence ('This may create or update Monarch data.') is vague and could be removed or clarified. Overall efficient but could be more precise.
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 7 parameters and no output schema, the description is inadequately complete. It does not specify what fields can be updated, the required parameter (category_id), or the outcome. The low schema coverage intensifies this gap.
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?
With only 29% schema description coverage, the description compensates poorly by not explaining any parameters. It omits details on what aspects of a category can be updated (e.g., name, icon, group_id). The schema's field descriptions are minimal, and the description adds zero value for parameter understanding.
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 'Update category', identifying the specific verb and resource. The name and title also make the purpose clear. However, it does not distinguish from sibling tools like categories_update_category_group, and the ambiguous 'may create' slightly dilutes the clarity.
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 on when to use this tool versus alternatives like categories_create_category or categories_remove_category. No context provided about prerequisites or typical use cases.
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?
Annotations already declare the tool is mutating (not read-only) and not idempotent. The description adds 'may create or update Monarch data,' which is somewhat misleading and doesn't clarify actual behavior like whether it can create a goal if it doesn't exist.
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 sentence but includes vague and redundant language ('Update goal' restates the name). It could be more concise and informative.
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 high parameter count (14), low schema coverage, and many sibling tools, the description is insufficient. It does not explain the update scope, effects on existing data, or return value.
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 does not explain any of the 14 parameters. It fails to add meaning beyond the schema, leaving many parameters like 'is_sinking_fund' or 'planned_monthly_contribution' unexplained.
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 tool name and description clearly indicate it's for updating a goal. However, the phrase 'This may create or update Monarch data' introduces ambiguity, as it's an update tool and there is a separate create goal sibling.
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 other goal-related tools like goals_create_goal or goals_archive_goal. No prerequisites or exclusions are mentioned.
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?
Description mentions 'may create or update Monarch data', adding context beyond annotations that indicate it is not read-only and may have side effects (openWorldHint true). Does not specify details like permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short (two sentences) but not maximally concise; the second sentence could be more precise or integrated into the first. Adequate but not efficient.
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 5 parameters, no output schema, and no parameter descriptions in the description, it is incomplete. Lacks info on what fields can be updated, return format, 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?
Description provides no information about parameters. With only 40% schema coverage, it fails to compensate. Agent receives no guidance on name, fields, output_mode, or session_path.
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?
Clearly states 'Update merchant', distinguishing it from siblings like get, delete, list. However, the added sentence about potentially creating data introduces ambiguity.
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 on when to use this tool vs. alternatives like merchants_create_merchant or merchants_update_merchant (if it existed). Lacks context for appropriate invocation.
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?
Description minimally notes that data modification occurs, which aligns with annotations (non-readonly), but fails to disclose any specific traits like idempotency, error conditions, or side effects beyond the basic creation.
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?
Description is very short (two sentences), but the second sentence is vague and could be removed or clarified; no wasted words but also lacks substance.
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 8 parameters (4 required) and no output schema, the description fails to explain the meaning of recurring streams, expected input formats, or return values, leaving the agent underinformed.
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?
Description adds no information about the 8 parameters; with only 25% schema coverage, the agent receives no help understanding merchant_id, frequency, amount, base_date, etc.
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?
Description clearly states the tool creates a recurring stream, but the phrase 'may create or update Monarch data' introduces ambiguity about the primary action, especially given the existence of a separate update tool.
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?
Description provides no guidance on when to use this tool versus alternatives like update or remove, and lacks prerequisites or conditions.
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?
Annotations already mark destructiveHint: true. The description adds 'This may delete, clear, reset, or otherwise remove data,' which is redundant and adds no new behavioral insight. No information about irreversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at two sentences, but the second sentence is redundant with the annotation. Could be improved by removing the second sentence or merging it.
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 deletion tool with 4 parameters and no output schema, the description lacks important context: required parameter (report_id), behavior on success/failure, any confirmation or undo options, and output shape. Incomplete for a user to fully understand the 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 has 50% description coverage (fields and output_mode have descriptions; report_id and session_path do not). The tool description does not add any parameter information, failing to compensate for the missing schema descriptions.
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?
Description clearly states the tool deletes a saved report. The verb 'delete' is specific and distinguishes it from sibling tools like reports_get_saved_report or reports_list_saved_reports.
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 on when to use this tool versus alternatives, such as when to use reports_delete_saved_report vs reports_update_saved_report or other deletion tools. No prerequisites or context 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat them. The description adds no extra behavioral context (e.g., required permissions, return format). With annotations covering safety, a mid score 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), which is front-loaded but lacks substantive content. It minimally satisfies the need for brevity but does not add value beyond the title.
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 tool with 4 parameters, 50% schema coverage, and no output schema, the description is severely inadequate. It does not explain what a tag is, what fields are returned, how output_mode affects results, or any error handling.
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 50%, but the description adds no parameter-specific guidance. Two parameters (tag_id, session_path) are undocumented in both schema and description. The description fails to compensate for the missing schema descriptions.
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 'Get tag.' clearly indicates the verb (get) and resource (tag). The required tag_id parameter implies retrieving a single tag, which distinguishes it from tags_list_tags. However, it could be more explicit about retrieving by ID.
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 like tags_list_tags. It lacks any usage context or exclusion criteria.
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?
Annotations already signal mutation (readOnlyHint=false) but are not destructive. The description adds 'may create or update', which is redundant and doesn't disclose specific side effects, permission requirements, or rate limits.
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 (two sentences), but it is appropriately concise. However, it lacks substance; it could be more informative without adding length.
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 8 parameters (3 required), the description should explain the purpose and usage more thoroughly. It does not define what a budget group is or what the parameters mean, making it incomplete.
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 only 25% (fields and output_mode have descriptions). The description does not explain any required parameters (month, category_group_id, amount) despite low coverage, leaving their formats and semantics unclear.
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 verb 'Set' and the resource 'budget group amount', distinguishing it from siblings like budget_set_budget_amount which sets individual category amounts. The addition 'may create or update' adds nuance about the 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 on when to use this tool versus alternatives like budget_set_budget_amount or budget_set_budget_group_rollover. No prerequisites or context provided beyond the action itself.
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?
The description adds 'This may create or update Monarch data' which suggests possible side effects beyond creation. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description provides some extra context about potential updates, but it remains vague and does not specify conditions or extent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but the second sentence is vague and could be more precise. It lacks structure and does not efficiently convey essential 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?
The tool has 6 parameters, no output schema, and no explanation of return values or side effects. The description is incomplete for a creation tool; it should describe the expected output (e.g., the created category object) and any consequences like updates to existing categories.
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 33%, and the description does not explain any parameters. It adds no meaning beyond what the schema already provides. For a creation tool with 3 required parameters (name, group_id, icon), the description should at least indicate their role.
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 'Create category' which is a specific verb and resource indicating creation. However, adding 'or update' introduces ambiguity about whether it updates existing categories, and it does not differentiate from siblings like categories_create_category_group or categories_update_category.
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, context for creation vs. updating, or comparison with sibling tools such as categories_create_category_group or categories_update_category.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the description carries little additional burden. However, it adds no extra behavioral context (e.g., pagination, ordering).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too minimal and lacks structure. It could benefit from additional but focused 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?
With four parameters, 50% schema description coverage, and no output schema, the one-line description is insufficient to fully prepare an agent for invoking the tool. Key details like event types or output format are missing.
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 coverage is 50%; the description does not explain any parameter semantics beyond what the schema provides. It fails to compensate for undocumented parameters like 'goal_id' and 'session_path'.
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 goal events', specifying the verb 'List' and the resource 'goal events'. It is distinct from sibling tools like 'goals_list_goals' and 'goals_get_goal'. However, it is very brief and does not elaborate on the scope of events.
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 on when to use this tool versus alternatives, no mention of prerequisites or exclusions. The description provides no usage 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?
Annotations already indicate write (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds 'This may create or update Monarch data,' which provides some side effect context, but does not detail what is created or updated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but the second sentence is vague and could be omitted. It lacks front-loading of critical 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 5 parameters (2 required), no output schema, and the need to explain what 'unlink' entails, the description is insufficient. It does not clarify the effect on the goal-account relationship.
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 coverage is low (40%) for the 5 parameters. The description does not mention any parameters, failing to add meaning beyond the schema. Key parameters like goal_id and account_id are left unexplained.
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 'Unlink goal account' which clearly specifies the verb and resource. It distinguishes from sibling 'goals_link_goal_account_balance' by name, but does not explicitly contrast them.
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 on when to use this tool versus alternatives. The description lacks any mention of context or exclusions, leaving the agent to infer usage from the tool name alone.
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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds that it 'may create or update Monarch data,' which confirms mutation but doesn't specify what gets created/updated or any other behavioral traits (e.g., permissions, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first is clear, the second is vague ('may create or update Monarch data'). The description is concise but not optimally structured to front-load key 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 4 parameters, no output schema, and moderate complexity, the description is insufficient. It doesn't explain what 'goal_ids' represents, how priorities are updated, or what the response contains, leaving 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?
Schema description coverage is 50% (2 of 4 parameters have descriptions). The description does not explain any parameters beyond the schema. 'goal_ids' and 'session_path' lack explanations, which the description could have provided.
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 title and description clearly state the action ('update goal priorities') and the resource (goals). The description adds 'This may create or update Monarch data,' which specifies the effect. It distinguishes from other goal tools (e.g., create, delete) but could be more specific about what 'priorities' 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 on when to use this tool versus alternatives like goals_set_goal_budget_amount or goals_update_goal. No prerequisites, side effects, or when-not-to-use information 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?
Annotations already indicate readOnlyHint=false, destructiveHint=false. The description adds 'This may create or update Monarch data', hinting at potential creation. However, it does not disclose required permissions, side effects, or rate limits. The added context is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) but at the cost of necessary detail. While no words are wasted, the structure does not provide front-loaded essential information for a mutation tool with multiple parameters. It is efficient but under-specified.
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 complexity (5 parameters, no output schema, potentially creatable side effect), the description is inadequate. It lacks detail on what fields can be updated, the meaning of output modes, and the behavior of session_path. An agent would need additional context to invoke this 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 only 40% (2 of 5 parameters have descriptions). The tool description adds no parameter explanations. An agent cannot infer what 'timezone', 'display_name', or 'session_path' mean for updating a user. This fails to compensate for the low schema 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 title and description clearly state 'Update current user', which matches the tool name. However, it does not distinguish this tool from its sibling 'household_get_current_user' or explain that it may also create data. A specific verb and resource are present, but sibling differentiation is missing.
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 on when to use this tool vs. alternatives (e.g., household_get_current_user for reading). No conditions, prerequisites, or when-not-to-use instructions are 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?
Annotations already indicate the tool is not read-only and not destructive. The description adds 'This may create or update Monarch data,' which provides slight additional context on possible side effects, but lacks details on permanence or impact on other users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but given the tool has 8 parameters, it is under-specified. It front-loads the purpose but omits necessary context, striking a poor balance for a tool of this complexity.
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 output schema, and low schema coverage, the description fails to provide sufficient context about which preferences are updatable, the effects of updating, or any prerequisites. It is incomplete for reliable agent usage.
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%, with five boolean parameters lacking descriptions. The tool description does not compensate by explaining what these parameters control, leaving the agent with insufficient information to correctly set them.
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 updates household preferences, with a specific verb and resource. It adds that it may create or update Monarch data, but does not differentiate from the sibling get counterpart (household_get_household_preferences).
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 to prefer update over get, or any usage context beyond the basic purpose.
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?
Annotations already provide destructiveHint: true and readOnlyHint: false. The description adds only vague wording ('may delete, clear, reset, or otherwise remove data') which doesn't meaningfully extend beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first is direct, but the second is redundant and could be removed without loss. It is adequate but not optimally concise.
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?
No output schema, minimal parameter description, and no usage context. For a delete tool, it lacks completeness about effects and return values.
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 coverage is 50%, and the description provides no explanation of parameters like holding_id, fields, output_mode, or session_path. The description fails to compensate for missing schema info.
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 it deletes a manual holding, distinguishing it from create/update siblings. However, the second sentence is vague and adds little, making it slightly less than excellent.
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 on when to use delete vs update or prerequisites. The description does not mention any context or exclusions.
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?
Annotations already indicate destructiveHint=true. The description adds 'may delete, clear, reset, or otherwise remove data,' which reinforces destructiveness but provides little new context. It does not detail side effects like cascading removal from associated transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, the first is clear. The second is vague and unnecessary, adding no real value. Could be trimmed to one sentence.
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?
Tool has 4 parameters and a destructive action, but the description lacks details on return values, impact on associated data, or output handling. Minimal info 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (two of four parameters have descriptions). The description does not mention any parameter or add meaning beyond the schema. For example, it doesn't explain the required tag_id or optional fields, output_mode, or session_path.
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 'Delete tag', which is a specific verb and resource. It distinguishes from sibling tools like tags_create_tag and tags_update_tag. However, the additional phrase 'This may delete, clear, reset, or otherwise remove data' is redundant and slightly confusing, lowering the 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?
No guidance on when to use this tool versus alternatives, such as tags_update_tag or other destructive tools. The context for deletion (e.g., prerequisites, irreversibility) is missing.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds no additional behavioral context (e.g., pagination, ordering). With annotations covering safety, a 3 is adequate but no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but under-informative. It meets the minimum but lacks details that would justify the space saved.
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?
No output schema exists, and the description does not mention what is returned (e.g., list of attachment metadata, file details). Missing context about required parameters and behavioral hints (e.g., redirect_posted impacts).
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 coverage is 40% (only fields and output_mode have descriptions). The tool description does not explain any parameters. For a 5-parameter tool, the description should compensate, especially for undocumented params like transaction_id and session_path.
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?
Description states 'List transaction attachments', which clearly indicates the verb and resource. It distinguishes from sibling tools like 'transactions_get_transaction_attachment' (single) and 'transactions_delete_transaction_attachment' (delete). However, it lacks specifics about the scope (e.g., for a given transaction).
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 on when to use this tool versus alternatives like 'get', 'download', or 'list_transactions'. No mention of required prerequisites (transaction_id) 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?
The description adds that the tool 'may create or update Monarch data', which provides context beyond annotations (e.g., openWorldHint, readOnlyHint=false). However, it doesn't disclose specific behavioral traits like required permissions, side effects, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise but lacks necessary detail. Every sentence is not earning its place; the second sentence introduces confusion without adding clear value.
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 17 parameters, no output schema, and no behavioral details beyond a vague note about creation, the description is incomplete. It does not explain return values, required fields, or how 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 description does not add any meaning beyond the input schema. With 17 parameters and only 12% schema description coverage, the description fails to compensate for the lack of parameter documentation, leaving the agent uncertain about parameter semantics.
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 'Update transaction', clearly indicating the verb and resource. However, the additional phrase 'This may create or update Monarch data' introduces ambiguity about whether it can also create transactions, which contradicts the name. Nonetheless, it distinguishes from sibling tools like transactions_create_transaction and transactions_delete_transaction.
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 transactions_create_transaction, nor are there any prerequisites or context about typical use cases.
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?
The description 'This may create or update Monarch data' adds minimal behavioral context beyond the annotations (readOnlyHint=false). Annotations already indicate it is a write operation but not destructive. The description does not reveal further traits like idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using two sentences to state purpose and a behavioral note. No extraneous words, 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 the tool has 5 parameters, no output schema, and no nested objects, the description is insufficient. It fails to explain the variability option, required category, or return behavior, leaving the agent underinformed 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?
With only 40% schema description coverage, the description should explain parameters but does not. It does not mention category_id, variability enum, or other parameters, leaving the agent to infer meaning solely from the schema, which lacks descriptions for critical fields.
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 sets budget category variability, which is a specific verb-resource pair. It distinguishes from similar sibling tools like budget_set_budget_group_variability by the resource type, but does not explicitly mention this 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?
The description provides no guidance on when to use this tool versus alternative sibling tools like budget_set_budget_amount or budget_set_budget_category_rollover. There is no mention of 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?
The description states it is destructive, matching annotations (destructiveHint:true). However, it is vague about what exactly happens (e.g., cascading effects on goal events). Minimal additional value beyond annotations.
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 concise at one sentence. While not structured with bullet points or sections, it is front-loaded with the action. Could include more key info without losing 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 destructive tool with no output schema, the description lacks essential context: permanence, what happens to associated data (e.g., goal events), and how to verify deletion. Incomplete for safe agent 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?
With 50% schema description coverage, the tool description adds no parameter explanations. The schema describes fields and output_mode, but not goal_id or session_path. Description fails to compensate for the gap.
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 'Delete goal,' indicating the action and resource. It distinguishes from siblings like goals_archive_goal by focusing on deletion, but could be more specific about what deletion entails beyond 'may delete, clear, reset, or otherwise remove data.'
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 on when to use this tool vs alternatives like archiving or the related goals_delete_goal_event. Given destructiveHint:true, it would be helpful to note that deletion is irreversible and suggest archiving as a safer 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?
Annotations already provide destructiveHint=true and readOnlyHint=false, clearly indicating a destructive operation. The description adds minimal value by stating it may 'delete, clear, reset, or otherwise remove data,' which is partially redundant and vague.
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?
Two sentences, front-loaded with the core action. The second sentence is vague but short. Overall efficient with no 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?
For a destructive operation with 4 parameters and no output schema, the description lacks detail on return behavior, side effects, or specifics of what 'delete, clear, reset' means in practice. The tool's purpose is clear but not fully contextualized.
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 50% schema description coverage, the description does not add any parameter explanations. Required 'event_id' and optional 'session_path' lack context, and the description does not compensate for these gaps.
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 'Delete goal event,' clearly identifying the action and resource. However, the vague addition 'This may delete, clear, reset, or otherwise remove data' does not differentiate it from similar tools like goals_delete_goal or goals_update_goal_event.
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 on when to use this tool versus alternatives like goals_delete_goal or goals_update_goal_event. Context signals indicate sibling tools exist but description lacks any usage direction.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety profile is clear. Description adds no additional behavioral context (e.g., pagination, return format). Adequate given annotations but no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at 3 words, but under-specified for a tool with 3 parameters. Could be expanded slightly without losing conciseness.
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 read-only tool with annotations covering safety and idempotency, the description is minimally adequate. However, it could clarify scope (e.g., 'of the current household') and mention no prerequisites. Missing output schema and no description of return shape.
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 67% (2 of 3 parameters described). The description does not add any parameter meaning; it relies solely on the schema. Session_path parameter lacks a description in schema, and description does not compensate.
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?
Description clearly states 'List household members' – specific verb and resource. Distinguishes from sibling 'household_get_household_member' which gets a single member, but does not explicitly mention scope (e.g., current household). Could be slightly more specific.
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 on when to use this tool versus siblings like 'household_get_household_member' or when not to use. Agent must infer from 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?
Annotations already indicate non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds that it may create or update, implying potential for both operations, which is a useful nuance beyond annotations.
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 concise sentence (13 words), front-loaded with the action. However, it could include more useful information while remaining concise.
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, no output schema, and minimal description, the tool lacks completeness. It does not explain what a manual holding is, what is created/updated, or what the response looks like.
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 low (29%); only fields and output_mode have descriptions. The description does not explain key parameters (account_id, security_id, quantity, cost_basis, session_path), failing to compensate for 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 clearly states the action ('create manual holding') and resource, distinguishing it from siblings like investments_update_manual_holding. However, the phrase 'This may create or update Monarch data' is vague, not fully clarifying what 'Monarch data' means.
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 on when to use this tool versus alternatives like investments_update_manual_holding. No mention of prerequisites or context for 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond stating the operation, such as what specific account types are included or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks essential context that would help the agent understand the tool's scope. It is front-loaded but under-specified.
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 simple nature of the tool and the presence of annotations and schema, the description is minimally adequate. However, it fails to clarify how it differs from 'accounts_list_accounts', leaving a completeness gap in context.
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 description coverage is 67%, with 'fields' and 'output_mode' described. The description does not add any additional meaning beyond the schema, so it meets the baseline.
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 verb 'list' and resource 'investment accounts', making the purpose unambiguous. However, it does not differentiate from the sibling tool 'accounts_list_accounts', which may list similar accounts.
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 'accounts_list_accounts' or other investment tools. No exclusions or context are mentioned.
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?
Annotations already indicate non-readonly and non-destructive. The description adds 'This may create or update Monarch data,' which aligns with openWorldHint but is vague. It does not disclose specifics like error handling, auth requirements, or what 'Monarch data' encompasses.
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?
Two concise sentences with no fluff. However, the second sentence could be more specific to improve clarity. It is appropriately 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 the complexity (5 parameters, potential side effects, no output schema), the description is too brief. It does not explain the tool's behavior, return format, or differentiate from sibling tools. Important context is missing.
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 40% (only 2 of 5 parameters described). The description does not elaborate on any parameter, especially report_id and name which lack schema descriptions. The description fails to compensate for the 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 clearly states 'Update saved report' which is a specific verb-resource pair. It distinguishes from sibling tools like reports_create_saved_report, though the ambiguous mention of 'create' in the second sentence slightly detracts from clarity.
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 on when to use this tool versus alternatives (e.g., when to update vs create). No prerequisites or conditions mentioned. The description lacks any explicit usage 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?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds no extra behavioral context, such as whether results are paginated or what happens with no tags. With annotations covering safety, a 3 is appropriate for not augmenting beyond them.
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 wasted sentences. It is front-loaded and efficient, though it could be slightly more informative without losing 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 the tool has 6 parameters and no output schema, the description is insufficient. It doesn't explain return values, pagination, or how parameters like search, limit, or fields affect the results. The tool needs more context to be fully usable.
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 6 parameters with only 33% description coverage (fields and output_mode are described). The description 'List tags' does not mention any parameter semantics, failing to compensate for the low schema coverage. The agent gets no additional meaning from the description.
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 tags' clearly states the action (list) and resource (tags), which distinguishes it from sibling tools like tags_get_tag (single) and tags_create_tag. However, it doesn't specify any additional context about what tags are or the scope of listing.
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. For example, it doesn't mention that it's suitable for retrieving all tags or that search/filtering is available. The agent must infer usage from the name alone.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. However, the description adds no further behavioral context such as what data is returned (e.g., list of splits with amounts, categories) or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, it is concise but too brief for a tool with 4 parameters. It is not wasteful but under-specified, balancing between brevity and adequacy.
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?
Missing output schema and no description of return value; the tool's behavior (e.g., returning splits for a transaction) is implied but not explained. With related sibling tools, more context would help.
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 50% (fields and output_mode have descriptions, session_path and transaction_id only have titles). The description adds no extra meaning for any parameter, failing to compensate for undocumented 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 'Get transaction splits' clearly states the action (get) and resource (transaction splits), distinguishing it from sibling tools like transactions_get_transaction or transactions_unsplit_transaction.
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 on when to use this tool vs alternatives (e.g., transactions_get_transaction for full details, transactions_list_transactions for all transactions). The description lacks context for selection.
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?
Annotations already indicate readOnlyHint=false (write) and destructiveHint=false. The description adds 'may create or update Monarch data', which is consistent but adds minimal extra behavioral context. It does not detail what happens to existing splits or side effects beyond annotations.
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?
Two sentences with clear purpose and a behavioral note. No redundancy, but could include more relevant details without becoming verbose.
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 5 parameters including a complex nested 'splits' input and no output schema, the description lacks essential context about how splits are structured, how they relate to the parent transaction, and any constraints (e.g., sum of splits must equal transaction amount).
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 40%, and the description does not explain any parameters (e.g., transaction_id, splits). The nested 'splits' object has many fields but no description, failing to compensate for 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 clearly states 'Update transaction splits' as a verb+resource. It distinguishes the tool as an update operation, but does not differentiate from related tools like 'unsplit_transaction' or 'create_transaction'.
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 on when to use this tool versus alternatives (e.g., unsplit_transaction, create_transaction). The description does not mention prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the note 'This may create or update Monarch data', which hints at potential upsert behavior but does not clarify idempotency (idempotentHint=false). Overall, minimal additional value beyond annotations.
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 (two sentences) and front-loaded with the core purpose. However, the second sentence is vague and does not add substantial value, making it slightly less efficient than ideal.
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 moderate complexity (5 parameters, no output schema), the description is insufficient. It does not explain what the response looks like, how to handle the 'type' enum, or the effect of optional parameters like 'fields' or 'output_mode'.
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 only 40% (2 of 5 parameters documented), yet the description adds no parameter information. It fails to explain the meaning of 'name', 'type', or other fields, leaving the agent without necessary guidance for correct invocation.
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 verb 'Create' and resource 'category group', making the tool's purpose unmistakable. It distinguishes itself from sibling tools like categories_delete_category_group and categories_update_category_group.
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 categories_create_category or other category tools. There is no mention of context, prerequisites, or exclusions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no additional behavioral context beyond the literal action. It does not contradict annotations, but also does not elaborate on return structure or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) and to the point. While it lacks richness, it is appropriately brief for a simple retrieval tool. No unnecessary content.
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's simplicity and the presence of annotations covering safety, the description is minimally adequate. However, it does not explain the purpose of parameters like 'output_mode' or that the tool requires a 'group_id'. The lack of output schema is not mitigated by 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?
Schema description coverage is 50%, with descriptions for 'fields' and 'output_mode' but none for 'group_id' or 'session_path'. The tool's description does not clarify any parameters or add meaning beyond the schema's existing descriptions.
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 'Get category group', which is a specific verb and resource. It distinguishes from sibling tools like 'categories_list_category_groups' (list) and 'categories_get_category' (different resource). However, it does not explicitly mention that it retrieves a single group by ID, though that is implied by the required 'group_id' parameter.
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 'categories_list_category_groups' or 'categories_get_category'. There is no mention of context or prerequisites.
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?
The description adds 'may create or update Monarch data,' which expands on the annotations (readOnlyHint=false, destructiveHint=false). However, it lacks details like side effects of reactivating an already active category or required permissions. Annotations already cover safety, so the description provides moderate added 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 (two sentences) with no redundancy. Every word is necessary, making it easy to parse. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and 4 parameters, the description is too sparse. It does not explain what 'reactivate' means operationally, what the response contains, or any important constraints. For a tool with many siblings, more context would improve usability.
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 50% schema description coverage, the description does not add any parameter-specific context. Two parameters (category_id, session_path) lack schema descriptions and are not explained in the description. The existing schema descriptions for 'fields' and 'output_mode' are adequate, but the overall contribution is minimal.
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 ('Reactivate category') and resource, distinguishing it from siblings like 'categories_remove_category' or 'categories_create_category'. However, it does not elaborate on what reactivation entails (e.g., making an inactive category active), leaving some ambiguity.
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 prerequisites, typical scenarios, or when not to use it, leaving the agent without decision support.
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?
The description adds 'This may create or update Monarch data,' which goes beyond annotations by specifying the nature of the write operation. Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive, so the description adds moderate value but does not disclose side effects, permissions, or error conditions.
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 with only two sentences, each serving a clear purpose: stating the action and noting the potential data mutation. No unnecessary words 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 8 parameters, no output schema, and a nontrivial domain (goal budgeting), the description is insufficient. It fails to explain return values, parameter interactions, or how this tool relates to other budgeting tools, making it hard for an agent to use correctly without additional context.
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 only 25% schema description coverage, the description does not compensate by explaining the purpose of parameters like goal_id, month, amount, account_id, or apply_to_future. It merely restates the tool's function, leaving agents without guidance on how to fill in the arguments.
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 ('set goal budget amount') and the resource ('monarch data'), making the purpose unambiguous. However, it does not differentiate from sibling tools like budget_set_budget_amount, which also sets a budget amount, so the specificity is slightly limited.
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 budget_set_budget_amount or goals_get_goal_budget_amounts. The description lacks context about prerequisites, constraints, or use cases.
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?
Annotations declare readOnlyHint=false and destructiveHint=false. The description adds the key behavioral trait that it 'may create or update Monarch data', which is beyond the annotations. However, it does not explain the conditions under which creation vs update occurs, nor does it disclose other behavioral aspects like required permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the core action, and the second adds a critical behavioral note. Every word earns its place, making it highly efficient.
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, low schema coverage, no output schema, and minimal annotations, the description is far too sparse. It does not explain the tool's purpose relative to goal events, what each parameter does, or what the return value looks like. An agent would struggle to invoke this tool correctly without additional context.
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 coverage is only 29% (descriptions for fields and output_mode). The description provides no parameter-level guidance. It does not explain the meaning or usage of event_id, date, notes, include_in_budget, or session_path. Given the low coverage, the description should compensate but 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 states 'Update goal event', identifying the verb and resource. However, the addition 'This may create or update Monarch data' introduces ambiguity—an update tool should not typically create data, and this mixing reduces clarity. It does not explicitly distinguish from siblings like goals_create_goal or goals_contribute_to_goal.
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 (e.g., goals_contribute_to_goal, goals_withdraw_from_goal). There is no mention of prerequisites, context, or exclusions. The agent must infer usage solely from the tool name and description.
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?
Annotations provide strong safety guarantees (readOnlyHint, idempotentHint, destructiveHint). The description does not add behavioral context such as rate limits, authorization needs, or side effects. With annotations covering the safety profile, a score of 3 is appropriate as it adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words), but it lacks structure. While it is front-loaded, it does not earn its place by providing enough information; it essentially restates the tool name. A single sentence without details is not optimally structured for agent use.
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 three parameters, strong annotations, and no output schema, the description is too brief. It does not explain what settings are returned, how to interpret results, or how to use parameters like 'output_mode' and 'fields'. The description leaves significant gaps for an agent to infer behavior.
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 67% (two out of three parameters have descriptions). The tool description does not enhance parameter understanding; it does not explain what 'budget settings' encompasses or how parameters like 'session_path' affect behavior. The description fails to compensate for the undocumented parameter.
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 budget settings' clearly states the verb and resource. It distinguishes from sibling tools like 'budget_get_budget' (which gets a specific budget) and 'budget_get_budget_category' by focusing on the overarching settings. The input schema further supports this with parameters for field selection and output mode.
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, nor does it mention preconditions or exclusions. There is no context about when this tool is appropriate or when to prefer related tools like 'budget_get_budget_settings' over others.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description 'Get' aligns with these annotations. No additional behavioral details are provided, but no contradictions either.
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 concise sentence of 5 words. It is front-loaded and efficient, but borderlines on under-specification for agents.
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?
Despite having good annotations, the description lacks context about what flex rollover settings are, what fields are returned, or how the output_mode parameter affects results. For a simple getter, more completeness is needed.
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 coverage is 67% (2 of 3 parameters described). The description adds no information about parameters beyond what the schema already provides. Baseline 3 is appropriate as the schema handles most of the 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 it retrieves flex rollover settings. It is specific and distinguishes from sibling 'budget_set_flex_rollover_settings' by implying a read operation. However, it could be more explicit about the scope.
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 on when to use this tool versus alternatives like budget_get_budget_settings or budget_set_flex_rollover_settings. No context provided for prerequisites or typical use cases.
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?
The description adds 'may create or update Monarch data,' which is consistent with annotations but remains vague; it does not elaborate on side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise but lacks sufficient detail; it is front-loaded but could be more informative without 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?
Given 4 parameters and no output schema, the description fails to explain what 'restore goal' entails (e.g., undeleting vs. unarchiving) and offers no context on return behavior.
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 parameters; schema coverage is 50% (only 'fields' and 'output_mode' have descriptions), yet the description adds no clarification for 'goal_id' or 'session_path'.
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 'Restore goal' with a specific verb and resource, distinguishing it from sibling tools like 'goals_archive_goal' and 'goals_delete_goal'.
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, nor any prerequisites or exclusions.
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?
The description adds value beyond annotations by disclosing that the tool may create or update Monarch data, which is not captured by the annotations (readOnlyHint: false, destructiveHint: false). This warns the agent of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the core purpose. However, it may be too sparse, lacking details that could fit without harming conciseness. Still, it avoids unnecessary 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 modifies data (unmatch a receipt) and has no output schema, the description does not explain return values, error handling, or prerequisites. It is insufficient for a state-changing 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 50%, but the description provides no information about any parameters. The required parameter receipt_id is not explained, and optional parameters like fields, output_mode, and session_path are not described in the description. The schema partially covers fields and output_mode, but the description does not compensate for the missing descriptions.
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 ('Unmatch receipt') and the resource, but does not differentiate from siblings like receipts_match_receipt or receipts_delete_receipt. The verb is specific and the resource is identified.
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 (e.g., receipts_match_receipt for the opposite action). No exclusions or prerequisites are mentioned.
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?
The description adds 'This may create or update Monarch data', which informs about mutation behavior. Annotations already indicate non-read-only (readOnlyHint=false). No contradictions. However, details like file size limits, overwrite behavior, or idempotency are missing.
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?
Two concise sentences with no unnecessary words. The purpose is front-loaded. Appropriate length for a straightforward mutation tool.
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?
Basic purpose and mutation fact are covered, but missing details like supported file types, size limits, account linkage, and error scenarios. No output schema, so return value is unknown. For a file upload, this is incomplete.
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 only 29% schema description coverage, the description adds no parameter details. It does not explain required parameters (transaction_id, file_path) or optional ones. The schema itself provides some descriptions (e.g., fields, output_mode), but the description fails to 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 states 'Upload transaction attachment' which clearly identifies the action and resource. It distinguishes from siblings like download and get attachment tools. However, it doesn't specify what kind of attachment or any constraints.
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 on when to use this tool versus alternatives. No prerequisites, expected file types, or error handling mentioned. The agent must infer usage from context alone.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds 'This may delete, clear, reset, or otherwise remove data,' which elaborates on the destructive nature but doesn't provide substantial new behavioral insight beyond the annotations.
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 (two sentences). However, the second sentence is somewhat redundant given the first. Still, it is concise and front-loaded with the core action.
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?
No output schema exists, yet the description doesn't specify what happens after deletion (e.g., return value, side effects, or impact on related data). For a destructive tool, more information about consequences is needed.
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 50% (fields and output_mode have descriptions), but the tool description doesn't mention any parameters. It fails to add value for the required account_id parameter or session_path, leaving the agent without guidance on their meaning or usage.
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 'Delete account', which is a specific verb-resource pair. This distinguishes it from sibling tools like accounts_update_account or accounts_get_account, which 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 on when to use this tool vs alternatives (e.g., deactivating vs deleting). No prerequisites or conditions are mentioned, leaving the AI agent without context for appropriate invocation.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no extra behavioral traits beyond what annotations imply. It does not mention any constraints like pagination or data limits, but annotations cover the safety profile.
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 (two words). While it is front-loaded, it is perhaps too minimal for a tool with 5 parameters and no output schema, but it does not waste 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 5 parameters (including nested filters) and no output schema, 'List categories' is insufficient. It lacks information about filtering options, output modes, pagination, or any behavioral details beyond the bare minimum.
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 40% (only fields and output_mode have descriptions). The description does not explain any parameters, including filters, session_path, and include_disabled. With low coverage, the description should compensate but fails to do so.
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 categories' clearly states the verb and resource. It distinguishes from siblings like categories_get_category (single) and categories_list_category_groups (groups), as the tool specifically lists 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 on when to use this tool vs alternatives such as categories_get_category for a specific category or categories_list_category_groups for groups. The description lacks context about filtering or scope.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's statement about deleting/clearing/resetting is consistent but adds little additional context. No further behavioral traits (e.g., authorization needs, side effects) are 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 extremely concise with two short sentences. No unnecessary words or repetition. It directly states the purpose without extraneous details.
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 operation (delete by ID) and the presence of annotations for safety, the description is minimally adequate. However, it lacks any mention of return values or side effects beyond the vague 'delete, clear, reset', and does not integrate with sibling tools or usage context.
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 50% coverage (fields and output_mode described), but the description does not mention any parameter details. The required attachment_id parameter lacks description both in schema and in the tool description, making it unclear what value to provide. The description fails to compensate for the schema's gaps.
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 ('Delete transaction attachment') and the resource (attachment of a transaction). It is a specific verb+resource combination that distinguishes from sibling tools like get, list, download, and upload attachments.
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 prerequisites, consequences, or scenarios where deleting an attachment is appropriate. The sibling tools include other attachment operations, so explicit usage context is needed.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond that, such as the source scope (uploaded/emailed) but nothing about pagination, output shape, or request limits. It is consistent with the annotations, so no contradiction.
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 core action and scope. It contains no unnecessary words or repetition, making it highly efficient.
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 6 parameters and no output schema. The description does not explain return format, pagination behavior, or the effect of fields/output_mode. While it is a simple list operation, the lack of detail on output shape and pagination makes it incomplete for an agent to use effectively without prior knowledge.
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 only 33% (fields and output_mode have descriptions; limit, offset, filters, and session_path lack them). The description mentions filtering by source or status, which adds meaning to the filters object, but it does not elaborate on pagination parameters or session handling. It partially compensates for the low coverage but not fully.
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 lists uploaded and emailed receipts with optional filtering. The verb 'List' and resource 'receipts' are explicit, and it distinguishes from sibling tools like receipts_upload_receipt or receipts_delete_receipt.
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 that this is for listing receipts, but it does not explicitly mention alternatives or exclusions (e.g., when to use a different list tool or fetch a single receipt). However, the purpose is unambiguous and no misleading guidance is given.
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:

[![monarch-mcp2 MCP server](https://glama.ai/mcp/servers/erikrubstein/monarch-mcp2/badges/card.svg)](https://glama.ai/mcp/servers/erikrubstein/monarch-mcp2)

Score Badge

Copy to your README.md:

[![monarch-mcp2 MCP server](https://glama.ai/mcp/servers/erikrubstein/monarch-mcp2/badges/score.svg)](https://glama.ai/mcp/servers/erikrubstein/monarch-mcp2)

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/erikrubstein/monarch-mcp2'

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