GunStore-POS Admin MCP

by xuanji86

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.2
Disambiguation4/5
Most tools target clearly separated resources and workflows, and descriptions explicitly disambiguate near-twins like woo_push_item vs woo_push_serial and mark_shipped_manually vs mark_consignment_shipped. The sheer number of tools creates some selection noise, but an agent can usually determine the correct tool from the name and description.
Naming Consistency3/5
Names are consistently snake_case and often use domain prefixes like woo_, frappe_, consignment_, and distributor_, which is helpful. However, the set mixes verb_noun actions (dispose_order, create_consignment_out), noun-phrase queue names (pending_orders, consignment_queue), and service-style names (test_connection, sync_catalog), so there is no single predictable pattern.
Tool Count2/5
At 77 tools, this is far beyond the typical well-scoped MCP surface and exceeds the 25+ too-many threshold. While the domain is broad, packing generic CRUD wrappers, integration actions, queues, and reports into one server creates a heavy surface that will strain agent context and tool-selection accuracy.
Completeness4/5
The tool set covers nearly the full gun-store administration lifecycle: inventory, FFL/FastBound compliance, orders, consignments, distributor operations, e-commerce integrations, and financial reporting. A few workflow actions are only reachable via generic frappe_run_method or are missing dedicated tools—e.g., GunBroker push/end and explicit distributor-order confirmation—but these are minor gaps.
Average 4.1/5 across 77 of 77 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states a batch operation but does not disclose side effects (e.g., API calls, state changes, duration). The mention of confirm is confusing given schema defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but omits critical details about the confirm parameter and behavior. Brevity comes at cost of clarity.
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?
Lacks essential context for a potentially destructive batch operation: what happens if confirm is false? Output? Error handling? No output schema. Sibling tools exist but no differentiation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description only mentions 'confirm=true' without explanation. The parameter 'confirm' is optional with default false in schema, but description implies it must be true, creating inconsistency. No added meaning beyond the name.
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?
Description clearly states verb 'Re-run ATF EZ Check' and resource 'EVERY FFL supplier on file', specifying batch re-verification. This distinguishes from sibling tools like atf_verify_ffl and verify_supplier_ffl which likely handle single FFL verification.
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 explicit guidance on when to use this batch tool vs alternatives like atf_verify_ffl or verify_supplier_ffl. The hint 'confirm=true' suggests a condition but is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It reveals the docstatus transition (1->2) and confirm requirement, but omits critical details such as irreversibility, permission needs, side effects on related records, or error conditions. This is insufficient for a mutation tool.
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?
The description is extremely concise at two sentences, both front-loaded with the core action and a critical usage condition. No redundant words or irrelevant details; every sentence provides essential information.
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 tool has no output schema, no annotations, and 3 parameters with 0% schema coverage, the description is too brief. It lacks information on return values, error scenarios, prerequisites, or potential impacts of cancellation. The agent is left with an incomplete picture of the tool's behavior.
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?
Schema description coverage is 0%, yet the description only adds meaning for the confirm parameter (requires true). The required parameters doctype and name lack any explanation of their format, constraints, or role, leaving the agent to guess. The description should elaborate on all parameters given the low schema coverage.
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 clearly states the tool cancels a submitted document by changing docstatus from 1 to 2, which distinguishes it from sibling tools like frappe_submit_document (does opposite) and frappe_delete_document (deletion). The verb-resource pairing is specific and actionable.
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 for submitted documents and explicitly requires confirm=true, but does not provide guidance on when to avoid using it or suggest alternatives like frappe_update_document or frappe_delete_document. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the tool returns 'columns + result rows', which is basic output behavior. However, with no annotations, it misses safety cues (e.g., read-only nature, potential side effects). It is adequate but not thorough.
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, front-loaded sentence with no filler. It could be improved by adding more detail without losing conciseness, but it is efficient for its length.
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 lack of output schema and annotations, the description should provide more context about valid report names, filter syntax, and error handling. The current text is too sparse for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only mentions report_name via an example. The filters parameter is completely undocumented; its structure (object, array, or null) and usage are unexplained, leaving the agent guessing.
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 action ('Run') and the resource ('Script/Query Report') with a concrete example ('Firearms In Stock'). This specific verb+resource combination distinguishes it from sibling tools like 'frappe_list_documents' or 'frappe_get_document'.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., frappe_list_documents, frappe_run_method), the agent would benefit from explicit when-to-use or comparison hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions a live check and write operation but lacks details on external ATE dependency, write side effects, error handling, or rate limits. Basic behavior is implied but insufficient for safe agent invocation.
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?
Two sentences, but the second is a fragment. No superfluous words, but the structure could be improved by merging and clarifying. Still relatively concise.
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?
For a mutation tool that performs a live external check and updates a database, the description is inadequate. It omits return values (no output schema), success/failure behavior, prerequisites (supplier existence), and any confirmation of action taken. Leaves significant gaps for agent understanding.
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?
With 0% schema description coverage, the description adds meaning: 'supplier_name' is contextualized as part of an FFL check, and 'confirm' is explained as the trigger for writing to the Supplier. This goes beyond the schema's default value and type.
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 clearly states the tool performs a live ATF EZ Check on a supplier's FFL and updates verification status/fields. The verb 'verify' and resource 'supplier FFL' are specific, but it does not differentiate from sibling tool atf_verify_ffl, which may be similar.
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?
Only minimal guidance on the confirm parameter ('confirm=true (it writes to the Supplier)'), with no advice on when to use this tool versus alternatives like atf_verify_ffl or other tools. No when-not-to-use or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral details. It only says 'Typeahead search' but lacks info on case sensitivity, pagination, error handling, or side effects.
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?
Single sentence, front-loaded with key information, no wasted words.
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 no output schema and no annotations, the description is incomplete. It lacks details on return format, pagination, error handling, or prerequisites.
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?
Schema description coverage is 0%. The description adds some meaning by listing what can be searched, but does not explain the 'limit' parameter or how the query parameter works beyond general search.
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 it is a typeahead search for items by barcode, item code, or name. This is specific and distinguishes it from sibling tools like frappe_list_documents or rsr_catalog_search.
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 guidance on when to use this tool versus other search tools. No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions setting a flag and opening/closing a ToDo, but does not disclose side effects, required permissions, or the meaning of 'confirm=true'. Behavioral details are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, but the second sentence ('confirm=true.') is cryptic and could be integrated or expanded. It is under-specified rather than concise.
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 lack of output schema, low schema coverage, and no annotations, the description is incomplete. It does not explain return values, error conditions, or prerequisites. It fails to provide sufficient context for correct use.
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?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'confirm=true' and the flag setting, but does not describe the 'value' parameter (boolean) or the role of 'confirm' beyond stating its presence. This adds minimal meaning over the 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 action ('Set a firearm's Service Needed flag'), the resource (firearm via serial), and the effect (open/close gunsmith ToDo). It distinguishes itself from sibling tools which are about stock management, FFL verification, etc.
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 by mentioning the flag and ToDo, but lacks explicit guidance on when to use this tool versus alternatives. The 'confirm=true' hint is not explained as a prerequisite or condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It honestly states 'Read-only' and documents valid status values and that empty status means all orders. However, it does not describe output shape, sorting, pagination behavior, or whether the distributor parameter restricts by name or ID.
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?
The description is compact and front-loaded with the core purpose, followed by the most important parameter semantics and a safety-relevant annotation substitute. The status list is useful rather than filler, and there is no redundant wording.
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 that there is no output schema and no annotations, the description should explain return format and all parameter semantics. It covers the status list and read-only nature but omits what the returned records contain, how limit and distributor interact, and any ordering or defaults beyond the schema's own default of 50. An agent could make a basic call but would not fully understand the results or optional filtering behavior.
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?
Schema description coverage is 0%, so the description must compensate. It explains the status parameter's allowed values and default meaning ('empty = all'), but it does not describe the limit parameter or the distributor parameter at all. This is insufficient for correct parameter usage beyond the one documented field.
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 clear verb and resource: 'List Distributor Orders' and clarifies the domain with '(drop-ship / restock purchase orders to RSR)'. It distinguishes the tool from catalog/route/quote siblings like distributor_catalog_search or distributor_quote, though it does not explicitly contrast it with nearby list tools like pending_orders.
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 context through the status filter list and 'empty = all', and the read-only note signals safe listing behavior. However, it does not explicitly say when to choose this over alternatives such as pending_orders or distributor_route_queue, and no 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that credential/password fields are stripped automatically and that some fields are refused outright, which is valuable. However, it does not mention permissions, side effects, idempotency, or what constitutes a refusal, leaving several behavioral questions unanswered.
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?
The description is two sentences long, front-loaded with the core action, and every sentence earns its place. The credential-stripping caveat and the pointer to frappe_update_document add useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and no output schema, and the description covers the central create behavior plus an important data-handling caveat. Still, it does not describe the return value, error behavior, or prerequisites, and delegates some needed context to frappe_update_document without explaining what the agent should do with that information.
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 compensate. It adds meaningful semantics around the values parameter by warning that credential/password fields are stripped and some fields are refused. However, it does not explain the structure of values or the meaning/format of doctype beyond what the name implies.
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 clear verb and resource: "Create a document." This distinguishes it from sibling operations like update, delete, or submit, but it does not explicitly clarify that it operates against a Frappe doctype using a values object, so it is slightly more generic than the strongest examples.
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 explicit when-to-use or when-not-to-use guidance is provided. The pointer "see frappe_update_document" hints at related behavior around refused fields, but it does not explain when an agent should choose this tool over frappe_update_document, frappe_run_method, or other document-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining side effects, and it does disclose meaningful behavior: it holds the invoice in Draft, opens a FastBound 4473, and returns the FastBound URL. It leaves ambiguity around the trailing 'confirm=true' and does not mention prerequisites, reversibility, or failure modes.
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 compact and front-loads the main purpose while providing a useful serial mapping example. The only structural issue is the awkward, unexplained 'confirm=true' fragment at the end.
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?
The tool involves a nested object, no output schema, and no annotations, so the description must do more to make the tool self-sufficient. It fails to clarify confirm semantics, invoice_name expectations, and how this differs from start_transfer_4473 or manager_override_4473, leaving an agent likely to need extra context.
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%, but the description adds real value by explaining serial_by_item_row with a concrete example and by mentioning confirm=true. It does not explain invoice_name or clarify what confirm actually controls, which leaves gaps for a three-parameter tool.
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 clearly states the verb ('kick off'), the resource (ATF 4473), and the context (firearm POS/Sales Invoice). It also explains the immediate effect—holding the invoice in Draft and opening a FastBound 4473—which helps distinguish it from generic document tools, though it does not explicitly contrast it with sibling tools like start_transfer_4473 or manager_override_4473.
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 phrase 'for a firearm POS/Sales Invoice' gives an implicit use case, so an agent can infer when this tool is relevant. However, there is no explicit guidance on when to choose this over related 4473 tools, and no when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'fetch' but does not disclose error handling (e.g., document not found), authentication, or side effects. Lacks behavioral depth.
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?
Two sentences with an example. No unnecessary words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple fetch tool, but missing return format and error behavior. Given no output schema, more detail would be beneficial.
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 coverage is 0%, but description adds value by explaining the special case for 'name' when doctype is Single. However, does not explain parameters beyond that.
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?
Description clearly states 'Fetch one document by name' and provides a specific note for Single/Settings doctypes, distinguishing it from sibling tools like frappe_list_documents.
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 gives important context for Single doctypes but does not explicitly guide when to use this tool over siblings (e.g., frappe_list_documents) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions 'confirm=true' but does not disclose what happens when confirm is false, or any side effects/requirements. Adequate but lacks depth.
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?
Concise single sentence with crucial exclusion info. Front-loaded with the main purpose, no wasted words.
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?
With 6 parameters, no output schema, and no annotations, the description provides insufficient context. Does not explain return values, side effects, or parameter semantics beyond confirm. Incomplete for a stock add operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'confirm' parameter, leaving the other 5 parameters (item_code, qty, warehouse, rate, remarks) completely unexplained. Fails to add meaning beyond the 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 verb 'Add stock', the resource 'NON-serialized item', and context 'Material Receipt Stock Entry'. It distinguishes from siblings by explicitly excluding serial-tracked firearms and directing to 'receive_goods'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (non-serialized items) and when not (serial-tracked firearms, use receive_goods). Also hints to set confirm=true, providing clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It discloses that the tool performs a write operation ('upsert') and requires explicit confirmation. However, it omits details such as side effects (e.g., what happens if the FFL is invalid), permissions needed, or any API rate limits. The behavioral summary is basic but not misleading.
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?
The description comprises two short, front-loaded sentences. Every word adds value: the first sentence states the core action, the second clarifies a key usage requirement. No filler or redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description covers the main action and a usage constraint. However, it lacks information about return values (e.g., success/failure indication), error handling, and what 'upsert an ATF FFL Record' entails in terms of data stored. It is minimally complete but has gaps.
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?
The schema has 0% description coverage, so the description must compensate. It explains the role of the confirm parameter ('requires confirm=true'), which is not obvious from the schema alone. However, the ffl_number parameter lacks additional context beyond its name. The description adds moderate value over the schema but does not fully cover all parameters.
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 purpose: 'Live-verify an FFL number via ATF EZ Check and upsert an ATF FFL Record.' It uses specific verbs (verify, upsert) and resources (FFL number, ATF FFL Record), distinguishing it from sibling tools like verify_supplier_ffl by referencing ATF EZ Check and the upsert action.
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 provides a usage note: 'Creates/updates a record, so requires confirm=true.' This indicates when to set the confirm parameter but does not explicitly state when to use this tool over alternatives like verify_supplier_ffl or other verification methods. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful traits: no ShipStation push, idempotency per {serial, order}, and the confirm=true requirement. Still, it never explains what 'dispose' actually does to inventory/records or whether the operation is reversible, leaving the core destructive semantics unclear.
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?
The description is three tight sentences with no filler. It front-loads the action and quickly adds the critical caveat, idempotency note, and confirmation requirement. Every sentence earns its place.
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?
This is a destructive, mutation-style tool with no annotations and no output schema, so the description needed to cover more ground. It explains the order type and the no-ShipStation side effect, but it does not define the format of woo_online_order, what happens when confirm is false, or what a successful disposal returns. These are material gaps for an agent deciding whether and how to invoke it.
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?
Schema description coverage is 0%, so the description needed to add meaning for both parameters. It only advises confirm=true and references an ambiguous {serial, order} idempotency key; the main parameter woo_online_order is not given a format, source, or example. The mention of 'serial' does not match any input field, which adds confusion rather than clarification.
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 states a specific verb ('Dispose') and a precise resource ('firearms on a paid Woo Online Order (web row)'). It also explicitly distinguishes this tool from ShipStation-handled orders with 'No ShipStation push here,' which differentiates it from related dispose/shipping tools.
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 clearly identifies the target scenario: a paid Woo Online Order that is shipped by the store's own WooCommerce plugin. However, it does not explicitly name an alternative sibling tool or provide an overt 'use dispose_order instead' rule, so it has solid context but no formal when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'read-only', indicating no side effects. However, with no annotations, it lacks detail on behavior such as error handling, response format, or whether it tests authentication. Provides basic but incomplete behavioral context.
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?
The description is a single sentence with no wasted words. It is front-loaded and concise, conveying essential information efficiently.
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 no-parameter connection test tool, the description is largely complete. It could be improved by briefly stating what constitutes a successful connection (e.g., returns success message), but given the tool's simplicity, the current description is adequate.
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?
No parameters exist, and schema coverage is 100%. Per guidelines, 0 parameters results in a baseline score of 4, as the description adds no additional parameter information beyond the schema.
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 clearly states the tool tests a connection to the FastBound API and is read-only. The verb 'probe' and resource 'FastBound API connection' are specific, but it does not explicitly differentiate from sibling connection test tools like rsr_test_connection or woo_test_connection.
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 for checking FastBound API connectivity but provides no explicit guidance on when to use this tool versus alternatives. Context implies it is for FastBound, but lacking clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read-only report but doesn't confirm non-destructive nature, permissions, or any side effects. Minimal behavioral disclosure.
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?
Single sentence with clear structure: action, output, options. No redundant words, front-loads purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers key output fields and filters but lacks details on ordering, pagination, or limitations. Without output schema, more completeness would be helpful.
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 has 0% description coverage, but description adds that warehouse and manufacturer are optional filters. This adds meaning beyond parameter names, though not detailed.
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?
Description clearly states it runs the 'Firearms In Stock' report, shows in-stock firearms by serial with acquisition source and FastBound link. This is specific and distinguishes it from siblings like 'add_stock' or 'find_item'.
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?
Description implies usage context (when you need in-stock firearm details) but lacks explicit guidance on when not to use it or how it differs from alternatives like 'item_stock' or 'find_item'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses a key behavioral trait: fields flagged is_password=true cannot be written through this MCP, and advises using Desk for those. This adds useful context beyond the obvious read operation.
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?
The description is extremely concise, consisting of two sentences. The first sentence immediately conveys the main purpose, and the second adds a critical behavioral note. No filler words or redundancy.
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?
Given no output schema, the description lists the returned fields (fieldname, label, fieldtype, options, reqd) and mentions that custom fields are included. It also notes a key limitation about password fields. It could mention error handling or that all fields are returned, but overall it is complete for a simple metadata retrieval tool.
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 input schema has one parameter (doctype) with no description (coverage 0%). The description mentions 'doctype' but does not elaborate on its meaning, format, or provide examples. The parameter is self-explanatory, but the description fails to compensate for the lack of schema description.
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 lists a doctype's fields, including custom fields, and lists the specific fields returned. It uses a specific verb ('List') and resource ('doctype fields'), and the action is distinct from sibling tools like frappe_get_document or frappe_list_documents which operate on document data.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention use cases (e.g., schema exploration before creating documents) or exclude any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains filter format and limit semantics (default 20, limit=0 for all rows), but omits details on pagination (start parameter), sorting (order_by), and return format. Adequate but not comprehensive.
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 concise with two short paragraphs. The first line gives the core purpose, and the second adds useful detail. No wasted words.
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?
With 6 parameters and no output schema, the description should be richer. It explains filters and limit but leaves fields, start, and order_by undocumented. Also lacks return format info, which is important for a listing tool. Incomplete for effective use.
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 coverage is 0%, so description must compensate. It thoroughly explains filters format and limit behavior, but does not explain the fields parameter (which fields to return), start (offset), or order_by format. Partial coverage.
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 it lists documents of any doctype, which is a specific verb+resource. It distinguishes from siblings like frappe_get_document (single) and frappe_describe_doctype (schema).
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 explains when to use this tool (listing documents) and suggests calling frappe_describe_doctype first if field names are unknown. It does not explicitly state when not to use alternatives, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that the tool bypasses ShipStation and enforces a safety guard, which is useful. However, the role of 'confirm=true' is ambiguous and the consequences or reversibility of clearing the queue are not stated.
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?
Three short sentences with no filler; the core action, use cases, and guard are front-loaded. The final 'confirm=true' is telegraphic but still compact and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the main scenario and an important safety precondition, which is enough to select the tool. However, it omits how sales_invoice should be supplied, what a successful call returns, and whether clearing is reversible, leaving an agent with gaps for safe invocation.
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?
Schema description coverage is 0%, so the description must compensate, but it only offers the terse 'confirm=true' hint. It never explicitly explains that sales_invoice identifies the DISPOSED order to clear, leaving the core parameter semantically underdocumented.
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?
States a specific action ('Clear ... from the Pending Order queue') and scope ('a DISPOSED order'), explicitly distinguishing itself from ShipStation-push flows. The parenthetical use cases further disambiguate this as a manual override tool.
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?
Provides concrete when-to-use scenarios: label bought elsewhere, integration off, or FFL expired after dispose. It also states a hard precondition by refusing while any firearm is undisposed, though it does not explicitly name sibling alternatives like push_shipment or dispose_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full disclosure burden and succeeds: it states that the call is synchronous, idempotent, persists nothing on API failure, and is safe to retry. It also clarifies the relationship to the Dispose step. This is strong behavioral disclosure for an action 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 concise and front-loads the core purpose, followed by useful execution traits. The final 'confirm=true.' fragment is cryptic and adds confusion rather than clarity, so the structure is efficient but not flawless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter action with no output schema or annotations, the description covers purpose, usage context, idempotency, and failure behavior well. However, the meaning of the required consignment_out parameter and the confirm flag are not explained, leaving a meaningful gap for an agent trying to invoke it correctly.
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?
Schema description coverage is 0%, so the description needed to explain the parameters. It only mentions 'confirm=true' without explaining what that means for the confirm parameter, and it never explains what consignment_out should contain, such as an ID or identifier. The required parameter is left ambiguous.
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 action and resource: push a DISPOSED Consignment Out to ShipStation so staff can buy the outbound label. It clearly identifies the business context as the At Dealer queue's Ship action. However, it does not explicitly differentiate from similarly named siblings such as ship_consignment_out or mark_consignment_shipped, so full distinction is left to inference.
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 concrete when-to-use context: this is the At Dealer queue's Ship action, intended so staff can buy the outbound label. It also notes that the step is independent of the Dispose step. But it does not explicitly name alternatives or state when to prefer another consignment/shipping tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the operation is a PUT (mutating), edits in place, and is a no-op if the firearm isn't in FastBound. This provides key behavioral context, though auth requirements or error handling are omitted.
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?
Two sentences with no filler. Front-loaded with the main action, then behavioral notes. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description provides minimal viability. It explains the core action and no-op case but lacks details on return values, errors, and the confirm parameter's semantics.
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?
Schema description coverage is 0%, so the description must compensate. It implies the 'serial' parameter's role but doesn't explain format or constraints. The 'confirm' parameter is mentioned as 'confirm=true' but without explanation of its effect (defaults to false). This is insufficient for an agent to use correctly.
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 it pushes a per-unit correction for a firearm to FastBound, editing in place. It specifies the resource (bound-book item) and action, distinguishing it from sibling tools like 'find_item' which are read-only.
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 after acquisition when a correction is needed for an already-booked firearm, but lacks explicit when-to-use or when-not-to-use guidance. It mentions 'No-op if the gun isn't in FastBound yet' but does not compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the sync runs in the background and returns once queued, which is adequate for a trigger tool. However, it does not describe failure modes, progress, or results beyond queuing.
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?
The description is extremely concise with two short sentences. Every word is necessary and front-loaded. No redundancy.
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 trigger tool with no parameters, no output schema, and no complex behavior, the description covers the essential purpose and async nature. Could mention what 'full sync' means or success indicators, but it's largely complete.
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?
No parameters exist in the schema, and schema description coverage is 100% trivially. The tool has no parameters, so baseline 4 is appropriate. No additional parameter info needed.
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 verb 'trigger' and the resource 'full RSR catalog sync'. It distinguishes from sibling tools like rsr_catalog_search which is a search, and backfill_from_rsr which is incremental. The purpose is unambiguous.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full disclosure burden and does so well: it reveals automatic stripping of credential/password fields, whole-call failure for refused fields, and the real-world safety rationale behind the GunBroker Settings exclusions. It also clearly positions the tool as a mutating operation, so an agent will not mistake it for read-only.
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 short and front-loaded, with the core purpose in the first clause and caveats following in a compact second sentence. The detailed GunBroker example is verbose but earns its place because it explains a non-obvious, high-stakes constraint.
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 mutation tool with no annotations and no output schema, the description covers the critical safety behavior and gives an agent enough to avoid destructive misuse. It leaves the return value unspecified and does not state whether values are merged or wholly replaced, but these are minor gaps relative to the safety-critical guidance provided.
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 schema has three parameters with zero description coverage, and the description never explains what doctype, name, or values mean or how to construct the values object. It mentions example field names only as restrictions, not as parameter semantics, so it does not compensate for the coverage gap.
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?
Description opens with a clear verb and resource: 'Update fields on a document.' This unambiguously names the operation and target, and together with the tool name separates it from sibling create/delete/submit/cancel tools. It does not explicitly contrast with a sibling, so it stops short of the strongest sibling differentiation.
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 explicitly tells agents not to attempt credential/password updates and, for GunBroker Settings, names specific fields that are refused and directs them to be changed in Desk by a person. This is clear when-not-to-use guidance, though it does not address the broader decision of when to update versus create or delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It does disclose that the operation is read-only and identifies the exact API call, which is useful. However, it does not describe what a successful probe returns, what happens on failure, or any response semantics, leaving the agent without full visibility into the tool's behavior.
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 with no filler. The action, target, and read-only nature are all front-loaded, and every word adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter connection test, the description is mostly complete: it names the system, the endpoint, and the safety profile. However, because there is no output schema, the agent is not told what a successful response looks like or how to interpret the result, which is a notable gap for a test/probe tool.
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?
The input schema has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter meanings because there are none to document.
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 states a specific action ('Probe'), a specific resource ('ShipStation API'), and the exact endpoint ('GET /v2/carriers'). It clearly distinguishes this tool from the other test_connection siblings by naming the target system explicitly.
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 the tool is used to verify ShipStation connectivity, but it does not explicitly state when to use this over other test_connection tools or provide exclusion criteria. The sibling names suggest alternatives, but the description itself offers no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value ('Returns the File doc incl. file_url') and the is_private behavior, but omits potential side effects, failure modes, or permission requirements. For a mutation-like operation (uploading a file), more could be said about what happens on overwrite or failure, so it is only moderately transparent.
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?
The description is three sentences, each earning its place: the core action and options, the return value and is_private default, and the alternative for bulk imports. It is front-loaded with the main purpose and avoids fluff.
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 5-parameter upload tool with no output schema and no annotations, the description covers the essential aspects: return type, the is_private nuance, and a pointer to a bulk alternative. It lacks explicit error-handling or prerequisite details, but for an upload operation with a required file_path, it is fairly complete.
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 description coverage is 0%, so the description must compensate. It clearly explains file_path (local file), the optional doctype/name/fieldname for attachment, and is_private with its default and when to set it false. This adds significant meaning beyond the bare schema, though it does not detail exact formats or constraints for name or fieldname.
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 clear verb ('Upload') and resource ('LOCAL file to the POS as a File document'), and explains the optional attachment to a document (doctype + name) and Attach field (fieldname). It distinguishes from a bulk import script but not from any sibling tool in the provided list, so it lacks explicit sibling differentiation. Still, the purpose is unambiguous.
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 provides concrete guidance: it notes the default is_private=true and that product photos for WooCommerce sideload need is_private=false, and explicitly steers away from this tool for bulk imports ('For bulk photo+gallery imports prefer the firearm-listing-import script'). It does not, however, compare to alternative upload or attachment tools among the siblings, so the guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by stating the exact state change ('Draft + stock 0') and the immediate commercial effect. It also surfaces the confirm=true requirement. It stops short of describing reversibility or what happens when confirm is false, but the core mutation is clearly disclosed.
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?
Two short sentences carry the action, the effect, and critical parameter constraints with no filler. The main behavior is front-loaded, and the inline 'site: retail | dealer. confirm=true.' is economical and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a no-annotation mutation with no output schema, so more context would help. The description covers the action and key parameter values, but it omits explicit distinction from the similar woo_delist_serial tool, possible side effects, and response/return behavior. Adequate for invoking, but not 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 compensate. It adds useful semantics for site ('retail | dealer') and instructs confirm=true, but it does not describe item_code, which is the only required parameter, nor explain the meaning of confirm=false beyond the schema's default.
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 opens with a specific verb and resource: 'Set the WooCommerce product for an Item to Draft + stock 0'. It clearly states the resulting outcome ('hiding it from the shop immediately') and distinguishes this item-level delist tool from serial-level siblings like woo_delist_serial.
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 usage context is only implied: this is the tool to use when an Item should no longer be visible in the shop. It does not explicitly state when to choose this over woo_delist_serial or when not to use it, such as when only a serial needs delisting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is read-only, which is a key behavioral trait beyond the schema. However, it does not describe the return value, error behavior, or any authentication prerequisites. Since no annotations are provided, the description carries the full burden, and for a simple probe tool it partially suffices but leaves gaps.
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?
The description is extremely concise: one sentence for the core purpose and a one-line parameter mapping. All information is front-loaded and essential, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only test tool, the description covers the purpose and the one parameter adequately. However, it omits any description of return values (e.g., success/failure, latency) and prerequisites (e.g., configured API credentials). It also does not explicitly differentiate from sibling test tools, though the name does. Given the lack of an output schema and annotations, more detail would be helpful.
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?
The description explicitly explains the only parameter 'site' by enumerating 'retail (main store)' and 'dealer (dealer portal)', which adds meaning beyond the bare schema. This compensates for the 0% schema description coverage, though it does not explicitly state that these are the only valid values.
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 verb 'Probe', the resource 'WooCommerce store's API connection', and explicitly marks it as read-only. It also names the site choices (retail vs dealer), making the tool's specific function unambiguous and easily distinguishable from sibling connection testers like rsr_test_connection or fastbound_test_connection.
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 provides a hint about when to use the tool by specifying the site options, but it does not explicitly state when to use this tool over other connection testers or when not to use it. The name and WooCommerce mention imply the context, but there is no direct alternation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'never overwrites' and mentions the confirm parameter, providing key behavioral traits. However, it does not mention any prerequisites or side effects, but overall is good.
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?
The description is a single sentence that packs all necessary information: purpose, behavior, parameter hints. No wasted words.
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?
Given no output schema and no annotations, the description covers purpose, behavior, and parameter usage adequately. It does not describe the return value, but that is acceptable for a backfill tool.
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?
The description adds meaning to parameters (item_codes omitted = all RSR-linked items, confirm=true) despite 0% schema coverage. However, it does not explain the types or formats of item_codes in detail.
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 backfills manufacturer/model/caliber from RSR catalog, specifying it only fills empty fields. This distinguishes it from sibling tools like rsr_sync_catalog which likely syncs the entire catalog.
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 provides parameter guidance (item_codes omitted = all, confirm=true) but does not explicitly state when to use this tool versus alternatives like rsr_sync_catalog or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and handles it well. It explicitly discloses that the tool is read-only, makes no HTTP call to the distributor, and that the quantity is a cached catalog figure whose freshness is not asserted. These are meaningful behavioral traits beyond what the schema alone provides.
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?
The description is compact, information-dense, and front-loaded with the core purpose. Every sentence earns its place: output scope, parameter selection rule, cached-quantity caveat, and read-only/no-HTTP note. There is no redundancy or filler.
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?
The description covers the main return fields, the key input distinction, and an important data-freshness caveat. It is slightly incomplete regarding how distributor factors into the lookup and what happens when no identifying parameter is supplied, but given the simple read-only nature, it is largely sufficient.
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?
The description adds value by distinguishing item_code (stocked item) from sku (raw catalog row), which the schema does not explain. However, the distributor parameter is left entirely implicit, and the description does not clarify whether item_code and sku are mutually exclusive or what happens when both are null, despite all parameters being optional in the schema.
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 clearly identifies the tool's domain as per-item economics, enumerating specific outputs (cost, MAP, MSRP, suggested sell price, cached quantity, restricted states, block flags). It does not use an explicit verb like 'retrieves' or 'gets,' and it does not name a sibling tool to distinguish against, so it falls just short of a 5.
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 gives partial usage direction by explaining to pass item_code for a stocked item or sku for a raw catalog row. However, it does not explicitly state when to prefer this tool over alternatives such as distributor_catalog_search, distributor_check_availability, or item_stock, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does this well by revealing side effects: a real FFL re-acquisition per gun, an automatic FastBound hook, and stock movement. It stops short of noting irreversibility, authorization requirements, or failure behavior, which matters for such a high-stakes operation.
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 compact and front-loaded, with the most important behavioral facts in the first sentence. The trailing fragments add useful parameter hints, though 'confirm=true' is cryptic and could be clearer without much added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives strong high-level behavior but is incomplete for a complex, sensitive operation. It does not describe the return value or success/failure signals, does not define consignment_out, and does not explicitly warn about irreversibility. An agent could probably invoke it correctly with some inference, but important gaps remain.
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 compensate. It explains lines as Consignment Out Line names, confirm as a boolean flag, and to_warehouse as the optional target warehouse, but it leaves the required consignment_out parameter completely undefined. The confirm=true fragment is also terse and reads more like an instruction than a parameter explanation.
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 names the action ('Take unsold consigned guns BACK from the dealer'), the target resource, and the expected outcomes: FFL re-acquisition per gun, FastBound push, and warehouse restock. This differentiates it from sibling tools like create_consignment_out, ship_consignment_out, or cancel_consignment without needing to open schemas.
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 states the intended scenario: returning unsold consigned guns from the dealer, and it mentions the optional destination warehouse. It does not explicitly name alternatives or exclusion conditions, so an agent must infer when not to use it, but the context is clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool is read-only and probes connection and configuration, which gives a basic behavioral understanding. However, it lacks detail on what constitutes a successful probe, error messages, or whether it makes any outbound network requests (which is implied by 'probe').
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?
The description is a single, well-structured sentence that is front-loaded with the action ('Probe') and resource. Every word adds value, with no unnecessary fluff. It is highly concise.
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?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It states the tool probes connection and configuration and is read-only. A minor gap is the absence of any indication of the output or return value, but for a connection test tool, this is acceptable.
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?
The tool has zero parameters and input schema coverage is 100% (trivially). According to guidelines, 0 params warrants a baseline of 4. The description adds no parameter information because none are needed. The purpose description suffices.
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 purpose: 'Probe the RSR FTPS connection + configuration (read-only).' It uses a specific verb ('probe') and resource ('RSR FTPS connection + configuration'), and explicitly notes it is read-only, distinguishing it from sibling tools like `rsr_sync_catalog`.
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 for testing the RSR FTPS connection, and the read-only annotation suggests safe invocation. However, it does not explicitly state when to use this tool versus alternatives like `fastbound_test_connection` or `woo_test_connection`, nor does it provide any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosures. It mentions audit trail recording and confirm parameter, but lacks details on reversibility, permissions, or side effects. The behavior is partially transparent but not fully detailed.
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?
The description is concise and front-loaded, with no wasted words. Every sentence provides relevant information about purpose, method, and key behaviors.
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?
Given the tool's simplicity and lack of output schema, the description covers the essential aspects: target items (non-serialized), operation type (absolute set), method (reconciliation), and key parameters (reason, confirm). It is mostly complete, though could clarify warehouse default behavior.
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 should compensate. It explains 'reason' is recorded and 'new_qty' is an absolute value, but does not describe 'item_code', 'warehouse', or 'confirm' semantics beyond their names. Partial value added.
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 sets a non-serialized item's on-hand quantity to an absolute value via stock reconciliation, distinguishing it from siblings like add_stock which likely increment quantity. The verb 'set' and resource 'NON-serialized item's on-hand qty' are specific, and the method (Stock Reconciliation) is mentioned.
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 implies use for non-serialized items and absolute quantity setting, contrasting with add_stock. However, it does not explicitly state when not to use or name alternatives, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly discloses the two concrete mutations (Draft status + stock 0) and the immediate effect (hiding the gun from the shop). It does not discuss reversibility or edge cases, but the core behavioral impact is explicit.
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?
The description is two short sentences with no filler. The primary action and effect are front-loaded, and the trailing parameter hints are minimal but useful. Every part 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?
For a simple 3-parameter tool with one required field and no output schema, the description covers the operation, the target state, the immediate result, site options, and the confirmation requirement. It is slightly terse on serial_no semantics but sufficient for correct invocation.
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 compensate. It adds meaning for 'site' by enumerating allowed values and clarifies that 'confirm' should be true to take effect. The required 'serial_no' is implied by the tool name and opening phrase, but no explicit format or guidance is given.
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 states a specific verb ('Set'), a precise resource ('ONE Serial No's WooCommerce product'), and the exact state change ('Draft + stock 0'). It also differentiates itself by emphasizing serial-level operation and immediate effect, distinguishing it from item-level siblings like woo_delist_item.
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 gives context by noting applicable sites ('retail | dealer') and requiring 'confirm=true', which implies the confirmation step before executing. However, it does not explicitly state when to prefer this tool over alternatives such as woo_delist_item, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Read-only,' defines the population of rows, and specifies that failed rows sort first, which is meaningful behavioral detail. It does not cover auth, rate limits, or output shape, but those are less critical for a zero-parameter read-only queue.
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?
The description is compact and efficiently structured: the first sentence defines scope, the second covers ordering, the third routes retry behavior, and the final phrase states read-only semantics. Every sentence adds value and there is no redundant restatement.
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 zero-parameter read-only tool, the description is largely complete: it explains what rows appear, their ordering, and the correct next action for failed rows. It does not enumerate return fields or specify how failures are indicated in the response, but the queue-of-orders framing makes the expected result type reasonably clear.
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?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to document. The description adds no parameter-level detail, but none is needed; the baseline for a 0-parameter tool applies.
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 clearly identifies the tool as the post-sale consignment settlement queue and defines its scope with concrete inclusion criteria: sold lines whose settlement invoice is unbooked or unpaid. It also distinguishes from retry_consignment_invoice by explicitly naming that tool for retries. However, it lacks an explicit verb like 'list' or 'get', relying on the queue/sorting language to imply a read-only list.
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 gives concrete usage context: this is the queue for incomplete consignment settlements, and any retry of a failed settlement invoice should be routed to retry_consignment_invoice. It does not explicitly contrast this tool with similar sibling tools such as consignment_queue or pending_orders, but the retry routing and read-only note provide sufficient directional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. It explicitly discloses read-only semantics, that blocked rows are returned rather than hidden, and how settlement/reference prices map to cost and msrp. This goes well beyond a minimal description.
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 dense sentence with no filler; purpose, filter behavior, pricing semantics, blocked-row behavior, and read-only status are all present. It is slightly heavy with parentheticals but remains appropriately sized and front-loaded.
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 filtered list tool with three optional parameters and no output schema, the description covers the core selection behavior, pricing annotations, blocked-row handling, and read-only nature. It could add return-shape or pagination details, but nothing critical is missing for correct invocation.
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 compensate. It explains item_code and search as filters, which adds real meaning, but it omits the limit parameter entirely and does not clarify search semantics such as partial matches or which fields are searched.
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?
States a specific verb-resource relationship: in-stock serials pickable for outbound consignment. It differentiates itself from siblings like available_serials and firearms_in_stock by anchoring to the consignment context and by mentioning blocked rows are included but greyed.
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?
Provides clear context for when to use the tool: when selecting in-stock serials for an outbound consignment. It also states how to filter via item_code and/or a search string, though it does not explicitly contrast against sibling consignment or serial-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states 'Reaches RSR over HTTP; changes nothing,' which discloses the network call and the read-only nature. This is strong behavioral context beyond the tool's name and purpose. It does not enumerate side effects or error conditions, but for a simple precheck operation this is sufficient to set expectations.
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?
Two sentences, no filler. The first sentence front-loads the purpose and the second provides behavioral transparency. Every word earns its place. The structure is ideal for a tool definition.
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 single-parameter precheck tool with no output schema, the description covers the action, the reason, and the behavior. It does not explicitly state the return format, but the question 'whether ... accepts' implies a yes/no answer. The only missing piece is a clear definition of the parameter, which is already penalized in parameter_semantics. Overall, it is nearly complete for its simplicity.
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?
Schema coverage is 0%, so the description must define the parameter. It says 'the transfer dealer named on this FDS order,' suggesting the input identifies the order or dealer, but it never explicitly states what 'do_name' means (e.g., is it the distributor order number, the dealer name, or the FDS order ID?). The description implies context but leaves the parameter mapping ambiguous, forcing the agent to guess.
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 action ('Ask the distributor'), the target ('the transfer dealer named on this FDS order'), and the specific question ('accepts drop-shipped firearms'). It also gives the operational purpose ('the cheapest way to avoid an FDS Hold'), which distinguishes it from other distributor tools like distributor_quote or distributor_check_availability. Though it doesn't name a sibling, the purpose is unambiguous.
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 says 'the cheapest way to avoid an FDS Hold,' implying this is the preferred tool over alternatives when that is the goal. It provides clear context for when to use it, though it does not explicitly mention alternatives or state when not to use it. Since it gives a specific use-case hint, it is above baseline but not fully explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explicitly states 'Read-only', which is a crucial behavioral trait. It also describes the data categories (draft orders, parked web orders, reasons, FFL expiry) that will be returned, giving the agent a clear expectation of the output contents without an output schema.
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?
The description is a single, information-dense sentence followed by two short, clear statements. It is front-loaded with the core purpose, then adds the usage hint and read-only trait. Every word earns its place; no redundancy or fluff.
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?
Given the tool's simplicity (only one param, no output schema), the description covers the essential context: what is in the queue, why it exists, and the fact that it is read-only. It doesn't mention ordering or pagination, but that is minor for a queue-reader. It is sufficiently complete for an agent to know when and how to call it.
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 only parameter is 'limit' (default 50), and schema description coverage is 0%. The description does not mention the parameter at all, nor does it clarify how it affects results. Since coverage is low, the description should have compensated by explaining that the limit controls the number of queue entries returned, but it doesn't. The schema gives only type and default, which is minimal help.
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 states a specific verb ('read'), a specific resource (human confirmation queue), and precisely enumerates its contents: Draft Distributor Orders plus parked web orders with reasons and FFL expiry. It distinguishes itself from siblings like pending_orders by explicitly naming the queue's scope and purpose.
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 a clear directive: 'This is the list to read before confirming anything.' This tells the agent exactly when to invoke it. It doesn't explicitly name alternatives or exclusions, but the context of being the pre-confirmation queue implies it is distinct from action-oriented tools like dispose_order or cancel_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It does mention side effects (FastBound push), which is valuable. It does not cover permissions, reversibility, or idempotency, but the provided information is sufficient for basic awareness.
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?
The description is one sentence plus a short note, with no waste. It front-loads the main action and requirement, then adds the side effect warning. Every part 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?
The tool has few parameters and no output schema. The description covers the action, requirement, and side effects. It could mention possible outcomes or errors, but overall it is fairly complete for a simple submit tool.
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?
Schema coverage is 0%, so the description should explain all parameters. It only explains confirm (as required), leaving doctype and name undocumented. This is insufficient for proper parameter understanding.
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 action (submit), the target resource (draft document), and the state change (docstatus 0 -> 1). It distinguishes from sibling tools like frappe_cancel_document or frappe_create_document by focusing on submission.
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 requires confirm=true and warns about side effects (e.g., FastBound push), which gives context for when to use. However, it lacks explicit alternatives or when-not-to-use guidance compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden; it explicitly states 'Read-only' and defines the exact row scope. It does not mention pagination or return shape, but for a zero-parameter read-only listing these are minor gaps.
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?
Two short clauses with the core meaning front-loaded; 'Read-only' is a valuable safety signal placed at the end. No wasted words.
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 zero-parameter list, the description gives source, payment status, fulfillment state, and read-only semantics. It could mention whether the result is paginated or all rows, but the tool is low complexity and no output schema exists to require more.
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?
The input schema has zero parameters, so the description has nothing to add. The baseline of 4 applies because no parameters require explanation.
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 clearly identifies the resource: paid WooCommerce web orders awaiting fulfillment, explicitly scoped to the source='woo' rows of the Pending Order page. It lacks a strong verb like 'list' or 'get,' but the meaning is unambiguous and distinguishes it from broader pending-order tools.
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 source='woo' and Pending Order page phrasing gives clear context for when this tool applies. It does not explicitly name alternatives such as pending_orders or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does well: it discloses the server-side invoice construction, FastBound 4473 opening, FFL-dealer refusal, and mentions confirm=true. It does not fully explain the side effects of confirm or whether the invoice is submitted vs. just built, but the key behaviors are visible.
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?
Three dense sentences, each earning its place: the first defines the core action and invoice structure, the second explains how to source fee parameters, and the third specifies a key constraint. Information is front-loaded with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description covers the core workflow but leaves gaps: return values, error behavior, and the roles of pos_profile and invoice_name are not addressed. It is adequate for a knowledgeable agent but not fully self-sufficient.
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 compensate. It adds meaning for fee_item and fee_amount (source them from get_transfer_config), and hints at serials ('per gun') and customer ('customer-transfer', FFL refusal). However, pos_profile and invoice_name are left unexplained, and the exact relationship between fee_amount and the retrieved default fee is not clarified.
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 states a specific action ('Start a customer-transfer 4473') and explains exactly what happens server-side: building a transfer POS Invoice with a $0 line per gun plus a Transfer Fee line, and opening the FastBound 4473. It distinguishes this from sibling tools by emphasizing 'customer-transfer' and noting FFL-dealer customers are refused.
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 clearly indicates this is for customer transfers and explicitly says FFL-dealer customers are refused server-side, giving a clear when-not-to-use condition. It also instructs the agent to retrieve fee_item and default fee via frappe_run_method, but does not name an alternative tool or explicitly contrast it with start_4473 or manager_override_4473.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and clearly discloses that the tool is read-only. It also reveals non-obvious behavior: consignment settlement invoices appear in AR under their dealer, and company defaults to the default company. This gives an agent useful expectations beyond the basic operation.
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?
The description is three compact sentences that cover essence, special behavior, defaults, and safety. It is front-loaded with the core definition and wastes no words.
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 read-only report with three parameters and no output schema, the description covers the inputs, scope, date basis, buckets, default company, and an important consignment nuance. It is complete enough to invoke correctly; a return-format example would be the only meaningful addition, but the report nature makes it optional.
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 description coverage is 0%, but the description compensates by explaining the kind parameter with the exact values 'ar' and 'ap', defining as_on_date as the report cutoff date, and clarifying company's default behavior. Only the date format is left unspecified, which is a minor gap given the clear semantics.
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 states exactly what the tool computes: an aged AR or AP summary as of a given date, using the standard ERPNext ageing report with defined 30/60/90/120 buckets. This is specific enough to distinguish it from siblings like financial_statement or sales_report without needing to open the schema.
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 phrase 'standard ERPNext ageing report' implies the tool is the canonical choice for ageing/AR-AP reporting, but the description does not explicitly name alternatives or state when not to use it. There are no exclusions, so the guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it clearly declares the tool read-only and defines both output fields. It also discloses that remote is null when there is no listing to ask about, which is the key behavioral edge case.
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?
Three dense sentences with the core read-only comparison front-loaded, followed by field definitions and a usage condition. No filler or repeated schema information.
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?
With only one parameter and no output schema, the description still covers the return semantics (state and remote values, null behavior) and the recommended usage context. This is enough for an agent to decide when to call and how to interpret the result.
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?
Schema description coverage is 0%, and the description never explains serial_no beyond the tool's general reference to 'ONE gun's listing'. It doesn't clarify serial format or whether it is the POS serial, so the parameter meaning is left mostly to inference.
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?
Opens with a precise statement of what the tool reports: POS vs GunBroker view of one gun's listing, explicitly marked read-only. The state/remote distinction and the 'before pushing or ending' mention differentiate it from sibling write/sync tools. No ambiguity about the resource it operates on.
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?
'Use this before pushing or ending anything if the two might disagree' gives an explicit call scenario. It doesn't name specific alternative tools or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It states read-only behavior, input flexibility, and output format. Missing details about error handling or missing items, but adequate for a simple query.
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?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
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 read-only tool with no output schema, the description covers input format, output structure, and read-only nature. It could mention error handling but is mostly complete.
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?
With 0% schema description coverage, the description adds essential meaning by specifying acceptable input formats (list, JSON list, comma-separated string), which the schema lacks.
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 returns stock on hand per item code summed across warehouses, with a sample output format. It distinguishes from sibling write tools like add_stock by specifying 'Read-only'.
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 does not explicitly say when to use this tool versus alternatives. It implies read-only usage but lacks direct comparison or exclusion criteria, such as 'Use this to check stock; use add_stock to update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'confirm=true' and lists promoted fields but lacks details on permissions, reversibility, or side effects. Adequate but not comprehensive.
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?
Two efficient sentences with no redundancy. Front-loaded purpose and key constraints.
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?
Covers purpose, payload structure, and prerequisite search. Lacks output specification or what happens after promotion. Adequate for the tool's complexity.
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 0%, description compensates by exemplifying payload structure (rsr_stock_number, item_code?, item_name?) and explains confirm parameter. Adds meaning beyond empty 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?
Clear verb 'promote' with specific resource transition from 'RSR catalog row' to 'sellable Item'. Distinguishes from siblings like 'rsr_catalog_search' (find candidates) and 'rsr_sync_catalog' (sync catalog).
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?
Explicitly mentions to use 'rsr_catalog_search' to find candidates before this tool. Hints at confirmation requirement with 'confirm=true'. Does not specify when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses write operations, external push to FastBound, and the consequential flag. Good behavioral transparency, though some details like error handling missing.
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?
Single dense paragraph, front-loaded with main action, then payload structure, then warning. No fluff, every sentence provides value.
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?
Covers core behavior and payload structure well. Lacks output schema and some edge cases (e.g., behavior when confirm=false), but sufficient for typical use.
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?
Description adds meaning by detailing payload structure (supplier, source, items with subfields) beyond schema's empty 'additionalProperties'. Compensates for 0% schema coverage with explicit object outline.
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?
Description clearly states it creates and submits a Purchase Receipt and handles firearms with FFL acquisitions and FastBound pushes. Specific verb-resource combination distinguishes it from siblings like add_stock or set_stock.
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?
Implies consequential nature with 'confirm=true', but no explicit when-to-use or when-not-to-use compared to alternatives like add_stock. Lacks clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose the write target, the deferred 'next push' timing, and the fetch_if_empty persistence behavior. However, it does not cover response shape, error behavior, permissions, or whether an existing title is overwritten, which are clear gaps for a mutation tool.
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?
Three dense sentences, no filler, and the core action and write target are front-loaded. Each sentence adds a distinct fact: what it writes, why it exists, and when it takes effect/persistence.
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 two-parameter setter this is largely complete: it covers the target field, the per-serial scope, persistence, and the push dependency. The lack of an output schema and annotations means return/error details are absent, but the core calling context is sufficient.
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 0%, so the description must compensate. It does: title is explained as the per-gun WooCommerce listing title persisted to Serial No.item_name, and serial_no is the identifier for 'one firearm'/'per-serial' gun. The meaning of both parameters is recoverable, though serial_no is not formally defined.
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 opens with a precise verb-resource pair: 'Set the per-gun WooCommerce listing title for one firearm' and names the underlying field it writes (Serial No.item_name). It distinguishes this from the shared Item name, so the tool's scope is unambiguous next to siblings like woo_push_serial and woo_push_item.
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 clear context for when to use it: to give one physical gun its own title instead of the model name shared by every serial. It also tells the agent the effect is deferred to the next push, but it stops short of explicitly naming when not to use it or comparing it to a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It explains side effects (books one FFL transfer disposition per serial, issues stock-out, pushes FastBound), blocking conditions, and idempotency, which gives an agent an unusually complete safety and effect profile.
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 dense and front-loaded with purpose and mechanics, and every clause adds information. However, the single run-on structure mixes behavior, constraints, warnings, and a parameter hint in one block, so it is efficient but not optimally structured.
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 mutation tool with no annotations or output schema, the description covers the key required context: preconditions, side effects, safety verification, and the confirm flag. Missing details such as success/error response shape are minor given the otherwise detailed behavior.
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 compensate. It does provide one key semantic instruction, 'confirm=true', and implies sales_invoice identifies the submitted order, but it never explicitly maps sales_invoice to the order or describes its format/source, leaving the required parameter under-specified.
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 states a specific action ('Dispose (ship) the firearms on a submitted counter/dealer order') and resource, then distinguishes the scope by noting it processes only not-yet-disposed serials. This is clearly differentiated from siblings like dispose_web_order and push_shipment.
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 gives clear context: the tool applies to submitted counter/dealer orders, is blocked while unpaid or when the destination FFL is invalid, and requires prior verification of the FFL and serials. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It discloses that the tool is read-only, that company defaults to the default company, that ERPNext fiscal_year is resolved from dates, and that a spanning trial-balance range is refused rather than guessed. This is exactly the kind of behavior an agent needs to know.
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?
The description is compact and front-loaded with the core purpose, then adds differentiated behavior per statement type. Every sentence earns its place; there is no filler or repetition of schema information.
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 tool with no output schema and no annotations, the description covers the key calling decisions: statement selection, date-range semantics, periodicity, fiscal-year limitation, and company defaulting. It stops slightly short of describing the return shape, but it is largely complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does. It documents valid statement values, periodicity choices, date-range meaning, the fiscal-year constraint on dates, and the company default. Every parameter in the schema gains meaning beyond its name and type.
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 clearly identifies the resource: one of the standard financial statements (pnl, balance_sheet, trial_balance) over a date range. It is specific enough to know what the tool returns, though it lacks an explicit action verb and does not directly distinguish itself from financial siblings like sales_report or gl_entries.
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 gives useful constraints—P&L/BS use date-range filtering with periodicity, and trial balance must stay within one fiscal year—so usage context is implied. However, it never explicitly states when to prefer this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only,' disclosing the key behavioral trait for a query tool. With no annotations, this is crucial. However, it does not detail return format, pagination, or edge cases, but the core trait is well-covered.
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?
Three sentences front-load the primary action, scope, and critical alternative. Every sentence adds value: search domain, identifier types, sibling reference, safety (read-only), and conversion hint. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks details on what the search returns (e.g., fields, pagination count). It implies catalog rows via 'Promote a catalog row' but doesn't state output format. For a simple search tool, this is adequate but not 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?
For the required query parameter, the description adds meaning by listing accepted identifier types (keyword, RSR stock #, UPC, MFG #), which is not in the schema. However, the optional limit parameter is not described at all, and schema coverage is 0%, so partial compensation.
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?
Explicitly states 'Search the RSR distributor CATALOG (not local stock)' with specific searchable identifiers, clearly distinguishing from sibling tools like find_item (local stock) and promote_to_item (conversion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly advises 'Use find_item for items already in this store,' providing an explicit alternative. Also clarifies scope with 'not local stock,' leaving no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that credential/password fields are stripped, and that on gunbroker a set of listed fields causes the call to fail rather than half-apply. This is meaningful beyond the schema, though it does not describe merge/replace semantics or return behavior for successful updates.
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?
The description is front-loaded with the core action, then provides a compact list of valid integration values, and finishes with two critical behavioral caveats. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must cover more ground. It does well on integration-specific failure modes, but omits whether `values` is merged or replaced, what the response contains, and any authentication or prerequisite requirements. For a mutation tool touching many integrations, these are notable gaps.
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 0%, so the description must compensate. It fully enumerates valid values for `which`, including the dealer nuance, and gives concrete examples of fields inside `values` via the gunbroker refusal list. It does not define a full schema for `values`, but the additionalProperties object is inherently flexible across eight integrations.
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 states a specific verb and resource: 'Update an integration's Settings', which clearly distinguishes it from the sibling get_settings tool. It also enumerates all supported integration identifiers, leaving no ambiguity about what resource is being acted on.
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 gives actionable guidance: credential/password fields should not be set here but in Desk, and on gunbroker certain fields are refused outright. It does not explicitly contrast with get_settings or test_connection tools, but the update-vs-read distinction is clear and the Desk instruction provides an explicit alternative for credentials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that apply=false is a read-only dry run and apply=true removes from stock (with confirm requirement). This covers key behavioral traits. No contradictions with annotations (none present).
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?
The description is concise (3 sentences) and front-loaded with the purpose. Every sentence adds value, including parameter explanations. No wasted words.
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?
Given the complexity of a reconciliation tool with side effects, the description provides sufficient context for usage. It covers the core logic, parameter roles, and modes. No output schema exists, so return value details are not expected, but the description could mention output format (e.g., list of discrepancies). Still, it is largely complete for safe invocation.
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?
Despite 0% schema description coverage, the description adds meaning for all parameters: apply's role (dry run vs action), item_ids (optional narrowing), and confirm (required when apply=true). It explains the relationship between parameters effectively.
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 purpose: reconcile in-stock firearm serial numbers against FastBound, specifically finding guns FastBound shows as disposed but still active in inventory. This is a specific verb-resource combination and distinguishes from sibling tools like woo_reconcile.
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 explains the two modes (dry run with apply=false and actual removal with apply=true requiring confirm=true) and mentions optional item_ids for narrowing. However, it does not explicitly state when to use this tool vs alternatives or provide exclusion criteria, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key side effects: line mode 'undoes the disposition' and whole-document mode 'books/moves nothing.' It also notes that reason is recorded and that confirm=true is required, which goes beyond what the schema alone conveys.
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?
The description is compact and well-structured, front-loading the primary purpose and using line breaks to separate the two modes. Every clause adds operational meaning—conditions, side effects, and required parameters—with no filler.
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 tool with two distinct behaviors, no annotations, no output schema, and zero parameter schema descriptions, the description covers the main scenarios, preconditions, and side effects well. Minor gaps remain around the exact form of `consignment_out` and what the tool returns or confirms after success.
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 0%, so the description must compensate. It explains the `line` parameter's dual behavior, the `reason` requirement, and the `confirm` requirement. However, `consignment_out` is not described beyond the tool name, and the exact format of `line` is left implicit.
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 states a specific verb and resource ('cancel a consignment') and precisely distinguishes two modes: canceling one shipped line vs. canceling the whole DRAFT document. This makes it clearly distinct from sibling tools like cancel_order and frappe_cancel_document.
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 gives explicit conditions for each usage mode: line cancellation is 'only reachable pre-invoice,' and whole-document cancellation applies to a 'never-shipped staging record.' It lacks an explicit statement of when not to use this tool versus named alternatives, but the conditions are clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full safety burden and clearly states 'Read-only,' which is the critical behavioral trait. It also describes the queue's scope, content, and independence from pending_orders. It does not disclose pagination or ordering, but for a read-only list tool the essential behavior is communicated.
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 dense but front-loaded with the tool's purpose and scope, then adds the distinguishing sibling note, parameter behavior, and read-only status. The first sentence is long and uses domain jargon like 'line pills' and 'action gating,' but every sentence 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?
The tool has one optional parameter, no output schema, and no annotations; the description covers scope, content, parameter behavior, and read-only status. It gives a reasonable picture of the returned card data, though it omits details like pagination and exact response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare boolean with no description, so the description must compensate. It does so directly: 'include_closed=true also returns Closed/Cancelled history.' This fully explains the only parameter's meaning and effect.
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 names a specific resource and verb: the outbound-consignment "At Dealer" queue for unfinished Consignment Out records (Draft/Shipped). It enumerates the card contents and explicitly differentiates itself from pending_orders, making the tool's identity unambiguous among many consignment siblings.
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 explicitly contrasts the queue with pending_orders and notes that pending_orders excludes consignment invoices, giving an agent a concrete selection signal. It also explains that include_closed=true extends the result to Closed/Cancelled history. It does not enumerate all alternative consignment tools, but the key distinction is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full behavioral burden. It discloses read-only behavior and the important staleness caveat (locally-synced, not live stock). It could add more about return shape or pagination, but the key behavioral trait is well covered.
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?
Two tight sentences with no wasted words. The primary behavior is front-loaded, the data-source caveat follows, and the actionable alternative is given in the same sentence. Excellent economy.
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 three-parameter search tool, the description covers the main concerns: what is searched, what data is read, the stale-data caveat, read-only status, and the appropriate fallback. Minor gaps remain around optional parameter behavior, but nothing critical blocks correct invocation.
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 compensate. It adds real meaning to 'query' by listing accepted identifier types (keyword, stock #, UPC, MFG #), but it does not clarify 'limit' or the 'distributor' parameter, including the meaning of the null default. Partial compensation only.
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 leads with a specific action ('Typeahead the distributor's catalog') and enumerates supported search inputs: keyword, stock #, UPC, MFG #. This clearly identifies the resource and differentiates it from sibling catalog searches like rsr_catalog_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that this tool reads a locally-synced catalog, not live stock, and directs the agent to use distributor_check_availability before acting on a quantity. This gives a concrete alternative and the condition for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers read-only semantics, the meaning of three-valued fields (null as 'not determined' with specific reasons), the interpretation of null as a hold, candidate flags (not_carried, blocked, stale), and money handling (unit_landed is per-unit goods-only, shipping null until order placed). It even warns against common pitfalls like misinterpreting null or ranking as permission. This is exemplary transparency.
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?
The description is well-structured with clear sections (three-valued fields, candidate flags, money) and is front-loaded with the core purpose. While lengthy, every sentence adds value—it explains complex semantics and warns against common misinterpretations, making the length justified. No filler or redundancy.
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?
The description is complete for a tool of this complexity. It covers input context (one web order), output semantics (verdict, flags, money), critical null behavior, and pitfalls. Even though there is no output schema, the description fully explains what the agent will receive and how to interpret it, leaving no gaps for correct invocation and interpretation.
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 only parameter 'woo_online_order' is not explained in the description beyond the schema's bare type (string). Schema coverage is 0%, and the description only implies the parameter identifies the web order ('ONE web order') without specifying the expected format (e.g., an ID) or any constraints. Since there's only one parameter, the description could easily compensate, but it doesn't, leaving the agent to infer meaning.
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 purpose with a specific verb ('decide how to fill ONE web order') and resource (web order), and lists the outputs (per-line distributor candidates, local stock comparison, verdict). It immediately differentiates itself from ordering tools by stating 'Read-only — it plans nothing and orders nothing', making it easy to distinguish from siblings like distributor_quote or distributor_orders.
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 clear context (for exactly one web order) and establishes that it is read-only, implying it should not be used for planning or ordering. However, it does not explicitly name alternative tools or state when another tool should be used instead (e.g., distributor_quote for pricing or distributor_orders for placing orders). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses destructive behavior ('Delete') and a required flag ('confirm=true'). However, it doesn't mention if deletion is soft or hard, or what happens to related records, which would be useful. Still, it's better than average.
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?
Two concise sentences with no wasted words. Front-loaded with the main action, then essential conditional guidance.
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 delete tool, the description covers purpose, usage rules, and alternatives. It lacks explanation of return values or side effects (e.g., whether the document is permanently removed or just archived), but given no output schema, this is a minor gap.
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 has 3 parameters with 0% coverage in description. The description adds value by noting that 'confirm' must be true, but it does not explain 'doctype' or 'name'. Given low schema coverage, description should compensate more. Baseline is 3, so score is appropriate.
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?
Clearly states 'Delete a document' (verb+resource). Also distinguishes from a sibling tool for firearms/Items, which is helpful for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires 'confirm=true' and provides an alternative tool for specific document types (firearms/Items) with a reason (preserves audit trail). This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it discloses important guardrails: refusal of generic mutators and the confirmation requirement for destructive methods. It does not cover return shape or error behavior, but for an arbitrary-method tool that is a reasonable boundary.
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?
Three dense sentences with no filler: purpose first, then the mutator guardrail, then the confirmation rule. Every sentence earns its place and is front-loaded.
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 generic arbitrary-method runner, it adequately covers invocation format, safety exclusions, and confirmation requirements. The missing kwargs documentation and output expectations are meaningful gaps, but the generic nature of the tool and the named alternatives reduce the risk.
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 compensate. It clarifies the method parameter with a dotted-path example and explains confirm semantics, but kwargs—the payload passed to the method—is left entirely unspecified, which is a notable gap.
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 states a precise action: calling a whitelisted server method by dotted path, with a concrete example. It also differentiates itself from the structured frappe_*_document tools, so an agent can tell this is the generic fallback runner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says generic Frappe mutators are refused and directs the agent to use the structured frappe_*_document tools instead. It also specifies when confirm=true is required for destructive or high-consequence methods, giving a clear selection condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses that the tool mints Retail Sale disposition(s) marked manual_override with WHO and WHY for auditability, does NOT push to FastBound, and requires separate bound book reconciliation. This gives an agent a clear picture of both effect and non-effect.
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?
The description is dense but every sentence carries essential information: purpose, preconditions, effects, audit trail, sync limitation, and required confirmation. It is front-loaded with the core purpose and follows with constraints, making it easy for an agent to parse quickly.
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 high-stakes override tool with no annotations and no output schema, the description covers the critical selection, confirmation, and auditability aspects. The main gap is the unexplained 'invoice_name' parameter and the absence of any hint about return/result behavior, but the tool can be invoked safely with the information provided.
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 compensate for missing parameter documentation. It does clarify that 'reason' is required and that 'confirm=true' is needed to execute, but it does not explain what 'invoice_name' refers to or how to supply it. This is partial compensation, not complete.
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 states a specific verb ('force-complete'), a specific resource ('stuck firearm POS sale'), and the exact precondition ('4473 WAS genuinely completed in FastBound but never synced back'). It clearly distinguishes this override from normal processing tools and even notes it does not push to FastBound, setting it apart from sync-related siblings.
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 gives a clear scenario for when this tool is appropriate: a 4473 that genuinely completed in FastBound but failed to sync due to edited serial, deleted disposition, or FastBound being down. It also warns against expecting FastBound sync and instructs to reconcile the bound book separately, though it does not explicitly name a sibling tool as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so very well. It discloses that the operation is synchronous, idempotent, fails closed on invalid FFL or unpaid orders, and is independent of Dispose. This is rich, decision-relevant behavior beyond what the schema shows.
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?
Two sentences carry the core action, scope, behavioral guarantees, failure conditions, and the key confirm flag. There is no filler, and the most important information is front-loaded.
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 tool with no annotations and no output schema, the description is unusually complete: it covers action, target system, source state, idempotency, failure modes, and disposition independence. Minor gaps remain around the exact semantic of sales_invoice and the behavior when confirm is false.
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 compensate. It adds meaning for confirm by saying 'confirm=true', and implies sales_invoice identifies the submitted order. However, it never explains the format or meaning of sales_invoice, nor exactly what happens when confirm is false. Partial compensation only.
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 names a specific verb and resource: 'Push a submitted order to ShipStation.' It further anchors the tool as the Pending Order 'Ship' action, which clearly separates it from related lifecycle tools like dispose_order, dispose_web_order, and push_consignment_shipment.
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 gives clear context: only submitted/pending orders should be pushed, and invalid FFL or unpaid orders will fail closed. It also notes independence from the Dispose step. It does not explicitly name alternative tools or say 'use X instead,' so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the side effects: it books and submits a Payment Entry and returns the new balance. It also surfaces conditional behavior (amount default, Zelle requiring transaction_number, confirm flag). It could go further on reversibility or confirmation semantics, but the core mutation is transparent.
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?
Three short sentences pack the purpose, the default behavior, and a conditional requirement with no filler. The most important action is front-loaded and every clause adds information.
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?
Despite lacking annotations and an output schema, the description covers the main behavior, the return value, and the crucial parameter relationships. It leaves some ambiguity around what confirm=false does and which payment modes are available, but an agent can invoke the tool correctly in common cases.
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 0%, so the description must compensate, and it does for the most important parameters: amount omitted means full outstanding, Zelle requires transaction_number, and confirm defaults to false. Sales invoice and allowed payment modes are left to inference, but the critical conditional meanings are explained.
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 names a specific action ('record a later payment'), a specific resource ('submitted, not-fully-paid Sales Invoice'), and the concrete effect ('books + submits a Payment Entry and returns the new balance'). This clearly separates it from generic document tools like frappe_create_document or frappe_update_document.
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 phrase 'against a submitted, not-fully-paid Sales Invoice' and 'later payment' give clear context for when the tool is appropriate. It does not explicitly rule out alternatives, but the target condition is precise enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it is exceptionally transparent. It discloses read-only behavior, dynamic account resolution rules, is_cancelled=0 filtering, voucher-level splits in output, internal identity assertion to the cent, fail-closed behavior on dropped rows, and the deliberate single-state design with no state parameter. This far exceeds what annotations alone would provide.
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 long but information-dense; the core purpose is front-loaded in the first sentence and the rest of the paragraphs each add necessary behavioral or output detail. The only minor concern is length, but no sentence is filler and the structure flows from purpose to trap to mechanics to output.
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?
Despite no output schema and no annotations, the description provides a full picture: source, calculation rule, account resolution, row filtering, output composition, validation behavior, and state limitations. For a financial computation tool with three parameters, this is complete enough for an agent to invoke it correctly without additional documentation.
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 compensate. It gives meaningful semantics for from_date and to_date through 'for the period' and 'opening_balance (before from_date)', and explicitly explains why there is no state parameter. However, it does not explain the optional company parameter or date formats, so parameter documentation remains incomplete.
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?
States a specific verb and resource: 'Sales-tax liability roll-forward for the period, straight from the GL.' The first sentence names exactly what the tool computes and from which source, distinguishing it from siblings like gl_entries, financial_statement, and sales_report. The follow-up trap clarifies that this tool reads only GL rows on sales-tax accounts, so an agent can immediately understand what it is and is not.
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 clearly implies the tool is for period-based sales-tax liability roll-forward and explicitly says it reads the GL, so an agent can infer when to use it versus broader GL or financial-statement tools. It does not name alternatives or state explicit 'when not to use' conditions, but the scope and the trap about 'Total Taxes and Charges' give strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the all-active-serials scope, restricts site to retail/dealer, and includes the important confirm=true instruction, which is not obvious from the schema default of false. It does not explain what confirm=false does or failure modes, but the core mutation behavior is clear.
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?
Three short, information-dense clauses with no filler. The main purpose is front-loaded, the use case follows, and parameter constraints are compactly appended. Every sentence 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?
For a simple three-parameter mutation with no output schema and no annotations, the description covers the necessary inputs, scenario, and the confirm flag. Minor gaps are the lack of return/error behavior and explicit mention of alternative tools, but these do not prevent correct invocation.
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 description coverage is 0%, so the description must compensate. It provides the identifier context for item_code, constrains site to retail/dealer, and points to confirm=true—enough to populate all three parameters with confidence. It is terse but adds value beyond the bare schema defaults.
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?
States a concrete action—push the item-level product AND all active serial numbers in one call—and ties it to the specific scenario of initial listing of a per-serial firearm. This clearly distinguishes it from siblings like woo_push_item and woo_push_serial, which handle only part of that operation.
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?
Gives an explicit use case: initial listing where everything must go live at once, which implies when this combined call is appropriate. It does not explicitly name alternatives or say when not to use it, but the scenario framing provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and does so exceptionally: it details the entire cascade including invoice cancellation, disposition reversal, stock restoration, FastBound delete queueing, Sales Order cancellation, ShipStation void, and refund booking. It also notes that reason is required and recorded.
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 content is front-loaded with the action and packed with necessary behavioral detail in one dense sentence. It is readable but could be improved with light structuring, such as separating the cascade effects into bullets; still, no information is wasted.
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?
The description covers the main behavioral context for a complex, destructive operation despite absence of annotations and output schema. It does not explain what happens when confirm=false, describe the return value, or explicitly identify sales_invoice as the invoice identifier, leaving minor but relevant gaps.
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 description coverage is 0%, so the description must compensate. It adds meaning for reason (required and recorded), confirm (must be true), and refund_mode/refund_reference (used when a refund is due). However, the required sales_invoice parameter is not explicitly defined beyond the title and the cascade mention of invoice cancellation.
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 opens with a specific verb and resource: 'Cancel a submitted counter/dealer transfer order' and ties it to the Pending Order page's Cancel Order action. This clearly distinguishes it from sibling disposal/cancellation tools like dispose_order and cancel_consignment.
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 establishes clear context by identifying the affected order type (counter/dealer transfer order) and the exact page action. It does not explicitly state when to use this tool instead of sibling cancel/dispose tools, but the resource and page reference make the intended scenario reasonably unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Read-only' and explains that the shippable/block_reason values reflect the same enforcement gate as ship_consignment_out, which is useful behavioral context beyond the schema. It could add more detail about response shape or data freshness, but the core safety and consistency semantics are covered.
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?
Three sentences deliver all the essential information: what is returned, the key fields, the relation to the enforcement gate, when to use it, and read-only status. No filler or redundancy.
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?
With no output schema and no annotations, the description still provides the key returned fields, the tool's purpose, and its usage timing. An agent has enough information to invoke the tool correctly and interpret its result.
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?
The tool has zero parameters, so there is no parameter semantics to add. The description's opening 'Every FFL-dealer Customer' reinforces that no filtering is involved. A baseline of 4 is appropriate for a no-parameter tool.
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 states precisely what the tool returns: every FFL-dealer customer's consignment shippability, including FFL number, eZ-Check status, expiry, and shippable/block_reason. It also distinguishes this tool from related consignment operations by tying it to the same gate ship_consignment_out enforces.
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 says 'Use before building a consignment,' giving the agent a clear trigger for when to call this tool. It does not explicitly discuss alternatives or when not to use it, but the contextual placement and relationship to ship_consignment_out make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses read-only behavior, passthrough semantics ('returned UNCHANGED'), fail-closed refusal of invalid product_type values, and profit being net pre-tax. The F-2 historical note is a genuinely useful behavioral nuance.
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 dense and front-loaded with the resource name and core behavioral guarantee before parameter details. Minor redundancy ('default here' and repeated 'empty = all') and the long single-paragraph structure keep it from a perfect score.
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?
Despite no output schema and no annotations, it explains the output shape ('columns, rows and report_summary cards'), view semantics, channel/product_type constraints, and read-only nature. Missing date-format details and explicit sibling-tool routing are the only substantive omissions.
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 description coverage is 0%, and the description compensates strongly for view, channel, and product_type by enumerating allowed values and defaults. However, from_date and to_date are required yet receive no format or range guidance, leaving a notable gap.
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 names an exact resource ('The POS Sales Report') and states it returns revenue + profit across all channels, returned UNCHANGED. This clearly distinguishes it from siblings like financial_statement, tax_liability, and frappe_run_report without requiring the schema.
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 clear invocation context by explaining valid values for view, channel, and product_type, including defaults and fail-closed behavior. It does not explicitly name alternative tools or say when not to use it, but an agent can determine the appropriate call from the provided context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses mutation, validation-before-mutation, idempotence on re-run, server-side blocking on invalid FFL, and the need for confirmation. This exceeds what the input schema alone reveals.
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?
The description is dense yet compact: purpose, side effects, validation, idempotence, blocking behavior, verification instruction, and confirmation flag are all packed into a few purposeful sentences with no filler.
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?
For a mutating operation with no output schema and no annotations, the description covers the essential invocation context: what will happen, required preconditions, idempotence, and blocking behavior. It is complete enough for an agent to use without guessing critical semantics.
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 compensate for parameter documentation. It supplies 'confirm=true' but does not explain confirm's effect or what happens when false, and it never explicitly describes the format/meaning of the required consignment_out parameter beyond the resource name.
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 uses a specific verb-resource pair—'Dispose (ship) every Draft line of a Consignment Out'—and details the concrete effects: books FFL transfer, moves stock, pushes FastBound. This clearly distinguishes it from siblings like push_consignment_shipment or mark_consignment_shipped.
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 a clear precondition ('VERIFY the dealer + serials first') and an explicit invocation requirement ('confirm=true'). It does not name sibling alternatives or say when not to use it, but the 'Draft line' scoping and idempotence note make the intended context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that the action is a create-or-update write operation, names the SKU pattern, and limits scope to one serial; it does not elaborate on confirmation semantics or side effects, but the key traits are explicit.
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 dense and front-loaded, with the core purpose first and then the decision rule. It is appropriately sized, though the trailing 'site: retail | dealer. confirm=true.' fragments are terse rather than fully structured.
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 three-parameter write tool with no output schema or annotations, the description covers purpose, scope, alternative, and all three parameters. It does not describe return values or confirm/false behavior, but it provides enough for a competent agent to invoke it correctly.
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 0%, but the description compensates by defining serial_no (the serial appearing in SKU item_code::serial), enumerating site values as retail | dealer, and recommending confirm=true. It does not explain what confirm=false does or what the fields mean beyond these fragments.
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?
States a specific verb ('Push'), a resource ('WooCommerce product for ONE firearm Serial No'), and the per-gun scope. It explicitly contrasts with woo_push_item, so an agent can distinguish the two listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit preference rule: use this over woo_push_item when only specific guns changed, and explains that woo_push_item pushes every Active serial. This is clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses concrete state effects: Draft creation, guns held, Woo delisted, queue-based disposal, best-effort ShipStation push, degraded=1 fallback on gate failure, and consequential confirmation. This is strong, specific behavioral disclosure for a mutation tool.
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?
The description is compact and information-dense: purpose, payload schema, mode behavior, degraded path, related tools, and confirmation requirement are all packed into three sentences with no filler.
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 complex tool with nested objects, no output schema, and no annotations, this description covers most of what an agent needs: payload structure, options, side effects, failure behavior, and related lookup tools. It lacks the response shape and explicit behavior when confirm is false, but the overall picture is strong.
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?
The schema only provides a generic payload object with additionalProperties, so the description is the only real documentation. It enumerates payload fields, optional markers, line-item subfields, and the meaning of dispose_now=0 vs 1. Some ambiguity remains about the types of dealer and company, and confirm semantics are terse.
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 opens with a specific verb and resource: 'Build an outbound consignment to an FFL dealer.' It also names the payload shape and related candidate-finding tools, distinguishing it from siblings like ship_consignment_out and cancel_consignment.
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 clearly frames when to use this tool: to build an outbound consignment, with two modes controlled by dispose_now. It also points to consignment_dealers / consignment_serials for candidate lookup. It does not explicitly state when NOT to use it or name alternatives like ship_consignment_out, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly says the operation is a read, and it adds a meaningful safety disclosure: 'Password fields are never returned by Frappe.' This goes beyond a bare statement of function, though it does not cover error behavior or response shape.
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?
The description is three short sentences with no filler. The verb and resource are front-loaded, followed directly by the parameter value list, and a brief redaction note. Every sentence adds necessary information.
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?
For a tool with only one required parameter, no annotations, and no output schema, the description covers everything an agent needs to invoke it correctly: what it does, all accepted argument values, and the key return-behavior caveat about passwords. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter 'which' has no enum. The description compensates fully by listing every accepted value, including a clarification for 'dealer (dealer-portal WooCommerce)'. This is essential semantic information that the schema alone does not provide.
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 opens with a specific verb-resource pair, 'Read an integration's Settings', which immediately distinguishes this getter from the sibling update_settings. It also enumerates the exact integration identifiers the tool supports, making the tool's scope unambiguous.
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 makes clear this is a read operation and even lists all accepted 'which' values, giving an agent enough context to decide when to call it. It does not explicitly name update_settings as the alternative for modifying settings, but the read-versus-update contrast is strongly implied and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It exposes that cancelled GL is always excluded, that truncation is explicit via truncated:true, that limit is clamped to 1..5000 with 0 falling back to 500, and that the operation is read-only. This is exceptional disclosure of edge-case behavior.
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?
The description is dense but every sentence earns its place: core purpose, cancellation behavior, truncation semantics, limit rules, pagination advice, and read-only status. The most important scoping information is front-loaded.
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 seven parameters, no annotations, and no output schema, the description still gives an agent everything needed to invoke the tool correctly: filters, date-range boundaries, limit behavior, cancellation exclusion, truncation signaling, and pagination guidance. No critical call-blocking detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 add meaning beyond the raw parameter names. It does so thoroughly: it explains how account, party, voucher_no, and voucher_type act as optional filters, and it gives detailed semantics for limit including clamping, fallback behavior, and the deliberate contrast with Frappe's convention.
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 clearly identifies the tool as returning general-ledger rows for a date range with optional filters, so an agent understands what resource is being acted on. It does not explicitly differentiate from accounting-related siblings like financial_statement or ar_ap_summary, so it stops short of the top score.
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 gives clear operational context: it is a read-only date-range query with optional filters, and it instructs paginating by narrowing the date range when more rows exist. It does not name specific alternative tools or state when-not-to-use, but the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it discloses the key effects: it does not push to ShipStation, it clears the Ship step, and it can hand-record label data so the dealer portal displays it. It does not cover reversibility or downstream side effects, but the essential mutation behavior is clearly communicated.
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?
The description is a single compact sentence that front-loads the action and packs the necessary conditions, sibling reference, parameter guidance, and confirmation requirement. Every element earns its place; there is no repetition of schema fields or filler.
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 mutable 4-parameter tool with no annotations and no output schema, the description covers the essential decision points: when to use it, what it does, what the optional parameters mean, and the required confirmation flag. Minor gaps such as return behavior and reversibility remain, but they are not necessary for a correct invocation.
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 description coverage is 0%, so the description must compensate, and it does: tracking_number/carrier are explained as hand-recorded label data, and confirm is specified as needing to be true. consignment_out is not named explicitly, but the description identifies the resource as the disposed consignment being acted on.
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?
States a specific action ('Clear') and target ('a DISPOSED consignment's Ship step') and immediately distinguishes this from mark_shipped_manually as the consignment twin. The parenthetical conditions make the exact scope unmistakable, so an agent can tell it apart from the related shipment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit situations where this tool is appropriate: label bought elsewhere, integration off, or dealer FFL expired after dispose. It also clarifies that it is the manual/consignment path vs. a ShipStation push and names mark_shipped_manually as the sibling equivalent, giving the agent a concrete alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It names the failure modes, implies a re-booking side effect, and explains the undo path via the cancel hook. It stops short of stating permissions, idempotency, or post-success state, but the core behavior and alternatives are transparent enough.
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?
The description is compact and every sentence earns its place: purpose, parameter guidance, undo alternative, and confirmation flag. There is no filler or repetition of schema information.
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 two-parameter retry action with no output schema, the description covers tool selection, parameter sourcing, and the correct alternative for undo. It omits return values and explicit success/failure signals, but the queue-action framing and sibling references supply enough context for invocation.
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 description coverage is 0%, so the description must compensate. It defines `line` precisely as the Consignment Out Line name and points to consignment_dealer_orders for resolution. It also mentions `confirm=true` as required, though it does not explain what confirm=false would do; this is a minor gap given the schema's default.
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 action: 'Retry the settlement Sales Invoice for a Sold consignment line whose automatic booking failed.' It also identifies the tool as the Dealer Orders queue's Retry Invoice action, making it easy to distinguish from related operations like consignment_dealer_orders and frappe_cancel_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use conditions: automatic booking failed due to error log, total mismatch, or expired dealer FFL at submit. It also provides an explicit when-not-to-use instruction by routing undo cases to frappe_cancel_document instead, with a note about the cancel hook reopening the parent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does so meaningfully: it flags the operation as consequential, requires confirm=true, and explains the push granularity for firearm categories. It stops short of describing overwrite effects, permissions, or what happens on partial failure, so it is good but not exhaustive.
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?
Three terse sentences pack the action, branching behavior, alternative, and key flags with no filler. The main action is front-loaded, and every clause adds information an agent needs.
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 3-parameter mutation tool with no output schema, the description covers core behavior, branching logic, the alternative, and the safety flag. It leaves minor ambiguity around return values and the exact meaning of 'uniform-price firearms,' but nothing essential to deciding whether to call it is missing.
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 description coverage is 0%, but the description compensates by documenting valid site values ('retail | dealer') and the confirm requirement. item_code is still only implied by the phrase 'for an Item,' but for a required single parameter that is sufficient context.
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?
States a specific action ('Push (create or update)') and target ('WooCommerce product(s) for an Item'), and distinguishes the per-serial vs item-level behavior. It also names the relevant sibling (woo_push_serial) for the single-gun case, so an agent can tell this from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the alternative and selection condition: 'For ONE gun use woo_push_serial instead.' It also clarifies when the tool pushes per-serial versus item-level, and notes the site parameter accepts retail or dealer, giving enough context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It states the operation is read-only, explains the meaning of the sandbox key in the reply, reveals that the environment cannot be changed from this server, and documents a permission difference that produces a 403 for stock-only users.
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?
The description is compact but information-dense; every sentence adds a distinct, useful fact: operation, environment detection, precedence, immutability, and permission boundary. The purpose is front-loaded, and no sentence is wasted.
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?
For a zero-parameter, no-output-schema probe tool, this description covers everything an agent needs: what the tool does, what response field to inspect, why the value matters, what cannot be changed, and which roles are required. There is no meaningful gap.
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?
The tool has zero parameters, so there is nothing for the description to explain about arguments. The baseline for a zero-parameter tool is 4, and the description appropriately avoids inventing parameter details.
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 opens with a specific verb ('Probe'), a specific resource ('GunBroker API connection + credentials'), and an explicit read-only scope. It clearly establishes that this tool determines which GunBroker environment the POS is connected to, which separates it from the other test_connection siblings.
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 gives clear situational guidance: read the sandbox key before doing anything else to learn which environment is active. It also notes that stock-only API users will get a 403 here, while the other gb_ tools accept their role. It does not explicitly enumerate alternative tools to use instead, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does state 'Read-only' directly. It also explains the inclusion/exclusion semantics of the result set. It could add more about return shape or ordering, but for a simple listing tool this is solid.
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?
Four concise sentences with no filler. The tool's identity and scope are front-loaded, and each sentence adds meaningful information: contents, source, exclusions, and read-only behavior.
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?
For a zero-parameter, read-only queue listing, the description covers what it contains, where web rows come from, what is excluded, which sibling to use instead, and that it is read-only. Nothing essential is missing for correct selection and invocation.
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?
The input schema has zero parameters and 100% schema coverage, so the baseline is 4. No parameter-level description is needed because there is nothing to invoke with.
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 defines what the tool exposes: a Pending Order queue of counter and dealer rows for submitted firearm shipments needing disposal, payment, or a ShipStation push. It also distinguishes itself from related sources by explicitly stating web-shop rows come from pending_web_orders and consignment fulfillment is excluded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing guidance: consignment fulfillment is NOT here and belongs in consignment_queue, while web-shop rows belong to pending_web_orders. This tells an agent when to use this tool versus its key siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so well. It discloses write scope ('Writes ONLY this shipment's line snapshot'), downstream effects (settlement and dealer portal follow automatically), atomic validation, and server rejection gates. This is far beyond typical mutation-tool descriptions.
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?
The description is dense but every sentence earns its place: purpose, parameter format, scope, server gates, and confirmation. The PR reference is minor noise, but the overall structure is front-loaded and efficient for the complexity involved.
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?
For a complex mutation with no annotations and no output schema, this description is notably complete. It covers input semantics, source of line names, server-side preconditions, batch atomicity, and downstream side effects. No critical information needed to invoke the tool correctly is missing.
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?
The description provides detailed semantics for the nested prices object, including the tri-state msrp behavior, cost constraint, and confirm=true requirement. The consignment_out parameter is not explicitly described, but its meaning is reasonably inferable from context; this is a minor gap given the 0% schema coverage.
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 uses a specific verb ('Edit') and resource ('per-consignment price snapshot on At Dealer lines'), and connects it to the queue's 'Edit prices' dialog. It also explicitly excludes Serial No / Item masters, which distinguishes it from the many consignment-related sibling tools.
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 gives clear operational conditions: the line must be At Dealer with no booked settlement invoice, line names come from consignment_queue, and the batch is validated as a whole. It stops short of naming alternative tools explicitly, but the when/where/conditions are clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it explicitly says 'Read-only', explains that held/consigned-out/consignment-warehouse guns are excluded by default because they are not sellable over the counter, and documents the raw-list behavior when exclude_unavailable is false. This meaningfully discloses behavior beyond what annotations or schema would provide.
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?
The description is compact but information-dense: purpose, return shape, default behavior, the flag for raw mode, and safety status are each covered in a single short sentence. The structure front-loads the core purpose before explaining the toggle, and no sentence is wasted.
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?
For a read-only lookup tool with no output schema and no annotations, this is complete. It covers what the tool returns, when to use it, the default filtering behavior, how to opt out, and that it is safe to call. The agent has everything needed to invoke it correctly in both the normal and audit use cases.
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 description coverage is 0%, so the description must compensate. It thoroughly explains exclude_unavailable, including its default and the difference between POS-picker and raw-audit behavior. item_codes is less explicit—it is inferable from the return shape and 'per firearm item', but the accepted formats and cardinality are not directly described. Still, the description adds meaning well beyond the bare 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 a specific verb and resource: it returns in-stock serial numbers per firearm item with per-gun sell prices. The return-shape example and the phrase 'which units do we have of this model + at what price' make it easy to distinguish from broader stock or consignment tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case: 'Use for which units do we have of this model + at what price'. It also explains when to change the default parameter, including the inventory-audit scenario that requires exclude_unavailable=false, which is strong practical guidance beyond just describing the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses that the tool 'changes nothing' (non-mutating), that it performs a live external HTTP call to RSR, and that it is a real-time re-confirmation rather than a cached browse. This is meaningful behavioral context beyond the schema.
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?
The description is a single compact sentence that front-loads the core behavior, then adds the important caveats about side effects and appropriate usage. Every clause earns its place with no filler or repetition.
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?
For a simple two-parameter, no-annotation, no-output-schema tool, the description covers purpose, parameter format, mutability, network behavior, and usage boundaries. An agent has enough context to invoke it correctly for its intended role.
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?
The schema provides no parameter descriptions (0% coverage), so the description must compensate. It usefully documents the main required parameter as '[{sku, qty}, …]', which goes beyond the bare schema. However, the optional 'distributor' parameter is not explained, leaving some ambiguity about how distributor selection works.
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 names a specific verb and resource: 'LIVE quantity/price re-confirm straight from the distributor'. It also distinguishes itself from distributor_quote by noting it reaches RSR over HTTP, so an agent can immediately differentiate it from a closely named sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('second-check before confirming an order') and when not to ('not to browse'). It also contrasts with distributor_quote, giving the agent a concrete alternative and the key difference between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gunstore-pos-mcp MCP server](https://glama.ai/mcp/servers/xuanji86/gunstore-pos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xuanji86/gunstore-pos-mcp)

Score Badge

Copy to your README.md:

[![gunstore-pos-mcp MCP server](https://glama.ai/mcp/servers/xuanji86/gunstore-pos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xuanji86/gunstore-pos-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/xuanji86/gunstore-pos-mcp'

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