Frappe MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between list_documents, run_doctype_report, and run_query_report, which could cause confusion in selecting the right tool for listing or reporting tasks. However, descriptions help clarify their specific uses, and other tools like create_document, update_document, and cancel_document are clearly differentiated.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_document, update_document, list_documents, and get_doctype_schema. All tools use snake_case with clear, descriptive names, making them predictable and easy to understand without any deviations or mixed conventions.
Tool Count4/5
With 24 tools, the count is slightly high but reasonable for a comprehensive Frappe server covering document management, reporting, and system operations. It includes core CRUD operations, financial statements, and utility tools, though it may feel heavy compared to simpler servers but aligns well with the domain's complexity.
Completeness5/5
The tool set provides complete coverage for Frappe document management, including full CRUD lifecycle (create, get, update, delete, submit, cancel, amend), schema exploration, reporting, and financial statements. There are no obvious gaps; agents can perform all essential operations without dead ends, supported by utility tools like ping and version.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool 'bypasses all parameter validation issues', which is a useful behavioral trait indicating it might skip checks. However, it lacks details on permissions, side effects, rate limits, or what 'verify Frappe API filtering works' entails operationally.
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 appropriately sized with two sentences that are front-loaded and efficient. Each sentence adds value: the first states the purpose, and the second clarifies a key behavioral trait. There's no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (testing-focused with 1 parameter), no annotations, and an output schema exists (which reduces need to explain returns), the description is minimally adequate. It covers the testing purpose and validation bypass but lacks details on usage context or parameter meaning, leaving gaps for an agent.
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 mentions 'hardcoded filter' but doesn't explain the 'doctype' parameter's meaning, how it relates to filtering, or what values are expected. The description adds minimal semantic value beyond the schema.
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 states the tool 'test[s] hardcoded filter to verify Frappe API filtering works' and 'bypasses all parameter validation issues', which gives a vague purpose focused on testing/verification rather than a specific operational function. It doesn't clearly distinguish from siblings like 'list_documents' or 'run_query_report' that might involve filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions it 'bypasses all parameter validation issues', which implies a specific testing context but doesn't explicitly state when or why to choose it over other filtering-related tools like 'list_documents'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'whitelisted' which implies security constraints, but doesn't explain what this means in practice, what authentication is required, what happens on failure, or what the output looks like. For a tool that executes arbitrary methods, this lack of behavioral context is a significant gap.
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 appropriately concise with a clear purpose statement followed by parameter documentation. The two-sentence structure is efficient, though the Args formatting could be more integrated with the main description. Every sentence serves a purpose with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary methods), lack of annotations, and presence of an output schema, the description is minimally adequate but incomplete. It covers basic purpose and parameters but misses critical context about security constraints, error handling, and relationship to sibling tools. The output schema existence means return values are documented elsewhere, but the description should still provide more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides basic parameter documentation in the Args section, naming both parameters and indicating that params is optional. However, with 0% schema description coverage and no details about what constitutes valid method names or parameter formats, this adds only marginal value beyond the bare schema. The baseline of 3 is appropriate given the schema does minimal documentation work.
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 ('Execute') and target ('a whitelisted Frappe method'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its many siblings (like amend_document, create_document, etc.) that also execute operations, leaving room for confusion about when to use this general-purpose method caller versus more specific document operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 22 sibling tools including many document-specific operations (create_document, update_document, etc.), the agent receives no help in choosing between this generic method executor and more specialized tools. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' metadata, implying a read-only operation, but doesn't disclose behavioral traits such as error handling (e.g., what happens if the report doesn't exist), authentication needs, rate limits, or response format. This leaves significant gaps for an agent to understand how to invoke it correctly.
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 appropriately sized with two sentences: one stating the purpose and one explaining the parameter. It's front-loaded with the core functionality. There's no wasted text, though it could be more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema exists, the description is minimally complete. It covers the basic purpose and parameter, but lacks behavioral context (e.g., error cases) and usage guidelines. The output schema mitigates the need to explain return values, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It documents the single parameter 'report_name' with a brief explanation ('Name of the report to get metadata for'), but schema description coverage is 0%, so the schema provides no details. The description compensates slightly by clarifying the parameter's role, but doesn't specify format (e.g., string constraints) or examples, leaving room for improvement.
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 'Get' and the resource 'metadata for a specific report', specifying it includes 'columns and filters'. This distinguishes it from sibling tools like 'get_report_columns' (which might only get columns) or 'list_reports' (which lists reports rather than metadata). However, it doesn't explicitly differentiate from all siblings, such as 'get_doctype_schema', which could have overlapping functionality.
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 doesn't mention prerequisites (e.g., whether the report must exist), exclusions, or compare it to siblings like 'get_report_columns' or 'run_doctype_report'. The user must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, if it requires authentication, what the output format is, or any rate limits or constraints beyond the parameters. This is inadequate for a tool with zero annotation coverage.
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 appropriately sized and front-loaded, with the core purpose stated first in a clear sentence. The parameter explanations are concise, though the formatting with 'Args:' is slightly verbose. Overall, it avoids unnecessary fluff and earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it should do more to explain behavioral aspects like authentication needs or output structure. The output schema mitigates some gaps, but overall completeness is just sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 0% description coverage. It mentions the parameters ('module' and 'limit') and their purposes (filtering and limiting), but doesn't explain what 'module' refers to, valid values, or the behavior when limits are exceeded. Since schema coverage is low, this partial compensation earns a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('list of all available reports'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_report_columns' or 'get_report_meta', which prevents 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 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 like 'get_report_columns' or 'run_doctype_report'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention permission requirements, whether it's idempotent, what happens on validation errors, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The Args section is well-structured but could be more front-loaded with critical usage information. No wasted sentences, though it could be more complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 3 parameters with 0% schema coverage, but with an output schema present, the description provides basic parameter semantics but lacks critical behavioral context. The output schema reduces the need to describe return values, but permission requirements, error handling, and sibling differentiation remain 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantic meaning for all three parameters (doctype, name, values), explaining what each represents. However, it doesn't provide format examples, constraints, or relationship details needed for effective use.
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 'Update' and the resource 'an existing document in Frappe', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'amend_document' or 'submit_document', which appear to be related document modification operations.
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 like 'amend_document', 'submit_document', or 'create_document'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Required fields must be included' which hints at validation behavior, but doesn't disclose critical traits like authentication needs, error handling, rate limits, or what happens on success (e.g., returns the created document). For a creation tool with zero annotation coverage, this is inadequate.
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 front-loaded with the core purpose, followed by a structured 'Args' section. It's efficient with no wasted sentences, though the formatting with indentation and line breaks slightly reduces readability compared to a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with nested objects, no annotations, and an output schema exists (which covers return values), the description is moderately complete. It explains parameter semantics well but lacks behavioral context like permissions or side effects, making it adequate but with clear gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'doctype' is explained as 'DocType name', and 'values' is detailed with examples for Link fields (exact document name) and Table fields (array of row objects), plus the requirement for including required fields. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new document') and resource ('in Frappe'), with the verb 'Create' being specific. However, it doesn't differentiate from sibling tools like 'amend_document' or 'submit_document' that also involve document creation/modification workflows, so it misses the highest tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'amend_document', 'submit_document', and 'update_document' available, there's no indication of prerequisites, typical use cases, or distinctions between creation and other document 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a destructive operation ('Delete') and describes error handling characteristics ('detailed feedback', 'actionable guidance'). However, it lacks information about rate limits, authentication requirements, or what specific 'linked documents, permissions, or constraints' might block deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, behavior, parameters, returns) and avoids unnecessary verbiage. The first sentence immediately states the core function. The only minor inefficiency is the slightly verbose phrasing in the behavioral section.
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 operation with no annotations, the description does reasonably well by explaining the tool's purpose and error handling behavior. The existence of an output schema means it doesn't need to detail return values. However, given the complexity of document deletion in systems like Frappe (with potential dependencies and permissions), more context about prerequisites and constraints would be valuable.
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 provides basic semantic information about the two parameters ('DocType name', 'Document name (case-sensitive)'), which adds value beyond the bare schema. However, it doesn't explain what constitutes valid doctype names or document names, nor does it provide examples or format requirements.
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 ('Delete') and resource ('document from Frappe'), making the purpose unambiguous. However, it doesn't explicitly differentiate this deletion tool from sibling tools like 'cancel_document' or 'amend_document', which might also modify document states in Frappe systems.
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 like 'cancel_document' or 'amend_document'. It mentions error handling for common deletion blockers, but doesn't specify prerequisites, permissions needed, or contextual factors that should influence tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It lacks behavioral details such as permissions needed, error handling, rate limits, or what happens if the document doesn't exist, which are critical for a retrieval 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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters) and the presence of an output schema, the description is minimally adequate. However, without annotations and with incomplete behavioral context, it leaves gaps in understanding the tool's full operation and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'doctype' is the DocType name and 'name' is the case-sensitive document name, providing essential context that the schema alone does not.
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 'Retrieve' and the resource 'a document from Frappe', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_documents' or 'get_doctype_schema', which would require more specific scope details for 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'list_documents' for multiple documents or 'get_doctype_schema' for schema details, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks server responsiveness, which implies a read-only, non-destructive operation, but doesn't specify details like response format, timeouts, or error handling. For a tool with zero annotation coverage, this leaves gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is minimally adequate. It explains the basic purpose but lacks details on behavioral traits or usage context. The output schema likely covers return values, so the description doesn't need to explain those, but it could benefit from more completeness for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking server responsiveness with the phrase 'check if the server is responding.' It uses a specific verb ('check') and resource ('server'), though it doesn't explicitly differentiate from siblings like 'validate_auth' or 'version' that might also test connectivity. The purpose is unambiguous but lacks sibling distinction.
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 doesn't mention prerequisites, timing, or compare it to other tools like 'validate_auth' for authentication checks or 'version' for server status. Usage is implied as a basic connectivity test, but there are no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates credentials and returns status, but doesn't specify what 'authentication status' includes (e.g., success/failure, error details, token validity), whether it has side effects (e.g., logs attempts), or any rate limits. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence: 'Validate API credentials and return authentication status.' It's front-loaded with the core action and outcome, with no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters) and the presence of an output schema (which should detail the return values), the description is minimally adequate. However, without annotations and with no guidance on usage or behavioral details, it leaves gaps in understanding the tool's full context and integration with siblings.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline. It implicitly confirms no parameters are required by not mentioning any, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate API credentials and return authentication status.' It specifies the verb ('validate') and resource ('API credentials'), and the outcome ('return authentication status'). However, it doesn't differentiate from sibling tools like 'ping' or 'get_frappe_usage_info', which might also involve system checks, so it's not a perfect 5.
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 doesn't mention prerequisites (e.g., before making other API calls), exclusions, or compare it to siblings like 'ping' for basic connectivity checks. This lack of context leaves the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's likely read-only, but doesn't explicitly confirm this or describe other behavioral traits such as authentication requirements, rate limits, error conditions, or what 'combined information' specifically entails. The description adds minimal context beyond the basic operation type.
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 appropriately sized and front-loaded, with the purpose stated clearly in the first sentence. The parameter explanations are concise and directly relevant. There's no unnecessary verbosity, though the formatting with extra whitespace could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values in the description) and no annotations, the description is moderately complete. It covers the purpose and parameters adequately but lacks behavioral details like error handling or performance characteristics. For a tool with 2 parameters and no annotations, it meets minimum viability but has clear gaps in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'doctype' is a 'DocType name (optional if workflow is provided)' and 'workflow' is a 'Workflow name (optional if doctype is provided),' clarifying the optionality and mutual exclusivity relationship. This compensates well for the schema's lack of descriptions, though it doesn't detail format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get combined information about a DocType or workflow, including schema metadata and usage guidance.' This specifies the verb ('Get'), resources ('DocType or workflow'), and what information is retrieved ('combined information... including schema metadata and usage guidance'). However, it doesn't explicitly differentiate from sibling tools like 'get_doctype_schema' or 'get_doctype_list', which appear to serve related but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the parameter documentation: 'doctype: DocType name (optional if workflow is provided)' and 'workflow: Workflow name (optional if doctype is provided).' This indicates the tool can be used with either parameter, but not necessarily when to choose this tool over alternatives like 'get_doctype_schema' or how it differs from them. No explicit when/when-not or alternative tool recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the core operation and filter syntax but lacks critical behavioral details: whether this is a read-only operation, what permissions are required, how results are returned (format, pagination), error handling, or performance characteristics. For a report-generation tool with 5 parameters, this leaves significant gaps in understanding how the tool behaves beyond basic parameter usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter documentation and filter syntax details. It's appropriately sized for a 5-parameter tool with custom syntax. Every sentence adds value, though the filter syntax section could be slightly more concise. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, custom filter syntax) and the presence of an output schema (which handles return values), the description covers the essential operational aspects. However, with no annotations and significant behavioral aspects unaddressed (permissions, error handling, performance), it's incomplete for safe and effective use. The parameter documentation is strong, but behavioral transparency gaps remain problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful semantic context for all 5 parameters beyond the 0% schema description coverage. It explains what each parameter represents (doctype, fields, filters, limit, order_by), provides default values, and gives detailed filter syntax with examples. This significantly compensates for the lack of schema descriptions, though it doesn't explain field format expectations or order_by syntax beyond naming the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a standard doctype report with filters and sorting.' It specifies the verb ('run'), resource ('doctype report'), and key capabilities (filters, sorting). However, it doesn't explicitly differentiate from sibling tools like 'run_query_report' or 'list_documents' beyond mentioning it's for 'standard doctype report' generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through parameter explanations and filter syntax, suggesting this tool is for generating filtered/sorted reports from doctypes. However, it lacks explicit guidance on when to use this versus alternatives like 'run_query_report', 'list_documents', or 'get_report_meta'. The filter syntax reference to other tools ('count_documents and list_documents') provides some indirect context but not clear when/when-not rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions what data is retrieved but doesn't disclose authentication requirements, rate limits, error conditions, or what format the financial statements are returned in. The description doesn't contradict any annotations since none exist.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter documentation is well-structured with clear formatting. While efficient, the parameter documentation could be slightly more concise by avoiding repetition of format details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial data retrieval with 5 parameters) and the presence of an output schema, the description is moderately complete. It explains what the tool does and documents parameters well, but lacks behavioral context about authentication, errors, and data freshness that would be important for financial reporting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all 5 parameters, including enum values for report_type and periodicity, format specifications for dates, and optionality indicators. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get') and resources ('standard financial reports'), explicitly listing the three report types (P&L, Balance Sheet, Cash Flow). It distinguishes itself from sibling tools by focusing on financial statements rather than general document operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it's clear this tool retrieves financial statements, there's no mention of when to choose it over other reporting tools like 'run_doctype_report' or 'list_reports' among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets a list' but doesn't disclose behavioral traits like whether it's read-only (implied but not stated), pagination details, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by concise parameter explanations. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is fairly complete. It covers purpose and parameters adequately, and the output schema means return values needn't be explained. However, it lacks behavioral context like safety or performance traits, which would be beneficial for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'module' filters by module name and 'limit' sets maximum returns with a default, which clarifies beyond the schema's basic types. However, it doesn't detail module name formats or limit constraints, slightly reducing the score from 5.
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 'Get' and resource 'list of available DocTypes', making the purpose evident. It distinguishes from siblings like get_doctype_schema (schema vs list) and list_documents (documents vs doctypes), though not explicitly named. However, it lacks explicit sibling differentiation, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally filtered by module', suggesting when to use the module parameter. However, it provides no explicit guidance on when to choose this tool over alternatives like get_doctype_schema or list_documents, nor any prerequisites or exclusions. This leaves usage context partially implied but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), which is straightforward, but doesn't add details like authentication requirements, rate limits, or what specific version information is returned. It's minimal but not misleading, fitting a baseline for a simple 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 a single, clear sentence that directly states the tool's function without any fluff or unnecessary elaboration. It's front-loaded and perfectly sized for its purpose, making it highly efficient and easy to 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?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is complete enough for basic understanding. It covers the core action and resource, and the output schema will handle return values, so gaps are minimal. However, it could benefit from slight elaboration on usage context to be fully comprehensive.
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 0 parameters, and the input schema has 100% description coverage, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant information, earning a high score for efficiency in this context.
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 ('Get') and resource ('version information for the Frappe MCP server'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ping' or 'get_frappe_usage_info', which might also provide server-related information, so it doesn't reach the highest score.
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 doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone. This lack of explicit guidance reduces its effectiveness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that filters use a custom syntax to bypass MCP validation issues, adding useful context about potential quirks. However, it doesn't cover other behavioral aspects like error handling, performance implications, or what the output contains, leaving gaps in transparency.
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 appropriately sized and front-loaded, starting with the core purpose followed by parameter details and examples. Every sentence adds value, such as explaining filter syntax and providing concrete examples. Minor improvements could include briefer phrasing, but overall it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, parameter usage, and filter syntax, which are crucial for invocation. Since an output schema exists, it doesn't need to explain return values, making the description adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining that 'filters' uses a custom string-based syntax with examples like 'status:Open', clarifying how to format this optional parameter. This compensates well for the low schema coverage, though it doesn't detail 'report_name' beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a Frappe query report with filters.' It specifies the verb 'execute' and the resource 'Frappe query report,' making the action and target explicit. However, it doesn't distinguish this tool from its sibling 'run_doctype_report,' which might serve a similar purpose, preventing 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 description implies usage by mentioning filters and providing syntax examples, suggesting it's for running reports with optional filtering. However, it lacks explicit guidance on when to use this tool versus alternatives like 'run_doctype_report' or other report-related tools, nor does it mention prerequisites or exclusions, leaving usage context partially unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that filters use 'custom syntax to bypass MCP validation issues' and provides syntax examples, which adds valuable behavioral context. However, it doesn't mention authentication requirements, rate limits, or what happens with invalid report names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter documentation and examples. Every sentence adds value, though the filter syntax explanation could be slightly more concise. It's appropriately sized for a tool with 2 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and an output schema present, the description provides good coverage of input semantics and behavioral context. The presence of an output schema means the description doesn't need to explain return values, making it reasonably complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: report_name ('Name of the report') and filters ('Filter string (optional)'), including detailed syntax examples and references to sibling tools. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('column structure for a specific report'), making the purpose explicit. It distinguishes from siblings like get_report_meta (metadata) and run_doctype_report (executing reports), providing specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve column structure for reports) and references sibling tools (count_documents, list_documents) for filter syntax consistency. However, it doesn't explicitly state when NOT to use it or name direct alternatives like get_report_meta.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it handles Frappe's cancellation workflow with validation and error handling, and provides clear feedback for corrective action. This covers key behavioral traits like validation, error handling, and feedback mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, behavioral context, parameters, and returns. It's appropriately sized but could be slightly more concise by integrating the Args/Returns into the flow rather than as separate labeled sections.
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 that there's an output schema (implied by 'Returns' section), the description doesn't need to detail return values. It adequately covers the tool's purpose, behavior, parameters, and general output for a document cancellation operation with no annotations, making it complete enough for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining that 'doctype' is the DocType name and 'name' is the document name (case-sensitive), which goes beyond the bare schema. However, it doesn't provide examples or format details for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel a document in Frappe') and the precise effect ('change docstatus from 1 to 2'), which distinguishes it from siblings like delete_document or submit_document. It uses a specific verb ('cancel') with a specific resource ('document in Frappe').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for document cancellation in Frappe's workflow but doesn't explicitly state when to use this tool versus alternatives like delete_document or amend_document. There's no guidance on prerequisites or exclusions, leaving usage context somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns data (not modifies) and describes the behavioral difference between Link and Select fields, but lacks details on permissions, rate limits, error handling, or pagination. It adds some context but is incomplete for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first, followed by clarifying details and parameter explanations. Every sentence adds value without redundancy, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose, usage context, and parameter semantics, but could improve by adding more behavioral details like error cases or performance hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's role: 'doctype' and 'fieldname' identify the target, and 'limit' controls result count with a default. However, it doesn't specify data formats or constraints beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get available options') and resources ('Link or Select field'), distinguishing it from siblings like get_doctype_schema or get_document. It explicitly differentiates between Link fields (returns documents) and Select fields (returns predefined options), providing precise scope.
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 context for when to use this tool (for Link or Select fields) but does not explicitly mention when not to use it or name alternatives. It implies usage by specifying the field types, though lacks explicit exclusions or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it performs a state change (submission), includes validation and error handling, and provides clear feedback. It doesn't mention authentication requirements, rate limits, or side effects on related records, but covers the core mutation behavior adequately for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, behavioral context, and parameter/return sections. Every sentence adds value, though the Args/Returns formatting is slightly verbose. It's appropriately sized for a 2-parameter mutation tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 2 parameters, and an output schema exists, the description provides good coverage: clear purpose, parameter semantics, and behavioral context about validation/error handling. The output schema handles return values, so the description appropriately focuses on what the tool does rather than return format. Minor gaps include lack of prerequisites and alternative tool guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear semantic meaning for both parameters: 'doctype: DocType name' and 'name: Document name (case-sensitive)', explaining what each represents and important details like case sensitivity. This adds significant value beyond the bare schema with no titles or descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Submit a document in Frappe') with precise technical detail ('change docstatus from 0 to 1'), distinguishing it from sibling tools like create_document, update_document, or cancel_document. It explicitly identifies the resource being acted upon (documents in Frappe) and the state transition involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'change docstatus from 0 to 1' and mentions validation/error handling, suggesting this is for finalizing draft documents. However, it doesn't explicitly state when to use this versus alternatives like update_document or cancel_document, nor does it mention prerequisites (e.g., document must exist and be in draft status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: creates a new document with amended naming convention, copies field values, establishes linkage, and requires the original document to be cancelled. However, it doesn't mention permission requirements, rate limits, or what happens to the original cancelled document.
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 efficiently structured with a clear purpose statement, detailed mechanism explanation, parameter semantics, and return value information. Every sentence adds value with no wasted words, and it's appropriately front-loaded with the core functionality.
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 2-parameter mutation tool with no annotations but with output schema, the description provides good coverage: clear purpose, usage context, parameter semantics, and return value information. It could be more complete by mentioning authentication requirements or error scenarios beyond validation errors, but the output schema likely covers return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'doctype' as DocType name and 'name' as the case-sensitive document name that must be a cancelled document. This adds crucial semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('amend a document'), the resource ('document in Frappe'), and the precise mechanism ('create a new amended version of a cancelled document'). It distinguishes from siblings like 'create_document' or 'update_document' by specifying this is for amending cancelled documents with version naming and linkage.
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 states when to use this tool: for amending cancelled documents. It implies alternatives by mentioning the 'amended_from' field linkage, but doesn't explicitly name when not to use it or list specific sibling alternatives like 'create_document' for non-cancelled documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it's a read operation (implied by 'List'), supports filtering with custom syntax, and includes examples of usage. However, it doesn't mention potential side effects like rate limits or authentication needs, though the examples suggest safe querying.
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 appropriately sized and front-loaded, starting with the tool's purpose. It uses sections like 'Args:' and 'Filter Syntax:' for structure, but includes extensive operator lists and examples that, while helpful, could be streamlined. Every sentence adds value, but it's slightly verbose.
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 complexity (5 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which handles return values), the description is complete. It covers all parameters, provides syntax details, examples, and usage context, making it sufficient for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the input schema by detailing each parameter's purpose, optionality, and examples (e.g., 'doctype: DocType name', 'filters: Filter string (optional)'). It also explains the custom filter syntax and operators, which are not covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List documents from Frappe with filters.' It specifies the verb ('List'), resource ('documents from Frappe'), and scope ('with filters'), distinguishing it from siblings like get_document (single document) or count_documents (aggregate).
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 through examples (e.g., filtering unreconciled transactions or open tasks) but does not explicitly state when to use this tool versus alternatives like get_document or count_documents. It provides context for filtering but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by explaining it uses Frappe's native count functionality via REST API with a custom filter language, addresses filtering limitations, and provides detailed syntax and examples. It does not cover aspects like rate limits or authentication needs, but given the lack of annotations, it adds substantial context beyond basic functionality.
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 well-structured with clear sections for purpose, args, filter syntax, operators, and examples, but it is lengthy with redundant examples that could be condensed. While informative, some sentences could be more efficient, such as combining similar example cases, making it less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (custom filter language, 2 parameters with 0% schema coverage) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, parameters, syntax, and examples thoroughly, providing all necessary context for an AI agent to understand and invoke the tool correctly without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate, and it does so comprehensively. It explains both parameters: 'doctype' as the DocType name and 'filters' as an optional string with custom syntax. It provides detailed filter syntax, supported operators, and multiple examples, adding significant meaning beyond what the bare input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Count documents in Frappe with optional filters,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'list_documents' by focusing on counting rather than listing, and mentions addressing filtering limitations in previous implementations, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage through extensive examples and filter syntax, showing when to use it for counting with various filter types. However, it does not explicitly state when to use this tool versus alternatives like 'list_documents' or 'get_document,' nor does it mention any exclusions or prerequisites, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns (schema details) but lacks behavioral traits like error handling, permissions required, or performance characteristics. It doesn't contradict annotations, but misses key operational 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?
Three sentences total, each earning its place: first states purpose, second provides usage guidance, third documents the parameter. No wasted words, well-structured with clear sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description is reasonably complete for a read-only schema tool. It covers purpose, usage, and parameter, but could benefit from more behavioral context like authentication or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the single parameter 'doctype' as 'DocType name' in the Args section. This adds meaning beyond the bare schema, though it could specify format or examples. With 0 parameters documented in schema, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'complete schema for a DocType', specifying it includes field definitions, validations, and linked DocTypes. It distinguishes from siblings like get_doctype_list (which lists DocTypes) and get_document (which retrieves document instances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'to understand the structure of a DocType before creating or updating documents.' This provides clear context for usage versus alternatives like create_document or update_document, which require schema knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![frappe-mcp-server MCP server](https://glama.ai/mcp/servers/appliedrelevance/frappe-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/appliedrelevance/frappe-mcp-server)

Score Badge

Copy to your README.md:

[![frappe-mcp-server MCP server](https://glama.ai/mcp/servers/appliedrelevance/frappe-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/appliedrelevance/frappe-mcp-server)

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/appliedrelevance/frappe-mcp-server'

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