Skip to main content
Glama

automated_reconciliation__tolerance_match

Pair items from two lists where amount differences are within a set tolerance, returning matched pairs and their differences.

Instructions

[automated-reconciliation] Pair items whose amounts differ by <= tol; returns (a, b, difference).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tolYes
side_aYes
side_bYes
Behavior3/5

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

With no annotations, the description discloses the basic behavior: pairing items within a tolerance and returning tuples. However, it does not detail the matching algorithm (e.g., greedy vs. optimal), handling of duplicates, or determinism, which are important for a reconciliation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that includes the tool's purpose, condition, and output. It is front-loaded and efficient, though it could benefit from a slightly more structured format (e.g., separating parameters and behavior).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a reconciliation matching tool and no output schema, the description is too brief. It lacks details on matching algorithm, edge cases, return format specifics, and prerequisites. The return 'returns (a, b, difference)' is helpful but insufficient for complete understanding.

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 only mentions 'items' and 'amounts' without specifying the structure of arrays side_a and side_b. With 0% schema coverage, the description should explain what fields each item must contain (e.g., an amount field), but it does not. The tolerance parameter is vaguely described as '<= tol'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool pairs items from two sides with a tolerance condition and returns the matched pairs with the difference. It distinguishes from sibling tools like exact_match (exact equality) and one_to_many_match (one-to-many matching).

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

Usage Guidelines3/5

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

The description implies usage when amounts may differ by a small tolerance, but does not explicitly state when to use this tool versus alternatives like exact_match or one_to_many_match. No exclusions or contextual guidance are provided.

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

Install Server

Other Tools

Latest Blog Posts

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/GAJETOso/financeskills'

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