smart-npv-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools target distinct resources and actions (clients, payments, simulations, contacts). A few document-related tools (upload_document, add_documentation, balance_report_parsing, approval_in_principle_scanning) could cause confusion, but descriptions clarify their specific purposes.
Naming Consistency3/5
The set uses a mix of get_/list_/check_ and noun-based names (balance_report_parsing), plus add_/update_/create_/delete_. While readable, there is no single consistent verb_noun pattern (e.g., list_clients vs get_banks, check_bank_availability vs get_banks).
Tool Count2/5
32 tools is heavy, exceeding the typical well-scoped range for an MCP server. The server covers many subdomains, but the count feels bloated and detracts from coherence.
Completeness3/5
Core client lifecycle is covered (CRUD, status, payments, simulations), but there are gaps: no delete_source, no contact update/delete, no payment delete, and some endpoints are unverified. These gaps might force workarounds but do not break the main workflows.
Average 3.5/5 across 32 of 32 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on July 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT 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?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no additional behavioral context. It does not describe what scanning does, any side effects, output format, or whether the document is stored or processed externally.
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 single-sentence description is brief and to the point, but it is under-specified. It does not include essential details about the tool's behavior or parameters, making it concise yet insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description leaves major gaps: the agent does not know what the scanning returns, what side effects occur, or what bank_id means. The tool is simple but these omissions prevent confident 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?
The schema describes file_path but not bank_id, and the description does not clarify what bank_id refers to. With only 50% schema coverage, the description should compensate but instead provides no parameter-level detail.
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 ('Upload') and the specific resource ('a bank approval-in-principle document'). It distinguishes from generic tools like upload_document by specifying the document type, though the term 'scanning' is somewhat vague about the intended processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as upload_document or balance_report_parsing is provided. The only hint is '[Premium]' which implies a licensing constraint, but no explicit use cases or exclusions are mentioned.
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 already indicate this is a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds no additional behavioral context, such as whether the client must exist, whether the record is appended or replaces existing documentation, or any rate limits.
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 with no wasted words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a write operation with no output schema and a permissive 'params' object (additionalProperties: {}), the description should explain what constitutes a documentation record, how it relates to the client, and what format 'params' should take. The one-sentence description is inadequate for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers only the 'params' object (50% coverage), leaving 'uuid' undocumented. The description does not explain what 'uuid' refers to or what fields 'params' should contain, and the schema's reference to 'Smart NPV' API is vague. The description adds no meaningful parameter information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a documentation record to a client'), using a specific verb and object. However, it does not explicitly differentiate from sibling tools like 'upload_document', which could be confused for adding a document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'upload_document' or 'get_client_documentations'. No context, prerequisites, or exclusions are mentioned.
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 (readOnlyHint=false, destructiveHint=false) already indicate this is a mutating but non-destructive operation. The description adds no additional behavioral context, such as whether the simulation appends, overwrites, or requires the client to exist. It does not contradict annotations, but also does not go beyond them.
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, clear sentence with no wasted words. It is concise and front-loaded. However, it is too short to cover the complexity of the tool, but for conciseness alone it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema with 6 parameters, nested objects, and no output schema. The description is a single sentence that does not explain the input structure, return value, or any behavioral details. It is grossly incomplete for an agent to invoke 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%, and the description does not explain any of the six parameters. Terms like 'mix', 'current_mix', and 'current_mix_toolbar' are left undefined, leaving the agent with no semantic understanding of the 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 ('Add') and resource ('a mortgage simulation (mix)') with a target ('a client'). This cleanly distinguishes the tool from siblings like get_simulation, delete_simulation, and calc_simulation.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites, preconditions, or situations where another tool would be more appropriate.
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 already indicate a non-read-only, non-destructive, open-world operation. The description adds no further behavioral context (e.g., side effects on the file system, data storage, or return behavior), leaving the agent uncertain about what happens after the upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the '[Premium]' flag, consisting of a single sentence with no wasted words. However, it under-specifies critical details, which prevents a higher 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?
There is no output schema and the description does not explain what the tool returns after parsing, nor does it provide prerequisites or postconditions. Given the tool's simplicity, the description is incomplete for an agent to invoke it correctly without significant assumptions.
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 only 50% schema description coverage, the tool description should compensate for the undocumented bank_id parameter, but it does not. file_path is described in the schema, but the description adds no meaning to either parameter, especially failing to explain what bank_id refers to.
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 ('upload') and the resource ('bank balance report PDF'), making the tool's core purpose obvious. It is specific enough to be distinguished from general upload_document or approval_in_principle_scanning, though it could more explicitly describe the parsing output.
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 siblings, nor are prerequisites like obtaining bank_id from get_banks mentioned. The description merely states the action without contextualizing the appropriate scenario.
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 already indicate readOnlyHint=false and destructiveHint=false, so the description adds little behavioral context. It doesn't disclose side effects, required permissions, error behavior, or the meaning of openWorldHint. The sentence about params is more about input structure than behavioral traits.
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 extremely concise: two short sentences totaling 9 words. The first sentence states the action; the second hints at the input structure. While every sentence earns its place, the second is largely redundant with the schema, reducing its value slightly.
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 has an opaque params object with no field documentation, no output schema, and no explanation of required fields or expected behavior. The description and annotations provide minimal context, leaving the agent unable to know how to construct a valid request without external API documentation. This is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'params' parameter has a schema description ('Object of fields passed to Smart NPV as documented in its API.'), giving 100% coverage. The description's 'Fields go inside params' reinforces this schema but doesn't add new semantics, such as which specific fields are allowed. Baseline 3 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 states 'Add a contact,' which is a clear verb+resource action. It distinguishes from sibling tools like get_contacts and add_contact_group by the resource type, but it doesn't explicitly call out the distinction. The added sentence about params is more about parameter handling than 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?
The description gives no guidance on when to use this tool versus alternatives. It only mentions 'Fields go inside params,' which is a parameter-structuring note, not a usage context. There are no exclusions, prerequisites, or alternative tool references.
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?
The description adds only the note that fields go inside the 'params' object, which is also evident from the schema. Annotations indicate this is a write operation, but the description doesn't disclose additional behavioral traits such as required fields, response format, or side effects beyond the basic add operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, comprising two short sentences. The first sentence communicates the purpose, while the second reiterates the parameter structure already evident from the schema. It is not overly verbose, but the second sentence adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the openWorldHint allowing arbitrary fields, the description does not explain what the tool returns, what fields are commonly used, or any constraints. This leaves significant gaps for an agent trying to invoke it effectively.
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 input schema has a single 'params' object parameter with high schema coverage (100%). The description reinforces that fields go inside params but adds no detailed information about the fields themselves. Since schema coverage is high, a baseline of 3 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 adds a contact group, using the verb 'add' and the resource 'contact group'. This distinguishes it from sibling tools like add_contact and add_source. However, it doesn't elaborate on what a contact group is or any specific scope.
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. It doesn't mention prerequisites, related tools, or scenarios. The description simply states the action without any contextual direction.
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 already indicate readOnlyHint=false and destructiveHint=false, and the description's 'Add or set' is consistent with that. However, it does not disclose any additional behavioral traits like side effects, required permissions, or reversibility. The openWorldHint=true annotation is not reflected in the description, leaving the tool's behavior underspecified.
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, short sentence that is easy to parse and free of fluff. It earns its place by stating the core action, though it could be slightly expanded to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an open-world parameter object and no output schema, this description is incomplete. It does not explain what fields are expected, how success is reported, or any side effects. Annotations and schema cover some basics, but the description leaves significant gaps for an agent to select and invoke the tool confidently.
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 input schema has 100% description coverage for the 'params' property, describing it as an object of fields passed to Smart NPV. The tool description's 'Fields go inside params' is redundant but consistent. With high schema coverage, the description adds minimal new meaning beyond what the schema already provides.
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 action ('Add or set') and target ('a status on a client'), using a specific verb+resource structure. It distinguishes from read-only siblings like get_client_status and get_status_list, though it doesn't explicitly differentiate from other update tools.
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 such as update_client or get_client_status. The description only states what it does, not the conditions or contexts that warrant its 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 indicate non-read-only, non-destructive, and open-world behavior. The description adds a relevant caution that the endpoint path is unverified and recommends confirmation with Smart NPV, which is useful behavioral context beyond annotations. However, it doesn't cover side effects, authorization, or error behavior.
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 action. The second sentence about fields is somewhat redundant, but the third sentence adds an important caveat. Overall, it is concise with minimal waste.
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 create operation, the description lacks essential context: what fields are needed, what constitutes a valid product, expected response, or effects. It has no output schema, and the params object is open-ended. The note about vendor docs is helpful but doesn't complete the picture.
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 defines a single 'params' parameter described as 'Object of fields passed to Smart NPV as documented in its API,' which is vague. The description only says 'Fields go inside params,' adding no meaning. The internal structure of the params object is undocumented, so the description fails to compensate for the schema's lack of field-level detail.
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 product' with a specific verb and resource. It distinguishes itself from sibling tools, as no other tool targets product creation. However, it doesn't elaborate on what a 'product' represents in this domain, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, or when not to use it. The note about confirming with Smart NPV is a caution but not usage context. The description lacks prerequisites, use cases, or 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds little context. It does not explain side effects (e.g., whether existing files are overwritten), required permissions, or what the tool returns after upload. This is a significant gap for a write operation with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and includes relevant file format details. Every word contributes meaning, with no fluff or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description is thin. It does not explain what happens after a successful upload, whether the file is associated with the client's documentation, how the response is returned, or any constraints (e.g., file size). Given the complexity and the presence of related sibling tools, this description is inadequate for an agent to fully anticipate the tool's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with descriptions for file_name and file_path but none for uuid. The tool description mentions 'to a client', which hints that uuid is a client identifier, but this is not explicit. The description adds some context beyond the schema but does not fully compensate for the missing uuid parameter 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 states the action ('Upload'), the resource ('document file'), accepted formats, and target ('to a client'). It is specific and goes beyond the title, but does not explicitly distinguish itself from the sibling tool 'add_documentation', which could be confused for a similar action.
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 use this tool versus alternatives. The description only states what the tool does, with no mention of prerequisites, exclusions, or when to prefer a different tool (e.g., 'add_documentation' for metadata-only 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?
Annotations already declare readOnlyHint=false and destructiveHint=false, which align with the description's implication of a write operation. However, the description adds no behavioral context beyond that, such as consequences of recording a payment, whether the client must exist, or implications of openWorldHint=true. The reference to Smart NPV is only in the schema, not the description.
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 states the action and object immediately, with a useful parenthetical example. It has no fluff and every word 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?
Given there is no output schema and the tool has a complex nested 'params' object, the description is quite inadequate. It does not explain return values, required payment fields, or any caveats (e.g., client must exist, no duplicate payments). The agent is left without enough context to correctly invoke this tool in many scenarios.
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 provides descriptions for only one of two parameters ('params' as 'Object of fields passed to Smart NPV'), and 'uuid' has no description. The tool description does not clarify either parameter, nor does it mention what payment fields are expected, leaving significant ambiguity for the agent.
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 'Record' and clearly identifies the resource ('a payment on a client'), with examples 'retainer / installment' that add clarity. It distinguishes itself from sibling tools like get_payments and update_payment by implying a creation operation.
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 alternatives, nor any prerequisites or exclusions. The examples hint at use cases but do not mention update_payment or other options, leaving the agent without clear decision 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?
Annotations already provide destructiveHint=true and readOnlyHint=false, and the description adds no extra behavioral context. It does not explain side effects, permissions required, reversibility, or what happens on update (e.g., whether old values are replaced or merged).
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, focused sentence: 'Update an existing payment by payment_uuid.' It is concise, front-loaded, and contains no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature (destructiveHint=true) and the nested 'params' object, the description is too sparse. It does not indicate what fields can be updated, how the params object should be structured, or what the response will look like. Since there is no output schema, this is a significant gap.
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 description mentions 'by payment_uuid' which clarifies the role of that parameter, but it provides no additional meaning for the 'params' object. With schema description coverage at only 50% and the params object being opaque (additionalProperties with no field details), the description does not compensate enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing payment'), and identifies the unique identifier 'payment_uuid'. This distinguishes it from sibling tools like add_payment (create) and get_payments (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 guidance is given on when to use this tool versus alternatives. It does not mention that add_payment is for creation, get_payments for listing, or any exclusions or prerequisites. The implied usage is obvious but 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 indicate a write operation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds the '[Premium]' requirement and the instruction that fields go inside 'params', which is useful but does not disclose side effects, return values, or authentication needs beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short, purposeful sentences. It front-loads the action and includes only necessary details, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with an opaque 'params' structure and no output schema. The description does not explain how to determine success, what fields are typically expected, or how it relates to sibling tools like 'get_sources' and 'update_source', leaving major gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'params', described as 'Object of fields passed to Smart NPV as documented in its API'. The description merely repeats 'Fields go inside params', adding no new meaning or detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('main lead source'), which distinguishes it from the sibling 'update_source'. However, the term 'main' is ambiguous, and no explicit differentiation from siblings is provided beyond the verb.
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 use this tool versus alternatives. It does not mention 'update_source' for modifications or any conditions/prerequisites for adding a source, leaving the agent without clear selection criteria.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds little beyond 'for a client' and fails to disclose behavior when simulation_uuid is omitted, or whether a single or multiple results are returned.
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 of seven words. Every word earns its place with no redundancy or filler.
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 no output schema, the description should clarify return values or behavior. The ambiguity around the optional simulation_uuid parameter and the lack of explanation about the response make the description inadequate for a fetch operation with an optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with simulation_uuid documented. The description adds context that the operation is 'for a client', which hints that uuid is a client identifier. However, it does not explicitly map uuid to a client or clarify the optional parameter behavior further.
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 'Fetch' with a clear resource ('specific simulation') and context ('for a client'). This distinguishes it from sibling tools like get_client_simulations, which likely lists simulations for a client.
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 such as get_client_simulations. The description lacks any exclusions or prerequisites, leaving the agent to infer usage 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 indicate readOnlyHint=false and destructiveHint=false, giving some safety context. The description adds minimal behavioral context by flagging '[Premium]' (suggesting access control) and describing the engine, but it does not disclose potential side effects, output format, or any rate limits—leaving the agent with incomplete behavioral expectations.
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 sentence that front-loads the premium tag and clearly states the action and target. It is economical with words and avoids fluff, though it could be slightly more structured to separate the premium requirement from the functional description.
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 description is thin for a computation tool that lacks an output schema. It does not explain what the tool returns or how the result is presented (e.g., stored, returned directly). With a complex nested request object and openWorldHint=true, the description should at least mention the response shape or outcome, but it remains silent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter 'request', already labeling it as 'The calculation request payload'. The tool description repeats this concept ('request payload') without adding syntactic or format details, so it provides no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Run') and the resource ('reform/recalculation engine'), with the input ('request payload'). This distinguishes it from sibling tools like get_simulation (retrieve) and add_simulation (create), as it emphasizes computation rather than storage or retrieval.
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 does not provide explicit guidance on when to use this tool versus alternatives. It lacks context about prerequisites, exclusions, or alternative tools such as add_simulation or get_simulation, leaving the agent to infer usage solely from the tool's name and purpose.
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 and destructiveHint=false, covering the safety profile. The description adds context about the balance-report service and the 'Premium' label hinting at access constraints, but it does not disclose return format, error behavior, or rate limits. Thus it adds some value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key verb and resource. The '[Premium]' tag adds a small extra element but does not detract from readability. It is concise, though perhaps too sparse to be fully self-contained.
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 no output schema, the description does not explain what the tool returns (e.g., a boolean, an error message) or how to handle unknown bank_id values. It also lacks parameter details and usage scenarios, making it incomplete for an agent to reliably invoke the tool without additional assumptions.
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 one parameter, bank_id, with 0% description coverage. The description only refers to 'a given bank', giving minimal interpretation of bank_id but no format, example, or relationship to get_banks. This does not sufficiently compensate for the missing schema 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 explicitly states the action: checking whether the balance-report service supports a given bank. It uses a specific verb 'check' and identifies the resource and context ('balance-report service'), which clearly distinguishes it from sibling tools like get_banks.
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?
No explicit when-to-use or alternative guidance is provided, but the purpose implies the scenario (verifying bank support before using balance reports). The description does not name alternative tools or exclusions, so guidance remains 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the domain context 'mortgage simulations' but does not disclose any additional behavioral traits such as pagination, ordering, or error handling. It is consistent with annotations, neither contradicting nor adding significant value.
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 redundant words. It conveys the purpose effectively without unnecessary elaboration.
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 simplicity of the tool (one parameter, no output schema), the description provides the basic purpose but lacks information about the return format or any details about what the list contains (e.g., simulation fields, statuses). The presence of annotations reduces the burden, but the description is still minimal for an agent to fully understand expected inputs and outputs.
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 one parameter 'uuid' with no description (0% coverage). The description mentions 'a client's' which hints that the uuid identifies the client, but it does not explicitly state that the uuid parameter is the client's UUID or how it should be formatted. The description fails to compensate for the lack of schema documentation.
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 'List' and identifies the resource as 'a client's mortgage simulations.' This clearly differentiates from sibling tools like get_simulation (singular) and calc_simulation, indicating this retrieves the collection of simulations for a specific client.
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 alternatives. The description implies it is for listing simulations but does not mention get_simulation for fetching a single simulation or any preconditions like having a client UUID. The usage context is only implicit.
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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which already cover the safety profile. The description adds 'reference list' which suggests a static, non-exhaustive enumeration, but it doesn't disclose potential quirks like pagination, sorting, or whether the list is authoritative. For such a simple tool, this is acceptable, but it doesn't go 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, concise sentence that gets straight to the point. It is front-loaded, with no wasted words or redundancy. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description gives the essential information: it returns a reference list of cities. It could be more explicit about the return format or usage context, but given the simplicity, the description is largely complete. Minor gaps are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description's phrase 'reference list of cities' correctly implies no inputs are required. There is no parameter documentation needed because there are none.
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 'Reference list of cities' clearly identifies the resource (cities) and the nature of the tool (a reference list). Combined with the title 'Get cities', the purpose is unambiguous and distinguishable from sibling tools, none of which relate to cities. A slight improvement would be an explicit 'Returns...' phrasing, but it's clear enough.
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 use this tool or when to prefer an alternative. The description is a single statement with no context about typical use cases, prerequisites, or exclusions. This leaves the agent without explicit direction on 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context (e.g., return format, pagination, or required permissions), but there is no contradiction.
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 of 10 words, front-loaded with the core action. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool with strong annotations, the description is mostly adequate. It tells what the tool does and its key use case, but it could mention the output structure (e.g., what 'status/stage' looks like) or explicitly confirm the uuid parameter. Still, the low complexity keeps this from being a major gap.
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 0% description coverage, so the description must compensate. It implies that the 'uuid' parameter identifies the client ('of a client'), but it does not explicitly state that the uuid is the client identifier, nor does it clarify any expected format or additional constraints.
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 ('Get') and clearly identifies the resource ('current status/stage of a client'). It distinguishes from sibling tools like get_client (full client details) and get_status_list (list of statuses). The added context 'Key for pipeline monitoring' reinforces its 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?
The phrase 'Key for pipeline monitoring' provides a general use case but does not explicitly state when to use this tool instead of alternatives such as get_client or get_status_list. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds a '[Premium]' qualifier that hints at access restrictions and the word 'main' to limit scope, but it does not disclose further behavioral details such as pagination, sorting, or output format.
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 short sentence: '[Premium] List main lead sources (networks).' It is front-loaded with the action, uses minimal words, and contains 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?
For a zero-parameter, read-only list tool with no output schema, the description is mostly sufficient. However, it lacks a description of the return structure and does not clarify what qualifies as a 'main' lead source or reference related sibling tools for broader 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 tool has zero parameters and the input schema is empty, so the schema fully covers parameter semantics. No additional explanation is needed, aligning with the baseline of 4 for zero-parameter tools.
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 starts with a clear verb 'List' and identifies the resource as 'main lead sources (networks)', which is specific and distinguishes it from tools targeting other resources (e.g., get_banks, get_cities). It does not explicitly contrast with sibling tools like add_source/update_source, but the purpose is clear.
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 that it complements add_source/update_source or how it differs from other list-type tools. No exclusions or preferred contexts are 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?
The description aligns with annotations (readOnlyHint=false, destructiveHint=true) by indicating a write operation ('Update'). It adds minimal behavioral context beyond that, such as the 'main' scope and '[Premium]' tag, but does not disclose effects, irreversibility, or required permissions. Since annotations already provide the safety profile, this meets expectations without adding richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the primary action and resource in the first sentence. The second sentence offers essential structural guidance about params. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimally adequate but leaves gaps. It does not clarify what 'main' signifies, what fields are accepted (though schema references API docs), or any return behavior. The annotations cover safety, but the lack of operational detail makes it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for the single 'params' parameter, describing it as an object of fields per API documentation. The description adds 'Fields go inside params,' which merely restates the parameter structure without explaining valid field names, formats, or examples. With high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the target resource ('a main lead source'), which is distinct from sibling tools like add_source and get_sources. It uses a specific verb+resource structure that leaves no ambiguity about what the tool does.
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 such as add_source or update_client. It does not mention prerequisites, exclusion criteria, or scenarios where another tool would be more appropriate. The '[Premium]' tag hints at access requirements but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only, non-destructive behavior is covered. The description adds little beyond the purpose; it does not disclose additional traits like pagination, ordering, or required context beyond the client identifier. 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, compact sentence that communicates the core action clearly. It is front-loaded and avoids any unnecessary words or repetition.
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 one parameter and no output schema, the description gives the essential purpose but does not mention return format, pagination, or any filtering behavior. The openWorldHint annotation hints at complete listing, but the description alone leaves these aspects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'uuid' parameter with no description, and schema coverage is 0%. The description compensates by implying the uuid identifies the client whose payments are listed, but it does not explicitly state that uuid is the client's unique identifier. This adds some meaning but leaves room for ambiguity about the parameter's exact role.
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 ('List') and resource ('a client's payments'), clearly indicating the tool retrieves payment records for a client. It distinguishes itself from sibling payment tools like add_payment and update_payment by focusing on read-only listing.
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 (when you need a client's payments) but does not explicitly state when to prefer this over alternatives like get_client_simulations or list_clients. No exclusions or alternative tool references are provided, making the guidance only implicit.
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 convey read-only safety (readOnlyHint: true, destructiveHint: false). The description adds the '[Premium]' access requirement, which is a behavioral trait beyond annotations. It does not contradict the annotations and offers limited additional context, so a mid-range score is appropriate.
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 the '[Premium]' tag and clear wording. Every word contributes meaning, with no filler or redundancy. It is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with annotations, the description sufficiently conveys the tool's scope and behavior. While it does not mention return value format or pagination, those are not critical for a basic list operation, and no output schema exists to warrant further explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0 params is 4. The description does not need to explain parameter meanings since there are none. No additional semantic value is required beyond what is already implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('banks') and scoping ('supported by the balance-report service'). This distinguishes it from siblings like check_bank_availability or get_cities, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only implies listing banks, and the '[Premium]' tag hints at access restrictions but does not clarify selection criteria or conditions. No alternative tools are mentioned or ruled 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds semantic examples but no additional behavioral details such as scope, pagination, or data completeness. It does not contradict 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 one sentence, concise, and front-loaded with the action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list operation with clear annotations, the description provides enough to understand the tool's function. However, it lacks any mention of return format or ordering, and does not differentiate usage from sibling tools beyond the name.
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 schema coverage is vacuously 100%. Per baseline for parameterless tools, the description does not need to provide parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'contacts', with examples ('bankers, appraisers') that clarify the scope. It distinguishes from sibling tools like get_contact_groups and add_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when to prefer this over related tools like get_contact_groups or add_contact, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds no additional behavioral details, such as whether the list includes both statuses and stages, or if any ordering or filtering applies. This is acceptable given the simple nature of the tool and the presence of safety annotations, but no extra transparency is provided.
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 is front-loaded with the verb and resource. There is no extraneous information, making it 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?
For a simple listing tool with no parameters and no output schema, the description adequately conveys the tool's purpose and scope. It does not describe the exact return format, but that is somewhat implicit for a listing operation. The annotations cover the safety profile, so the description is complete enough for this low-complexity 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 zero parameters and the schema is empty, so there are no parameter semantics to clarify. The description's mention of 'status/stage definitions' refers to the resource being listed rather than a parameter, which is fine. The baseline for zero parameters is 4, and no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and a specific resource ('status/stage definitions available in the account'). It distinguishes itself from sibling tools like get_client_status (which fetches a single client's status) and add_status (which creates a new status).
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 simply states what the tool does without any contextual hints. For a tool that could be confused with get_client_status or add_status, some usage direction would be helpful, but none is given.
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 destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable transparency by disclosing that the API path is unverified and may not work as expected, which is not captured in the annotations. This is a meaningful risk disclosure beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the action front-loaded. The second sentence is a necessary and informative caveat, and there is no redundant or extraneous wording. It is concise without sacrificing important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete operation with destructive annotations, the description adequately covers the action and the key reliability caveat. It does not describe return values, but no output schema exists. The openWorldHint suggests potential unknown side effects, which the caveat partially addresses, making this complete enough for the tool's complexity.
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 input schema provides 100% coverage for the sole parameter (uuid), including a description. The tool description adds no additional parameter semantics, relying on the schema's baseline. The schema description is somewhat ambiguous ('or client uuid + simulation ref in params'), but since coverage is complete, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Delete a simulation,' a clear and specific verb+resource statement. The tool name and title reinforce this, and it distinguishes well from sibling tools like delete_client. The caveat about the unverified path does not obscure the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a cautionary usage guideline: 'confirm with Smart NPV before relying on it,' which tells the agent to verify before use. However, it does not explicitly contrast with alternative deletion or simulation tools, nor does it state when deletion is appropriate. The intended usage is largely implied by the tool name.
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 and destructiveHint=false. The description adds the clarifying scope that documents are 'uploaded', which is useful. It doesn't disclose return format or pagination, but with read-only annotations the bar is lower and no 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?
One sentence, front-loaded with the verb 'List', zero filler. The parenthetical clarifier earns its place and the description is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only list tool, the description plus annotations fully cover the main context. No output schema exists, but the return type (list of documents) is implied. Minor missing details like pagination or ordering are not critical for this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'uuid' with description 'Client uuid'. The tool description does not add additional param semantics, but the baseline of 3 applies since schema already documents it adequately.
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 'List the documents attached to a client (what has been uploaded)' clearly specifies the verb (List), the resource (documents attached to a client), and the scope (uploaded), distinguishing it from siblings like upload_document and add_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to retrieve the list of uploaded documents for a given client. It doesn't explicitly mention alternatives or exclusions, but the contrast with upload_document/add_documentation is evident from sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the verb 'List', such as pagination, ordering, or filtering behavior. It doesn't contradict annotations, but also doesn't enrich them.
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: 'List contact groups.' Every word earns its place, with zero redundancy. Perfectly concise for a zero-parameter list operation.
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 low complexity (no params, no output schema, strong annotations), the description is minimally sufficient. It states the action and resource. It doesn't detail return format, but the simplicity of the tool makes that acceptable. Slightly more context (e.g., 'returns all groups') could push it higher, but for a list with no knobs, this is complete enough.
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 100% schema coverage, so the baseline is 4. The description adds no parameter details, but none are needed. The empty schema fully documents that there are no 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 'List contact groups' uses a specific verb ('List') and identifies the resource ('contact groups') clearly. It distinguishes from siblings like get_contacts (contacts vs groups) and add_contact_group (write vs read).
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 purpose is self-evident: use when you need to fetch all contact groups. However, there is no explicit guidance on when to prefer this over get_contacts or add_contact_group, and no exclusions or alternatives are named. The usage is implied but not elaborated.
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 this as read-only and non-destructive, and the description aligns with that. It adds valuable context about the return structure ('full record under responseClientFields', listing key fields) and points to documentation. The description does not contradict 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 two sentences, front-loaded with the action and key information. The pointer to docs/client-fields.md is a helpful addition without repeating schema details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values. It does so by listing the major fields ('borrowers _1/_2, employment, income, contract amounts, last note') and naming the response container. It could be more detailed about the exact structure, but for a read-only lookup with 3 simple parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage only at 33%, the description must compensate for the undocumented uuid and phone parameters. It does clarify that lookup can be by uuid or phone, but it does not fully explain the relationship between 'type' and the provided field, nor does it specify which parameter is required (required: 0). This is a partial compensation, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('a single client') with explicit lookup keys ('by uuid or phone'), clearly distinguishing it from siblings like list_clients or get_client_status. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need a single client record and know either the uuid or phone. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5. The context is clear enough for an agent to select this over list_clients.
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 context about the param structure (fields inside params, using documented field names) beyond the annotations. Annotations already indicate it is destructive (destructiveHint: true), and the description aligns with that. It does not contradict 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 two sentences, front-loaded with the purpose and then providing essential param guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with nested params and no output schema, the description covers the key aspects: target identification (uuid), param structure, and field naming convention. It lacks explicit mention of return values or side effects, but annotations cover destructive behavior and the openWorldHint adds context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; uuid lacks description but params has one. The tool description adds the key detail that params uses '_1/_2' field names from docs, partially compensating for the missing schema descriptions. However, it does not elaborate on all possible fields or the uuid parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing client by uuid, using a specific verb and resource that distinguishes it from sibling tools like create_client, delete_client, and get_client. The scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for modifying an existing client, which differentiates it from creating or deleting. It also provides guidance on how to structure params with '_1/_2' borrower field names, but it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, but the description adds the key detail that deletion is 'Irreversible,' which goes beyond the generic destructive hint. This communicates a permanent, non-recoverable action. No contradictions 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 two short sentences: the first states the action and method, the second warns of irreversibility. Every word earns its place, with no redundant phrasing. Excellent front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and annotations covering destructive behavior, the description sufficiently covers what, how, and consequence. No output schema exists, so return values are not expected to be described. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, uuid, with no description (0% coverage). The description's 'by uuid' clarifies that the parameter is the identifier of the client to delete, which adds meaning beyond the schema. However, it does not specify the expected format or how to obtain the uuid, leaving some ambiguity for a 0% coverage case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('client'), and the method ('by uuid'). This distinguishes it from sibling tools like get_client, create_client, and update_client, each of which has a different operation. The irreversibility warning reinforces the destructive nature, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: delete a client when you need to permanently remove it. It does not explicitly list alternatives or exclusions, but the 'Irreversible' warning cautions against casual use. For a delete tool, the context is clear enough that a 4 is appropriate.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses that the unfiltered list can be very large, explains the client structure with up to two borrowers and field suffixes, and locates rows under 'responseClients'. This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then performance guidance, then structural details. Every sentence earns its place, and the reference to docs keeps it from becoming bloated.
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 list tool with no output schema, the description covers response location, field naming conventions, and points to full field docs. Minor gaps like explaining 'reference' and 'range_type' are acceptable given the doc link and overall guidance.
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 documentation covers 86% of parameters, so the baseline is 3. The description adds the advisability of a small limit but does not clarify the meaning of 'reference' or the exact semantics of 'range_type'. No substantial additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List clients / leads' and specifies paging and date range. It distinguishes from sibling get_client by using the plural 'list' and covering both clients and leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Prefer a small limit (e.g. 25)' due to large unfiltered lists. No explicit alternatives are named, but the context clearly implies listing vs. single-client retrieval.
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 this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the important detail that fields must use the _1/_2 borrower naming convention from docs/client-fields.md, which is not visible in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the primary purpose front-loaded. Every sentence adds value, referencing the field naming convention without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an open-world create tool with a single flexible params object and no output schema, the description covers the main complexity: how to structure field names. It gives examples and points to a doc file, making it sufficient for an agent to select and invoke 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 only describes 'params' as an object of fields passed to Smart NPV. The description adds specific examples (firstname_1, phone_1, income_1) and directs to documentation, significantly enriching the meaning for correct 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 clearly states 'Create a new client' with a specific verb and resource, distinguishing it from sibling tools like update_client and delete_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (creating a new client) but lacks explicit exclusion or alternative comparisons. It does provide guidance on structuring fields inside params, which is helpful for invocation.
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:

[![smart-npv-mcp MCP server](https://glama.ai/mcp/servers/binyaminboukaya/smart-npv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/binyaminboukaya/smart-npv-mcp)

Score Badge

Copy to your README.md:

[![smart-npv-mcp MCP server](https://glama.ai/mcp/servers/binyaminboukaya/smart-npv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/binyaminboukaya/smart-npv-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/binyaminboukaya/smart-npv-mcp'

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