monarch-mcp2-obot

by dcode

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are cleanly namespaced by domain with distinct resource-action pairs, so the overall set is navigable. However, a few pairs like reports_get_report_data vs reports_get_saved_report and transactions_get_transaction_attachment vs transactions_download_transaction_attachment could cause misselection because the descriptions are too terse to fully separate them.
Naming Consistency5/5
All tools use a consistent lowercase snake_case domain_verb_noun pattern, with familiar verbs like list, get, create, update, and delete. Minor variations such as remove vs delete or archive vs delete are tied to specific resource behavior and do not break the overall pattern.
Tool Count1/5
At 127 tools, this is an extreme count that creates a large context and selection burden for an agent. Even though the tools are organized by domain, this many operations makes the surface unwieldy and impractical for reliable agent navigation.
Completeness5/5
The tool surface provides comprehensive lifecycle coverage across accounts, categories, tags, transactions, budgets, goals, recurring streams, investments, reports, receipts, and household data. Read-only analytics and supporting operations like attachments, matches, and rollover settings are also present, leaving few obvious dead ends.
Average 2.6/5 across 127 of 127 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 safety profile is covered. However, the description adds no behavioral context of its own, such as how net worth performance is aggregated, how adaptive granularity changes results, or how date ranges are handled, so it contributes nothing beyond the structured 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 a single, under-specified sentence that adds no detail; this is under-specification rather than meaningful conciseness. It briefly front-loads the resource name but contains no structure, caveats, or context that would justify its 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?
With 6 parameters, a nested AccountFilterInput, date inputs, an output_mode enum, no output schema, and many sibling tools that overlap in domain, this definition is far from complete. It lacks any information about the returned shape, date range constraints, filtering semantics, or what differentiates this from historical balances/breakdown endpoints.
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%, covering fields and output_mode, but filters, start_date, end_date, and use_adaptive_granularity are undocumented in the schema and the description mentions none of them. Because coverage is low, the description was required to compensate and instead provides zero parameter explanation.
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 net worth performance.' merely restates the tool's name/title and provides no definition of what 'performance' means (e.g., time-series returns, growth over period, or a chart dataset). It also does not distinguish the tool from nearby siblings like accounts_get_net_worth_breakdown or accounts_get_historical_balances, so an agent cannot tell what unique result this returns.
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 about when to choose this tool over alternatives. The sibling list includes several accounts_* net-worth/history tools, but the description never names a selection condition or exclusion, leaving the agent to guess from parameter names and 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'may delete, clear, reset, or otherwise remove data' adds little beyond the structured hints. It does not disclose what specific data is removed, whether the operation is scoped to a month/category, or what state remains. No contradiction exists with the annotations, but the behavioral context is 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 short, but not effectively concise: the second sentence 'This may delete, clear, reset, or otherwise remove data' is vague and repeats the destructive annotation without operational value. The lack of specificity is under-specification rather than tight writing, and the description is not front-loaded with the most useful 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?
This is a destructive operation with 7 parameters, no output schema, and a large sibling toolset, yet the description provides almost no operational context. It fails to explain what data is reset, how month filters the operation, what overwrite_existing does, or how this differs from budget_clear_budget. An agent would be unable to predict the tool's effect or invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description does not mention any parameters. The required 'month' parameter has no description, and important options such as category_ids, category_type, budget_variability, and overwrite_existing are left entirely unexplained. With low schema coverage, the description needed to compensate, but it does not.
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' essentially restates the tool name without specifying what a reset entails. It does not distinguish this from siblings like budget_clear_budget or budget_reset_budget_rollover, and gives no detail about scope (e.g., month, categories, amounts). The added clause 'may delete, clear, reset, or otherwise remove data' is too generic to clarify the actual resource being 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?
No guidance is provided about when to use this tool versus alternatives such as budget_clear_budget, budget_reset_budget_rollover, or the various budget_set_* tools. There is no mention of prerequisites, filters, or conditions that would help an agent choose this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile: readOnlyHint=true, idempotentHint=true, and destructiveHint=false. However, the description itself adds no behavioral insight beyond those annotations; it does not mention date-range semantics, filtering behavior, or what shape of summary is returned.
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 and free of filler, but this is under-specification rather than effective conciseness. It uses none of the available space to clarify scope, inputs, or output.
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, five parameters, required date strings, a nested filter object, and several closely related sibling tools, the description is far too minimal to support correct tool selection or invocation. An agent would still not know what data is returned or what date formats are expected.
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 zero parameter-level meaning. Schema description coverage is only 40%, so the description needed to compensate for undocumented parameters such as start_date, end_date, and the nested filters object, but it does not.
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 is a verbatim restatement of the tool name and title: 'Get cashflow summary.' It names a verb and resource but adds no definition of what a cashflow summary actually contains, and it does not differentiate this tool from sibling tools like cashflow_get_cashflow_trends or cashflow_get_cashflow_breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no usage context, no when-to-use guidance, and no mention of alternatives. The description only implies the generic action without telling an agent when to select this over the other cashflow tools or reports_get_report_data.
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 state readOnlyHint=false and idempotentHint=false, and the description only adds the vague note that it 'may create or update Monarch data.' This adds little beyond what annotations convey and does not disclose real behavioral consequences such as whether a transaction is created, whether funds move between accounts, or how include_in_budget affects budget 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 short, but brevity here is under-specification rather than earned conciseness. The first sentence repeats the tool name and the second is a generic warning, so neither sentence provides substantive information worth its place.
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 eight parameters, a mutating action, no output schema, and many sibling tools, the description is dramatically incomplete. It fails to define the core operation, parameter roles, effect on budget, return value, or how it relates to goal contribution/withdrawal workflows.
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%, so the description must compensate for undocumented parameters, but it explains none of them. goal_id, account_id, amount, date, notes, and include_in_budget are left without meaning; an agent cannot tell whether amount is a currency amount, how it relates to the account, or what include_in_budget does.
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 'Contribute to goal' directly restates the tool name and title, so it is a tautology rather than an explanation. 'This may create or update Monarch data' is a generic side-effect note and does not clarify what contributing means or how it differs from siblings like goals_withdraw_from_goal or goals_link_goal_account_balance.
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 gives no guidance about when to use this tool versus alternatives. It does not mention contributing money from an account, linking balances, withdrawing, or any condition that would select this tool over the many closely related goals_* operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. However, the description adds no behavioral context beyond the annotations, such as whether the result is scoped by account, date, hidden holdings, or what output shape variations 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 technically short but this is under-specification rather than effective conciseness. A two-word phrase earns no substantive information and does not front-load any meaningful behavior, constraints, or selection criteria.
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 seven parameters, no output schema, and a large sibling set, the description is radically incomplete. It fails to explain what a 'portfolio' is, what the response contains, how filtering parameters work, or how this relates to adjacent investment tools. An agent cannot invoke this correctly based on the provided definition.
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 five of seven parameters lacking any schema description. The tool description does nothing to explain fields, dates, account_ids, top_movers_limit, or include_hidden_holdings, leaving the agent to guess their meaning and format.
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 is a bare tautology: 'Get portfolio' restates the tool name/title without adding any specificity about what a portfolio contains or how it differs from sibling tools like investments_list_holdings or investments_get_holding_performance. An agent cannot tell what resource, scope, or aggregation is being returned.
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. There is no indication of when to call this tool versus investments_list_investment_accounts, investments_list_holdings, or investments_get_holding. Neither prerequisites, alternatives, nor exclusion 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 already cover the safety profile (readOnly, openWorld, idempotent, not destructive), so the description needs to add behavioral context. It adds none: no mention of default grouping, date range semantics, output modes, or filtering behavior. It doesn't contradict the annotations, but it provides no extra 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 text is short, but it is under-specified rather than concisely structured. A single vague phrase does not earn its place as a helpful description; it reads as a stub. There is no front-loaded useful detail to outweigh the 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?
The tool has 7 parameters, 3 required, a low schema coverage, and no output schema. The description is far too minimal to be complete: it doesn't explain what the breakdown returns, how direction and group_by interact, or what filters/fields affect. An agent has essentially no support beyond the schema and names.
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%, with descriptions only on fields and output_mode. The description supplies no parameter semantics, so it fails to compensate for the missing context on start_date, end_date, direction, group_by, and filters. Parameter names and enum values provide some inherent clarity, which prevents a 1, but the description itself adds zero meaning.
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' essentially restates the tool's name and title without adding meaning. 'Breakdown' is undefined and the description fails to differentiate this from cashflow_get_cashflow_summary or cashflow_get_cashflow_trends. It offers nc more value than the resource name 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?
No guidance is provided about when to use this tool instead of alternates. The description doesn't mention the sibling cashflow tools or any conditions that would favor a breakdown over a summary or trends. An agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the description's 'may create or update Monarch data' largely restates the open-world write nature rather than adding new behavioral detail. It does not disclose what data may change, whether renames propagate to historical transactions, or whether effects are reversible. No contradiction with annotations, but 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 short and front-loaded, but its first sentence 'Update category' is redundant with the title and does not earn its place. The text is under-specified rather than efficiently informative; only the second sentence carries any content, and it is vague.
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 mutating tool with six parameters, one required, no output schema, and only 33% parameter documentation, a two-sentence description is inadequate. The annotations cover the safety profile, but the description leaves the semantics of the operation, side effects, and parameter meaning unexplained, which is especially risky given the openWorldHint=true annotation.
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% (fields and output_mode are documented in the schema), yet the description mentions no parameters at all and fails to compensate for the four undocumented ones: icon, name, group_id, and category_id. An agent cannot determine from the tool definition what group_id or icon mean or what constraints apply.
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 states 'Update category', which is essentially a tautology that restates the tool name and title ('Categories Update Category'). It does not explain what updating a category entails—rename, icon change, group reassignment—or how it differs from sibling tools like categories_create_category or categories_update_category_group. The second sentence, 'This may create or update Monarch data,' is vague about scope and effect.
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 for when to use this tool versus the many closely related siblings, such as categories_create_category, categories_remove_category, categories_reactivate_category, or categories_update_category_group. There are no preconditions, exclusions, or alternative-routing cues, leaving an agent to infer the appropriate 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, and the terse description does not contradict them. However, the description contributes no behavioral context beyond the annotations — no mention of output_mode shapes (summary/full/raw), field filtering, or what data the goal includes — so it adds essentially zero value here.
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?
'Get goal.' is under-specification, not conciseness — it duplicates the tool name and title, so the description does not earn its place as independent information. There is no front-loading problem, but there is also no content.
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 present, the description bears the burden of explaining what a goal entity contains, how summary/full/raw modes differ, and how this tool relates to goals_get_goal_budget_amounts. It does none of this. The schema and annotations partially mitigate the gap, but a two-word description is fundamentally inadequate for a 3-parameter retrieval tool in a large sibling family.
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%: the fields and output_mode parameters carry meaningful descriptions in the schema, and goal_id is self-explanatory, but the tool description itself adds no parameter semantics whatsoever. Since coverage falls short of the >80% threshold for the baseline-3 treatment, and the description compensates for nothing, a 2 is appropriate.
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 goal.' is a word-for-word restatement of the tool title 'Get Goal' and adds zero information beyond the name. It fails to distinguish this from siblings like goals_list_goals or goals_get_goal_budget_amounts, so an agent cannot tell which retrieval operation returns the full goal object versus 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 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 never mentions that a goal_id is required, nor does it differentiate from goals_list_goals (retrieve many vs. one) or goals_get_goal_budget_amounts (goal budget data vs. goal itself).
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 detail beyond the annotations, which already indicate read-only, idempotent, and non-destructive behavior. It does not mention aggregation semantics, default grouping, output modes, or any transformation logic. The description neither contradicts the annotations nor enriches 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?
The description is only three words, which is under-specification rather than purposeful conciseness. While it is inherently concise, it lacks structural orientation such as key concepts, defaults, or examples that would help an agent use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has multiple aggregation parameters, a large nested filter object, no output schema, and no behavioral description. One sentence provides almost no actionable context for an agent to understand what data is returned, how filters combine, how grouping affects results, or what output_mode should be selected. Given the tool's complexity, this description is fundamentally inadequate.
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 and no parameter explanations in the description, the agent must infer meaning from names like filters, group_by, and fill_empty_values. The schema documents fields and output_mode, but the complex TransactionFilterInput and aggregation parameters remain unexplained, and the description does nothing 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 report data' is essentially a restatement of the tool name and title, providing no differentiation from the sibling reports_get_saved_report, which also retrieves report-related data. It names a verb and resource at a very abstract level but gives no indication of what a 'report' is in this context or what data it returns.
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_get_saved_report, reports_list_saved_reports, or the broader transaction/aggregation tools. The description provides no context for selection, prerequisites, or typical 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 destructiveHint=true and readOnlyHint=false, so the description's 'This may delete, clear, reset, or otherwise remove data' merely restates that safety profile. The description does not add useful context such as whether data is irrecoverable, whether a confirmation is required, or the scope of the deletion (single month vs. entire budget). The word 'may' introduces unnecessary uncertainty.
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 text is short at two sentences, but the first sentence is a tautology of the tool name and the second is a vague, hedged warning. Neither sentence earns its place by conveying useful, non-obvious information. The structure is sparse rather than 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 destructive tool with a confirm flag, a required month, and multiple similar budget-related siblings, the description is significantly incomplete. It does not explain the effect on budget data, the meaning of the month parameter, why confirm is needed, or how it differs from budget_reset_budget. The absence of an output schema means the description carries more burden, which it fails to meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, leaving required parameter 'month' and important parameter 'confirm' undocumented. The tool description mentions no parameters at all, so an agent receives no help understanding what 'month' refers to or how the destructive operation is gated by confirm. The schema documents 'fields' and 'output_mode', but the description does nothing to compensate for the uncovered parameters.
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's first sentence 'Clear budget' essentially restates the tool name and title, adding no new information. The second sentence 'This may delete, clear, reset, or otherwise remove data' is hedged and vague, failing to specify what 'budget' refers to or what data is actually affected. The description does not distinguish this tool from sibling budget_reset_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?
There is no guidance on when to use this tool versus alternatives such as budget_reset_budget or budget_reset_budget_rollover. The description provides no context about prerequisites, the need to set confirm=true, or scenarios where this tool is appropriate or inappropriate. The large sibling list creates ambiguity that the description does not resolve.
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 this as readOnly, idempotent, open world, and non-destructive. The description adds no behavioral context beyond that, such as whether the budget must pre-exist, how output_mode alters behavior, or what happens when no data is found. It does not contradict 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than effective conciseness. It front-loads nothing because it contains no useful information beyond the tool name. A minimal description can earn points, but only when the remaining substance is present in schema or annotations.
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?
There is no output schema and no return-shape description, so an agent cannot know what data to expect. The tool has one required parameter (month) whose format is not clarified, and no guidance distinguishes this from related budget tools. This description is not sufficient 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?
The schema describes the fields and output_mode parameters, but the required month parameter only has a title and type. The description provides no clarification of acceptable month formats or meaning. With 67% schema coverage and no parameter details in the description, the required parameter remains underdocumented.
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 budget." is essentially a restatement of the tool name budget_get_budget, providing no additional detail about what 'budget' refers to. It does not distinguish this tool from closely related siblings such as 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of the required month parameter, expected context such as retrieving a specific month's budget, or exclusions like budget category or settings retrieval.
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 false, covering the safety profile. However, the description adds no behavioral context beyond the word 'Get'—it does not explain the nature of the returned trends, how filters affect results, or what the interval grouping means.
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 and free of filler. However, it is under-specified to the point of providing little value, so it is not 'appropriately sized' for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, two required, filter objects, enums, and no output schema, this tool needs a substantive description. 'Get cashflow trends' is completely inadequate: an agent cannot tell what the trends represent, how the date range is aggregated, or how filters and output modes affect results.
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%, with only fields and output_mode having descriptions. The description does not compensate: it explains none of the six parameters, leaving start_date, end_date, interval, and filters semantically underdocumented for an 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?
The description 'Get cashflow trends' is essentially a restatement of the tool name and title, so it falls into tautology territory. It gives no concrete detail about what a cashflow trend is or how this tool differs from sibling tools like cashflow_get_cashflow_summary and cashflow_get_cashflow_breakdown.
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 about when to use this tool versus the closely related cashflow summary and breakdown tools. The interval parameter implies time-series aggregation, but the description itself says nothing about appropriate use cases 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that—it does not explain output modes, whether nested categories are included, or what 'raw' vs 'summary' implies for a single group. Since it adds no value beyond the annotations, the score is low.
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 definition is extremely short, but this is under-specification rather than effective conciseness. The single sentence 'Get category group.' repeats the tool title without earning its place by adding unique, useful information. There is no structured presentation of key facts such as required parameter, typical use, or expected result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, a minimal description, and a required parameter that is undocumented, the definition is not complete enough for an agent to understand the return shape or how to use this in a broader workflow. It does not explain what a category group is, how to discover group_id, or what the response contains. Annotations cover safety but not 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 description 'Get category group.' adds no meaning to the input parameters. Schema descriptions cover fields and output_mode, but group_id—the only required parameter—has no description in either the schema or the tool description. With 67% schema coverage, the description should at least clarify that group_id identifies a specific category group, but it does not.
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 category group.' is essentially a restatement of the tool name/title 'Categories Get Category Group'. It provides no additional detail about what a category group is, what it contains, or how it differs from the sibling tools categories_get_category and categories_list_category_groups. This is a tautology rather than a meaningful purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description does not mention that this fetches a single group by ID, when to prefer categories_list_category_groups, or how it relates to categories_get_category. The agent is left with no contextual routing information.
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 convey that this is read-only, idempotent, and non-destructive, but the description itself adds no behavioral context. It does not mention what is returned, whether the result is a single object, or how output_mode affects the response.
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?
One short sentence is not effective conciseness here; it is under-specification. The description contains no front-loaded semantic content beyond the tool 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?
For a three-parameter tool with no output schema, this description is far too thin. It omits what a security is, what the response contains, and how this call relates to the broader investments tool family, forcing the agent to rely entirely on the schema and name inference.
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 documents fields and output_mode reasonably well, but security_id has no description and the tool description provides no parameter insight. With only 67% schema coverage, the description should compensate for the undocumented required parameter but does not.
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 is essentially a verbatim restatement of the tool title: 'Get security.' adds no conceptual information beyond the name. It does not define what a security is or differentiate this from sibling tools like investments_get_holding or investments_search_securities.
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 mention of prerequisites, and no exclusion criteria. An agent gets no help deciding between investments_get_security, investments_get_holding, or investments_search_securities.
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 readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. However, it adds no behavioral context beyond the annotations, such as what happens for missing ids, whether associated merchant/category data is included, or how output_mode affects the response.
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 maximally concise, but it is under-specified rather than efficiently informative. One short sentence restating the tool name does not earn its place in a definition that needs to support correct tool selection and invocation.
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?
There is no output schema, so the description should explain what a receipt getter returns or how to choose output shapes, but it does not. Combined with a minimal description and one undocumented required parameter, the definition leaves too much for the agent to infer.
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 already documents fields and output_mode, but receipt_id has no description and the tool description adds no parameter-level clarification. The description 'Get receipt.' contributes nothing to understanding the three params or their interplay.
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 receipt.' is essentially a restatement of the tool title 'Get Receipt' and the tool name receipts_get_receipt. It names the verb and resource but provides no detail about scope, return content, or how it differs from sibling tools like receipts_list_receipts.
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 about when to use this tool versus alternatives. The existence of receipts_list_receipts implies this is for fetching a single resceipt by id, but the description never states that usage condition or contrasts with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured metadata. The description adds no behavioral context beyond the word 'get'—no mention of output shape, return values, permissions, or side effects—so it contributes nothing beyond what the 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 short and front-loaded, but it is under-specified and redundant with the title. The single sentence does not earn its place because it adds no new information; this brevity is a symptom of missing content rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and several similar recurring domain siblings, a one-sentence description is insufficient to orient an agent. It omits what a recurring stream is, which output modes are relevant, and how this tool differs from recurring_get_recurring_summary or recurring_list_recurring_streams. The annotations cover the safety profile but not the operational 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 schema description coverage at 50%, fields and output_mode are documented in the schema but reccurring_id and include_liabilities are not. The description provides no compensating detail, so an agent gains no additional understanding of the parameters from the description itself.
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 stream.' simply restates the tool name and title without explaining what a recurring stream is or what data is returned. It also fails to distinguish this tool from sibling tools like recurring_get_recurring_summary or recurring_list_recurring_streams, making it tautological rather than informative.
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 such as recurring_list_recurring_streams or recurring_get_recurring_summary. The only implied context is the singular 'stream' and the required recurring_id in the schema, but the description itself provides no explicit usage conditions, exclusions, 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 carry the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false), so the bar for added context is lower but the description still must add value. It adds none: no mention of the include_pending/include_liabilities defaults, no filter behavior, no output-shape semantics. The description contributes zero behavioral context beyond the structured 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?
Three words is under-specification, not conciseness. There is no wasted text, but the description is far smaller than the tool's complexity warrants (5 parameters, a nested filter object, three output modes). A single tautological sentence cannot serve as an adequate definition.
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 a one-line description, an agent cannot anticipate what the summary/full/raw output modes return, what include_pending and include_liabilities control, or how filters compose. The description does not distinguish this tool from the recurring get/summary/occurrences siblings. For a 5-parameter list tool, this is materially 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 40% (only fields and output_mode have schema descriptions; filters, include_pending, and include_liabilities do not), so the description must compensate for five parameters. It mentions none of them, leaving ambiguous terms like 'pending' and 'liabilities' unexplained. The nested RecurringFilterInput properties are understandable only through naming inference and the enum values already present in the schema.
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 recurring streams.' is a near-verbatim restatement of the tool's own title ('List Recurring Streams') and name (recurring_list_recurring_streams). It supplies no definition of what a recurring stream is and does not differentiate the plural list operation from siblings like recurring_get_recurring_stream or recurring_get_recurring_summary. This is a tautology rather than an informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool versus recurring_get_recurring_stream, recurring_list_recurring_occurrences, or recurring_get_recurring_summary. There is no mention of filter-driven selection, default inclusion of pending/liability streams, or when the summary/full/raw output modes are appropriate. An agent must infer all selection context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already provide. While annotations indicate a read-only, idempotent, non-destructive operation, the description contributes nothing about return behavior, error conditions, 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?
At seven words, the description is concise, but it is under-specified rather than efficiently informative. It merely repeats the tool's name/title and fails to use the available space to add helpful context.
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 no output schema and four parameters, the description is far too thin. It leaves the agent without guidance on the return shape, the meaning of redirect_posted, or how output_mode affects the result, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema has descriptions for 'fields' and 'output_mode', but 'transaction_id' and especially 'redirect_posted' are left unexplained, and with 50% schema coverage the description needed to compensate for these 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 transaction.' is essentially a verbatim restatement of the title 'Get Transaction' and the tool name. It identifies the resource and action, but it is a tautology and gives no distinguishing detail against sibling tools like transactions_get_transaction_splits or transactions_list_transactions.
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 prerequisites, and no context about how it differs from the many other transaction-related tools. An agent must infer usage entirely from the name and schema.
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 false, so the safety profile is covered. The description adds no behavioral context beyond that, such as what is returned, how missing splits are handled, or how output_mode and fields affect the response.
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, front-loaded sentence with no filler, which is concise. However, it is under-specified for a 3-parameter tool, so it earns only a middle score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of the return shape or the semantics of 'splits', the description is not complete enough for an agent to understand the tool's behavior. It also fails to explain how this relates to the broader transactions tool family, making selection among siblings harder.
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 documents fields and output_mode, but transaction_id has no description and the tool description does not explain it. At 67% schema description coverage, the description should compensate for the undocumented required parameter, but it adds no parameter-specific meaning.
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 transaction splits' is a direct restatement of the tool title and name, adding no new information about what the operation does. It names a resource and verb but is essentially a tautology, with no explicit differentiation from siblings like transactions_get_transaction or transactions_update_transaction_splits.
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. The description does not mention transactions_get_transaction for retrieving a single transaction, or transactions_update_transaction_splits for modifying splits, leaving an agent to infer the appropriate 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 indicate a non-read-only, non-idempotent write operation, and the description's 'This may create or update Monarch data' adds little beyond that. It does not disclose what happens to split data, whether the operation is reversible, or what side effects may occur.
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 text is short and front-loaded with the action, but the second sentence is generic and adds limited value. It is not verbose, but the brevity borders on under-specification rather than effective 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 mutating operation with no output schema, the description fails to explain what 'unsplit' actually does, what changes occur, and what the caller should expect. An agent would not have enough context to invoke this tool correctly or safely.
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 leaves transaction_id undocumented, and the description provides no additional meaning for this required parameter. Fields and output_mode have schema descriptions, but the critical required parameter lacks semantic guidance and the description does not 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 'Unsplit transaction' is essentially a restatement of the tool's name and title, and does not explain what unsplitting entails, such as removing splits from a transaction or consolidating them. It does not differentiate this tool from related transaction tools like transactions_update_transaction_splits.
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 transactions_get_transaction_splits or transactions_update_transaction_splits. No conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. However, the description adds no behavioral context beyond what the name implies; it does not disclose output shape, pagination, ordering, or any limits. With annotations present, the bar is lower, but the description still contributes nothing.
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 under-specification rather than effective conciseness. It omits essential context about what the history contains and how it relates to sibling tools, so the brevity does not serve the agent.
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 ambiguity of 'account history', the description is incomplete. It does not describe the return format, scope of history, or how to interpret the output_mode parameter in this context. An agent would need to inspect the schema and make assumptions about the tool's actual behavior.
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 67% (fields and output_mode are documented, account_id is not). The description itself provides no parameter-level detail, but the schema already explains the two non-trivial parameters well. Given moderate coverage and an obvious required account_id, the description's lack of additional parameter semantics is a gap but not severe.
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 a near-verbatim restatement of the tool name and title, providing no additional specificity. It does not clarify what constitutes 'history' (e.g., transactions, balance changes, activity events) or how it differs from sibling tools like accounts_get_historical_balances.
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 such as accounts_get_historical_balances, accounts_get_account, or transactions_list_transactions. An agent cannot determine the appropriate context for selecting this tool over its siblings.
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 provide the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), but the description adds no behavioral context of its own — nothing about 404 behavior, return shape, or that it returns exactly one category. There is no contradiction between the description and annotations, so this is not a 1.
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 words is not conciseness but under-specification — the sentence merely restates the title and earns no informational weight. There is no front-loaded useful content because there is none; the space could have held a differentiating clause.
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 present, the description should at least clarify what the call returns, but it says nothing. Given the large sibling set including the confusable categories_get_category_catalog and categories_get_category_group, a sentence distinguishing this tool was needed; the bare phrase is inadequate.
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 already documents two of three parameters well: fields and output_mode both have meaningful descriptions. The description contributes nothing about parameters, but the undocumented category_id is self-explanatory from its name, required status, and string type, so at 67% coverage the schema carries the weight adequately.
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 category.' is essentially a verbatim restatement of the title 'Get Category' — a tautology. It does not say what a category is in this domain, nor does it distinguish this tool from siblings like categories_get_category_catalog or categories_get_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?
No guidance is given on when to use this tool versus alternatives. The description never mentions that categories_list_categories is the way to discover category IDs, nor does it contrast with the closely named categories_get_category_catalog and categories_get_category_group.
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 false, but the description adds no behavioral context beyond the word 'Get'. It does not state what is returned, whether a binary download is involved, or any edge conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specification rather than conciseness: it merely restates the title and does not add information that would help an agent invoke the tool correctly.
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 a potentially ambiguous relationship to download_transaction_attachment, the description is incomplete. It fails to explain the return type or how this tool differs from the sibling download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides meaningful descriptions for fields and output_mode, and the description adds no additional parameter meaning. The required attachment_id has only a title, but its semantics are reasonably inferable from its name and the attachment tool family.
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 transaction attachment' restates the tool name and title without adding any specification of what is retrieved. It does not distinguish this tool from transactions_download_transaction_attachment, which has overlapping semantics.
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 list, download, upload, or delete attachment siblings. An agent cannot determine whether this returns attachment metadata, file content, or something else.
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, openWorldHint, and destructiveHint false, so the description adds no behavioral disclosure beyond what is structured. It does not describe missing-account behavior, pagination, or how output_mode and fields affect the result, and it only repeats the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is trivially short and front-loaded, but this is under-specification rather than concise clarity. A single sentence that restates the title does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with strong annotations, the combination of schema and required account_id is almost enough to invoke it. However, there is no output schema and no description of return shape or relationship to list_accounts, so the definition is only minimally complete.
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 already provides meaningful descriptions for fields and output_mode, and account_id is self-explanatory from its name and required status. The description itself adds no parameter semantics, but with 67% schema coverage and low parameter complexity, the schema carries that burden adequately.
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 is a word-for-word restatement of the title ('Get Account' vs 'Get account.') and adds no detail about what an account is or that this retrieves a single account by account_id. It does nothing to differentiate the operation from siblings such as accounts_list_accounts, accounts_get_account_history, or 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?
There is no guidance on when to use this tool versus alternatives. The agent is not told to use it when it already has an account_id and needs a single account object, nor is any sibling or exclusion mentioned; only the schema's required account_id provides an implicit hint.
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, openWorldHint=true, and destructiveHint=false, so the description carries a low bar for safety disclosure. But it adds no behavioral context beyond restating the operation: it does not explain default filtering behavior (whether hidden/deleted accounts are exclued), whether results are per-account or aggregated, or what net-worth-specific grouping is applied. No contradiction with annotations exists.
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 four-word description is maximally short, but this is under-specification rather than effective conciseness. It contains no front-loaded distinguishing information, no scoping constraints, and no operational detail, so the terseness costs more information than it saves.
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 params including a nested AccountFilterInput with 6 sub-properties, 2 required date/time params, and no output schema — moderately high complexity. The description addresses none of this: no return-shape guidance, no date/time semantics, no filter defaults. The schema and annotations carry almost the entire burden, leaving the agent to guess at the meaning of the required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% — start_date and timeframe are required yet undocumentated (no date format, no timeframe unit/semantics), and the nested filters object has no description at all. With low coverage, the description must compensate, but 'Get net worth breakown' says nothing about date formats, filter semantics, or output modes. The coverade is left entirely to param-name inference.
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 a verb and resource ('Get net worth breakdown'), so it is not a tautology. However, 'breakdown' is ambiguous — it does not say whether the breakdown is by account type, by asset/liability, or over time, despite required start_date/timeframe params hinting at a time dimension. It also does not distinguish this from the closely named sibling accounts_get_net_worth_performance or the parallel cashflow_get_cashflow_breakdown.
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 of any kind is provided. The description never says when to prefer this tool over accounts_get_net_worth_performance, accounts_get_historical_balances, or cashflow_get_cashflow_breakdown, all of which could plausibly overlap in purpose. No exclusions, prerequistes, or alternatives are named.
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 safety is covered. However, the description adds no behavioral context beyond the bare verb 'load'—it does not explain whether loading restores a previously saved session, whether it overwrites current state, what data is returned, or any prerequisites.
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 undeniably concise, but this is under-specification rather than efficient structure. A three-parameter tool with no output schema needs more than 'Load session.' to orient an agent.
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 lacks essential context: what a session is, what is returned, how fields/output_mode/include_token affect the result, and when to use this instead of auth_status or auth_login. The presence of a rich sibling list and no output schema makes this brevity insufficient.
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%, with fields and output_mode documented, but include_token has no description. The tool description itself adds no parameter meaning, does not explain the effect of output_mode or fields, and fails to compensate for the undocumented include_token parameter.
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 a verb ('Load') and a resource ('session'), so the basic action is identifiable. However, it is too vague to stand apart from sibling tools like auth_create_session, auth_save_session, and auth_status, and it does not clarify what 'session' means in this context or what loading 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?
There is no guidance about when to call this tool versus the many auth-related siblings such as auth_save_session, auth_create_session, or auth_login. The name hints at a load-after-save workflow, but the description never states that intended usage or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond this: it does not mention how month or category_id are interpreted, what happens with missing data, or what output shape to expect.
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 this is under-specification rather than effective conciseness. A single vague sentence does not earn its place because it conveys almost no information beyond the tool name.
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 required parameters and no output schema, the description should clarify required input semantics, return behavior, and relationship to sibling tools. None of that is present. The annotations cover safety, but the description leaves too much to inference.
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%: the fields and output_mode parameters have descriptions, but the required month and category_id parameters have no descriptions in the schema. The description 'Get budget category' does not compensate by explaining the expected format, semantics, or relationship of these 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 names the resource ('budget category') and implies a read operation ('Get'), so the basic purpose is clear. However, it is so terse that it does not distinguish this tool from siblings like categories_get_category or budget_get_budget, and it offers no detail about scope or what a 'budget category' means in this API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related tools such as categories_get_category, budget_get_budget, or budget_list_budget_months. The context is only implied by the name and parameters, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it 'may delete, clear, reset, or otherwise remove data,' which is a warning, but this mostly restates the destructiveHint=true annotation. It doesn't say what rollover data is affected, whether the operation is reversible, or how month/category scoping changes the blast radius. No contradiction with annotations, but no meaningful new behavioral disclosure.
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 and front-loaded with the main action, but the second sentence ('This may delete, clear, reset...') is generic and largely duplicates the destructiveHint annotation. It is appropriately concise in length, but the second sentence doesn't earn its place with specific 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?
For a destructive tool with six parameters and no output schema, this provides almost no operational context. It doesn't define what rollover data is reset, what the month parameter selects, what starting_balance means, whether the action covers specific categories/groups, or what the response contains. This is inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description explains none of the six parameters. Schema coverage is only 33% (fields and output_mode), and critical parameters like month, category_id, category_group_id, and starting_balance remain unexplained. The description doesn't compensate for the low coverage, leaving the agent without enough information to set parameters correctly.
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 names the action and resource ('Reset budget rollover'), but it adds little beyond the tool title and gives no details about scope (category, group, or whole budget). It also doesn't distinguish this from closely related siblings like budget_reset_budget, budget_clear_budget, or budget_set_budget_category_rollover. The generic warning about deleting data doesn't clarify 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, what prerequisites or context are needed, or what alternatives exist. An agent cannot tell from the description whether to choose this over budget_set_budget_category_rollover or budget_reset_budget. The name hints at the intended use, but the description provides no 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?
The description states 'This may create or update Monarch data,' which loosely reflects the openWorldHint and non-idempotent annotations, but it adds no meaningful behavioral context beyond those structured signals. It does not disclose whether existing rollover settings are overwritten, what side effects occur for budget calculations, or what data is affected. Since annotations already signal mutation and non-idempotency, the description carries minimal 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 short, but brevity is not the same as conciseness. The first sentence simply restates the tool name, and the second is a generic mutation warning that is already encoded in annotations. Neither sentence earns its place by adding useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and only 20% schema description coverage, this definition is far from complete. It lacks explanation of rollover behavior, the role of each parameter, expected input formats, and return values. The surrounding sibling list shows there are closely related rollover tools, but the description provides no context to choose among them.
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 20%, and the description does not compensate for the undocumented parameters. Required parameters like category_id and enabled are not explained, nor are optional ones such as frequency, rollover_type, target_amount, apply_to_future, and starting_balance. An agent cannot determine valid formats, expected date conventions, or how these parameters interact.
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 names a specific verb and resource: 'Set budget category rollover.' This distinguishes it from sibling tools like budget_set_budget_group_rollover through the 'category' qualifier, though it does not explain what rollover means or how it differs from reset_budget_rollover. It is clear enough for initial identification but lacks differentiation detail.
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 about when to use this tool versus alternatives such as budget_set_budget_group_rollover, budget_set_flex_rollover_settings, or budget_reset_budget_rollover. The phrase 'This may create or update Monarch data' is a side-effect warning, not a usage condition. An agent has no basis for selecting this tool over its siblings.
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 readOnlyHint, idempotentHint, and destructiveHint=false, so the description is not required to restate safety. But the description adds no additional behavioral context—no mention of event ordering, pagination, return shape, or whether the goal must exist. It contributes nothing beyond what the annotations already establish.
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 terse, but this is under-specification rather than effective conciseness. It contains no information about scoping, filtering, or return behavior that would justify such brevity, so it does not earn its place relative to what an agent needs to know.
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 a large sibling set, the description leaves the agent without a clear model of what goal events are, what data the response contains, or how output_mode interacts with the listing. It is not complete enough for a tool with three parameters and no structured output documentation.
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?
Two of the three parameters (fields, output_mode) have descriptions in the input schema, but goal_id is undocumented and the description does not reference it or clarify that events are scoped to a goal. The description therefore adds no parameter-level meaning and fails to compensate for the 67% schema description 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 the verb 'list' and the resource 'goal events', so it identifies the basic operation. However, it is nearly a verbatim restatement of the title and does not clarify what a goal event is or how this differs from related goals_* tools such as goals_list_goals or goals_get_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 about when to use this tool versus alternatives like goals_get_goal, goals_update_goal_event, or goals_delete_goal_event. The description gives no context about prerequisites such as needing a goal_id first or situations where listing goal events 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 a safe, idempotent read, so the description does not need to restate that. But it adds no behavioral context such as whether a missing holding_id returns an error, what response shape to expect, or how output_mode/fields affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. It only repeats the tool name and earns no additional informational 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 three parameters, absent output schema, and a crowded investments sibling group, the description is too sparse to fully orient an agent. It does not mention return shape, filtering, or the relationship to list_holdings/get_holding_performance.
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%; fields and output_mode have descriptions, but the required holding_id has none and the description does not fill that gap. An agent is left to infer that holding_id identifies which holding to fetch.
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 names a specific action and resource ('Get holding'), so an agent can tell this is the read-single-holding tool. However, it is essentially a restatement of the tool name and leaves the boundary against investments_get_holding_performance and investments_list_holdings to inference.
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 about when to use this tool instead of investments_list_holdings or investments_get_holding_performance. The intended use case (retrieve one holding when you already have its holding_id) is only implied by the name and schema.
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 the operation is read-only, idempotent, and non-destructive, but the description adds no behavioral context beyond that. It does not disclose what 'performance' includes, how date range parameters affect results, or what output_mode changes.
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 rather than effective conciseness. It simply restates the tool title and provides no operational detail to help an agent select or invoke the tool.
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 five parameters and no output schema, the description offers almost no context. There is no indication of what the response contains, what date defaults apply, how output_mode affects the result, or how this differs from the many sibling investment 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?
Schema description coverage is only 40%, and the description does not compensate for the undocumented holding_id, start_date, or end_date parameters. The description adds no parameter semantics at all, leaving the agent to guess the meaning and formatting of required and optional inputs.
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 a specific verb and resource: retrieving performance data for an investment holding. It is clear about the general purpose, but it does not differentiate it from sibling tools like investments_get_holding, investments_get_portfolio, or investments_get_security.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related investments tools. The description does not mention prerequisites, contexts, or alternatives, so an agent must rely purely on name inference.
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 establish readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, and the description adds no behavioral context beyond the read-only 'get' operation. It does not disclose what the summary contains, how filters affect aggregation, or that start_date and end_date are required. There is no annotation contradiction, but the description provides no extra transparency 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 only five words, but this is under-specification rather than effective conciseness. It restates the tool's name without front-loading any useful decision-making 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?
For a tool with five parameters, no output schema, and several closely related recurring-tool siblings, this description is materially incomplete. It does not explain the expected return shape, what 'summary' means, or how the date range and optional filters shape the result. An agent would have to rely almost entirely on the schema and tool name.
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%, so the description needed to compensate for the undocumented start_date, end_date, and filters parameters, but it says nothing about parameters at all. Only fields and output_mode have schema descriptions; the description contributes zero parameter guidance.
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 a verb ('get') and a resource ('recurring summary'), but 'recurring summary' is vague: it does not specify what is being summarized or how this differs from sibling tools like recurring_list_recurring_streams or recurring_get_recurring_stream. Sibling differentiation must be inferred from the tool name rather than the description.
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 the closely related recurring read tools. There are no conditions, exclusions, or alternative tool mentions.
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=false, so the safety profile is covered. The description adds no behavioral context beyond the action itself, such as the required date-window behavior, output modes, or how occurrences relate to recurring streams.
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 this is under-specification rather than efficient conciseness. A single clause with no constraints, scope, or context does not provide enough information for an agent to use the tool correctly.
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 six parameters, two required parameters, a nested filter object, and no output schema, the description is far too thin. It leaves the agent without information about the required date range, what an occurrence is, or what the return shape will be.
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%, and key parameters like start_date, end_date, include_liabilities, and all nested filter fields have no descriptions. The tool description also says nothing about parameters, so it 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 description names a specific operation ('List recurring occurrences') and resource, so an agent can tell this is a read-only listing tool. However, it doesn't distinguish occurrences from the sibling recurring_list_recurring_streams or recurring_get_recurring_summary, leaving the domain concept undefined.
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 when-to-use guidance or mention of alternatives. The description doesn't explain when to choose recurring occurrences versus recurring streams or the recurring summary, so the agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a mutation (readOnlyHint=false), non-idempotent, and open-world, so the bar for added context is low but the description barely clears it. It adds only the vague claim that the operation 'may create or update Monarch data' without explaining what triggers the update path or what side effects occur, such as balance updates via should_update_balance. No contradiction with annotations, but the added behavioral context is minimal and confusing.
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 two short sentences, the description wastes no words and front-loads the core purpose. However, the second sentence is vague filler that does not earn its place since it raises an ambiguity instead of resolving one.
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 non-read-only tool with 11 parameters, 5 required, and no output schema, the description is severely incomplete: no return-value information, no handling of duplicates or updates, no explanation of required inputs, and no guidance on how output_mode or fields shape the response. An agent cannot reliably construct a correct call from this definition 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?
With schema description coverage at only 18%, nine of eleven parameters (including required amount, date, merchant_name, and category_id) are undocumented, and the description adds nothing about them. The description does not compensate for the schema gaps — a caller gets no help understanding owner_user_id, goal_id, fields, output_mode, or should_update_balance beyond their raw names.
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 a specific verb and resource ('Create transaction'), so it is not a tautology, and the name distinguishes it from transactions_update_transaction. However, the second sentence ('This may create or update Monarch data') introduces ambiguity about whether the tool creates, updates, or both, which muddies the stated purpose rather than clarifying 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?
No guidance is given for when to use this tool versus siblings such as transactions_update_transaction or transactions_delete_transaction. The 'may create or update' phrasing is the opposite of an exclusion — it never states the conditions under which an update occurs or when a caller should choose the dedicated update 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no behavioral context beyond the annotations; it merely restates the operation and does not mention scoping, return shape, 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?
'Get historical balances.' is very short and front-loaded, but it is under-specification rather than effective conciseness. It restates the tool name and does not earn its place by adding useful 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?
For a tool with four parameters, a nested filter object, and no output schema, a single generic sentence is insufficient. It leaves unclear what historical balances are, how balance_date affects results, what filters do, and what the agent should expect in return.
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 balance_date and filters are only named. The description does not compensate by clarifying the date format, filter semantics, or how balances are scoped.
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 a specific verb and resource: get historical balances. It is reasonably clear about the operation, though it does not differentiate from sibling tools like accounts_get_account_history or mention that balances are tied to a specific date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There are no exclusions, prerequisites, or comparisons with the many sibling account and report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) already establish this is a non-read-only, non-idempotent write, and the description adds only the vague note 'This may create or update Monarch data.' It does not disclose what happens when a budget already exists for the month, whether existing amounts are overwritten, or what consequences the write has, so it adds little 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?
Two sentences, so it is appropriately short and front-loaded with the verb. However, the second sentence ('This may create or update Monarch data') is low-value filler that reads like a disclaimer rather than useful behavioral detail, so the brevity is under-specification as much as 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 write tool with no output schema and an opaque required 'month' parameter, the description omits essential context: expected month format, behavior on an existing budget, return value shape, and how it differs from the budget_set_* family. An agent would not be able to invoke this correctly or predict its side effects from the definition 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 description contributes zero parameter-level information. The schema documents 'fields' and 'output_mode', but the only required parameter, 'month', is described merely as 'Month' with no format guidance (e.g., YYYY-MM), and the tool description does not compensate for that 67% coverage gap.
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 names a verb and resource ('Create budget') so an agent can tell it is a write operation on a budget, but it is vague about scope: it never mentions the month dimension even though 'month' is the sole required parameter, and 'This may create or update Monarch data' muddies what 'create' means. It also does nothing to distinguish itself from the many budget siblings (budget_set_budget_amount, budget_reset_budget, budget_clear_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 given on when to call this tool versus alternatives. Given roughly 20 sibling budget tools including budget_set_budget_amount, budget_reset_budget, and budget_clear_budget, an agent has no criteria to decide which one applies. The second sentence is a data-side-effect disclaimer, not 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as how include_disabled affects the catalog, whether the result is paginated, or what output_mode shapes are available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. A single vague phrase earns no explanatory weight and does not help an agent understand the catalog concept or the tool's output.
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 presence of many closely related sibling tools, the description is incomplete. It fails to explain what a catalog contains, how it differs from listing categories, or how parameters like output_mode and include_disabled affect the returned data.
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 itself provides descriptions for fields and output_mode, covering two of three parameters. The description adds no parameter meaning, but the schema largely compensates; include_disabled only lacks a description, though its name and default are fairly self-explanatory.
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 category catalog' uses a clear verb and resource, so it presents a basic purpose. However, it is essentially a restatement of the tool name and does not explain what a 'category catalog' is, nor does it distinguish this operation from sibling tools like categories_list_categories or categories_get_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?
There is no guidance on when to use this tool versus the many sibling category tools. The description does not mention alternatives such as categories_list_categories or explain any conditions that would favor this endpoint, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already signals mutation, and the description's 'This may create or update Monarch data' adds a generic side-effect warning. However, it does not disclose what specific data changes, whether archiving is reversible, or what impact it has on goal state. It is consistent with annotations but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. 'Archive goal.' adds nothing beyond the tool title, and the second sentence is a vague side-effect warning. It is front-loaded but not appropriately sized for a mutation tool whose semantics are otherwise unexplained.
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 an output schema and the presence of closely related siblings, the description is incomplete. It fails to explain what archiving means, whether it can be undone, how it relates to goals_restore_goal or goals_delete_goal, or what outcome the agent should expect.
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 67%, with fields and output_mode already documented by the schema. The description adds no parameter-level meaning, and goal_id is left undocumented, though its name is self-explanatory. This meets the baseline for high schema coverage but does not exceed it.
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 'Archive goal.' merely restates the tool name and title without explaining what archiving entails or how it differs from sibling actions like goals_delete_goal or goals_restore_goal. It identifies a verb and resource but adds no distinguishing meaning.
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 such as goals_update_goal, goals_delete_goal, or goals_restore_goal. The description offers no context, prerequisites, or exclusion criteria, 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 readOnlyHint=false, so the agent knows this is a mutating operation. The description's 'may create or update Monarch data' adds little beyond what annotations already convey. It does not disclose side effects, idempotency, required permissions, or what happens on duplicate names, and it ignores the openWorldHint signal.
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 and front-loaded with the verb and resource, but the second sentence is generic and adds little value. It is concise but under-specified for a tool with 11 configurable parameters, so it achieves only minimum viability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and rich sibling context, yet the description supplies only a two-sentence summary. Missing crucial details include goal type semantics, date and amount formats, relationship to budget/account linking, and expected response shape. The description is inadequate for an agent to correctly configure a call without guessing.
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 18%, and the tool description provides no parameter explanations. With 11 parameters and only two described in the schema, the agent is left without meaning for crucial fields like goal_type, target_amount, priority, target_date, and planned_monthly_contribution. The description completely fails to compensate for this 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 states a clear verb and resource: 'Create goal.' This distinguishes it from sibling tools like goals_list_goals, goals_get_goal, and goals_update_goal. The added note 'may create or update Monarch data' slightly muddies the create-only purpose, but the core intent remains unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of using goals_update_goal for existing goals, goals_archive_goal for archiving, or any prerequisite conditions. The agent is left to infer usage solely from the tool name and sibling list.
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 convey that this is a non-read-only, non-idempotent operation. The description's 'This may create or update Monarch data' restates this in vaguer terms and adds little concrete behavioral context, such as what happens to an existing goal, whether changes are reversible, or what side effects creation might entail.
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 brief and front-loaded with 'Update goal,' which is good, but it is under-specified rather than usefully concise. The boilerplate clause about Monarch data does not earn its place given how little actionable information is provided for a tool with 13 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?
Given the high parameter count, multiple enums, and absence of an output schema, this description is far from complete. It does not explain which fields can be updated, what the response looks like, or how this relates to sibling goal operations, leaving an agent without enough context to invoke the tool reliably.
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 description coverage and 13 parameters, the description needed to compensate by explaining key parameters, but it does not mention any of them. The schema itself leaves most parameters undescribed, so the agent receives no semantic guidance for goal_id, target_amount, status, priority, or other options.
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 and resource clearly: 'Update goal.' This makes the basic purpose understandable. However, it does not distinguish this tool from goals_update_goal_priorities or goals_update_goal_event, and the clause 'This may create or update Monarch data' is vague and potentially confusing rather than clarifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related goal tools such as goals_update_goal_priorities, goals_archive_goal, or goals_update_goal_event. The description only provides a generic write warning and does not mention required prerequisites or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the name: it does not mention output_mode behavior, field projection semantics, potential errors, or what 'get' returns. No contradiction exists, but the description contributes almost nothing 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 a single short sentence and is not verbose, which is structurally clean. However, it is under-specified rather than efficiently informative; it conveys almost the same information as the title and leaves important operational details absent.
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 simple retrieval tool, the combination of name, schema, and annotations provides partial context, but the description itself is too thin. There is no output schema, no explanation of member_id semantics, no note distinguishing this from list/get siblings, and no coverage of how output_mode and fields affect the result. An agent would need to infer most operational detail from parameter names 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 schema documents fields and output_mode with meaningful descriptions, providing 67% coverage. However, member_id, the only required parameter, has no description and the tool description does not explain its meaning or where to obtain it. The description also does not clarify how fields/output_mode interact with the returned member data.
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 'household member', so an agent can tell it retrieves a member. However, it is nearly identical to the tool name/title and does not clarify whether this fetches by ID or which member, nor does it distinguish it from sibling tools like household_get_current_user or household_list_household_members.
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 existence of household_list_household_members and household_get_current_user as siblings creates potential ambiguity, and the description does not mention that member_id is required or that this tool is for fetching a single member by identifier.
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, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds no behavioral detail beyond the word 'List'—for example, whether all merchants are returned, how pagination works, or that results may change over time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than concise in a useful way. One sentence with no qualifying or routing information does not earn its place as a complete tool description.
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 six optional parameters, no output schema, and sibling tools for singular merchant operations, the description is incomplete. It does not explain return shape, pagination, filtering, or when to prefer this over merchants_get_merchant, so an agent must rely on the schema and defaults.
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% (fields and output_mode), leaving sort, limit, offset, and search undocumented. The description provides no parameter guidance to compensate, so an agent gets little help selecting or formatting the four undocumented 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 'List merchants' states a clear verb and resource, making the basic purpose obvious and distinguishing it from merchants_get_merchant/update/delete. However, it provides no scope (all merchants, filtered, paginated) and simply restates the title, so it is clear but not richly differentiating.
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 list operation versus merchants_get_merchant, or how the search parameter relates to finding a specific merchant. No alternatives or exclusions are mentioned, so the agent must infer usage from the sibling names.
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 signal readOnly=false, idempotent=false, and destructive=false, so the description need not repeat basic write semantics. 'This may create or update Monarch data' adds a slight hint of upsert-like behavior without specifying what data is affected, whether existing streams can be modified, or what side effects could occur. It does not contradict 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but under-specification is not conciseness. The first sentence restates the tool title, and the second sentence is a vague side-effect note. There is no structure, no parameter overview, and no guidance, so despite the lack of fluff, the content is not 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?
For a write tool with 7 parameters, 4 required fields, no output schema, and only minimal annotation coverage, this description is far too thin. It omits return behavior, parameter semantics, prerequisites, and when to choose create versus update. An agent receiving only this description could not confidently construct a valid call or interpret the result.
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%, and the description adds no parameter-level meaning beyond the schema. The four required parameters (merchant_id, frequency, amount, base_date) are left entirely undocumented in both the schema and the prose, so an agent cannot reason about their formats, constraints, or relationships.
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 a specific verb and resource: 'Create recurring stream.' This clearly identifies the core action and differentiates it from read/list/delete recurring tools by name. However, it does not distinguish it from recurring_update_recurring_stream, and the phrase 'This may create or update Monarch data' slightly muddies whether the operation is strictly a create or an upsert.
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 the sibling recurring_update_recurring_stream or recurring_remove_recurring_stream. An agent gets no criteria to decide between creating a new recurring stream and updating an existing one, and no context about required prior steps or 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. However, 'Get tag.' adds no behavioral context beyond those annotations, such as behavior when the tag is missing or the shape of the returned object.
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 very short, but this is under-specification rather than effective conciseness. It front-loads nothing useful because it merely repeats the tool's title and contains no structured guidance for the agent.
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?
Even though the schema and annotations are fairly rich, the description does not explain the core invocation concept (fetch one tag by tag_id) or what the response modes mean beyond the schema defaults. With no output schema, an agent gets little help understanding what this 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?
The input schema describes fields and output_mode, but the required tag_id has no description and the tool description does not clarify that tag_id selects the tag to fetch. The description adds no meaning beyond the schema, and at 67% coverage it does not compensate for the undocumented required parameter.
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 gives a specific verb and resource ('Get tag'), so it is not missing or misleading, but it only restates the tool name/title and does not mention that this fetches a single tag by ID or how it differs from tags_list_tags. It is clear at a high level but too vague to stand alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this instead of sibling tag tools (list/create/update/delete/reorder). The description offers no context, prerequisites, or exclusions, so an agent must infer placement 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — nothing about default pagination (limit=100, offset=0), the three output modes (summary/full/raw), or how results are scoped. Although the bar is lowered by the annotations, the description contributes zero additional behavioral disclosure.
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 words is under-specification, not conciseness, for a tool with 6 parameters and a 26-field nested filter object. Like the 'Process' calibration case, this is a bare phrase that happens to be a valid sentence rather than a deliberately pruned description. There is nothing structured or front-loaded because there is essentially no content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool — no output schema, a rich nested filter input, three output modes, and a crowded sibling group of six transactions tools. A two-word description is completely inadequate: it explains nothing about what the filters do, what summary/full/raw return, how pagination works, or how this differs from transactions_get_transaction. Even with annotations covering safety, the description fails almost every completeness requirement.
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; sort, limit, offset, and the deeply nested 26-property filters object lack them). Since coverage is below 50%, the description should compensate, but it says nothing about any parameter. The schema's enums and defaults partially self-document sort/limit/offset, and the filter property names are descriptive, but the description itself adds no meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('transactions'), so an agent understands this is a query/read operation returning multiple transactions. However, it does nothing to distinguish itself from siblings like transactions_get_transaction or transactions_get_transaction_splits — the differentiation is carried entirely by the tool name, not the description. Clear but minimal, with no sibling 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?
There is no usage guidance whatsoever. The description 'List transactions.' contains no conditions, no exclusions, and no mention of when to prefer this over the single-transaction getter (transactions_get_transaction) or the attachments lister (transactions_list_transaction_attachments). An agent gets zero help selecting among the six transactions_* siblings.
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=false, so the description's 'may create or update Monarch data' adds little beyond structured data. It does not disclose which Monarch entities are affected, whether the withdrawal is reversible, or any auth or side-effect details. There is no annotation contradiction, but the behavioral value added is 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 short but under-specified. The first sentence merely paraphrases the title, and the second repeats a mutation hint already encoded by the annotations. It is not a case of efficient conciseness; it is a case of missing 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?
With 8 parameters, no output schema, and a large family of goal-related sibling tools, this description is insufficient for an agent to call the tool correctly. It lacks expected side effects, return shape, and parameter-level context, leaving the agent heavily reliant on guessing.
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%, and the description compensates for none of the gaps. It says nothing about goal_id, account_id, amount, date, notes, or include_in_budget, leaving key semantics like whether account_id is the source or destination of withdrawn funds entirely to inference.
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 names a specific action ('Withdraw') and resource ('goal'), so the core purpose is identifiable. However, it offers no functional detail and does not distinguish itself from closely related siblings such as goals_contribute_to_goal or goals_unlink_goal_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It never mentions that goals_contribute_to_goal is the inverse operation, nor does it explain what type of withdrawal scenario requires this tool. The generic 'may create or update Monarch data' sentence provides no selection 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?
The read-only, idempotent, open-world, and non-destructive annotations are present and the description does not contradict them. However, the description adds no behavioral context beyond those annotations, such as search scope, matching semantics, or result formatting.
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?
It is short and free of filler, but the extreme brevity veers into under-specification rather than purposeful conciseness. There is no structure or detail beyond a bare action phrase.
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 many closely related sibling tools, this one-line description is not complete enough for a caller to use the tool confidently. Missing details include what universe of securities is searched, how results are ordered, and how this relates to investments_get_security.
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 40%, and query/limit/order_by_popularity are effectively undocumented. The sentence 'Search securities' does not explain any parameter semantics beyond what the query field's name already implies.
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 names a concrete verb ('search') and resource ('securities'), so a caller can tell this is a search operation rather than a get/list operation. It does not explicitly contrast with siblings such as investments_get_security or investments_list_holdings, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus the many related investment tools. There are no use cases, prerequisites, or exclusions, so an agent must infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond that: no indication of what is returned, whether the report is a saved definition or data, or how missing/invalid report_id is handled.
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 short sentence with no filler, which is concise. But it is so minimal that it misses useful orientation, such as the distinction from reports_get_report_data or what a saved report contains. It is under-specified rather than efficiently 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?
With no output schema and a terse description, the agent lacks key context about return values and the meaning of a saved report. The sibling tools, especially reports_get_report_data, create ambiguity that this description does not resolve. The annotations and schema are not enough to make this a complete tool definition.
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 itself covers two of three parameters well: fields explains dotted output paths with examples, and output_mode explains summary/full/raw behavior. The required report_id has no description, but its meaning is reasonably clear from its name. The tool description adds no parameter-level meaning, but the schema does most of the work.
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 saved report' names a clear action and resource, so it is not entirely tautological. However, it is essentially the tool name and does not explain what a saved report is or how this differs from sibling tools like reports_get_report_data. This leaves the purpose understandable but vague in 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?
There is no guidance about when to use this tool versus alternatives. The description does not mention reports_list_saved_reports, reports_get_report_data, or any condition that would make this tool the right choice. An agent must rely entirely on naming conventions.
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 a non-read-only, non-idempotent operation, so the vague claim that it 'may create or update Monarch data' adds little new information. The description does not disclose whether existing splits are replaced, merged, or validated, nor does it explain side effects beyond the generic warning.
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 definition is short, but the first sentence simply restates the tool name and the second is vague boilerplate. Neither sentence earns its place by adding concrete details that are not already visible in the title or annotations.
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 mutation tool with a nested splits object and no output schema, this description is under-specified. It does not explain how an update interacts with existing splits, what transaction_id must reference, or what output modes should be chosen, leaving important invocation decisions to inference.
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, fields and output_mode are documented in the schema, but the required transaction_id and splits parameters are not described anywhere. The description adds no parameter-level meaning, so an agent must infer that transaction_id identifies the parent transaction and that splits is the array to write.
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 first clause, 'Update transaction splits,' states a specific verb and resource, making the tool's core function clear and separating it from transaction-level operations like transactions_update_transaction. However, the added 'may create or update Monarch data' introduces ambiguity and no sibling tool is named, so it stops short of full 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 gives no guidance on when to use this tool versus transactions_get_transaction_splits, transactions_unsplit_transaction, or transactions_update_transaction. The only implied context is the tool name itself; no alternatives or exclusions 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 declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds one useful contextual warning—'This may create or update Monarch data'—which is consistent with the annotations, but it does not disclose what happens on auth failure, whether tokens are persisted, or any rate/security limits. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, but the first sentence merely restates the title and the second is vague ('may create or update'). Compact but low information density.
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 7-parameter auth tool with no output schema, the description omits the auth flow entirely: when mfa_code is required, what include_token means, what trusted_device does, and what a successful session creation returns. The presence of sibling auth_login makes this gap more serious since the agent cannot route between them.
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% (only fields and output_mode have descriptions). The description adds no parameter information at all, failing to compensate for undocumented params like mfa_code, include_token, and trusted_device—critical for understanding the auth flow.
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 session' with a clear verb and resource, so it is not a pure tautology. However, it does not distinguish this tool from the sibling auth_login or explain what a session is versus a login, and the phrase 'This may create or update Monarch data' clouds the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus auth_login, auth_save_session, or auth_load_session. There is no mention of prerequisites (e.g., MFA enrollment), when mfa_code or trusted_device are needed, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'This may create or update Monarch data,' which indicates mutation, but annotations already convey readOnlyHint=false. It adds no detail about auth requirements, side effects, what 'update' means, whether existing data can be overwritten, or any other behavioral context. The vague 'may create or update' is not a meaningful disclosure 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 and front-loaded with the core action, which is good. However, the second sentence 'This may create or update Monarch data' is vague and adds little value, so not every sentence earns its place. It is concise but not tightly 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?
For a mutation tool with four parameters, two required parameters, no output schema, and a sibling tool for updating category groups, this description is incomplete. An agent is left without guidance on when to call this versus categories_update_category_group, what the type parameter means, or what output to expect. The vague 'create or update' creates more ambiguity than it resolves.
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 mention any parameters. Schema coverage is only 50%, covering fields and output_mode, but the required parameters name and type are undocumented in both schema and description. The description adds no value for understanding how name and type should be used or how the type enum affects group creation.
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 a specific verb and resource: 'Create category group.' This is clear and distinguishes the tool from update, delete, and reorder siblings at a basic level. However, it does not explicitly differentiate it from the sibling categories_create_category, and the second sentence blurs the action by saying it 'may create or 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?
The description provides no guidance on when to use this tool versus alternatives such as categories_update_category_group or categories_create_category. It does not state whether this is for new category groups only, whether it can update existing groups, or what distinguishes it from related tools. Usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, and the description's hedge sentence adds almost nothing beyond that flag. Critically, the description does not disclose what actually happens to the categories inside the deleted group (deleted outright, unlinked, or moved to move_to_group_id), which is the central behavioral question for a destructive operation. No contradiction with annotations, but no real value added.
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 and front-loaded with the core action, which is commendable. However, the second sentence is generic disclaimer filler that does not earn its place since destructiveHint=true already communicates the risk. It is concise but not information-dense.
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 no output schema, no guidance on return values, two undocumented parameters, and an unresolved question about the fate of contained categories, this description is incomplete. An agent cannot determine what will happen to the group's categories or whether move_to_group_id is the safeguard against destroying them.
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 50% schema description coverage, group_id and move_to_group_id are undocumented in the schema, and the description compensates for none of them. move_to_group_id is the most behaviorally significant parameter for a destructive tool — it likely determines the fate of contained categories — and its semantics are left entirely to inference.
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 first sentence, 'Delete category group,' states a specific verb and resource and distinguishes the tool from sibling create/update/list/reorder group tools. However, the second sentence is hedged boilerplate ('may delete, clear, reset, or otherwise remove data') that muddies rather than sharpens the purpose, and the tool is not differentiated from categories_remove_category, which could easily be confused with 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?
No guidance is given about when to use this tool versus alternatives such as categories_remove_category or categories_update_category_group. The presence of the move_to_group_id parameter implies a meaningful usage pattern (moving contained categories elsewhere before/while deleting), but the description never surfaces this 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 read-only, idempotent, non-destructive behavior, and the description adds no additional behavioral context. It does not mention default filtering behavior, include_disabled semantics, or output_mode implications. There is no contradiction, but also no value added 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 and front-loaded with no filler. However, it is under-sized for a tool with four parameters and several closely related siblings, so the brevity crosses into 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?
For a list tool with filtering parameters, output mode options, and a disabled-category flag, the description is incomplete. There is no output schema, and the description does not explain the available filters, return modes, or how this differs from other category list/catalog 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?
The schema covers only 50% of top-level parameters, and the description adds no parameter meaning at all. The fields and output_mode parameters have schema descriptions, but filters and include_disabled remain undocumented in both schema and description. The description does not compensate for the coverage 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 states a clear verb ('List') and resource ('categories'), so the agent knows the basic operation. It does not explicitly distinguish itself from sibling tools like categories_list_category_groups or categories_get_category_catalog, but the resource name provides some 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention filtering by types or groups, whether to use get_category for a single category, or when list_category_groups is more appropriate. The agent is left to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds that the operation 'may create or update Monarch data,' which is useful behavioral context beyond what annotations state. However, it does not explain what kind of update may occur or why creation is possible.
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 and front-loaded, but the first sentence essentially repeats the tool title. The second sentence provides some value but is somewhat vague. Overall it is compact but not fully efficient because a sentence is spent restating the obvious.
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 mutation tool with no output schema, the description lacks key context such as what the order parameter represents, whether reordering has constraints, or what the response contains. The side-effect note is helpful but does not make the description complete enough for an agent to confidently 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?
Schema description coverage is only 50%; the required parameters group_id and order lack descriptions in the schema. The description adds no parameter semantics, failing to explain what 'order' means or how group_id is used. The optional fields and output_mode are documented in the schema, but the critical required parameters remain underspecified.
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 first sentence 'Reorder category group' restates the tool title without adding specificity, which borders on tautology. However, the second sentence 'This may create or update Monarch data' adds a meaningful side-effect detail, giving some purpose clarity 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?
The description offers no guidance on when to use this tool versus alternatives like categories_reorder_category or other category group operations. There are no exclusions, prerequisites, or contextual conditions 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 signal readOnlyHint=false, establishing this as a write operation. The description adds the context that Monarch data 'may create or update,' hinting at possible upsert behavior and that writes go to the Monarch backend — useful but vague. It does not disclose side effects on categories within the group, reversibility, or behavior when group_id does not exist. No contradiction with the annotations exists.
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 and front-loaded with the verb-resource pair, containing no redundant wording. However, the second sentence is phrased so vaguely ('may create or update') that it contributes marginal clarity relative to the space it occupies.
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 mutation tool with five parameters and no output schema, the description is incomplete. It does not state what response shape to expect, whether this is an upsert, what happens to categories under the group when it is updated, or how it relates to the create/delete/reorder sibling tools. An agent would have to guess at side 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 description coverage is only 40%, below the 50% threshold, so the description should compensate — but it contains no parameter-level semantics at all. The schema's self-descriptive titles (name, type, group_id) and the descriptions for fields and output_mode limit the damage, yet nothing explains parameter interactions, constraints, or how name/type changes affect existing categories.
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 first sentence states the core action, 'Update category group,' which is a clear verb-plus-resource pair. However, the second sentence, 'This may create or update Monarch data,' introduces ambiguity about whether the tool performs an upsert or merely has downstream write effects, and it does not explicitly distinguish this from sibling tools such as categories_update_category or categories_create_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?
The description offers no guidance on when to use this tool versus the many relevant siblings (categories_create_category_group, categories_delete_category_group, categories_reorder_category_group, categories_update_category). No preconditions, exclusions, or alternative-selection criteria are provided, so an agent must infer the appropriate 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?
The description adds a vague 'This may delete, clear, reset, or otherwise remove data' clause that provides no concrete behavioral detail beyond the destructiveHint=true annotation. It does not disclose cascading effects, irreversibility, or what data is affected, which is critical for a destructive tool.
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 and front-loaded with the primary statement 'Delete goal.' However, the second sentence is vague filler that does not earn its place, and the overall structure leaves room for more informative phrasing.
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 and only one documented parameter, the description is incomplete. It does not explain return behavior, side effects, or the relationship to archive_goal. An agent would be uncertain whether deleting a goal removes related events, linked accounts, or budget amounts.
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 documents fields and output_mode, but goal_id—the only required parameter—has no schema description and the tool description says nothing about it either. Schema coverage is only 67%, and the description does not compensate for the undocumented goal_id. No additional meaning is added 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 a specific verb and resource ('Delete goal'), making its purpose clear. The name and title align, and the destructive nature is evident. However, it does not explicitly differentiate from the sibling goals_archive_goal, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 archive_goal/restore_goal tools likely offer non-destructive alternatives, but the description does not mention them or any prerequisites. The only implicit signal is the verb 'Delete', which leaves 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?
The description adds 'This may create or update Monarch data,' which is a generic side-effect statement already implied by readOnlyHint=false. It does not disclose what actually changes (e.g., whether unlinking creates a goal event, whether it is reversible, or whether it affects other linked accounts). Given the annotations provide the same broad safety information, the description adds little meaningful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short at two sentences, so it is not verbose. However, the first sentence merely restates the title, and the second is a vague warning. While it is not bloated, it is under-specified rather than efficiently informative, so it earns a middle score.
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 mutation tool with two required identifiers and no output schema, the description fails to explain the purpose of the goal_id/account_id pair, what 'unlink' means in context, or what the expected outcome looks like. The openWorldHint annotation further suggests unknown behaviors, yet the description does not clarify these. An agent would need to guess or rely on naming conventions to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, leaving required goal_id and account_id undocumented in the schema. The tool description does not compensate by explaining what these parameters mean or how they relate to the unlink operation. The only parameter clarity comes from the schema titles 'Goal Id' and 'Account Id' and the descriptions for fields and output_mode, not from the description text.
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 a specific verb and resource: 'Unlink goal account.' It clearly identifies the action of removing an account from a goal. However, it does not explicitly distinguish itself from sibling tools like goals_link_goal_account_balance or goals_delete_goal, relying on the tool name rather than the description to differentiate.
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. The description does not mention prerequisites, consequences, or any scenario where another tool would be more appropriate. The only extra sentence about creating/updating Monarch data is a side-effect warning, not 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?
Annotations already convey that the tool is not read-only, not idempotent, and not destructive. The description adds only the generic statement 'This may create or update Monarch data,' which provides little concrete behavioral detail about side effects, ordering behavior, or what changes are applied.
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 and front-loaded, but the second sentence is vague boilerplate that does not earn its place. It is not overly verbose, yet it sacrifices substance 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?
For a mutation tool with no output schema and a critical parameter whose semantics are unclear, this description is incomplete. An agent cannot confidently determine how goal_ids map to priorities, what the tool returns, or what side effects to expect.
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%, and the most important parameter, goal_ids, has no semantic description. The description does not clarify that the order of goal_ids likely determines priority, which is essential for correct invocation. Fields and output_mode are documented in the schema, but the key parameter is left 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 states a clear action ('Update goal priorities') on a specific resource, and the name distinguishes it from sibling goals tools. However, it does not explain what 'priorities' means or how the update is represented, so it stops short of a fully self-contained 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 goals_update_goal, nor any mention of prerequisites or order semantics. The tool name implies its niche, but the description leaves all usage decisions to inference.
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 sentence 'This may create or update Monarch data' adds only a vague effect that largely restates the annotations already provided (readOnlyHint=false, openWorldHint=true). It does not disclose what happens to unspecified preferences, whether this is a partial update, or what side effects may occur.
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 and front-loaded with the main action, which is good. However, the second sentence is vague and largely redundant with the annotations, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, no output schema, and minimal annotation coverage of behavioral effects, the description is substantially incomplete. It does not explain what 'household preferences' encompasses, what the response looks like, or how the output_mode/fields parameters interact with the result.
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%, covering just 'fields' and 'output_mode'; the five boolean preference parameters have no descriptions in the schema or the tool description. The description does nothing to clarify the meaning or effect of parameters like 'exclude_business_from_budget' or 'pending_transactions_can_be_edited'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update household preferences') and the resource, so an agent knows what the tool operates on. However, it does not differentiate this from sibling tools like household_update_current_user or the read-only household_get_household_preferences, so it stops short of full 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?
There is no guidance on when to use this tool instead of related household tools, no mention of reading preferences first, and no explanation of prerequisites or update semantics. The agent is left to infer usage entirely from the tool name and schema.
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 this is not read-only (readOnlyHint=false) and is not idempotent. The description adds only the vague statement 'This may create or update Monarch data,' which does not meaningfully clarify side effects, what settings are affected, whether changes are reversible, or what happens to existing settings. It offers little behavioral insight beyond what annotations already convey.
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 and front-loads the main action, so it is not bloated. However, the second sentence is mostly vague and uninformative, and the overall brevity reflects under-specification rather than efficient 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?
For a tool with four parameters, no required fields, and no output schema, the description should explain the settings being updated, the effect of each parameter, and any relevant caveats. It does none of this, so 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 description coverage is only 50%. The auto_categorize and update_transaction_notes parameters have no descriptions, and the tool description does not explain them or provide any additional meaning. The description fails to compensate for the undocumented parameters, leaving the agent without enough information to understand what values are meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update receipt settings' and the resource (receipt settings), so an agent can tell this is a mutation of settings rather than a retrieval like receipts_get_receipt_settings. However, it does not explicitly distinguish it from related receipt mutation tools, and the phrase 'may create or update Monarch data' introduces mild ambiguity about whether this creates records.
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 gives no guidance on when to use this tool versus alternatives such as receipts_get_receipt_settings, receipts_update_receipt, or other settings-related tools. There is no mention of prerequisites, context, or conditions that would indicate this tool is the right choice.
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 non-read-only, non-idempotent mutation. The description only adds a vague statement about possibly creating or updating Monarch data, without clarifying upsert semantics, prerequisites, or what existing state might be affected. This does not contradict the annotations, but adds minimal 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with no redundant filler beyond the title-like first sentence. However, the second sentence is vague, and the overall under-specification means brevity is achieved at the cost of useful 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 no output schema and four parameters, the description leaves the agent without enough context about return behavior, side effects, or how this operation relates to the many sibling report tools. The schema provides some parameter detail, but the description itself is minimally informative.
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 contributes no parameter-level meaning. Schema coverage is only 50%, and the undocumented required parameters (report_id, name) are not explained in the description; the documented fields and output_mode are already handled by 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 a specific verb and resource—'Update saved report'—making it clear this is the update operation in the reports CRUD family. It does not explicitly contrast with reports_create_saved_report or reports_get_saved_report, and 'may create or update Monarch data' slightly blurs the update-only intent.
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 instead of reports_create_saved_report, reports_get_saved_report, or reports_delete_saved_report. The vague 'may create or update' phrase could actually mislead an agent about whether to choose update versus create.
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 known. The description adds no behavioral detail beyond those hints; it does not clarify what the download returns (e.g., binary file vs JSON), whether it requires special permissions, 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 a single, brief sentence that is front-loaded with the action. However, it essentially restates the title and provides no additional structure or information; it is under-specified rather than efficiently 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?
There is no output schema, and the description is a bare phrase. It omits the key distinction from transactions_get_transaction_attachment, the expected return format, and how the optional parameters affect the behavior. An agent cannot reliably determine correct invocation or output 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%; only fields and output_mode have descriptions. The description adds no meaning for the required attachment_id or the optional path parameter, and does not explain how fields or output_mode affect the download outcome. The required parameter remains 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 uses a specific verb and resource, clearly indicating a read operation for an attachment. However, it does not distinguish this tool from the similarly named transactions_get_transaction_attachment sibling, so an agent could still be unsure which one 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 for when to use this tool versus transactions_get_transaction_attachment, transactions_upload_transaction_attachment, or other attachment-related tools. There is no mention of when downloading is preferable, no exclusions, and no alternative naming.
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 says 'This may create or update Monarch data,' which warns about side effects and aligns with readOnlyHint=false and idempotentHint=false. However, it does not add deeper behavioral context such as whether existing accounts can be overwritten, ownership requirements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary verb and resource. The second sentence is a short side-effect note, and there is no wasted phrasing. It is appropriately compact, though it achieves brevity at the cost of useful 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 8 parameters, 3 required, no output schema, and limited schema documentation, the description is too sparse to fully support correct invocation. It does not explain valid account types/subtypes, what fields are relevant, what response shapes to expect, or how this relates to account update operations.
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%, with descriptions present only for fields and output_mode. Six parameters, including the required name, type, and subtype, lack meaningful descriptions in the schema, and the tool description adds no parameter-level meaning. The agent has no guidance on valid type/subtype values, balance semantics, or owner_user_id 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 states the core action 'Create manual account' with a specific verb and resource, matching the tool name. It is distinguishable from accounts_update_account and investments_create_manual_holding, though it does not explain what makes an account 'manual' or how manual account creation differs from other creation flows.
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 accounts_update_account, imports, or investments_create_manual_holding, so an agent must infer usage only from the tool name and 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 annotations already cover the safety profile (read-only, idempotent, non-destructive), and 'List accounts' adds no behavioral detail beyond them. It does not disclose defaults for include_hidden/include_deleted, pagination, or the scope of accounts returned.
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 phrase is maximally terse and front-loaded, with no wasted words. However, it is under-specified for a tool with an optional filter object and three output modes, so the brevity reads more like a label than a helpful definition.
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?
With no required parameters, strong read-only annotations, and self-describing schema fields, an agent could make a basic call safely. But with no output schema and no description of hidden/deleted defaults or how filters interact, the definition is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes nothing to parameter understanding; fields and output_mode carry their own schema descriptions, while filters is left to inference from its property names. At 67% schema coverage, a description could add value 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 a clear verb ('list') and resource ('accounts'), and the plural form distinguishes it from the singular accounts_get_account and the metrics-oriented accounts_get_* tools. It is terse but unambiguous about the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus accounts_get_account or the reporting/balance sibling tools. An agent must rely entirely on the tool name and sibling set to infer the right context, which the description does not 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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The phrase 'This may create or update Monarch data' adds a small human-readable warning about side effects and aligns with openWorldHint. It does not reveal what specific Monarch records can be affected, but with annotations carrying the safety profile this is acceptable.
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 two short sentences and the first is essentially a restatement of the title. The second sentence is vague and does not replace the missing usage or parameter details. This is under-specification rather than efficient conciseness for a 12-parameter tool.
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 12 parameters, a 17% schema coverage, no output schema, and a large CRUD sibling set, the definition leaves too much to inference. An agent can infer the basic update action but cannot determine valid field values, output behavior, or how this update affects Monarch data. The annotations help, but the description remains incomplete 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 17%, yet the description contributes no parameter-level meaning. It never explains account_id behavior, valid types, balance/subtype semantics, owner_user_id, deactivated_at format, or the boolean visibility flags. The description therefore fails to compensate for the mostly undocumented 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 a concrete action on a concrete resource: 'Update account.' The required account_id and the update verb make the intent clear. However, it does not explicitly distinguish this from sibling tools such as accounts_create_manual_account or accounts_get_account, so it stops short of full 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?
There is no guidance on when to use this tool versus the related accounts_* tools. It never says to use accounts_get_account for reads, accounts_create_manual_account for new accounts, or accounts_delete_account for removals. Only the name and the word 'update' imply the intended 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=false, idempotentHint=false, and destructiveHint=false. The description adds that the operation 'may create or update Monarch data,' which clarifies the mutation side effect beyond the raw annotation values. However, it does not describe what happens to existing session data, how conflicts are resolved, or whether any authentication state is replaced.
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, with no fluff, and front-loads the primary action. It loses a point because 'This may create or update Monarch data' is vague and 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?
Given the presence of sibling auth tools, a nested required session object, and no output schema, the description is too thin to fully guide an agent. It does not explain the relationship to authentication flow, how to construct the session, what fields are necessary, or what the result of a successful save 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 67%, since fields and output_mode have descriptions but the session object is a bare $ref with no top-level description. The description does not explain that session.token is required, what email or token_expiration represent, or how these values are stored. This leaves the most important parameter, session, largely 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 a clear action ('Save session') and resource ('session'), and adds that it 'may create or update Monarch data,' which is more specific than just repeating the tool name. However, it does not distinguish this tool from the closely related sibling auth_create_session beyond the word 'save,' and it leaves the operational purpose 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?
There is no guidance on when to use this tool versus auth_create_session, auth_load_session, or auth_login. The sentence 'Save session' implies the action but does not explain the context in which saving a session is appropriate or what alternatives exist.
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, idempotentHint, openWorldHint, and destructiveHint=false, but the description adds no behavioral context beyond the tool's name. It does not disclose how months are returned, whether the range is inclusive, or any constraints on start_month/end_month values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. While it is minimal, it is clean and focused, and every word contributes to the core message.
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 clarify what a budget month is and how start_month/end_month should be formatted or interpreted. It does neither, and the schema's partial documentation of output_mode and fields does not compensate for the missing explanation of required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents only fields and output_mode; required start_month and end_month lack descriptions. The description provides no parameter-level information, leaving date format and range semantics entirely unspecified, so an agent cannot confidently construct valid month values.
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 uses a specific verb and resource: 'List budget months,' which makes it clear the tool returns a collection of months rather than a single budget or budget settings object. However, it does not explicitly differentiate itself from sibling budget_get_* tools or clarify what exactly a 'budget month' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list contains many budget-related read tools, but the description offers no context for choosing this one, no mention of the required date range, and no exclusions or alternative tool references.
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 establish that this is a non-read-only, non-idempotent mutation. The description adds vague context that it 'may create or update Monarch data,' which is useful but shallow. It does not disclose what happens to existing budget amounts, how apply_to_future affects behavior, or any prerequisite 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?
The description is very compact, with the core action front-loaded in the first sentence. The second sentence is generic but adds a small behavioral note, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and minimal schema descriptions, this tool needs more context on required inputs, return shape, and side effects. The description only states what the tool does, not how to invoke it correctly or what to expect afterward.
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%, and the description contributes no parameter explanation beyond the bare action. Month format, category_id semantics, default_amount behavior, and apply_to_future effects are all left unexplained, forcing the agent to guess.
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 budget amount') and the resource being operated on, so an agent can grasp the basic operation. However, it does not distinguish this tool from sibling tools like budget_set_budget_group_amount or budget_set_flex_budget_amount, leaving ambiguity 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?
There is no guidance on when to use this tool versus alternatives such as budget_set_budget_group_amount or goals_set_goal_budget_amount. The sentence about creating/updating Monarch data addresses side effects, not usage context or selection criteria.
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 annotations already establish the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description's 'This may create or update Monarch data' is consistent with those and adds the small context that this writes to Monarch's data store. However, it reveals nothing about overwrite semantics, the effects of repeated calls, or any required preconditions. No contradiction with 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?
Two sentences with no filler, and the core action is front-loaded. The second sentence earns its place by disclosing the create/update side-effect profile. The brevity is efficient, though it is partly a byproduct of under-specification that the other dimensions properly penalize.
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, three of five parameters semantically undocumented, and a money-affecting mutation, the description provides far too little. An agent is left to guess the meaning of enabled, start_month, and starting_balance solely from their names, and the description doesn't tie this tool to its read sibling budget_get_flex_rollover_settings for pre-reading current state.
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%, leaving enabled, start_month, and starting_balance undocumented, and the tool description compensates for none of these. It adds zero meaning beyond what the schema already provides, which falls well below the threshold where the description is expected to carry the burden for under-documented 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 first sentence 'Set flex rollover settings' restates the tool name and title nearly verbatim, edging toward tautology, and never explains what flex rollover settings are or what effect enabling them has. It does distinguish itself at the surface level from the read sibling budget_get_flex_rollover_settings and from other budget_set_* mutations, but the added sentence about creating/updating Monarch data speaks to side effects, not 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?
No guidance is given on when to invoke this tool versus any of the closely related siblings such as budget_set_budget_category_rollover, budget_set_flex_budget_amount, or the read counterpart budget_get_flex_rollover_settings. There are no conditions, prerequisites, or exclusions that would help an agent select between the many budget_set_* tools.
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, establishing this as a non-read, non-destructive operation. The description adds the context that the operation 'may create or update Monarch data,' which is a useful behavioral hint beyond the annotation booleans, though it remains vague about conditions, side effects, and idempotency. No contradiction with annotations is present.
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, with no fluff or redundant detail. It is front-loaded with the core purpose. The mild weakness is that the first sentence essentially repeats the tool name and title, and the second sentence is vague, but there is no structural waste.
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 mutation tool with no output schema and 40% parameter coverage. It lacks return-value information, prerequisites, group_id semantics, and any explanation of the 'may update' condition. The output_mode parameter partially covers output shape, but the overall tool behavior is not sufficiently specified for an agent to invoke it correctly without external knowledge.
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%, covering fields and output_mode, while important required parameters like name, group_id, and icon lack descriptions. The tool description provides no parameter semantics whatsoever, so it does not compensate for the low schema coverage. Agents get no explanation of what group_id refers to or how icon/name are structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create category,' which clearly identifies the verb and resource, and the tool name/title align. However, the follow-up 'This may create or update Monarch data' muddies the purpose by suggesting an update behavior that the name and title do not convey, and it does not explicitly differentiate from 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. The phrase 'Create category' is the only usage signal, and it largely restates the tool name. The description does not mention that updates to existing categories should use categories_update_category, nor does it clarify the ambiguous 'may create or update' behavior.
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 conveys a non-obvious side effect beyond the annotations' readOnlyHint=false and openWorldHint=true. However, it is vague about what data gets created, when creation happens instead of update, or what the broader consequences are, so it provides only modest additional transparency.
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 and front-loaded, but the second sentence, 'This may create or update Monarch data,' is vague and does not add concrete value. It is compact but under-specified rather than efficiently 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?
For a 6-parameter mutating tool with no output schema, the description omits when to use it, what the event fields mean, and what response shape to expect. It provides only basic purpose and a vague side-effect note, leaving significant gaps for an agent choosing and invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description mentions no parameters at all. Required event_id, date, notes, and include_in_budget are left entirely undocumented in both the schema and description, so 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 a specific verb and resource, 'Update goal event', which is enough to identify the target object as distinct from tools like goals_update_goal or goals_delete_goal_event. However, it does not clarify what a 'goal event' is or how this tool differs from goals_contribute_to_goal or goals_withdraw_from_goal, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives, and no conditions that would select this over related goal tools. The only implied context is the resource name, which is not enough to reliably route an agent.
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 communicate readOnly, idempotent, and non-destructive behavior; the description adds no additional behavioral context. It does not mention what a 'household' result contains, whether there are permissions involved, or how output modes affect the returned 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 only a two-word restatement of the tool name. While there is no fluff, the extreme brevity leaves out context that an agent needs, so this reads as under-specification rather than effective 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?
There is no output schema to clarify return values, and the description does not explain what 'household' data is returned or how output_mode and fields shape the result. For a tool with zero required parameters and minimal description, an agent would still be guessing about the response format and the intended scope relative to sibling tools.
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 100%, so both fields and output_mode are already documented in the input schema. The description offers no additional parameter meaning, but with full schema coverage the baseline of 3 is appropriate.
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 the resource 'household,' so an agent can tell this returns the household aggregate object. It is clear, though it does not explicitly differentiate itself from sibling getters like household_get_current_user or household_get_household_member.
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 about when to use this tool versus the many related household tools, such as getting the current user, a member, or preferences. No exclusions, prerequisites, or alternative recommendations 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 signal readOnlyHint=false and idempotentHint=false, lowering the burden on the description. The phrase 'This may create or update Monarch data' adds a mild upsert-like hint not present in structured fields, but it remains vague about actual side effects and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The second sentence adds little value, but the definition is compact and free of redundant prose.
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?
There is no output schema, yet the description says nothing about return values, required identifier semantics, or behavior when a holding already exists. For a six-parameter mutation tool, this is incomplete and leaves important operational details unspecified.
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%; only 'fields' and 'output_mode' have schema descriptions, while account_id, security_id, quantity, and cost_basis are undocumented. The tool description names none of these parameters and does nothing 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 clearly states the action and resource: 'Create manual holding.' The verb distinguishes it from list/get tools, but the follow-up 'may create or update Monarch data' blurs the distinction from investments_update_manual_holding and no explicit sibling differentiation is provided.
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 for when to use this tool versus investments_update_manual_holding or investments_delete_manual_holding. The agent is left to infer that 'create' is for new holdings with no stated criteria 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 mark this as read-only, idempotent, open-world, and non-destructive, and the description does not contradict them. But 'List holdings' contributes no behavioral detail beyond that—no mention of default output_mode, hidden-holding handling, pagination, or that results are an open set. With no output schema, the agent has no further behavioral signal.
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 text is three words, front-loaded, and free of filler—readable at a glance. It is concise but under-specified, so it earns a moderate score rather than a top score.
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 optional parameters, no output schema, and a large sibling family, this terse description is not enough: it does not state what a holding is, how account_ids constrains results, what summary/full/raw means for this domain, or when to choose sibling tools. Annotations cover safety but not call semantics.
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 covers fields and output_mode well, including enum choices, but account_ids and include_hidden_holdings are bare. The tool description adds no parameter meaning, so an agent must infer account filtering and hidden-holding defaults 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 states a concrete verb ('List') and resource ('holdings'), and the plural form distinguishes it from the singular investments_get_holding sibling. However, it does no more than restate the title and gives no detail on scope, filters, or what counts as a holding.
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 prefer this tool over investments_get_holding, investments_get_portfolio, or investments_list_investment_accounts. The only implied cue is the plural list verb, which is not explicit enough for an agent choosing among related investment siblings.
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, covering the safety profile. The description adds no further behavioral context such as pagination, ordering, filtering behavior, or response shape, so it contributes nothing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is maximally concise and front-loaded. However, it is so brief that it approaches under-specification; while there is no wasted text, it also misses opportunities to add useful guidance.
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 optional parameters, no output schema, and no mention of return structure, pagination, or filtering, the description is incomplete. An agent cannot infer how to shape results or what the response contains 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 coverage is only 40%, with descriptions for 'fields' and 'output_mode' but none for 'limit', 'search', or 'include_transaction_count'. The description 'List tags' adds no meaning for these parameters, 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.
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 the resource 'tags', conveying the core action. However, it is minimal and does not explicitly differentiate from sibling tools like tags_get_tag, though the plural resource strongly implies listing all tags.
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 tags_get_tag, tags_create_tag, or other list_* tools. There is no mention of conditions, exclusions, or recommended usage contexts.
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 readOnly, openWorld, and idempotent behavior. The description adds no behavioral context beyond the bare operation: it does not say whether the response contains metadata, file content, pagination details, or how redirect_posted affects results. No contradiction exists, but the description contributes no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is front-loaded with the verb and resource, though it achieves conciseness at the expense of substantive guidance.
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 an unclear parameter like redirect_posted, the description is too sparse. The agent is left without enough context to understand response structure, pagination behavior, or the impact of optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with fields and output_mode documented in the schema, but transaction_id and redirect_posted lack parameter descriptions. The tool description itself adds no meaning for any parameter, so it does not compensate for the undocumented 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 states a specific verb and resource: 'List transaction attachments.' This clearly distinguishes it from attachment operations like get, upload, download, and delete. However, it does not explicitly differentiate itself from the sibling transactions_get_transaction_attachment beyond the singular/plural distinction.
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 for when to use this tool versus alternatives such as transactions_get_transaction_attachment, transactions_download_transaction_attachment, or transactions_list_transactions. 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?
The annotations already communicate that this is a non-read-only, non-idempotent, open-world write operation. The description adds 'This may create or update Monarch data,' which reinforces the write nature and gives domain context, but it does not explain side effects, partial-update behavior, or what 'create' might mean in an update context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key verb and resource. The second sentence adds a small amount of behavioral context, though it is somewhat vague. No words are wasted, but the brevity borders on underspecification.
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 16-parameter mutation tool with no output schema, the description is severely incomplete. It does not explain which fields can be updated, whether the update is partial or full replacement, what the response contains, or what 'may create' means. An agent cannot understand the tool's behavior or return shape from this definition 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 only 13%, and the description provides no parameter-level guidance. With 16 parameters, including date, amount, category_id, tag_ids, merchant_name, and review_status, the description does nothing to explain their meaning or update semantics. It 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 description states a clear verb and resource: 'Update transaction.' It is unambiguous about the operation being performed and distinguishes it from create/delete/split operations. However, it is brief and does not explicitly mention that the update targets an existing transaction by ID, though the required transaction_id parameter makes that 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?
There is no guidance about when to use this tool versus alternatives such as transactions_create_transaction or transactions_update_transaction_splits. The description implies a basic update use case but provides no exclusions, prerequisites, or context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, and the description adds no behavioral detail beyond restating the operation. It doesn't disclose pagination, ordering, or how include_archived interacts with results, so it adds no transparency 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?
At only two words, it is maximally concise and front-loaded; there is no filler. The brevity is a completeness concern, not a conciseness flaw.
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 list tool with strong annotations and fairly descriptive parameter schemas, the description is minimally viable. It leaves include_archived semantics and return-shape details implicit, but an agent can likely call it correctly using the schema and 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 67%, and include_archived has only a title/default with no explanation. The description contains no parameter semantics and does not compensate for the undocumented include_archived behavior or the effect of output_mode/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 uses a specific verb ('List') and resource ('goals'), and the plural form signals a collection operation that is distinct from goals_get_goal. It doesn't explicitly differentiate from goals_list_goal_events or describe scope, so it stops short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus goals_get_goal, goals_list_goal_events, or other goal tools. An agent must rely on the tool name and sibling context rather than the 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 already mark this as a write operation with readOnlyHint=false. The phrase 'may create or update Monarch data' adds a small useful upsert nuance beyond the annotations. However, it omits side effects, idempotency behavior, and details about what data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb and resource. The second sentence is slightly generic but not wasteful, so it earns a solid score for structure.
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 7-parameter mutation with no output schema, low schema coverage, and no idempotency guarantee, two sentences are far too little. It lacks parameter semantics, return shape, and usage context, making the definition inadequate for reliable tool 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%, with only fields and output_mode documented. The description does not explain apply_to_future, account_id, month, or the relationship between goal_id and amount, forcing the agent to 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 names a specific action ('Set') and resource ('goal budget amount'), and the second sentence clarifies this may be an upsert operation. It is clear enough to understand the basic intent, though it does not explicitly differentiate it from similar sibling tools like budget_set_budget_amount 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 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 related goal or budget tools. It does not name alternatives, conditions, or prerequisites, leaving the agent to infer context 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 already declare readOnlyHint=false and idempotentHint=false, so the write behavior is known. The description adds only 'This may create or update Monarch data,' which is minimal but does not contradict the annotations and gives a slight behavioral hint. No contradiction detected.
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 desciption is very short and the main verb is front-loaded, but the second sentence is generic and does little work. It is concise more because it is under-specified than because every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with four parameters, no output schema, and openWorldHint=true, the description leaves important gaps: it does not say which user fields are updatable, what 'create' means in this context, or what side effects to expect. The schema and sibling list do not fill those 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: fields and output_mode have descriptions, but timezone and display_name do not. The tool description mentions no parameters at all, so it adds no semantic value beyond what the schema already provides and fails to compensate for the half-covered 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 states a specific verb and resource: 'Update current user.' It is clearly distinct from household_get_current_user on the read side, though it does not enumerate what fields can be updated or how it relates to household_update_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?
There is no guidance on when to use this tool, when not to use it, or which sibling tool would be an alternative. The description only restates the action and adds a vague side-effect note, leaving the agent to infer appropriateness.
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 and readOnlyHint=false, so the destructive nature is known. The description adds little beyond a vague warning that data 'may delete, clear, reset, or otherwise remove,' which does not meaningfully clarify the specific behavioral 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 short and front-loaded with 'Delete merchant,' but the second sentence is largely a tautological expansion that adds little concrete information. It is concise, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description should explain what happens to associated data, what move_to_merchant_id does, and what the return shapes mean. None of that is addressed, leaving an agent unprepared to invoke this safely.
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 adds no parameter semantics. Schema coverage is only 50%, and the undocumented move_to_merchant_id parameter is significant and ambiguous, yet the description does not clarify whether it preserves or migrates data before deletion.
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 a specific verb and resource: delete merchant. While the follow-up 'This may delete, clear, reset, or otherwise remove data' is vague, the name and first sentence are enough to distinguish it from sibling tools like merchants_update_merchant or merchants_get_merchant.
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 about when to use this tool versus alternatives, no mention of prerequisites, and no warning about what circumstances make deletion appropriate or what to do with related data. The description leaves all usage decisions to inference.
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=true, idempotentHint=true, and destructiveHint=false, which cover safety. The description itself adds little behavioral context beyond 'get', but it does not contradict annotations. Lacking additional details like return behavior or error cases, the description contributes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and front-loaded. It contains no unnecessary words, and while it is minimal, it earns its place by stating 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?
For a simple get operation with annotations covering safety, the description is adequate but thin. It does not explain what a merchant is, how output_mode interacts with retrieval, or how this differs from related tools like accounts_get_account. Given no output schema, a bit more context would help.
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 67%, with 'fields' and 'output_mode' documented. The required 'merchant_id' parameter lacks a description, though its purpose is clear from its name. The description adds no semantic detail beyond the schema, so it does not compensate for the undocumented merchant_id.
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' states a clear verb and resource, identifying this as a read operation for a single merchant. However, it does not distinguish this from sibling tools like merchants_list_merchants or merchants_update_merchant, nor does it specify what a merchant is in this domain.
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. An agent must infer from the tool name and schema that this retrieves a single merchant by ID, while merchants_list_merchants likely lists merchants. 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 indicate the operation is destructive and not idempotent. The description adds only the vague hedge 'This may delete, clear, reset, or otherwise remove data,' which provides no concrete side-effect information such as irreversibility, cascaded deletions, or impact on matched receipts/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?
The first sentence is appropriately concise and clear. The second sentence is redundant filler that says little beyond what the annotations and first sentence already convey, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially destructive operation with no output schema, the description should explain what happens after deletion, whether the action is permanent, or what effect it has on linked data. The annotations cover the destructive nature, but the description lacks the practical context an agent would need to call this safely and correctly.
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 already documents fields and output_mode with meaningful descriptions, so the description need not repeat them. However, the required receipt_id parameter has no schema description and the description adds no clarification, though its purpose is reasonably inferable from 'Delete receipt.'
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 begins with 'Delete receipt,' a specific verb and resource that clearly says what the tool does and separates it from sibling operations like update or unmatch. The second sentence, however, broadens the behavior to 'clear, reset, or otherwise remove data,' which slightly muddies 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?
The description gives no guidance on when to use this tool versus alternatives such as receipts_unmatch_receipt or receipts_update_receipt. Usage is only implied by the tool's name and first sentence, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond that—it does not mention what settings are returned, whether any defaults apply, or whether the response shape varies. It does not contradict the annotations, but it provides no added value over them.
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 short sentence with no filler, which is concise. However, it is so minimal that it borders on under-specification rather than effective conciseness, since it omits meaningful detail about what the settings represent.
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 at least convey what the settings response contains, but it does not. The optional 'output_mode' parameter hints at return shapes, but the description gives no information about typical settings fields, defaults, or how the result relates to receipt workflows. Annotations mitigate safety concerns but not the completeness gap.
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 100%, so both 'fields' and 'output_mode' have clear descriptions and defaults in the input schema. The tool description adds no parameter-specific information, but the schema already carries the semantic load, warranting the baseline score of 3.
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 uses the verb 'Get' and the resource 'receipt settings', clearly identifying a read operation on settings. It is distinguishable from the sibling 'receipts_update_receipt_settings' by intent, but it does not specify what settings are included or how they differ from '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 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 call this tool versus alternatives. There is no mention of related tools such as 'receipts_update_receipt_settings' or 'budget_get_budget_settings', and no context about typical use cases. The only implied usage is reading settings, which is already evident from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond what is already known, such as output shape, open-world caveats, or any side effects. It is not contradictory, but it contributes no additional transparency.
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 filler, so it is structurally clean. However, it is heavily redundant with the tool name and title, essentially repeating them. It is concise to the point of providing minimal added 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 there is no output schema, the description does not convey what the returned list looks like, whether pagination applies, or how this differs from reports_get_saved_report. The schema covers parameters and annotations cover safety, but the description alone leaves the agent without enough behavioral or usage context to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'fields' and 'output_mode' well documented. The description does not add parameter information, but it does not need to because the schema fully explains the parameters. Baseline 3 is appropriate.
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 is concise and clearly states the action and resource: 'List saved reports.' It uses a specific verb and resource, making the tool's basic purpose unambiguous. It does not explicitly distinguish this from the sibling reports_get_saved_report, but the list-versus-get distinction is implicit and fairly obvious.
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 gives no guidance on when to use this tool versus alternatives such as reports_get_saved_report. There is no mention of scenarios, exclusions, or selection criteria. An agent must infer usage entirely from the tool name and surrounding 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 and readOnlyHint=false. The description's "may delete, clear, reset, or otherwise remove data" is a vague restatement of destructiveness without specifying what gets affected, whether associated data is cascaded, or whether the action is reversible. It adds no concrete behavioral detail beyond what the annotations already communicate.
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 and front-loaded with the core purpose. However, the second sentence is vague and largely redundant with the destructiveHint annotation, so it does not fully earn its place. The structure is acceptable but not maximally 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 destructive tool with no output schema, the description omits concrete side effects, permanence, required permissions, and expected return behavior. The vague warning raises questions about what data will be deleted or reset without answering them, leaving the definition incomplete for an agent assessing consequences.
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 67%, with fields and output_mode documented in the input schema. The tag_id parameter is self-explanatory even without a description. The tool description itself adds no parameter semantics, but the schema carries most of the burden, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action and resource: "Delete tag." This distinguishes it from sibling tag operations like tags_update_tag and tags_create_tag. However, the second sentence broadens the action to "delete, clear, reset, or otherwise remove data," introducing ambiguity about the exact scope and preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The only actionable statement is the tool's name and a vague warning; an agent receives no help deciding between delete operations, update operations, or other associated tag actions.
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 adds no real behavioral disclosure beyond what is structured. 'This may delete, clear, reset, or otherwise remove data' is vague and does not specify whether splits, attachments, or other linked data are also removed, or whether the deletion is permanent.
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 front-loaded. The second sentence is filler that restates destructiveness without adding concrete details, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no output schema and an undocumented required parameter. The description does not explain side effects, irreversibility, or return behavior, so an agent cannot fully anticipate the consequences of calling it.
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 provides good descriptions for fields and output_mode, covering 67% of parameters. transaction_id lacks a description but is self-explanatory given the tool name. The description itself adds no parameter-level information, so the schema carries the weight.
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 first sentence 'Delete transaction' is a specific verb+resource that unmistakably identifies the operation. It distinguishes from sibling tools like transactions_get_transaction and transactions_update_transaction, though it does not explicitly differentiate from transactions_delete_transaction_attachment. The second sentence adds ambiguity but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_unsplit_transaction or transactions_delete_transaction_attachment. There are no prerequisites, no warnings about irreversibility, and no explicit context for when this operation 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 declare readOnlyHint=true and idempotentHint=true, and the description adds no behavioral context beyond saying 'Get'. It doesn't mention what output shape to expect, whether any hidden side effects are absent, or any rate/authorization considerations. No contradiction, but no value added.
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?
Single sentence 'Get budget settings.' has no filler and is direct; front-loaded and easy to parse.
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 rich schema and annotations, no output schema exists, and the description doesn't clarify what budget settings are returned (e.g., currency/date formats) nor how this differs from budget_get_flex_rollover_settings. For a tool with several budget siblings, this is insufficient 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?
Schema description coverage is 100%, with clear descriptions for fields and output_mode, including enum meanings. The description itself adds no parameter semantics, so baseline 3 applies.
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?
States a specific verb ('Get') and resource ('budget settings'), so an agent can tell it is a read operation. However, it doesn't expand on what counts as 'budget settings' or distinguish it from sibling budget_get_flex_rollover_settings, 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 on when to use this tool versus alternatives; there is no mention of conditions or exclusions. The sibling set includes budget_get_flex_rollover_settings and budget_get_budget, so the agent must infer selection 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is mutating (readOnlyHint=false) and non-idempotent. The description adds that it 'may create or update Monarch data,' which gives some context about the side effect, but it does not explain overwrite behavior, consequences for existing budget settings, or any result details.
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 and front-loaded with the core action. The second sentence about creating or updating Monarch data is somewhat generic but adds a minimal side-effect note; overall there is no unnecessary fluff.
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 mutating tool with two undocumented required params and no output schema, the description is too sparse. It lacks usage guidance, parameter semantics, and any explanation of return behavior or output modes, leaving too much for the agent to infer.
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%, and the two required parameters, category_id and variability, have no descriptions. The tool description does not explain what category_id refers to or the meaning/effect of the fixed, flexible, and non_monthly variability values, so the agent must rely on parameter names and enums.
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 and target resource: 'Set budget category variability.' This distinguishes it from sibling tools like budget_set_budget_group_variability, though it does not define what 'variability' means or list possible values.
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 such as budget_set_budget_group_variability or budget_set_budget_category_rollover. The description does not mention preconditions, scope, or scenarios where this tool is the appropriate choice.
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 phrase 'This may create or update Monarch data' aligns with annotations showing readOnlyHint=false and idempotentHint=false, but adds little beyond what those annotations already imply. It does not disclose side effects of parameters like default_amount or apply_to_future, nor any rollover or reset behavior, though the mutation warning prevents contradiction.
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 short — two sentences, no filler, and the operation is stated at the front. However, the brevity veers into under-specification rather than disciplined conciseness, so it doesn't earn a 5.
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, 3 required, low schema coverage, no output schema, and a large family of closely related budget tools, the description is too thin for an agent to invoke it confidently. It omits month format, behavior of default_amount/apply_to_future, return shape, and any guidance on how 'group amount' interacts with category-level budgets.
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%, and the description does not compensate. It provides no explanation for required parameters like month format, amount units, or category_group_id semantics, and no context for optional parameters like default_amount or apply_to_future. The description adds essentially no parameter-level meaning beyond the schema's sparse field 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 operation: 'Set budget group amount' — a specific verb and resource. It distinguishes from sibling tools like budget_set_budget_amount and budget_set_flex_budget_amount through the 'group' qualifier, though it doesn't explain what a budget group amount is or how it differs semantically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related budget mutation tools (e.g., budget_set_budget_amount, budget_set_budget_group_rollover, budget_set_flex_budget_amount). The only hint is the tool name and the generic 'may create or update' note, leaving the agent to infer selection criteria.
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 discloses that the operation 'may create or update Monarch data,' which is consistent with readOnlyHint=false and destructiveHint=false and adds a mild upsert connotation. It does not detail side effects of apply_to_future or default_amount, but annotations already carry the core safety profile, so the added value is moderate.
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 compact—two short sentences with no redundancy, front-loading the core action. However, the brevity is achieved by omitting substantive guidance, so conciseness is good but not exemplary.
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 and no output schema, and it sits among many similar budget setters, yet the description gives no context on return values, the meaning of 'flex,' or how 'default_amount'/'apply_to_future' behave. This is insufficient for an agent to call it correctly in varied situations.
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, the description needed to explain the required 'month' and 'amount' parameters and the optional 'default_amount' and 'apply_to_future,' but it does not. Only 'fields' and 'output_mode' have schema descriptions; the description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set flex budget amount') on a clearly scoped resource, and the word 'flex' distinguishes it from sibling tools like budget_set_budget_amount. However, it does not explain what a flex budget amount is or how it differs beyond the name, so it stops short of full 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?
There is no guidance on when to select this tool over the many sibling budget setters (budget_set_budget_amount, budget_set_budget_group_amount, etc.). The description provides no context about use cases, prerequisites, or exclusions, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a mutating, non-idempotent, open-world operation; the description adds that it 'may create or update Monarch data,' which is consistent but says little about exact side effects. There is no contradiction, but it does not explain what happens to the category, related transactions, or budgets.
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 and front-loads the action, but the first sentence largely restates the tool name. The second sentence adds useful side-effect context, yielding a compact but minimally informative structure.
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 mutating, open-world operation with no output schema, the description is incomplete: it does not define what reactivation means, whether the category must already exist, what may be created or updated, or what response shape to expect. These gaps are material given the rich lifecycle sibling set (create, update, remove, reorder).
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 already documents fields and output_mode with concrete descriptions, so the main gap is category_id, which only has the label 'Category Id.' The prose adds no parameter detail, but the required parameter is reasonably inferable from the tool name and the schema carries most of the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Reactivate') and the resource ('category'), so an agent can infer the basic operation without opening the schema. It does not differentiate reactivation from sibling tools like categories_update_category or categories_remove_category, but the core purpose is not 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?
There is no guidance on when to call this tool instead of alternatives, no mention of prerequisites (e.g., the category must be inactive), and no explanation of when the tool creates versus updates data. An agent picking between this and the category sibling tools must infer the trigger conditions.
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 a generic warning that it 'may delete, clear, reset, or otherwise remove data,' which signals broad potential impact but lacks specifics such as whether deletion is permanent, whether move_to_category_id reassigns data, or what happens to associated transactions. It does not contradict 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 short and the main purpose is front-loaded. The second sentence is somewhat vague and repetitive ('delete, clear, reset, or otherwise remove data'), but it still serves as a compact warning. No word count or structure issue prevents quick parsing.
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 four parameters, no output schema, and an unexplained optional move_to_category_id, this description is incomplete. An agent cannot determine what happens to the category's contents, whether the operation is reversible, or what output to expect. The description leans on annotations but leaves too many invocation-critical details unstated.
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%, and the description adds no parameter meaning. category_id and move_to_category_id are undocumented in the schema and unexplained in the description, leaving the agent to guess what the category identifier refers to and what the optional move target does. The description does not compensate for the coverage 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 states the action clearly: 'Remove category' — a specific verb and resource. The sibling list contains categories_update_category, categories_reactivate_category, and categories_delete_category_group, but no categories_delete_category, so this is evidently the category deletion tool. The phrase 'or otherwise remove data' slightly broadens the scope and could confuse an agent about whether it removes only the category or 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?
There is no guidance on when to use this tool versus categories_reactivate_category, categories_update_category, or categories_delete_category_group. The description does not mention prerequisites, exclusions, or consequences that would help an agent choose this tool over alternatives.
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 establish readOnlyHint=false and idempotentHint=false, so the description's burden is lower. 'This may create or update Monarch data' adds a small side-effect warning that is consistent with the annotations, though it does not explain effects on existing category ordering or persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core operation. The second sentence is somewhat generic and adds limited value, which keeps it from a 5, but there is no redundancy or unnecessary structure.
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 5-parameter mutation tool with no output schema, the description is incomplete. It does not explain what order means, how category_id and group_id relate, what return shape to expect, or how this tool differs from related category/tag reorder operations. The schema documents fields and output_mode, but that does not compensate for the missing core semantics.
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 required parameters category_id, group_id, and order have no schema descriptions. The description offers no additional semantics, especially for order, where the agent is left guessing about zero-based positioning, group-relative ordering, or absolute position.
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 operation: reorder a category. It does not rise to a 5 because it omits the grouping/scope context and does not explicitly differentiate from sibling tools like categories_reorder_category_group or categories_update_category, but the core verb+resource meaning is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools such as categories_reorder_category_group and categories_update_category exist, but the description gives no conditions, prerequisites, or exclusions to help an agent choose correctly.
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=false, so the safety profile is covered. The description adds no additional behavioral context such as output shape, month-range semantics, or what 'budget amounts' includes, but it also does not contradict 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 a single, front-loaded sentence with no filler or redundancy. It is concise and readable, though it is also terse enough to leave key details uncovered elsewhere.
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 five parameters, three required, and no output schema, the description is too sparse. An agent would not know the required month format, what the response looks like, or how to disambiguate this from goals_set_goal_budget_amount without opening the schema and inferring heavily from sibling names.
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 three required parameters (goal_id, start_month, end_month) are undocumented in both the schema and the description. The description does not explain month format, ID format, or how the parameters relate to the returned budget amounts, so it 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 description uses a specific verb ('Get') and resource ('goal budget amounts'), clearly marking this as a read operation. It does not explicitly distinguish itself from the sibling goals_set_goal_budget_amount, but the get/set contrast and the tool name make the distinction fairly apparent.
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 prerequisites, and no mention of when not to use it. The get/set naming implies a read context, but the description does not explicitly route the agent toward or away from any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context, such as what 'current user' returns, whether authorization is assumed, or how the result is shaped.
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 brief and front-loaded, but it essentially restates the tool title with no added substance. This borders on under-specification rather than useful conciseness, though it is not overly verbose.
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, zero-required-parameter read operation, the definition is minimally adequate. However, with no output schema and no clarification of what 'current user' means in the household context or what fields the result contains, an agent must infer important details.
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 100% and both parameters ('fields' and 'output_mode') have clear descriptions, so the baseline is 3. The description itself provides no additional parameter meaning beyond what the schema already supplies.
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 a clear verb and resource ('get current user'), and 'current user' is distinct from sibling household getters like household_get_household or household_get_household_member. However, it does not explicitly call out how it differs from those related tools, so it lacks explicit sibling 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?
There is no guidance on when to use this tool versus alternatives, no exclusions, prerequisites, or mention of related functions. The description simply states the action without any contextual 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds no further behavioral context such as authentication requirements or rate limits, but it does not contradict the annotations. Given the annotations, this is adequate.
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 short sentence with no filler, but it essentially restates the tool title and provides no additional structure or context. It is concise but under-informative, so it does not earn a higher score.
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?
There is no output schema and the description gives no hint of what 'preferences' actually contain or how this tool differs from household_get_household. The well-documented parameters partially compensate, but the description is incomplete for an agent choosing among many household-related getters.
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 100%, and both parameters are well documented: 'fields' explains dotted output paths, and 'output_mode' explains summary/full/raw shapes. The description itself contributes nothing beyond the schema, so the baseline of 3 applies.
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 a clear verb and resource: 'Get household preferences.' This is specific enough to distinguish the action from other household tools like household_get_household or household_get_current_user. However, it does not explicitly name or differentiate against those siblings, so it misses the top 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?
The description provides no guidance on when to use this tool versus alternatives. It neither mentions conditions nor names related tools such as household_update_household_preferences or household_get_household. The agent is left 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description's additional phrase 'may delete, clear, reset, or otherwise remove data' is vague and does not specify what is cleared or reset, whether deletion is irreversible, or what cascading effects might occur. It adds little 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 and front-loaded with the core action, but the second sentence 'This may delete, clear, reset, or otherwise remove data' is vague filler that adds little concrete information. It is concise, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema and no usage guidance, the description is incomplete. It does not explain consequences, required ownership, or what 'manual holding' deletion entails. The annotations cover the safety profile, but the overall definition lacks essential context for confident 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 coverage is 67%, below the high threshold, so the description should compensate by explaining key parameters. It does not mention holding_id, fields, or output_mode at all. The schema documents fields and output_mode, but holding_id remains undescribed and the tool description offers no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('manual holding'), clearly identifying the tool's function. Among the investments siblings, only this tool performs deletion, so it is well distinguished from list/get/create/update alternatives.
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 prerequisites, and no exclusions. The agent must infer from the tool name and sibling context that this is for removing a manual holding; the description itself offers no 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe-read profile is covered. The description itself adds no behavioral detail beyond 'list', such as pagination, scoping, ordering, or how investment accounts relate to holdings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no padding, making it very concise and front-loaded. It is not poorly organized, though its brevity leaves explanatory gaps captured by other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list operation with rich annotations and full schema coverage, the description is serviceable. However, with no output schema and several closely related sibling tools, it does not clarify what an investment account is or how its result relates to holdings and portfolio tools.
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 100%, and both parameters (fields and output_mode) are fully documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies.
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 a specific verb ('List') and resource ('investment accounts'), so an agent knows what operation this is. It does not explicitly contrast with siblings like investments_list_holdings or accounts_list_accounts, but the resource phrase is distinct enough to convey the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 investments_list_holdings, accounts_list_accounts, or investments_get_portfolio. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a mutating, non-read-only, non-idempotent operation. The description adds the detail that it 'may create or update Monarch data', which hints at an upsert-like side effect. However, it does not explain what other side effects, permissions, or data changes could occur, so the added transparency is limited.
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 and front-loaded, with no redundant filler beyond the second sentence. It could earn its place more fully, but as a conciseness matter it is 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 six parameters, no output schema, and a mutation operation, this description is far from complete. It does not state which fields are updatable, how the output changes across output_mode values, or how update relates to the create/delete siblings, so an agent would lack critical call 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 33%, and the tool description does not compensate by explaining the key parameters. Quantity, cost_basis, and security_type remain semantically ambiguous (e.g., total cost basis vs. per-share, units, allowed security types), and holding_id is only identified as required, not explained.
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 a specific verb and resource, 'Update manual holding', which makes the core operation clear. It is distinguishable from sibling tools like investments_create_manual_holding and investments_delete_manual_holding, though it mostly restates the tool name and adds little beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus creating, deleting, or retrieving a manual holding. The phrase 'may create or update' hints at upsert behavior but does not explain when that occurs, nor does it mention prerequisites or alternatives.
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 convey that this is a mutating, open-world, non-idempotent operation. The description adds 'This may create or update Monarch data,' which hints at possible upsert behavior, but it remains too vague to clarify side effects, required auth, or what data may be created.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences with the core action front-loaded. The second sentence is somewhat vague but does not add much length; overall it is concise and quickly scannable.
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 mutating tool with no output schema, the description leaves major questions open: what fields can be changed, whether it creates a merchant when absent, and what the response shape is. The annotations and schema provide structure, but the description alone is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the four parameters. Schema covers fields and output_mode with descriptions, but name and merchant_id have no descriptions, and the description adds no meaning to help an agent understand parameter constraints or relationships.
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?
'Update merchant' states a specific verb and resource, and the sibling set (list/get/delete) makes 'update' a distinct operation. The second sentence, 'may create or update Monarch data,' is vague but does not obscure the 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?
The description gives no guidance on when to use this tool versus merchants_get_merchant, merchants_delete_merchant, or other merchant tools. It does not mention whether merchant_id must reference an existing merchant, any required permissions, or when the 'create' path applies.
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, idempotentHint=false, and openWorldHint=true, so the description need not restate that this mutates data. It adds a useful detail by specifying the effect: 'This may create or update Monarch data.' It does not describe side effects such as duplicate matching or whether an existing match is replaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core action in the first sentence. The second sentence about creating/updating Monarch data earns its place as a behavioral warning, though the overall terseness sacrifices useful operational 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?
For a mutating tool with two undocumented required parameters and no output schema, the description is too thin. It does not explain what matching a receipt means, when to use this instead of unmatch/upload, or what happens to an existing match. The schema conveys parameter structure but not enough contextual semantics.
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 50% schema description coverage, the description needed to clarify the required receipt_id and transaction_id, but it does not. The names are self-explanatory to some degree, yet the description adds no meaning about how the two parameters relate or what kinds of values are expected.
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 begins with a specific verb and resource, 'Match receipt,' which clearly identifies the operation of linking a receipt to a transaction (implied by required transaction_id). It is clear enough at a high level but does not explicitly differentiate itself from siblings such as receipts_unmatch_receipt or receipts_upload_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 given about when to use this tool versus alternatives. The description does not mention that unmatch_receipt reverses this operation or that this is the tool to associate an existing receipt with a transaction, leaving the agent to infer usage from the name and schema.
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, idempotentHint=false, and openWorldHint=true. The description adds 'This may create or update Monarch data,' which communicates mutation and potential creation beyond the raw annotation flags. However, it does not disclose details like whether updates overwrite existing fields, how line items are merged, or any side effects of calling with openWorldHint true.
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 two short sentences with no filler, front-loading the core action. It is concise and easy to parse, though arguably too sparse for the complexity of the tool and its 12 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?
Given 12 parameters, no output schema, and a mutating operation, the description is far from complete. It does not explain how line_items are handled, what 'fields' and 'output_mode' control, whether the update is partial or full replacement, or what the return value looks like. An agent would need to inspect the schema carefully and still lack important operational 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 17%, and the tool description provides no parameter-level explanations. Most of the 12 parameters (tax, tip, grand_total, line_items, etc.) rely solely on their titles and types. Since the description needs to compensate for low schema coverage but does not, the agent receives little help understanding 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 a clear verb and resource: 'Update receipt.' This distinguishes it from sibling tools like receipts_upload_receipt, receipts_delete_receipt, and receipts_match_receipt. However, the added clause 'This may create or update Monarch data' introduces some ambiguity about whether it can create new receipts or 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?
The description provides no guidance on when to use this tool versus alternatives such as receipts_upload_receipt or receipts_match_receipt. There is no mention of prerequisites, such as whether the receipt must already exist, or what conditions would favor updating over other receipt operations.
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, so the description's statement that it 'may create or update Monarch data' adds useful context about the kind of write operation. However, it does not disclose file handling behavior, required permissions, or what happens to an uploaded receipt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no filler and places the core action first. The opening sentence is somewhat redundant with the title, but the second sentence adds useful behavioral context without unnecessary 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 no output schema and only a two-sentence description, an agent cannot determine what the tool returns, what file formats or paths are accepted, or how the uploaded receipt relates to transactions or matching workflows. The write behavior is annotated, but operational 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 40%, and the tool description adds no parameter-level meaning beyond the schema. The required file_path parameter is undocumented in both the schema and description, and filename and content_type are also 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 the specific action 'Upload receipt' and clarifies the effect as creating or updating Monarch data. This distinguishes it from sibling receipt tools by the verb 'upload', though the first sentence largely restates 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 is given about when to use this tool versus alternatives such as receipts_match_receipt, receipts_update_receipt, or transactions_upload_transaction_attachment. Usage is only implied by the tool name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description's 'may delete, clear, reset, or otherwise remove data' adds little concrete behavioral detail. It does not state whether the stream definition, future occurrences, or related data are destroyed, nor whether the action is reversible. The word 'may' also leaves uncertainty about side effects, which is weak for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: 'Remove recurring stream' immediately states the action. The second sentence is concise, though vague, and the overall definition is not padded with irrelevant 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?
For a destructive tool with no output schema and no guidance on return shape, side effects, or what data is affected, the description is incomplete. It leaves an agent unsure about whether deletion is permanent, what happens to related occurrences, or what a successful removal returns. The lack of this context is material for a write/destructive operation.
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 provides useful descriptions for the optional fields and output_mode parameters, covering the more complex semantics. However, the required recurring_id parameter has no schema description, and the tool description does not explain how to identify the recurring stream beyond a self-evident name. This is an adequate but incomplete parameter story for an agent.
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 names the verb 'Remove' and the resource 'recurring stream,' making the core operation recognizable among CRUD siblings like recurring_create/update/get/list. The second sentence, however, is overly broad: 'may delete, clear, reset, or otherwise remove data' does not specify what exactly is removed. It does not fully disambiguate from other reource removal tools, but the resource name is specific enough.
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 over alternatives, such as when a user wants to permanently delete a recurring stream versus updating or deactivating it. No exclusions, prerequisites, or alternative tool names are mentioned. Context must be inferred solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly=false and idempotent=false, so the description only adds 'This may create or update Monarch data,' which hints that an update might also create a stream. This is some extra context but remains vague about actual side effects and does not explain what data is affected 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, no redundant padding. The second sentence adds a behavioral warning and earns its place, making this highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with seven parameters, no output schema, and no usage guidance, this description is too thin. It fails to clarify the required recurring_id, when creation may occur, or the expected response shape, leaving the agent to infer most behavior from schema and sibling names.
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 seven parameters, and schema coverage is only 29%, meaning most properties are undocumented by both schema and description. With such low coverage, the description needed to compensate but instead adds zero parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource, 'Update recurring stream,' so an agent can see the primary action and target. It does not, however, distinguish this from recurring_create_recurring_stream or recurring_remove_recurring_stream, which limits sibling 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?
There is no guidance on when to use this tool versus the create or remove siblings. The phrase 'This may create or update Monarch data' hints at upsert behavior but never states explicit conditions, exclusions, or alternatives.
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 establish readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds a mild side-effect disclosure ('This may create or update Monarch data') that names the mutated system. However, it does not clarify that repeated calls likely create duplicate reports given idempotentHint=false, nor what response to expect. The statement 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded. The second sentence is vague but earns its place as a side-effect warning. It is appropriately sized for what it communicates, though the vague 'may create or update' phrasing could have been replaced with a more precise statement about persisting report data.
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 write tool with 6 parameters (including a large nested filter object), no output schema, and a rich sibling family, this description is too thin. It does not explain what the tool returns, whether identical names create duplicates, or how it relates to reports_update_saved_report and reports_get_report_data. The ambiguous 'create or update' wording leaves an agent unsure of the operation's exact scope.
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% (fields and output_mode have descriptions; name, filters, group_by, and timeframe do not). Since coverage is below 50%, the description should compensate, but it adds zero parameter-level information. The nested filters object's field titles are self-explanatory, but the description fails to help an agent choose among name/group_by/timeframe 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 a specific verb and resource ('Create saved report'), which is a distinct operation among siblings like reports_get_saved_report, reports_update_saved_report, and reports_delete_saved_report. However, the second sentence 'This may create or update Monarch data' is ambiguous — it could be read as meaning this tool also updates saved reports, which blurs the line with reports_update_saved_report rather than clarifying it as a persistence side-effect warning.
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. An agent is not told to use reports_update_saved_report for modifying an existing report, reports_get_report_data for computing report data without persisting, or reports_list_saved_reports to check for duplicates first. Usage context is only implied by the verb 'create.'
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 mark readOnlyHint=false and destructiveHint=false, so the description's 'This may create or update Monarch data' adds a useful side-effect warning that goes slightly beyond annotations. However, it remains vague—'may create' is not specific about which Monarch data is affected or under what 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?
At two short sentences, the description is front-loaded and contains no redundancy; the purpose and a risk warning are stated immediately. It is concise, though the brevity comes at the cost of missing parameter and usage 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?
For a mutation tool with 4 parameters, no output schema, and sibling reorder tools, the description omits critical context: the meaning/semantics of 'order', the response shape, and how this differs from categories_reorder_category. The agent cannot reliably invoke it correctly with only this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the two required parameters (tag_id, order) have no schema descriptions. The tool description adds no meaning to these parameters—it doesn't explain what 'order' represents (e.g., index, weight, sort position) or how the fields/output_mode params behave, leaving the agent to guess.
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 uses a clear verb+resource construction ('Reorder tag') that tells an agent exactly what operation this performs. It does not, however, distinguish itself from sibling tools like tags_update_tag or categories_reorder_category, so the agent must infer the unique 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 given about when to use tags_reorder_tag versus tags_update_tag, categories_reorder_category, or other tag mutation tools. The description only states what it does, not the conditions or alternative tools, so usage context is entirely absent.
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 idempotentHint=false, indicating a mutating operation. The description adds a side-effect warning ('may create or update Monarch data') but is vague about the exact scope of the side effects, such as whether other resources are affected or what the response shape looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler. The second sentence acts as a side-effect warning, but it could be worded more precisely to aid 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?
With no output schema, sparse annotations, and a vague side-effect warning, the description leaves important gaps. It does not explain return values, error behavior, or the implications of 'may create or update Monarch data', making it insufficient for confident autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description provides no parameter information. Schema description coverage is only 40%, with only 'fields' and 'output_mode' documented; 'name', 'color', and 'tag_id' are left to their titles. The description does not compensate for this low coverage, though the parameter names are somewhat self-explanatory.
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 a specific verb and resource ('Update tag'), clearly distinguishing it from sibling tags_create_tag and tags_delete_tag. However, the added clause 'This may create or update Monarch data' creates some ambiguity about what exactly is created or updated.
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 tags_create_tag or tags_reorder_tag. No prerequisites, exclusions, or context are provided, so the agent must rely solely on the tool's name.
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 idempotentHint=false, and the description adds 'This may create or update Monarch data,' which clarifies the side-effect profile. However, it does not disclose what happens to existing rollover settings, whether changes are reversible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the second sentence adds a relevant side-effect warning without unnecessary 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 seven parameters, no output schema, and openWorldHint=true, the description is too thin. It does not explain what rollover configuration involves, how the parameters interact, what the response looks like, or which preconditions or side effects should be expected. An agent would likely need external knowledge or trial-and-error to invoke this 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 29%, and the description adds no parameter-level meaning. Required parameters like category_group_id and enabled are left to name inference, and optional fields such as start_month, rollover_type, and starting_balance are not explained. The description does not compensate for the schema's sparse 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 states a clear verb and resource: 'Set budget group rollover.' This distinguishes it from sibling tools like budget_set_budget_category_rollover by the 'group' scope, though it does not explain what rollover means or how it differs functionally from related budget tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as budget_set_budget_category_rollover, budget_set_flex_rollover_settings, or budget_reset_budget_rollover. The usage context is only implied by the tool name and sibling list, not stated in the 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 already signal this is a mutating operation (readOnlyHint=false, idempotentHint=false). The description adds that it 'may create or update Monarch data,' which gives a bit more specificity about upsert-like behavior, but it does not disclose side effects, reversibility, or what happens to existing values.
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 and front-loaded with the primary action in the first sentence. The second sentence about creating or updating is relevant and not redundant, though it adds limited behavioral depth. No unnecessary wording is present.
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 is relatively simple, but the description omits important context such as what 'variability' means, which budget timeframe is affected, and what the response contains. The schema covers the output-mode fields, and annotations cover the safety profile, but the description is barely sufficient 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?
The required parameters category_group_id and variability have no schema descriptions, and the description does not explain them either. The enum values for variability are self-explanatory and the parameter names are somewhat obvious, but the description compensates for none of the missing required-parameter 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 states a specific verb and resource: 'Set budget group variability.' It is clear about what the tool does, though it does not explicitly distinguish itself from the closely named sibling budget_set_budget_category_variability beyond using 'group' instead of '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 about when to use this tool versus alternatives such as budget_set_budget_category_variability or budget_set_budget_group_rollover. The description does not mention prerequisites, exclusions, or conditions that would help an agent choose this tool correctly.
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=false, and the description's 'may create or update Monarch data' only restates that this is a mutating operation without specifying what gets updated, under what conditions, or what side effects may occur. The openWorldHint=true and idempotentHint=false annotations are not elaborated with any concrete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. 'Create tag' is front-loaded immediately, and the additional mutation note is brief. Every word earns its place for a simple tool.
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 an output schema, the description should compensate by explaining what the tool returns or what happens on success, but it does not. It also fails to clarify the create-versus-update ambiguity, document required parameter semantics, or mention how this relates to tags_update_tag. For a mutation tool with two undocumented required parameters, 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?
Schema description coverage is 50%, and the description adds no parameter information. The required 'name' and 'color' parameters have no descriptions in the schema and no elaboration in the tool description, leaving their acceptable formats and meaning undocumented. The optional fields and output_mode are described in the schema, but the required core inputs are 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 first sentence 'Create tag' states a specific verb and resource, clearly identifying this as the create operation among the sibling tag tools. It does not explicitly distinguish itself from tags_update_tag, and the second sentence 'This may create or update Monarch data' introduces mild ambiguity about whether it performs an upsert, so it falls short of top marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit when-to-use guidance or alternatives. The intended use is implied by the verb 'Create', and an agent can infer it should be used when a new tag is needed, but the description does not clarify when to use this versus tags_update_tag given the 'or update' clause.
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 and readOnlyHint=false, and the description adds a hedged caveat that the operation 'may delete, clear, reset, or otherwise remove data.' This adds slight context about non-straightforward deletion, but it is vague and does not describe reversibility, cascading effects, or what kind of goal event data is affected.
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 and front-loaded with the core purpose. The second sentence is somewhat redundant and vague, but it does not waste much space. It is concise, though not maximally 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?
For a destructive tool with no output schema and a required event_id, the description is too thin. It does not explain what a 'goal event' is, how deletion affects goal progress or history, or what the caller should expect in return. With no output schema and minimal parameter info, an agent has insufficient context to invoke this correctly beyond guessing.
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 67%, with fields and output_mode having inline descriptions but event_id lacking any. The tool description adds no parameter-specific meaning, so it does not compensate for the undocumented required parameter. Baseline 3 is appropriate since coverage is moderate and the schema does most of the work.
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 a specific verb and resource: 'Delete goal event.' This is clear and distinct from the sibling 'goals_delete_goal', which deletes a goal object rather than an event. However, it does not explicitly differentiate itself from closely related siblings like goals_update_goal_event or goals_list_goal_events, so it relies on the tool 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention goals_update_goal_event, goals_archive_goal, or goals_delete_goal, nor does it state that deleting an event is for removing a specific contribution/withdrawal record. An 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.
Behavior4/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 idempotent, and the description adds a concrete warning that it 'may create or update Monarch data.' This usefully signals mutation and side effects beyond the raw boolean flags, though it does not specify exactly which data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the action, and the second sentence adds a safety-relevant side-effect warning. There is no filler or redundancy, though the brevity leaves out substantive guidance that would ideally accompany the tool.
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 non-idempotent mutation tool with six parameters and no output schema, this description leaves too much unstated: parameter semantics, return shape, and when to use it relative to sibling goal tools. The side-effect warning is helpful, but the description is not complete enough for an agent to call the tool 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 only 33%, and the description contributes no parameter-level meaning. It does not clarify how amount relates to use_entire_balance, whether amount is a target balance or a contribution, or how fields and output_mode shape the response. This is a significant gap for a tool with six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Link', and identifies the resource as a goal account balance, which makes the core action clear. It is distinct from the obvious sibling goals_unlink_goal_account, though it does not explain exactly what 'link goal account balance' means in terms of account and goal relationship.
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 for when to use this tool versus alternatives like goals_unlink_goal_account, goals_contribute_to_goal, or goals_withdraw_from_goal. The description does not mention prerequisites, exclusions, or the contexts in which linking an account balance 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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which already tell the agent this is a mutating, non-idempotent operation. The description adds the important warning 'This may create or update Monarch data', which is useful because it signals that the operation can have broader data-changing effects than just flipping a flag. This adds value beyond the annotations, though it could disclose more about what data gets 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is front-loaded, and the warning about data mutation follows immediately. It is concise, though it could arguably include more context without becoming bloated.
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 mutating tool with no output schema, no description of return values, and a critical required parameter (goal_id) that is undocumented, this is thin. The openWorldHint=true annotation suggests the operation may have side effects beyond the immediate goal, and the description's warning hints at this but doesn't elaborate. An agent would struggle to know what exactly happens on restore, what the expected outcome is, or what errors might occur.
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 67%: goal_id has no description, while fields and output_mode have descriptions. The description does not explain what goal_id means or how to obtain it, and doesn't clarify the semantics of restoring (e.g., whether it recreates a deleted goal or unarchives it). Since the critical required parameter goal_id lacks any description, the description should compensate but doesn't.
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 says 'Restore goal' which is a specific verb and resource, clearly indicating the action of restoring a previously deleted or archived goal. It distinguishes from siblings like goals_archive_goal, goals_delete_goal, and goals_create_goal by implying a restoration operation, though it doesn't explicitly name the alternative 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 vs alternatives. It doesn't explain what state a goal must be in (deleted, archived) for restoration, or how it relates to goals_reactivate_category (a sibling that does a similar restore/activate for categories). The context of when restoration is appropriate is entirely left to inference.
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 and idempotentHint=false, so the description does not contradict them and adds a broad warning that data may be deleted, cleared, reset, or removed. However, the warning is vague and does not specify whether associated transactions, balances, or other linked data are affected.
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 and front-loaded with the core action. The second sentence adds a caution about data removal without excessive fluff, though it is somewhat vague.
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 destructive single-resource delete operation, the description is minimally adequate: it names the action and warns of data removal. Missing details about reversibility, cascading effects, or what happens to associated data leave meaningful gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level detail, but the schema covers fields and output_mode with useful descriptions. The required account_id is undocumented in both schema and description, though its purpose is reasonably inferable from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete account') with a specific verb and resource. It distinguishes itself from account creation, updates, and reads by naming the delete operation, though it does not explicitly differentiate itself from sibling tools or elaborate on 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?
There is no guidance on when to use this tool versus alternatives like accounts_update_account or accounts_list_accounts. The description does not mention prerequisites, irreversible consequences, or any 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, which cover the safety profile. The description adds no extra behavioral context beyond the word 'Get', but it does not contradict the annotations 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, front-loaded sentence with no filler. It is appropriately concise for a simple getter, though it is also quite thin in substantive 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?
The schema and annotations cover parameter semantics and safety. However, the description does not explain what flex rollover settings represent, how they relate to budget_get_budget_settings, or what the response contains, and there is no output schema to fill that gap.
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 100%, and both parameters are well-documented: 'fields' explains dotted output paths and 'output_mode' explains its enum values. The description itself adds no parameter-level detail, so it appropriately relies 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 a verb ('Get') and a specific resource ('flex rollover settings'), making the basic action understandable. However, it does not distinguish this from sibling tools like budget_get_budget_settings or clarify what flex rollover settings encompass, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 related alternatives such as budget_set_flex_rollover_settings or budget_get_budget_settings. An agent cannot infer under what conditions this getter should be preferred.
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 non-destructive behavior, so the safety profile is covered. The description adds no extra behavioral details beyond the basic listing action, such as return shape or scope, but it does not contradict 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 extremely concise and front-loaded: 'List household members.' It contains no wasted words, though it is brief enough that some contextual information is pushed to other sources.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with optional parameters and rich annotations, the description is minimally adequate. However, with no output schema and no mention of return format, ordering, or member scope, it leaves some ambiguity for an agent deciding whether full details are returned or just a summary.
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 100%, so fields and output_mode are already well documented in the input schema. The description does not add additional parameter context, which is acceptable given the schema carries the burden.
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 a clear verb and resource: it lists household members. It is unambiguous and distinguishable from the singular sibling household_get_household_member, though it does not explicitly compare itself to related household tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no context about when to use this tool versus siblings like household_get_household_member or household_get_current_user. There is no guidance on prerequisites, intended use cases, or when an alternative would be more 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?
The annotations already establish that this is read-only, idempotent, non-destructive, and open-world. The description adds no additional behavioral context such as pagination, ordering, or scope. With the annotations covering the safety profile and no contradiction, a neutral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly three words, front-loads the action, and contains no wasted or redundant content. Every word earns its place.
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 low-complexity read-only tool with a complete parameter schema and strong annotations, this is barely adequate. However, without an output schema or any explanation of what a category group is and how it relates to categories, an agent has limited contextual cues for confident selection and interpretation of results.
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 100%: both fields and output_mode have explicit descriptions, defaults, and enums. The tool description itself says nothing about parameters, but the baseline of 3 applies because the schema fully documents 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 an action ('List') and a resource ('category groups'), so an agent can identify what the tool does. It does not explicitly contrast with sibling tools like categories_list_categories or categories_get_category_group, but the resource name is specific enough to avoid tautology.
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 categories_get_category_group, categories_list_categories, or categories_create_category_group. The agent must infer the intended use solely from the name and sibling list, with no explicit when-to-use or when-not-to-use instructions.
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 idempotentHint=false, and the description adds that the call 'may create or update Monach data,' which is relevant side-effect context. However, it does not specify what data can be created or updated or provide additional behavioral caveats.
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 short sentences, front-loaded with the primary action, and no filler. The side-effect warning about creating or updating Monach data earns its place as a behavioral caveat.
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 one-required-parameter tool, the description plus schema is minimally callable. It lacks context about prerequisites, such as the receipt needing to be currently matched, and does not explain consequences beyond a generic update/create warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning beyond what the schema already provides. The schema documents fields and output_mode, while receipt_id is self-evident from the property title and tool purpose, so the lack of description-level param detail is adequate, though not enriched.
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 names a specific operation ('Unmatch receipt') and is clearly distinct from receipts_match_receipt by the verb. It mostly restates the title, though, and does not explain the concept of unmatching 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 guidance is given about when to unmatch a receipt, what state the receipt must be in, or how this differs from receipts_update_receipt or receipts_match_receipt. The usage context is only implied by the verb 'Unmatch'.
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 the behavioral note that this 'may create or update Monarch data,' which aligned with annotations readOnlyHint=false and openWorldHint=true. However, it does not disclose important behavior such as whether an existing attachment is replaced, how file_path is resolved, what side effects occur, or what a successful response contains. The note adds some value but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action is front-loaded, and the mutation note is a single useful additional clause. It is appropriately sized 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?
For a non-readonly operation with six parameters, no output schema, and a large sibling set including receipt uploads, this description is incomplete. It fails to explain what an attachment is, how to provide the file, what data is returned, or how this differs from uploading a receipt. An agent has enough to guess the action but not enough to invoke it reliably in 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 only 33% (fields and output_mode are described, but transaction_id, file_path, filename, and content_type are not). The description provides no additional meaning for these parameters — it does not explain that file_path is a local file path, how filename/content_type are used, or what transaction_id refers to. With low schema coverage, the description needed to compensate and did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Upload transaction attachment.' This clearly distinguishes it from the sibling attachment tools (list, get, download, delete) and from the receipts upload tool because it names the resource as 'transaction attachment.' The second sentence clarifies it is a write operation on Monarch 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?
There is no guidance about when to use this tool versus alternatives such as receipts_upload_receipt or transactions_list_transaction_attachments. The description implies the use case by its name, but it does not state prerequisites, exclusions, or when another tool would be more appropriate. An agent is left to infer the intended trigger.
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 and idempotentHint=false, so the safety profile is known. The description adds the generic warning 'This may delete, clear, reset, or otherwise remove data,' which offers some context about side effects but is vague and does not specify what data is affected or whether the action is permanent. It does not contradict 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 short and front-loaded with the primary action. The second sentence is somewhat redundant with the annotations, but it is brief and adds a cautionary tone without bloating the text. It is appropriately concise overall.
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 delete tool with one required parameter and strong annotations, the description is mostly sufficient. However, the vague second sentence leaves ambiguity about what exactly gets removed or reset, and there is no mention of permanence or return behavior. The annotations fill the safety gap, but the description could be more explicit about the operation's effects.
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 67%: fields and output_mode have descriptions, while report_id does not. The tool description adds no parameter-level meaning, but report_id is self-explanatory and the other parameters are already well described in the schema. The baseline of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Delete saved report.' This clearly differentiates it from sibling tools like reports_get_saved_report, reports_create_saved_report, and reports_update_saved_report. The added warning sentence does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no conditions or prerequisites, and no mention of irreversibility or when deletion is appropriate. Usage must be inferred entirely from the tool name and first sentence.
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 communicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive mutation. The second sentence vaguely adds that data 'may delete, clear, reset, or otherwise remove data,' but it does not specify what data beyond the attachment or whether deletion is reversible. It neither contradicts the annotations nor provides concrete behavioral detail.
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 direct and front-loaded, but the second sentence is largely redundant with the destructiveHint and the first sentence. 'This may delete, clear, reset, or otherwise remove data' is generic filler rather than a precise disclosure. The overall length is appropriate, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter, the schema plus annotations provide most of the necessary context: destructive behavior, idempotency, read-only status, and output shaping. The description is sufficient for an agent to understand the core call, though it omits explicit side-effect scope and usage guidance. A return/value description would be nice but is not essential for a destructive action.
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 documents fields and output_mode with clear descriptions and examples, covering 67% of parameters. The required attachment_id has no schema description, but its meaning is reasonably inferable from its name and the tool purpose. The description itself does not add any parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the imperative 'Delete transaction attachment,' which names a specific action and resource. The noun 'attachment' clearly distinguishes it from transactions_delete_transaction and from list/get/upload/download attachment siblings. There is no ambiguity 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 is given about when to use this tool versus alternatives, such as downloading the attachment first, removing just the attachment versus deleting the whole transaction, or how to add an attachment back. The agent is left to infer usage entirely from the tool name and sibling list. Destructive preconditions or side effects are not 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 a valuable disclosure beyond the annotations: the response will not expose the session token. However, the annotations declare readOnlyHint=false and idempotentHint=false, hinting at possible side effects (e.g., session validation or refresh), while 'Report whether' frames the call as a pure query; this tension is left unresolved. Not a hard contradition, but the side-effect potential is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 16-word sentence, front-loaded with the action, with neither padding nor wasted words. Every element — the resource, the validity criteria, and the token-safety disclaimer — earns its place.
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?
Adequate for a zero-required-param status check: purpose and token-safety are clear, and destructiveHint=false in the annotations carries the safety profile. But with no output schema, the description never hints at the return shape, and the existence of fields/output_mode parameters (summary/full/raw) implies structured output that 'Report whether' does not account for. Behavior when no session exists is also unspecified.
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 contains no parameter information; the schema already documents fields and output_mode in detail, giving 67% coverage. The critical gap is `validate` (boolean, default true), which is undocumented in both schema and description — an agent cannot determine whether validate=false skips network validation or merely changes the reported result. The description could have closed this gap but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Report whether this deployment has a usable, currently-valid Monarch session.' The qualifier 'without exposing the session token' adds meaningful scope. It clearly differentiates from the sibling auth_* tools (auth_create_session, auth_save_session, auth_load_session, auth_login), which create, persist, load, or authenticate rather than report status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording 'Report whether' implies a passive status-check use case, but the description never explicitly says when to prefer this tool over alternatives or what to do when no valid session exists (e.g., route to auth_login or auth_create_session). No exclusions or alternative routing are provided, so the agent must infer usage from the verb 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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds the value of scoping the result set to uploaded/emailed receipts and revealing the filter capability. It does not contradict annotations, but it also adds no behavioral depth beyond that scope — pagination behavior, default ordering, and result-set shape are left to the schema and inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, then packs scope and capability into the second clause. Every word earns its place, and it is appropriately sized for a tool of this simplicity. No redundant restatement of the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity list tool, the description plus strong annotations and a reasonably detailed schema give an agent enough to call it correctly: the purpose, filter dimensions, output-shape controls (output_mode and fields are schema-described), and pagination knobs with defaults. Remaining gaps — default ordering, explicit pagination behavior, and no output schema describing the return envelope — are minor for this tool class and partially covered by the output_mode parameter description.
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 40%, so the description must partially compensate for the undocumented limit, offset, and filters parameters. It does name the two filter dimensions (source, status), giving meaning to the otherwise undescribed ReceiptFilterInput object. It does not, however, clarify limit/offset semantics or how filters combine with them. The schema itself documents fields and output_mode well, creating a mixed picture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('receipts') and adds distinguishing scope: 'uploaded and emailed receipts.' It also surfaces the optional filtering dimensions (source, status), going beyond a mere tautology of the title. The plural list verb and source dimension clearly separate it from siblings like receipts_get_receipt, receipts_upload_receipt, and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the verb and resource: this is the collection-listing operation for receipts, in contrast to singular get/create/update/delete siblings. However, the description never explicitly states when to prefer it over receipts_get_receipt or how it relates to receipts_upload_receipt/receipts_match_receipt. No exclusions or alternative routing are given, so the agent must infer the boundary from naming conventions alone.
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?
Annotations only indicate the tool is not read-only and not idempotent. The description adds important behavioral details: it automatically handles MFA when MONARCH_TOTP_SECRET is configured, saves the resulting session, and uses either configured or explicit credentials. This goes beyond the annotations without contradicting them.
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 compact sentences deliver the core purpose, credential mechanism, MFA behavior, and side-effect of saving the session. Every clause adds necessary information and the most important action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers authentication flow and session persistence adequately for a first call, but with no output schema and sparse annotations, it omits important context such as failure modes, output shape expectations, and how session persistence interacts with sibling session tools. It is functional but not fully comprehensive.
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 low (33%), so the description carries extra responsibility. It does clarify the roles of email/password as 'explicit overrides' and relates mfa_code/totp_secret to automatic MFA handling. However, it does not explain fields or output_mode, which remain defined only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Log in to Monarch' using configured credentials or overrides. It also distinguishes itself from sibling auth tools by noting it saves the session for the deployment's single Monarch account, making it unambiguous which tool to use for logging in.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use for authenticating a session and saving it, but it does not explicitly contrast it with alternatives like auth_create_session, auth_save_session, auth_load_session, or auth_status. The when-to-use context is present implicitly, but exclusion guidance is missing.
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-obot MCP server](https://glama.ai/mcp/servers/dcode/monarch-mcp2-obot/badges/card.svg)](https://glama.ai/mcp/servers/dcode/monarch-mcp2-obot)

Score Badge

Copy to your README.md:

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

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

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