ERPNext MCP

by Cec1c

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
The set mixes specific resource tools like doc_create and stock_balance with generic escape hatches like api_request and call_method, so there is definite overlap for document operations. However, the detailed descriptions and the strong erpnext_ prefix give agents enough clues to usually select the intended tool.
Naming Consistency4/5
Most tools follow an erpnext_<resource>_<action> pattern, such as doc_create, plan_list, and input_finalize, which is predictable and readable. Minor deviations like call_method, api_request, doctype_schema, and stock_balance break the strict pattern but are still intuitive.
Tool Count2/5
31 tools is above the 25+ threshold for a coherent MCP surface, and a large portion are infrastructure mechanics such as input_begin/append/finalize, plan_list/inspect/execute, and result_read. ERPNext is a broad domain, but this count feels heavy and could be consolidated.
Completeness4/5
The surface covers core ERPNext workflows well: document lifecycle, BOMs, work orders, stock, accounting, reports, and process tracing, with generic api_request and call_method as backstops. Minor gaps like report discovery or attachment-specific helpers exist but are workable through generic routes.
Average 3.4/5 across 31 of 31 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint=false and destructiveHint=true, so the mutation risk is covered. The description adds some useful context by describing the operation as being 'frozen' into a 'sensitive plan' and noting that no separate whitelist is used. However, it does not explain concrete side effects, what makes the plan sensitive, or what openWorldHint=true implies behaviorally.
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 very short and contains no filler, so it is concise in length. But the single dense sentence is not structured for comprehension, and the semicolon-separated 'no separate whitelist' clause is left unexplained. It is under-specified rather than effectively 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 a four-parameter configuration tool with two required fields and a rich ecosystem of plan-related siblings, the description leaves too much unexplained: what a naming-series controller request is, what a sensitive plan means, and how this tool connects to plan execution or validation. The output schema mitigates return-value uncertainty, but the description still fails to provide enough operational context for correct invocation.
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%, and the description does not mention doctype, series_options, dry_run, or counters at all. The description had the responsibility to compensate for the bare schema but provides no help on valid values, required combinations, or how dry_run alters behavior. This is a critical gap for a tool with four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Freeze') and resource ('native naming-series controller requests'), and the 'no separate whitelist' clause hints at a distinctive approach. However, the meaning of 'freeze ... as one sensitive plan' is opaque domain jargon, and the description does not clearly explain what the tool actually configures or accomplishes. It is not a tautology, but it is only a vague statement of purpose.
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?
There is no explicit guidance about when to use this tool versus any of the many siblings such as erpnext_plan_execute, erpnext_batch_prepare, or erpnext_doc_update. The phrase 'no separate whitelist' implies a contrast with an alternative approach, but it does not name a sibling or specify a condition. An agent is left to infer the intended use.
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?
Annotations already carry the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal domain context ('accounting balance for a Customer or Supplier') but does not disclose behavior beyond that, such as how the optional date and company parameters affect the result or what the balance represents. It does not contradict the annotations.
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 a single, direct sentence with no wasted words. However, it is under-specified for a tool with four parameters, and the brevity comes at the cost of missing parameter and usage context, so it is not 'appropriately sized' despite being 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 tool with four parameters, two required, and zero schema descriptions, the description is too thin. The output schema covers return values, but the description does not explain how 'party', 'date', and 'company' interact, what balance is returned, or how this tool fits among the many ERPNext siblings. An agent would need external knowledge to call it correctly in non-trivial cases.
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 should compensate for the undocumented parameters. It only hints at party_type by naming 'Customer or Supplier' and implies party is the entity of that type, but it provides no meaning or guidance for the required 'party' parameter or the optional 'date' and 'company' parameters.
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 action ('Return'), the resource ('ERPNext accounting balance'), and the party types ('Customer or Supplier'). It also differentiates reasonably from sibling tools like erpnext_stock_balance by specifying 'accounting balance' rather than stock balance, though it could be more explicit about what 'accounting balance' means in context.
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 about when to use this tool versus alternatives, when not to use it, or what conditions select it. The description gives no context about using erpnext_stock_balance for inventory balances or erpnext_report_run for broader accounting reports, leaving the agent to infer applicability from the name alone.
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?
Annotations already signal that the operation mutates state (readOnlyHint=false, destructiveHint=true). The description adds some behavioral context by mentioning 'safe_mode preflights' and 'expected_lengths checks child rows', which are useful, though safe_mode is unexplained and not present in the input schema.
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: two short sentences, with the primary purpose front-loaded. It avoids bloat, though 'safe_mode preflights' is cryptic and could use a brief clarification without hurting conciseness much.
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 mutating create operation with a required free-form doc object, the absence of guidance on document shape, dry_run behavior, safe_mode semantics, and relationship to sibling tools leaves significant gaps. The output schema helps with return values but cannot compensate for missing parameter and usage context.
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?
With 0% schema description coverage, the description must carry parameter meaning, but it only adds context for expected_lengths ('checks child rows'). The required doc parameter and dry_run are left undocumented, and the mention of safe_mode refers to a concept outside the schema, so parameters remain largely underspecified.
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' using native REST. This distinguishes it from sibling tools like erpnext_doc_update/delete/list/get by the core create action, but it does not explicitly define the scope of 'document' or name an alternative, so it stops short of full differentiation.
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?
There is no guidance about when to choose this tool over alternatives such as erpnext_doc_update, erpnext_call_method, or erpnext_api_request. 'Using native REST' hints at an implementation approach but is not an explicit usage condition or exclusion, leaving the agent to infer selection criteria.
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?
Annotations already indicate destructiveIntent=true, so the destructive nature is known without the description. The description adds context beyond this: 'safe_mode requires plan confirmation' discloses a safety gate, and 'no draft-only MCP gate' clarifies that draft status is not an MCP-level restriction. Still, it does not explain what 'safe_mode' is or what actually happens to the document beyond 'delete.'
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 compact and front-loads the main operation, with no filler sentences. However, the compressed jargon 'Prepare/delete' and 'draft-only MCP gate' sacrifices clarity, and the phrasing is dense enough that an agent may struggle to interpret the actual workflow.
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 destructive tool with four parameters, no parameter documentation, and a dangerous default-unsafe operation, the description is too thin. It does not explain dry_run, expected_modified, safe_mode behavior, or how this relates to erpnext_doc_cancel. The presence of an output schema helps with return values, but the agent still lacks enough information to invoke the tool safely and correctly.
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%, so the description must compensate for undocumented parameters, but it does not. None of the four parameters—name, doctype, dry_run, expected_modified—are explained. In particular, the meaning and effect of dry_run are central to the 'Prepare/delete' ambiguity and are left entirely to 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 states a clear verb and resource: it can 'delete any document allowed by ERPNext.' The phrase 'no draft-only MCP gate' adds useful scope by indicating that deletion is not limited to draft documents. However, the combined 'Prepare/delete' wording blurs whether this tool only prepares a deletion or also executes it, and it does not explicitly distinguish itself from erpnext_doc_cancel.
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?
There is no explicit guidance on when to use this tool versus siblings like erpnext_doc_cancel or erpnext_doc_update. The phrase 'any document allowed by ERPNext' implies broad applicability, but the description never states when deletion is appropriate, when cancellation should be preferred, or what prerequisites apply.
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?
Annotations already declare the tool to be non-read-only, destructive, and non-idempotent. The description adds a process hint—generate then 'freeze' a save—which is consistent with the destructive annotation, but it does not clarify what is created, modified, or destroyed. This is acceptable given annotation coverage but not richly transparent.
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 operation stated first and the sibling routing second. It is concise, though the phrasing is cryptic enough that brevity comes at the 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?
For a tool with six parameters, no schema descriptions, and destructive behavior, the description omits key operational details: what 'common mapped document' means, how dry_run and save_draft interact, and what the output contains. The output schema reduces the need to explain return values, but the rest of the calling contract remains largely unspecified.
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%, and the description provides no explanation of source_doctype, source_name, target_doctype, dry_run, save_draft, or extra_args. With six undocumented parameters and zero compensation in the description, an agent has no way to know what values to pass or how parameters affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource ('Generate a common mapped document') and distinguishes itself from call_method, but 'common mapped document' and 'freeze any requested save' are vague and do not clearly explain what the tool produces or how it relates to source/target doctypes. An agent would still be unsure what makes this mapping 'common' or what freezing a save entails.
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 names an alternative ('Use call_method for other mappings') and gives a rough routing condition. It does not fully explain when this tool is preferred over sibling doc tools, but it provides clear enough guidance to steer an agent away from call_method for mapping-like operations.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds a useful restriction via the word 'allowed', implying not every report can be run, but it does not explain how allowlisting works, what permissions are needed, or what happens when a disallowed report is requested.
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 efficiently communicates the core action and useful examples, though it omits contextual details that would make it fully self-sufficient.
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 annotations and an output schema present, the description does not need to explain return values or safety. However, it leaves important gaps: what 'allowed' means, how to discover allowed reports, how to use filters, and how to choose between this tool and the balance-focused sibling tools. These gaps make it incomplete for confident tool 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%, and the description only partially compensates by providing example report names that map to report_name. It gives no guidance on the filters parameter, its accepted shape, or how filters relate to the chosen report, leaving the agent to guess for an open-ended additionalProperties object.
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 uses a specific verb ('Run') with a clear resource ('ERPNext report') and gives concrete examples (General Ledger, Accounts Receivable, Stock Balance). It is understandable and generally distinguishable from the sibling CRUD and planning tools, though it does not explicitly differentiate itself from erpnext_stock_balance or erpnext_party_balance.
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?
There is no explicit statement about when to use this tool versus alternatives, and no exclusions or when-not guidance. The example 'Stock Balance' directly overlaps with the sibling tool erpnext_stock_balance, creating ambiguity for an agent deciding between running a report and using a dedicated balance tool.
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?
Annotations already indicate this is a non-read-only, destructive, non-idempotent operation, so the description does not need to restate that. The phrase 'freeze create/submit as one confirmable dependent batch' adds some behavioral context beyond the annotations by suggesting a batched, confirmable workflow. However, it remains vague about side effects, confirmation mechanics, and what 'freeze' actually means in practice.
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 very short and front-loads the primary action with 'Generate Stock Entry using ERPNext.' It contains no filler or redundant restatement of the schema. However, the awkward and unclear 'freeze create/submit as one confirmable dependent batch' phrase reduces structural clarity even though it is 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 tool's complexity—9 parameters, 0% schema coverage, and a destructive mutation—the description is far too sparse. It does not explain valid purpose values, the interaction between submit, save_draft, and dry_run, or how the 'dependent batch' is confirmed. The output schema exists, but it cannot compensate for missing workflow and parameter guidance.
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 carries the burden of explaining parameters, but it fails to do so. The only implicit parameter hint is 'create/submit,' which loosely maps to the submit boolean. Nothing explains purpose, qty, dry_run, save_draft, target_warehouse, source_stock_entry, or is_additional_transfer_entry, leaving the agent to guess critical input semantics.
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: 'Generate Stock Entry using ERPNext.' This is clear and distinguishes the tool from generic document tools such as erpnext_doc_create. However, the phrase 'freeze create/submit as one confirmable dependent batch' is cryptic and does not clearly explain the core behavior, and no explicit differentiation from sibling tools is provided.
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 gives no guidance on when to use this tool versus alternatives like erpnext_doc_create, erpnext_doc_submit, or erpnext_batch_prepare. There is no mention of prerequisites, exclusions, or conditions that would select this tool over its siblings. The intended use is only implied by the tool name and the phrase 'Work Order,' not stated in the description.
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?
Annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, yet the description gives no hint of side effects, destructive behavior, or non-idempotence. The word 'prepare' suggests a benign read-like operation, which is potentially misleading given the destructive flag, but it does not directly contradict the annotations.
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, front-loaded sentence with no filler or redundancy. It communicates the core operation efficiently, which is appropriate for its short 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?
With three parameters, no schema property descriptions, and a destructive annotation, the description is too thin to fully support correct invocation. It gives no parameter semantics, no side-effect warning, and no routing guidance, though the presence of an output schema partially reduces the need to document return values.
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 carries the burden of explaining artifact_id, expected_count, and label. It only hints that artifact_id refers to the source artifact and that the output is a JSON array of requests, but it does not explain expected_count or label, leaving key parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('prepare') and resource ('a complete JSON array of requests') from a 'finalized source artifact', which gives the agent a clear picture of the operation. It does not explicitly differentiate from sibling erpnext_batch_prepare, but the artifact-based source is a distinguishing clue.
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 'from a finalized source artifact' implies that the tool should be used only after an artifact has been finalized, providing some contextual guidance. However, it does not explicitly state when to use this tool versus alternatives like erpnext_batch_prepare, nor does it mention any exclusions or prerequisites beyond finalization.
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?
Annotations already declare destructive and non-read-only behavior, and the description adds concrete side-effect information: 'may post stock/accounting effects.' This goes beyond the annotations and helps the agent anticipate impact, though it does not cover dry_run behavior or reversibility.
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 core action is front-loaded, and the sensitivity warning earns its place as important supplementary 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?
For a mutating, destructive-capable tool, the description does not explain when submission is appropriate, what 'frozen' implies as a prerequisite, how dry_run changes behavior, or what the output represents. The presence of an output schema does not fill these gaps.
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%, and the description does not explain doctype, name, or dry_run. The dry_run parameter, which is essential for safe invocation, is completely undocumented in both the schema and the description.
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 operation as 'Submit' and the resource as 'a frozen current document through Frappe,' which distinguishes it from sibling create/update/cancel/delete operations. It does not explicitly contrast with sibling tools or explain 'frozen current' in depth, so it stops just short of full differentiation.
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 offers no guidance on when to use this tool versus alternatives, what conditions make a document ready to submit, or when dry_run should be used. The only additional note is a sensitivity warning about consequences, not selection criteria.
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?
Annotations already flag destructive=true and readOnly=false, and the description adds value beyond that by disclosing the safe_mode conflict-check behavior (pin modified for Frappe save conflicts) and the sensitivity of child-table replacement. This complements the destructiveHint rather than contradicting it.
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 with zero filler and the core purpose front-loaded. The second sentence is slightly run-on, but every clause carries non-redundant 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?
For a 6-param destructive tool with nested fields and conflict-check machinery, this is too thin: no explanation of what 'native fields' excludes, how dry_run behaves, what expected_lengths/expected_modified are for, or the child-table replacement semantics. The output schema covers return values, but the usage model is under-specified.
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 does not explain doctype, name, fields, dry_run, expected_lengths, or expected_modified. It even references 'safe_mode,' which is not a schema parameter at all, leaving the actual params — especially dry_run and the expected_* conflict-check fields — semantically opaque.
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?
"Update native fields" states a specific verb and resource, clearly positioning this as the modify-existing-document operation within the doc family (create/delete/submit/cancel/get/list/map). It distinguishes itself from siblings by operation type, though "native fields" is domain jargon that is never explained.
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, and no alternatives are named despite 29 siblings. The safe_mode and child-table remarks hint at constraints, but an agent gets no routing help to distinguish this from erpnext_doc_create, erpnext_doc_submit, or erpnext_doc_map.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate basic safety. It adds useful context about verification and the finalization gate for execution/upload, but it does not disclose that finalization may be irreversible or that the input may become locked after this step.
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 with no filler, and the key behavioral consequence is stated early. The structure is efficient, though it sacrifices parameter-level detail that would be more valuable than brevity.
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 single-parameter tool with an output schema and annotations, the description covers the main purpose and consequence. However, it omits the meaning of artifact_id and does not explicitly place this step in the sequence between appending input data and executing/uploading.
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%, and the description does not explain the meaning or role of artifact_id at all. Since this is the only parameter and is required, the agent must infer what artifact_id refers to, which is a significant 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?
The description states a specific action: verifying source length and SHA-256 and marking an input as finalized, with the outcome that only finalized inputs can be executed/uploaded. It clearly differentiates this tool from input_begin and input_append by focusing on the finalization step. It could be slightly stronger by explicitly naming the finalize action rather than leading with 'Verify'.
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 'Only finalized inputs can be executed/uploaded' implies this should be used after input construction and before execution/upload, but it does not explicitly name sibling tools or state when not to use it. The guidance is present but indirect and could mislead an agent into thinking this is a read-only verification step.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. The description adds the useful context that data comes from ERPNext bin details, but it does not describe aggregation behavior, quantity types, or other runtime details.
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 concise sentence with no filler. It front-loads the operation and resource, making the purpose immediately clear.
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?
Annotations and the output schema cover safety and return shape, and the core purpose is understandable. However, with 0% schema coverage and no explanation of optional parameters or alternatives, the description leaves some invocation decisions to inference.
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 for parameter meaning. It semantically covers item_code and warehouse, but says nothing about company or include_child_warehouses, which are non-obvious optional parameters.
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 verb 'Return' and a clear resource: stock quantities for an item and warehouse, with 'using ERPNext bin details' identifying the data source. It is clear but does not explicitly distinguish itself from sibling tools such as erpnext_party_balance or erpnext_report_run.
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 when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. An agent must infer when to use this tool instead of neighboring tools like erpnext_party_balance or erpnext_doc_get.
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?
Beyond the destructiveHint annotation, the description discloses that cancellation triggers ledger reversal and custom hooks and that preflight cannot simulate these effects. This is valuable behavioral context an agent would not derive from the schema or annotations.
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 pack the operation and the key safety caveat with no filler. The structure is front-loaded and every clause 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?
For a destructive tool with three undocumented parameters, the description is too sparse. It does not clarify what dry_run does, what inputs are required, or how to validate before invoking, and the preflight reference is unexplained.
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 0% description coverage, so the description must compensate, but it does not explain doctype, name, or dry_run. The verb 'Cancel' gives partial meaning to the parameters, but dry_run's behavior is entirely undocumented.
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 names the operation ('Cancel') and the system ('Frappe'), which is enough to identify document cancellation. It does not explicitly state the object is an ERPNext document or distinguish from delete/submit, but the tool name and schema fill that gap.
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 about when to use cancel versus alternatives like erpnext_doc_delete, erpnext_doc_update, or erpnext_doc_submit. The warning about preflight is cautionary, not usage-directional.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the bar is lower. The description adds genuinely new behavioral context beyond those: the limit parameter is honored without a hidden cap, and has_more cannot be trusted on a full page unless include_total is set. These are exactly the runtime gotchas structured annotations cannot express.
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 with zero filler; the operative verb 'List' is front-loaded and the caveat sentence follows the primary claim. Every word earns its place, and the most actionable information appears first.
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 eight parameters and zero schema descriptions, two caveat sentences are not enough. The output schema covers return values and annotations cover safety, but filter formats, or_filters semantics, order_by syntax, and offset behavior are left entirely to domain guessing.
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%, placing the full burden on the description. It only hints at two of the eight parameters — limit via 'hidden limit clamp' and include_total via 'without total' — while filters, or_filters, order_by, fields, offset, and doctype receive no semantic clarification.
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 verb and scope — 'List one page' — and the tool name plus the required doctype parameter make the resource (ERPNext documents of a doctype) reasonably inferable. It gestures at differentiation with 'without a hidden limit clamp' but never explicitly names the resource or contrasts itself with siblings like erpnext_doc_get or erpnext_plan_list.
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, and no alternative tool is named. The phrase 'without a hidden limit clamp' implies a contrast with other listing paths, and the has_more caveat hints at pagination trade-offs, but the agent is left to infer selection criteria entirely.
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?
Annotations already convey destructive=true and readOnly=false, so the description does not need to restate those. It adds useful context by noting that unlisted methods require review and that the correct response is not to edit an allowlist, which is valuable governance/behavioral guidance for a powerful generic RPC 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?
Two short sentences, with the core action front-loaded and a concise safety policy second. There is no filler or redundant restating of schema or annotations.
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 broad, potentially destructive RPC tool with five parameters and zero schema description coverage, the description is too thin. It does not explain method naming conventions, how dry_run behaves, when to switch http_method or api_version, or how this relates to the established sibling tools. The output schema reduces some burden, but the invocation context remains under-specified.
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 carries the burden of explaining parameters, but it only mentions the concept of a method. The roles of args, dry_run, http_method, and api_version are left entirely to inference from names, enums, and defaults; the description adds no parameter-level meaning.
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 and resource: call any Frappe-exposed RPC method. The word 'any' signals that this is the generic escape-hatch tool, which helps distinguish it from the many higher-level ERPNEXT sibling tools for specific operations. It lacks an explicit sibling comparison, so it stops just short of a perfect score.
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 'Unlisted methods need review, not an allowlist edit' implies a governance boundary: this tool can call methods beyond the normal allowlist, but they require review. It does not explicitly state when to prefer specific siblings such as erpnext_api_request or the doc_* tools, so usage guidance is only 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds a useful recovery-oriented framing and the distinction of running/unknown receipts, but it does not explain ordering, pagination, or status semantics in detail.
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 compact sentence with no filler and front-loads the main recovery purpose. The semicolon joins two related use cases efficiently, though splitting into two sentences could improve readability slightly.
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 listing tool with a rich annotation set and an output schema, the description covers the key recovery scenario adequately. It leaves status filtering and pagination implicit, but these are inferable from parameter names and schema defaults, so the definition is minimally viable.
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 weakly hints at parameter meaning: 'running/unknown' suggests possible status values and 'recent' implies ordering and limit relevance. It does not explicitly document limit, offset, or status behavior.
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 identifies a concrete action — listing/recovering recent plan IDs and receipts — and attaches it to a specific scenario (lost tool response, before retrying). It avoids tautology and names the resource, though it does not explicitly differentiate itself from closely related siblings like erpnext_plan_inspect or erpnext_result_read.
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 clear usage context: use this tool after a lost tool response, or to list running/unknown receipts before retrying. It does not name alternative tools 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful safety behavior beyond the annotations: 'Unknown methods become confirmable sensitive plans in safe_mode' and 'dry_run never sends the requested mutation; it saves the exact request and reports what could/could not be verified.' This is exactly the kind of non-obvious behavioral context an agent needs for a destructive, open-world tool. It supplements the destructiveHint rather than repeating it.
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 tightly written with no filler. The first sentence front-loads the core capability and scope; the second adds the crucial dry_run and safe_mode behavior. Every sentence earns its place and the structure is easy to parse.
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 highly complex, with an output schema but 0% parameter description coverage. The description covers broad capability and dry_run behavior, yet important operational context is missing: how authentication is handled, what safe_mode actually requires, and how the various body/expected_* fields cooperate. It is adequate but not complete for a raw HTTP gateway with destructive potential.
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 request object has many fields like params, bindings, expected_lengths, body_artifact_id, and json_artifact_id whose semantics are not explained anywhere. The description does add value for dry_run and for the broad content-type categories (JSON/form/multipart/binary), but it does not compensate for the large amount of undocumented nested parameter structure.
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 a specific verb and resource: 'Call any same-origin ERPNext HTTP route, including API v1/v2, JSON/form/multipart/binary.' This establishes a general-purpose raw HTTP tool. However, it does not explicitly distinguish it from the similar sibling erpnext_call_method, so it misses the full differentiator a 5 would require.
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?
There is no guidance on when to prefer this tool over the many sibling tools, nor any explicit when-not-to-use conditions. The phrase 'any same-origin ERPNext HTTP route' implies broad/generic use, but no alternatives or exclusions are named. This leaves the agent to infer routing on its own.
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?
Annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=false) already signal the safety profile, and the description adds meaningful behavioral traits beyond them: batches are explicitly non-atomic and stop on error, source count verification is performed, and a single user confirmation covers the whole batch. These are genuine operational disclosures that shape how an agent invokes and monitors the 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 front-loaded: the core purpose appears in the opening sentence, followed by the binding example and the critical non-atomicity caveat. Every sentence earns its place; there is no filler or repetition of schema content.
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 destructive, non-idempotent tool with a complex requests array parameter, the description covers key behaviors (count verification, confirmation, non-atomicity) and an output schema exists, so return values are covered. Still, it lacks guidance on side effects of 'prepare' in the broader flow, the distinction from erpnext_batch_prepare_from_artifact, and what differentiates this from execution tools — leaving meaningful gaps for an agent navigating the sibling set.
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 for the bindings parameter via a concrete example ({'/doc': {'step': 0, 'pointer': '/data'}}) that explains the response-to-request pointer mechanism. However, the primary parameters requests, expected_count, and label are only indirectly referenced through 'exact ordered batch' and 'Verify source count'; the description adds meaning for one nested parameter but leaves the others to inference.
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 verb and resource: 'Prepare an exact ordered batch' — clear and unambiguous about the object and scope, with qualifiers ('exact', 'ordered') that add precision. However, it does not explicitly differentiate from the sibling erpnext_batch_prepare_from_artifact, which appears to be an alternative preparation path, so the distinction is left to the agent.
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 gives no explicit guidance on when to use this tool versus alternatives such as erpnext_batch_prepare_from_artifact, erpnext_plan_execute, or erpnext_api_request. Notes like 'one user confirmation covers the batch' are contextual but do not tell the agent which sibling to select under which conditions, so the agent must infer usage from purpose alone.
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?
Annotations already signal a non-read-only, destructive, non-idempotent operation. The description adds valuable context by stating that a draft revision is generated and frozen while the source BOM remains unchanged, clarifying a key behavioral side effect. It does not fully explain what 'freeze' implies or what destructive side effects may occur, but it does not contradict the annotations.
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, front-loaded sentence with no filler. Every clause contributes meaning: 'generate and freeze', 'draft revision', 'submitted BOM', and 'source remains unchanged'.
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 core operation is stated, but the description leaves the parameter semantics completely unaddressed and gives no guidance on when to use this tool versus related BOM/update tools. Even with an output schema present, the missing parameter documentation and usage guidance make this incomplete for reliable selection and invocation.
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%, and the description does not explain the meaning of 'source_bom', 'fields', or 'dry_run'. While 'source_bom' is inferable from the tool name, the roles of the optional 'fields' object and 'dry_run' flag are entirely undocumented, leaving an agent unable to use them 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 names the specific action ('Generate and freeze a draft revision') and the resource ('submitted BOM'), and adds a differentiating constraint: the source remains unchanged. This clearly distinguishes it from general doc mutation tools like erpnext_doc_update or erpnext_doc_delete.
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: it is for creating a draft revision of an already submitted BOM, not for editing the source directly. However, it does not explicitly state when to prefer this over siblings such as erpnext_doc_update or erpnext_bom_preflight, nor does it give 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, covering the safety profile. The description adds the 'readable' qualifier, indicating results respect the user's read permissions, and 'Link field candidates' clarifies the output as selectable options. This is useful context beyond the annotations.
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 14-word sentence that is front-loaded with the action ('Search') and the object ('readable ERPNext Link field candidates'). Every word earns its place, and there is no redundant or filler content.
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 core purpose is clear, annotations cover the safety profile, and an output schema is present to describe return values. However, the description gives no parameter semantics and no guidance on selecting this tool over siblings, which is a notable gap for a four-parameter tool. It is minimally viable but not complete enough for confident usage without further inference.
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 provides no information about the four parameters. While 'doctype', 'text', and 'limit' are somewhat self-explanatory, 'filters' is ambiguous and no parameter is described in relation to how the search behaves. With zero schema coverage, the description fails to compensate for the lack of parameter documentation.
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 uses a specific verb ('Search') and a specific resource ('readable ERPNext Link field candidates') with concrete examples (Customer, Item, Account, Warehouse, or Supplier). It clearly conveys the tool's unique purpose within the sibling set, though it does not explicitly contrast with related tools like erpnext_doc_list or erpnext_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Link field candidates' implies this tool is used when an agent needs to find valid values for a Link field in ERPNext, but there is no explicit statement of when to use it versus alternatives, no exclusions, and no mention of related tools. Usage context is only implied, not spelled out.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds a non-obvious behavior not present in the annotations: large documents are returned through result artifacts. This is valuable contextual information for the agent.
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 filler. The core action is front-loaded, and the artifact caveat is included efficiently. Every word contributes meaning.
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 tool with output schema and safety annotations, the description is mostly adequate. However, the complete absence of parameter explanation at 0% schema description coverage is a genuine gap, and the relationship to erpnext_result_read is only implied. It is minimally sufficient but not fully complete.
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%, so the description must compensate, but it does not mention doctype or name at all. It provides no guidance on what values to supply, how the two parameters relate, or any constraints. The agent is left with only the parameter names themselves.
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 with a resource: 'Read a complete document.' This clearly distinguishes it from create/update/delete/submit/cancel siblings and from doc_list, which would not return a single complete document. The artifact caveat adds further specificity.
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 'Read a complete document' implies the usage context for fetching a single full document, and the artifact note hints at a follow-up for large results. However, there is no explicit routing to alternatives like erpnext_result_read for consuming artifacts, nor any mention of when doc_list would be more appropriate. Guidance is only implied, not stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns with those rather than contradicting them. The description adds the metadata categories returned but does not address error behavior, permissions, or data freshness; the safe, read-only profile is adequately covered by annotations.
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 concise sentence that front-loads the action and resource, then uses a colon-separated list to enumerate details. There is no filler, repetition, or unnecessary context.
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?
This is a simple single-parameter metadata getter with rich annotations (read-only, idempotent, non-destructive) and an existing output schema. The description covers what the tool returns, and the output schema handles return-value details, so nothing essential for invoking it correctly is missing.
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 a bare 'doctype' string with 0% schema description coverage, and the description does not explain the accepted format, case sensitivity, or examples. The parameter name is somewhat self-explanatory within ERPNext, but the description adds almost no semantic value 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 states a specific action ('Return') and resource ('ERPNext DocType metadata'), then enumerates exact contents: fields, required fields, child tables, links, and docstatus support. This clearly distinguishes it from sibling doc CRUD/list tools like erpnext_doc_get and erpnext_doc_list.
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. It does not mention prerequisites, conditions, or contrast with any sibling tool, leaving the agent to infer usage solely from the tool name and purpose.
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 adds genuine behavioral constraints beyond the annotations: the 256 KiB size limit and rejection of out-of-order or excess bytes are not present in the annotation flags. This tells the agent what inputs will fail. It does not explain why destructiveHint=true is set for an append operation, but no annotation contradiction exists.
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 with no filler. The primary action is front-loaded, and the size limit plus rejection behavior both earn their place as operation-critical constraints. Nothing extraneous is present.
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 is one step in a stateful protocol, yet the description does not state that input_append requires an active session started by input_begin and must be completed by input_finalize. With 0% schema coverage and no mention of the workflow, offset semantics, or artifact_id meaning, an agent lacks enough context to call it correctly despite the output schema existing.
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 partially does: 'up to 256 KiB' bounds data_base64, and 'out-of-order ... rejected' explains that offset must follow sequence order. However, it leaves artifact_id's referent and whether offset is a byte position or chunk index unstated, which are critical for correct invocation.
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 verb and resource ('Append one local input chunk') with a size cap, which clearly identifies the operation. It is distinguishable from siblings like erpnext_input_begin and erpnext_input_finalize by the 'append' verb. The term 'local input' is somewhat vague without protocol context, but the core action 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: 'append' suggests it fits between erpnext_input_begin and erpnext_input_finalize, and the sibling list reinforces that. However, the description never states the expected call sequence, prerequisites (an begun input session), or when to choose this over alternatives. The rejection of out-of-order chunks hints at protocol ordering but does not spell it out.
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?
Annotations already signal mutation and destructiveness (readOnlyHint false, destructiveHint true, idempotentHint false). The description adds that the upload is local and that inputs must be calculated from the source, but it does not explain the side effects of beginning an upload, such as creating a pending artifact or resetting an existing one. No contradiction with annotations.
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 front-loaded sentence with no filler. Every word contributes: the action, the resource, and the key parameter semantics are all present in a compact string.
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 stateful multi-step upload flow, the description conveys the purpose but omits important context such as the required sequence (begin → append → finalize), what starting a new upload does to prior state, and any constraints on concurrent uploads. The presence of an output schema mitigates the need to explain return values, but lifecycle context is still missing.
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?
With 0% schema description coverage, the description must compensate, and it does partially: 'byte length' clarifies expected_bytes and 'SHA-256 calculated from the source' clarifies sha256. However, it does not provide details on expected_bytes units/limits, sha256 encoding, or the optional mime_type, so semantic coverage 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?
The description uses a specific verb ('Begin') with a clear resource ('a local artifact upload') and names the two key inputs (byte length and SHA-256). This clearly distinguishes it from sibling tools like erpnext_input_append and erpnext_input_finalize, which handle later phases of the same workflow.
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 word 'Begin' implies this is the first step in a local artifact upload sequence, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention that it should be followed by append/finalize. Usage context is present but only implicitly.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral scope of tracing across multiple modules, but does not explain how the trace is constructed or what constraints apply (e.g., how filters combine). This adds some value beyond the annotations but not rich behavioral detail.
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 front-loaded sentence: the verb and object come first, followed by a compact list of covered domains. There is no filler or repetition of schema/annotation information, so it earns a high conciseness score.
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 tool with nine optional parameters, zero schema descriptions, and a broad trace operation, the one-line description leaves key invocation questions open, such as how to identify the starting flow and what happens when no filter is supplied. The output schema and read-only annotations cover the return shape and side-effect profile, but they do not compensate for missing parameter semantics. The description is a good selector-level overview but not enough for confident correct 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?
With 0% schema description coverage, the description needed to define the nine parameters but only indirectly references sales, buying, production planning, subcontracting, and work orders. Parameters like tag, limit, company, and item_code are not explained or mapped to invocation behavior. The domain list gives a partial hint at best.
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 ('Trace') and a concrete resource ('one ERPNext business flow'), then enumerates the modules it spans. This makes it easy to distinguish from sibling tools like doc_get or report_run, which operate on single documents or reports rather than cross-module flows.
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 the intended use case clear: end-to-end business-flow tracing across ERPNext domains. It does not explicitly name alternatives or state when not to use this tool, but the scope is specific enough that an agent can select it for flow-tracing tasks. Missing explicit exclusions keeps this from 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?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond annotations: the tool works without contacting ERPNext and reports that legacy allowlists are inactive. No contradiction with annotations.
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 with no filler. The primary action and scope are front-loaded, and the legacy allowlist note adds useful context without bloating the description.
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 tool with rich annotations and an output schema, the description is largely complete: it identifies what is inspected and that no network contact occurs. Minor ambiguity around what 'resolved target' refers to prevents a 5, but nothing critical 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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is fully consistent with the described inspect-only behavior.
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 action ('Inspect') and the specific resources ('resolved target and safe_mode') without contacting ERPNext. It is not a tautology and distinguishes this as a local configuration inspection tool rather than an API call, though 'resolved target' is somewhat jargon-dependent.
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 for inspecting local configuration state without network access, and notes that legacy allowlists are inactive. However, it does not explicitly state when to use this tool versus siblings like erpnext_health_check or erpnext_plan_inspect, nor does it name alternatives or 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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds useful behavioral context by stating that Routing operations are resolved and rules like positive operation time are checked. It does not enumerate all checks, but the annotation coverage lowers the burden.
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 redundancy. The core purpose is front-loaded, followed by the key behavioral details. Every clause 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?
The description covers the tool's purpose and main behavior well, and the output schema plus annotations fill in return-value and safety context. However, one parameter (include_doc) is left unexplained, and the rule set is vaguely described as 'known rules' rather than summarized or linked.
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 hints that 'existing BOM' maps to bom_name and 'proposed BOM payload' maps to doc, but it entirely omits include_doc. An agent cannot determine what include_doc controls or how it affects the invocation.
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 ('Preflight') and resource ('existing BOM or proposed BOM payload'), explicitly notes that it does not write, and names concrete behaviors: resolving Routing operations and checking ERPNext manufacturing rules. This clearly distinguishes it from BOM creation/revision and other write-oriented 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 conveys the intended use case: validate a BOM before writing, whether existing by name or proposed as a payload. The phrase 'without writing' implicitly tells the agent not to use this for actual create/update operations, though it does not explicitly name alternative tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral detail by specifying that it reads status, execution receipts, and the full immutable request, which is more informative than simply saying 'read plan'.
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 with no filler. It front-loads the action ('Read') and packs the relevant scope into a compact form.
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 single-parameter read tool with an output schema and strong annotations, the description covers the essential context: what is read and when it should be used. The phrase 'before confirming it' is slightly ambiguous about which tool performs the confirmation, but the overall context is sufficient for correct tool selection.
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 carries the burden for parameter meaning. It never explicitly describes plan_id, though the resource name and tool name make it inferable that plan_id identifies the plan to inspect. The description does not add format, lookup, or validation details beyond what the schema already shows.
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 ('Read') and identifies three concrete resources: plan status, execution receipts, and the full immutable request. The phrase 'before confirming it' adds a clear purpose, and this helps differentiate the tool from siblings like erpnext_plan_list and erpnext_result_read.
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 usage context: this tool should be used to inspect a plan before confirming/executing it. It does not explicitly name alternatives or exclusion conditions, but the temporal cue 'before confirming it' is a useful and specific guideline.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context beyond those annotations by disclosing bounded base64 chunking, completeness of reads, and subtree selection via JSON pointer, which are not visible in the structured annotations.
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 compact two-sentence definition with no filler. It front-loads the core action and resource, then adds the optional capability, making it easy to scan and parse.
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, idempotent tool with an output schema, the description covers the main operational aspects: full coverage, chunking, and subtree filtering. It does not mention where artifact_id originates or how clients detect the final chunk, but the output schema and sibling context likely fill those 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?
With 0% schema description coverage, the description carries the burden of explaining parameters. It explicitly explains json_pointer and implies limit/offset through 'bounded base64 chunks', but it never states whether limit/offset are raw bytes, base64 characters, or chunk indices, which is a meaningful ambiguity for an agent invoking the 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 names a specific verb ('Read'), a concrete resource ('complete result/input bytes'), and the chunking mechanism ('bounded base64 chunks'). The optional JSON pointer adds further precision, and this clearly separates the tool from siblings like erpnext_doc_get or erpnext_input_begin.
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 read behavior is clearly stated and easily distinguishable from the mutation and query siblings, so the intended context is obvious. It does not explicitly list exclusions or alternatives, but no sibling appears to offer the same artifact-bytes read capability.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying that the tool verifies connectivity, the authenticated user, and app versions, making the operation's scope transparent beyond the annotations.
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 front-loads the action and lists the exact check targets with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, zero parameters, existing output schema, and annotations that already cover safety and idempotency, the description is complete enough for an agent to select and invoke the tool correctly. Return-value details are already handled by the output schema.
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 schema is empty, so parameters impose no burden. Baseline for zero parameters is 4, and the description does not need to compensate for any undocumented inputs.
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 ('Check') and names a concrete resource: ERPNext connectivity, authenticated user, and installed app versions. This distinguishes it from sibling tools like erpnext_api_request or erpnext_config_status by enumerating exactly which health dimensions it covers.
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 when to use the tool: whenever an agent needs to verify ERPNext connectivity, authentication, or installed app versions. However, it does not explicitly state when to prefer this over siblings or mention exclusions, so usage guidance remains inferred rather than direct.
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?
Annotations already flag destructive, non-idempotent behavior, but the description adds important context: it records agent-attested consent rather than verified human identity, warns against retrying ambiguous writes, and directs the agent to verify the receipt and upstream state. This meaningfully enriches the safety profile.
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 short, front-loaded with the primary action, and every sentence earns its place: the action, the consent caveat, and the safety directives are all necessary. There is no filler or repetition.
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 handles the dangerous-execution context well: it warns about retries, demands user confirmation, and instructs post-execution verification. With an output schema present, return-value details are not required. The main gap is the unexplained plan_id and request_sha256, which prevents full self-sufficiency.
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 carries the full burden for parameter meaning. It partially explains user_confirmation by referencing 'actual in-scope user approval text,' but plan_id and request_sha256 are left completely undefined. The agent must infer their meaning from the tool name and siblings.
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: 'Execute the frozen plan once.' It clearly distinguishes this from sibling tools like plan_list, plan_inspect, and batch_prepare by indicating this is the action that runs an already-frozen plan.
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 actionable guidance: supply actual in-scope user approval text for sensitive plans, do not create another plan to retry an ambiguous write, and inspect the receipt and upstream state after execution. This provides clear when-and-how-to-use direction beyond simply stating the operation.
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

ERPNext MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![ERPNext MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Cec1c/ERPNext-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Cec1c/ERPNext-MCP)

Score Badge

Copy to your README.md:

[![ERPNext MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Cec1c/ERPNext-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Cec1c/ERPNext-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/Cec1c/ERPNext-MCP'

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