log_expenseCreate an expense transaction. merchant defaults to description/notes or "Unknown" when omitted. ($0.10; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| notes | No | ||
| amount | Yes | ||
| category | No | ||
| currency | No | ||
| merchant | No | Payee name (defaults when omitted) | |
| description | No |
| Name | Required | Description | Default |
|---|---|---|---|
| expense | No | Expense/income transaction row. | |
| message | No | ||
| expense_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal this is a write operation, so the description adds useful extra behavior: a $0.10 cost, an API key requirement, and merchant defaulting logic. This goes beyond what the schema or annotations provide. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The main action is front-loaded, and the parenthetical cost/auth detail is compact yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers cost, auth, and merchant defaulting, which is helpful, but with 7 parameters and sparse schema coverage it should also address key field semantics and the choice between log_expense and similar tools. The output schema partially compensates for return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low at 14%, and the description only clarifies merchant defaulting. It does not explain the meaning or defaults for amount, date, category, currency, notes, or description, leaving required and optional parameter semantics mostly to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Create an expense transaction.' This clearly identifies what the tool does and differentiates it from read/update siblings such as get_expenses and update_expense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use log_expense versus similar tools like record_purchase or log_event. The only usage-related detail is the merchant defaulting behavior, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have explicit 'prefer X' guidance and mostly target distinct resources, but get_money_between_people is literally an alias for get_person_transactions, get_context_pack and get_life_context overlap heavily, and upload_asset/upload_photo both upload and re-encode images. Detailed descriptions partially rescue it, but the agent still faces avoidable near-duplicates.
The vast majority follow verb_noun snake_case conventions (get_, log_, update_, search_, delete_, add_, archive_, resolve_, etc.). Deviations like the notable_* family and verbose aliases such as get_money_between_people are internally consistent subdomain patterns rather than chaotic naming. No camelCase or mixed style conventions appear.
At 71 tools this far exceeds the 50+ threshold for an extreme tool count. Each domain may have legitimate operations, but the sheer volume would make agent navigation and tool selection expensive. Many listing, search, and upload variants could be consolidated without losing functionality.
The set broadly covers calendar, food, people, inventory, money, travel, assets, photos, Gmail, memories, and notable-people lookup with mostly CRUD-style operations. Notable gaps include no delete_expense, no delete_person, and no direct food-diary listing/getter, so some lifecycles end in workarounds. Overall it is broad but not fully complete.