Skip to main content
Glama

Classify entry via LLM sampling

classify_entry
Read-only

Classify a bank statement entry into a semantic category using LLM sampling, returning the chosen category, confidence score, and explanation.

Instructions

Classify one statement entry into a category via MCP LLM Sampling.

Use this when you want a semantic, model-driven label for an entry (payroll,
fee, refund, …) rather than a deterministic rule match. Because it delegates
an LLM completion to the client it is open-world and non-idempotent; for the
fixed candidate categories it chooses from, call
``list_classify_entry_categories`` first.

Uses the **MCP Sampling** protocol primitive: the server (this
process) asks the *client* (the agent's host application) to
perform an LLM completion on the server's behalf, then receives
the model's structured response. Keeps every LLM call in the
operator's existing model contract (privacy, billing, audit).

The model is asked to choose exactly one category from
``categories`` (or :data:`camt053_mcp.classify.DEFAULT_CATEGORIES`
if ``None`` is passed) and return a structured
``{category, confidence, explanation}`` payload.

Clients that do not support Sampling will get an
``{"error": "..."}`` envelope and can fall back to a rules-only
classifier.

Args:
    ctx: The FastMCP Context (auto-injected; provides
        ``session.create_message``).
    entry: A statement entry dict (the shape returned by
        ``parse_statement`` / ``list_entries``).
    categories: The candidate categories. ``None`` uses the
        built-in default list (12 common payment buckets).

Returns:
    ``{"category", "confidence", "explanation"}`` on success or
    ``{"error": "..."}`` on Sampling failure / malformed model
    response / out-of-vocabulary category.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entryYesA single statement entry dict, in the shape returned by parse_statement / list_entries, to classify into one category.
categoriesNoThe candidate categories the model must choose exactly one from. None (the default) uses the built-in default list exposed by list_classify_entry_categories.
Behavior4/5

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

The description expands on annotations by explaining the MCP Sampling protocol, non-idempotence, open-world nature, and custom return format including error handling. It adds context beyond annotations, though it could mention rate limits or privacy implications more explicitly.

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 well-structured with paragraphs and bullet points, front-loading the core purpose. While slightly verbose, each section earns its place by explaining the protocol, parameters, and behavior. Could be trimmed slightly but remains effective.

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

Completeness5/5

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

Given the tool's complexity (LLM sampling, custom return, error handling) and lack of output schema, the description is remarkably complete. It covers the protocol, failure modes (client unsupported, malformed response, out-of-vocabulary), and precisely specifies the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds useful context: it explains that 'entry' should be in the shape from parse_statement / list_entries, and that 'categories' can be None to use the default list. It also describes the return payload, compensating for the absence of an output 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 tool's function: 'Classify one statement entry into a category via MCP LLM Sampling'. It specifies the specific verb (classify), resource (one statement entry), and method (LLM sampling), distinguishing it from deterministic rule matching.

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

Usage Guidelines4/5

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

The description explicitly advises when to use this tool: 'when you want a semantic, model-driven label... rather than a deterministic rule match.' It also instructs users to call list_classify_entry_categories first for fixed categories. While it does not explicitly state when not to use it, the context is clear.

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/sebastienrousseau/camt053-mcp'

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