Skip to main content
Glama
Sign In
YNAB MCP Server

YNAB MCP Server

by oliverames
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Execute YNAB Tool

ynab_tool_execute
Read-onlyIdempotent

Run a specified read-only YNAB query by passing a tool name and JSON input; use the tool index to find supported read-only operations.

Instructions

Execute a read-only tool by name and JSON input; discover with ynab_tool_index. Writes require direct tools or ynab_write_tool_execute.

Input Schema

NameRequiredDescriptionDefault
inputNoTool JSON input; omit or {} for no-input tools.
tool_nameYesRead-only tool name from ynab_tool_index.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv6.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / input / description
      Previous value: -"JSON input for the selected YNAB tool. Omit or pass an empty object for tools that take no input."New value: +"Tool JSON input; omit or {} for no-input tools."
    • changedInput schema / properties / tool_name / description
      Previous value: -"Existing read-only YNAB tool name, such as review_unapproved, get_transactions, list_categories, search_categories, or search_payees."New value: +"Read-only tool name from ynab_tool_index."
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv5.4.0
    • removedOutput schema / properties / result / description
      Removed value: -"Structured result returned by Execute YNAB Tool."
  3. Changed1 schema field changedv5.1.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "result": {
+      "description": "Structured result returned by Execute YNAB Tool."
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object"
+}
  4. Addedv3.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, and the description is consistent with them by explicitly excluding writes. It adds useful routing context that the annotations cannot express (write tools have their own executor). It does not cover failure behavior for an unknown tool_name or mismatched input, which is the notable remaining gap.

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 action and packs discovery and the write-alternative into the same line with zero filler. Every clause 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?

An output schema exists, so return values need no explanation, and the write/read split plus discovery pointer cover the essential routing. The one thing an agent might still need is what happens when tool_name is invalid or input doesn't match the target tool's schema, which is not addressed.

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 tool_name and input documented inline, including the 'omit or {} for no-input tools' convention. The description's 'by name and JSON input' merely restates the schema, adding no new syntax or constraint information. Baseline 3 applies when the schema does 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 mechanism: execute a read-only YNAB tool by name with a JSON input, and names ynab_tool_index as the discovery path. It clearly separates itself from the write path (ynab_write_tool_execute). What it doesn't clarify is its relationship to the many concrete read-only siblings (get_transaction, list_accounts), which an agent could plausibly call directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing rules: read-only tools go here, writes must go to direct tools or ynab_write_tool_execute, and discovery happens via ynab_tool_index. That covers when-to-use and the main alternative, but leaves unanswered why an agent would route through this dispatcher versus invoking a known read-only sibling directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools