Skip to main content
Glama
ZahiriNatZuke

local-delegate

by ZahiriNatZuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

local_classify

Read-only

Classify text into one label from a supplied list using a local model, returning only the matching label. Use it to route, tag, or categorize content without sending full text to Claude.

Instructions

Classifies a text into ONE of the given labels, with a local model.

Returns exactly one label from the list, with no additional text.

Args:
    text: Text to classify.
    labels: List of candidate labels.

Input Schema

NameRequiredDescriptionDefault
textYes
labelsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, which the phrase 'with a local model' reinforces consistently. The description adds the useful output contract ('returns exactly one label... with no additional text'), though an output schema exists, so this is partially redundant.

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?

Front-loads the purpose, then the return contract, then the args — no wasted sentences. The return statement is slightly redundant given an output schema exists.

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 two-parameter read-only classification tool with an output schema present, the description covers purpose, return shape, and both parameters. Only the missing when-to-use guidance against siblings keeps it from being fully 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?

Schema description coverage is 0%, so the description must carry the parameter burden; it does list both args and glosses them ('text: Text to classify', 'labels: List of candidate labels'). However it adds no format guidance beyond the schema types, e.g. whether labels must be unique or non-empty.

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 (classifies) and resource (text) plus the constraint that output is ONE of the provided labels, using a local model. It does not explicitly differentiate itself from siblings like local_extract or local_summarize, though the label-constrained framing is distinctive enough to infer.

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 statement of when to pick this tool over the ten sibling local_* tools, and no exclusions or prerequisites. The agent must infer usage entirely from the name and purpose sentence.

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