netsuite-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinguished by resource type and action, but there is some overlap among vendor retrieval variants (list, latest, by name) and between list vs filtered list for bills. Overall, descriptions help agents select correctly.
Naming Consistency4/5
All tools use the netsuite_ prefix with snake_case, but collection retrieval inconsistently uses either 'get' or 'list' (e.g., get_vendors vs list_files). One tool also includes 'ns' in its name; otherwise consistent.
Tool Count2/5
With 45 tools, the server carries a large surface. While NetSuite is complex, many similar reference list tools could be consolidated, making this feel heavy and harder to navigate.
Completeness4/5
Core lifecycle coverage exists for vendors, bills, payments, credits, journal entries, and expense reports. However, there are no delete/void operations and only update support for vendors and bills, which are notable gaps for full record management.
Average 4/5 across 45 of 45 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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?
With no annotations, the description carries the full burden. It provides some behavioral details like the status format example ('VendBill:A') and optional pagination, but it does not disclose return format, default pagination behavior, or any read-only assurances. The tool is a read operation, but the description does not explicitly state safety or lack of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a compact parameter list. It is front-loaded with the primary purpose, and every word adds value. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the essential purpose and parameters, but it lacks completeness given the many sibling tools and no output schema. It does not mention what the response contains, whether all bills are returned when no filters are applied, or how to choose this tool over vendor-specific variants. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining all four parameters: limit and offset for pagination, q as a search query, and status with an example value. This adds meaningful context beyond the bare schema and covers all parameters, though not with exhaustive syntax details.
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 lists NetSuite vendor bills with optional search and pagination, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like netsuite_get_vendor_bills_for_vendor, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as netsuite_get_vendor_bills_for_vendor or netsuite_get_vendor_bill. The description implies usage via 'optional search and pagination' but does not state exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'List' and mentions optional search/pagination, but does not explain authentication, rate limits, return format, or pagination details. This is a thin disclosure for a network 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 a single concise sentence plus parameter list, with no wasted words. It is front-loaded with the main action, though it could be structured more clearly for parameter details.
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 annotations and no output schema, the description leaves gaps about what is returned, how pagination works, and what the search query searches across. For a simple list tool, it is minimally adequate but not 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 0% description coverage, so the description adds some meaning by labeling parameters: limit (number), offset (number), q (string, search query). It connects limit/offset to pagination and q to search, which is helpful but does not explain the search syntax or default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NetSuite vendor payments (bill payments) and mentions optional search and pagination. It uses a specific verb ('List') and resource, distinguishing it from the singular 'get_bill_payment' sibling.
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 this tool is for listing multiple bill payments, but it does not explicitly compare with alternatives like 'netsuite_get_bill_payment' for single records. No exclusions or when-to-use guidance beyond the mention of optional search and pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a create (mutating) operation and mentions that externalId is for idempotence, which is useful. However, it does not mention the dryRun debug mode (described in the schema), potential validation rules (e.g., debits = credits), or what the response contains. The transparency is adequate but not rich.
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 primary action. The parameter list is dense but readable. It could be improved with bullet points for clarity, but it remains efficient without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is expected to explain more. It covers required and optional parameters but omits dryRun, return value, and any differentiation from the accrual entry sibling. It is adequate for basic usage but leaves gaps that could cost an agent in edge cases or when choosing the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the baseline is 3. The description adds value by specifying tranDate format (YYYY-MM-DD) and explaining that externalId is for idempotence, which the schema does not provide. However, it omits dryRun entirely and mostly restates the line array structure already in the schema. It does not fully compensate for the missing schema descriptions for memo and externalId, though externalId is partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new NetSuite journal entry with debit/credit lines.' This is a specific verb+resource combination. However, it does not differentiate from the sibling tool netsuite_create_accrual_journal_entry, which also creates a journal entry (accrual type), so it misses the opportunity to distinguish between related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when creating a journal entry) but gives no explicit guidance on alternatives or exclusions. It does not mention netsuite_create_accrual_journal_entry or any other sibling, so the agent is left to infer usage from the tool's purpose. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only states the action and a usage note; it does not disclose pagination behavior, return format, filtering, or any potential side effects. The note about category.id is about data usage, not tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose and an important usage constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with two optional parameters and no output schema. The description sufficiently states the purpose but omits pagination semantics and return structure. Given the lack of annotations and output schema, the description is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no insight into the 'limit' and 'offset' parameters. The description does not compensate for the lack of schema documentation, leaving parameters completely unexplained.
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 clearly identifies the resource ('NS expense categories'), with added context about expense report lines and a required field (category.id). This clearly distinguishes it from sibling tools, none of which focus on expense categories.
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 by stating these are 'for expense report lines' and notes a critical dependency (category.id required per line). While it doesn't explicitly mention alternatives or when not to use, there are no competing category-listing tools among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Update' which is already in the tool name, and does not reveal whether the update is partial or full, whether it returns the updated vendor, requires special permissions, or has any side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the action and the key parameter requirements. No wasted words; it is efficient and directly addresses the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with only four string parameters and no output schema, the description gives the essential action and parameter list. However, it omits what the tool returns (e.g., updated vendor object, success/failure) and any prerequisites. Given the low complexity, this is acceptable but not complete.
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 description coverage is 0%, so the description must compensate. It lists the parameter names and marks 'id' as required and others optional, but it does not explain the meaning or expected format of parameters like 'externalId'. The information provided adds minimal value over the schema's property names and required array.
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 an existing NetSuite vendor') with a specific verb and resource. It distinguishes itself from sibling tools like netsuite_create_vendor (create) and netsuite_get_vendor_by_id (get), leaving no ambiguity about 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying existing vendors, but it does not explicitly state when to use it versus alternatives (e.g., create_vendor for new vendors, get_vendor_* for reading). No exclusions or alternative tool recommendations are provided, leaving the usage context only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('List') and mentions optional search/pagination, but does not disclose return format, default limit, or any further behavioral details such as authentication or error conditions.
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 main action, and clearly lists options without unnecessary detail. Every word earns its place.
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 list tool with 3 optional params and no output schema, the description covers the essentials but lacks information on response shape, default behavior, and explicit differentiation among sibling tools. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists parameters and types (redundant with schema) and adds a meaningful hint for 'q' as 'search query'. However, it provides no additional detail for limit/offset beyond their names and the word 'pagination' in the first sentence.
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 'List NetSuite journal entries' with a specific verb and resource, and distinguishes it from siblings like get_journal_entry_by_external_id (which fetches a single entry) and create_journal_entry (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing journal entries with optional search and pagination, but does not explicitly mention when to use this tool versus alternatives like get_journal_entry_by_external_id. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the use of REST API and that SuiteQL is not required, but it does not address permissions, result size behavior, or the discrepancy that the optional limit parameter is absent from the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences with the core purpose front-loaded. The mention of the limit parameter is potentially extraneous and introduces ambiguity, but overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output fields and implementation detail but lacks explicit information about the return structure (e.g., array vs object) and does not reconcile the limit parameter with the schema. It is adequate but leaves gaps.
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 lists no properties, yet the description introduces an optional 'limit' parameter with a default value. This conflicts with the schema and could mislead the agent into passing an unsupported parameter; no additional parameter semantics are 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 states a specific verb ('Get'), resource ('vendors'), and qualifier ('most recently created'), and specifies the output format ('Spendesk-compatible'), clearly distinguishing it from sibling tools like netsuite_get_vendors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the tool's purpose (retrieving recent vendors) and the context that it outputs Spendesk-compatible data, but it does not explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions optional search and pagination but does not confirm read-only status, describe default/max pagination limits, specify q field semantics, or outline return format. The agent is left to infer behavior from the tool name.
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 primary action, and includes a concise parameter list. Every sentence adds value with no filler, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three optional parameters and no output schema or annotations, the description covers basic semantics but lacks context on pagination behavior, searchable fields, and expected response shape. It is adequate for a simple list tool but incomplete for an agent needing to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds 'search query' semantics for q and marks all parameters optional, but limit and offset only receive their type names without defaults or range info. This provides some meaning beyond the bare schema but not comprehensive.
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 'List' as a specific verb with 'NetSuite vendor credits' as the resource, clearly indicating a list operation. It distinguishes from sibling tools like netsuite_get_vendor_credit_by_external_id (single record) and netsuite_create_vendor_credit (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk listing or searching via 'List' and 'optional search', but it does not explicitly name alternatives or state when not to use this tool. Sibling names provide contrast, but no explicit exclusion or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It mentions multi-currency and externalId as optional, but does not explain side effects, validation failure behavior, idempotency semantics, or return values. The description focuses on input requirements rather than what the tool does beyond creating a record, leaving the agent with limited insight into execution 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 concise and front-loaded with the primary purpose. It efficiently communicates required fields and optional ones in a single, dense sentence. The use of 'etc.' is vague and slightly undermines completeness, but overall it avoids unnecessary verbosity and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (9 params, nested objects, no output schema), and the description covers the essential input structure but leaves gaps. It does not explain what the tool returns, the dryRun debug mode, or the expenseListFormat variants, which are present in the schema but omitted from the description. Without an output schema or annotations, the description should provide more context on outputs and error behavior, but it at least covers the core creation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (89%), so the baseline is 3. The description adds value by explicitly highlighting required fields (employee, subsidiary, tranDate, category, amount) and the multi-currency condition for currency. It also gives a compact representation of the nested expenseList structure. While mostly redundant with schema, the multi-currency nuance and the summary of required per-line fields provide added semantic clarity.
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 ('Create a new NetSuite expense report'), the target resource ('for an employee'), and the scope ('with expense lines'). It uses a specific verb and resource, and it is distinct from sibling tools like create_vendor_bill or create_journal_entry. This 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by its verb 'Create' but provides no explicit guidance on when to choose this tool over alternatives. It does list required and optional parameters, which gives some context on prerequisites, but it does not state exclusions or alternative tool recommendations. The usage is inferred rather than explicitly stated.
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?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only says 'List' and mentions optional parameters. It does not disclose output format, sorting behavior, pagination defaults, error handling, or any side effects. For a read-only tool, this is somewhat understandable, but the lack of any behavioral detail beyond the action leaves the agent guessing.
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 concise sentence with a parenthetical clarifying context, followed by a brief parameter note. Every word earns its place; no filler or unnecessary detail. It is effectively front-loaded with the main action.
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 no annotations, the description should at least hint at the shape of the return value or any notable behaviors. It neither explains what fields are returned nor confirms whether the output is a list of objects, IDs, or something else. The mention of limit/offset suggests pagination but not the response structure. This is an incomplete picture for an agent without additional 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 input schema has no properties, so the description provides valuable info about limit and offset parameters that are not present in the structured schema. This goes beyond the schema and gives the agent actionable parameter semantics. However, it does not elaborate on constraints (e.g., max limit value, data types beyond 'number'), which keeps it from a perfect score.
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 action and resource: 'List NetSuite locations'. It also adds context that 'locations' is an 'analytical dimension for geographical or physical location tracking', which distinguishes it from sibling tools that list vendors, accounts, etc. The verb 'List' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve NetSuite locations, and the optional limit/offset parameters suggest pagination usage. However, it does not explicitly mention when to use this tool versus alternatives, nor does it state any exclusions, prerequisites, or scenarios. The guidance is minimal and largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that parameters are optional and gives example type values, but does not mention pagination behavior, response format, or whether inactive accounts are included. Some behavioral context is present, but key details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the main purpose is front-loaded, followed by a clean list of optional parameters. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description provides the essential operation and parameters. However, it lacks information about return format and pagination, which would be helpful but is not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (type has a description). The tool description repeats the type examples but does not explain the purpose of limit and offset beyond their names. For limit and offset, it only restates 'number', adding no semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NetSuite accounts (chart of accounts) with an optional type filter. The verb 'List' and specific resource distinguish it from sibling tools like vendor or bill retrieval tools.
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: call it to list accounts, optionally filtered by type. However, it does not explicitly state when to use this tool over alternatives (e.g., netsuite_get_bank_accounts_by_subsidiary) or provide any exclusion 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?
No annotations are provided, so the description must fully disclose behavior. It states the operation is 'Get' (read-only), which is also inherent in the tool name. It provides no additional context about error handling, permissions, side effects, or what happens if the ID does not exist. The description adds no value beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and provides exactly the necessary information about the required parameter. Every word is informative, 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?
The tool is simple (one parameter, no output schema), but the description omits what the tool returns (e.g., the full payment record) and any error behavior. It covers the core function and parameter adequately, but the absence of return-value specification and edge-case handling leaves it marginally incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (id) with no description (0% coverage). The description compensates by explaining 'id (string, payment ID)', giving the parameter semantic meaning and confirming its type. This adds value beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'NetSuite vendor payment (bill payment)' with scope 'by ID', which distinguishes it from sibling tools like netsuite_get_bill_payments (plural). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single payment by ID, but it does not explicitly state when to use this tool versus alternatives such as listing all bill payments. No exclusions or alternative references are given, making the guidance implicit 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions optional limit and offset parameters, implying pagination, and the verb 'List' suggests a read operation. However, it does not state whether the operation is read-only, what the response format looks like, or any constraints such as default limits or required authentication. This is adequate for a simple list but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose and then noting the optional parameters. No redundant or filler content. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description does its best to cover purpose and pagination, but it omits return structure, default pagination behavior, and any prerequisites. For a simple list tool this may be sufficient, but it could be more complete, especially since the schema is empty and no output schema exists.
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 defines no properties, yet the description mentions optional 'limit' and 'offset' parameters with types. This adds meaning beyond the schema, but it also creates a contradiction with the schema's empty properties. The description does not explain what limit and offset control (e.g., page size, starting position), leaving some semantic ambiguity.
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 action ('List NetSuite classifications') and resource, with a brief clarification of what classifications are (analytical dimension for project/product/business unit tracking). This verb+resource structure is unambiguous and distinguishes it from sibling list tools for other NetSuite entities.
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: use this tool when you need to list classifications. However, it does not provide explicit guidance on when to choose this over alternatives, mention any exclusions, or suggest sibling tools. The purpose is clear enough that the intended use is obvious, but there is no direct comparison to other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates the tool lists currencies with exchange rates, but it does not mention pagination defaults, whether all currencies are returned, or any rate-limiting behavior. The read-only nature is implied by 'List' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description covers the core purpose (list currencies with exchange rates) and mentions the parameters, but it omits pagination behavior and return structure. For this simplicity, it is mostly complete, though a bit more detail would be ideal.
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 no descriptions (0% coverage), so the description must compensate. It merely restates the parameter names and types ('limit (number), offset (number)') without explaining their meaning, such as pagination or default values. This adds no real value beyond the schema itself.
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 a clear resource 'NetSuite currencies with exchange rates', which immediately distinguishes it from sibling tools focused on vendors, bills, and other entities. The addition of 'with exchange rates' makes the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 list of currencies) but does not explicitly state when to use this tool versus alternatives or provide exclusions. There are no sibling currency tools, so the lack of explicit alternatives is understandable, but there is still no guidance beyond the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits itself. It mentions optional search and pagination and gives a status example, but it does not describe default pagination behavior, what fields q searches, or the response shape. This leaves significant ambiguity for a read tool with no annotation safety net.
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 concise sentences with the primary action front-loaded. Every phrase contributes value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the list action and all parameters, but omits return value details and any default or boundary behavior. Given no output schema and no annotations, it is functional but incomplete for selecting confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines q as a search query, status with a concrete example, and notes limit/offset for pagination. This adds meaning beyond raw property names, though limit/offset semantics are only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NetSuite expense reports with optional search and pagination. The verb 'List' distinguishes it from single-record siblings like get_expense_report_by_id and get_expense_report_by_external_id, and the mention of search/pagination frames it as a query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing/filtering, but does not explicitly contrast with sibling tools for fetching individual reports. No when-not-to-use guidance is provided, so the agent must infer the distinction from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does indicate that this is a read operation ('List') and mentions pagination support, which is useful. However, it does not disclose details such as default pagination behavior, response format, or whether permissions are required. This is a basic level of transparency, not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose. It avoids unnecessary details and every word earns its place. This is an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (a list operation with optional pagination), but with no output schema or annotations, the description should cover more. It covers the purpose and parameters adequately but does not describe the return value or any edge cases. Given the simplicity, it is sufficient but not thorough.
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 is empty, providing no parameter definitions. The description compensates by explicitly naming optional parameters 'limit (number)' and 'offset (number)', which clarifies the pagination semantics. This adds meaningful information that is missing from the schema, going beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List files from NetSuite File Cabinet', with a specific verb ('List') and resource ('files from NetSuite File Cabinet'). This distinguishes it from sibling tools like netsuite_upload_file and netsuite_attach_file_to_record, which involve uploading or attaching files rather than listing. No ambiguity about the core function.
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 mentions 'optional pagination' and optional parameters 'limit' and 'offset', which give some hint about controlling result size. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. This is minimal guidance at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action ('attach') and required parameters, but does not disclose side effects (e.g., whether attaching replaces existing attachments), permission requirements, idempotency, or any consequences of repeated calls. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the action, and includes essential usage context and required fields without redundant filler. Every sentence adds value, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (3 required params, no output schema), the description provides solid context: what it does, when to use it (after upload), and what is required. The main missing piece is behavioral nuance (e.g., idempotency, effect on existing attachments), but overall it is sufficiently complete for an agent to select and invoke the tool correctly.
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 already provides descriptions for all three parameters (recordType, recordId, fileId), achieving 100% coverage. The description repeats these and adds example values for recordType ('vendorBill', 'vendorCredit'), but does not introduce new semantic information beyond what the schema provides. Baseline 3 applies because the schema does the heavy lifting.
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: 'Attach a File Cabinet file to a NetSuite record (e.g. vendor bill).' It uses a specific verb (attach) and resource (file to record), and is distinct from siblings like netsuite_upload_file or netsuite_list_files. The examples and required parameter list further clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage context with 'Use after netsuite_upload_file', which indicates the intended sequence and distinguishes it from the upload tool. It also enumerates the required parameters and their types, giving practical guidance. It does not explicitly state when not to use it or alternative tools, but the sequencing note is a strong usage hint.
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 discloses that the tool 'Fetches pages and enriches each entry via the detail endpoint,' which gives useful behavioral context beyond a simple list call. Since no annotations are provided, the description carries the transparency burden, and it does so adequately by mentioning pagination and enrichment. It stops short of a 5 by not discussing side effects, permissions, or potential performance impacts explicitly, but the disclosure is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded: the first sentence defines the purpose, the second describes key behavior. There is no wasted verbiage, and it is appropriately sized for a tool with three self-explanatory parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description mentions the returned fields (names, full names, parent) and the enrichment behavior, which helps the agent understand what to expect. It does not detail the exact response structure or error cases, but the description is reasonably complete for a list-type tool, especially with fully documented parameters.
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 100% for all three parameters, so the schema already documents limit, offset, and activeOnly. The description adds the context that pagination is used ('Fetches pages'), which relates to limit/offset, but it does not add substantial meaning beyond the schema. 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 'List NetSuite departments / cost centers with names, full names, and parent,' which clearly identifies the resource and action. It provides a specific verb ('List') and the resource (departments/cost centers), but does not explicitly distinguish from sibling tools like netsuite_get_classifications, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing departments, but does not explicitly state when to use this tool over alternatives or provide exclusions. The mention of pagination and enrichment hints at when it might be appropriate, but no direct alternatives are named, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the response includes expanded sub-resources, which is a useful behavioral trait. However, it does not explicitly state read-only nature, authentication needs, or error behavior. The word 'GET' implies a safe operation, but this is not formalized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('GET a NS expense report') and adds only essential detail about expanded sub-resources. No unnecessary words 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 simple get-by-ID tool with one parameter and no output schema, the description is quite complete. It specifies the identifier type and gives a concrete example of the response shape (expense.items[].category). While it doesn't cover error cases, this is not critical for such a straightforward read operation.
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 required parameter 'id', and the schema already describes it as 'Expense report internal ID'. The description does not add any additional parameter semantics beyond what is already in the schema, so a 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 uses a specific verb 'GET' and clearly identifies the resource: 'NS expense report by internal ID'. It also distinguishes from sibling tools by noting 'expanded sub-resources' (e.g., expense.items[].category), which differentiates it from simpler lookup tools like get_expense_report_by_external_id.
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 have an internal ID, but it does not explicitly state when to use this over alternatives like `netsuite_get_expense_report_by_external_id` or `netsuite_get_expense_reports`. No exclusions or alternative references are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosure. It clearly indicates a read-only list operation and specifies returned fields, but does not mention behavior such as pagination, sorting, or handling of the 'limit' parameter beyond what the schema already states. This is adequate for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the action, and contains no redundant or extraneous information. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the return fields. However, it does not explicitly state the structure of the returned list or any constraints beyond the schema, so it falls slightly short of fully complete 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 100% for the single 'limit' parameter, which is fully documented in the input schema. The description does not add any additional parameter meaning, so 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 uses a specific verb ('List') and resource ('NetSuite subsidiaries'), and enumerates the key attributes returned (names, countries, currencies, elimination flags). This clearly distinguishes it from sibling tools, which focus on vendors, bills, employees, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly address when to use it versus alternatives. There are no sibling tools for subsidiaries, so the use case is implicitly clear, but no contextual guidance or exclusionary conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context such as 'Set department from cost center map for analytics' and the critical note that vatLines sets taxDetailsOverride so the tax authority ledger is updated. However, it omits permissions, response shape, dryRun behavior, and error conditions.
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 compact two-sentence block, front-loaded with the primary purpose, then systematically listing required/optional fields and specific guidance. It is dense but efficient, with no 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?
Given 15 parameters and no annotations or output schema, the description covers required fields, expense line structure, and VAT handling well. However, it leaves gaps around return value, dryRun behavior, externalId semantics, and potential errors, making it substantial but not fully complete for a complex create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 47%, but the description compensates by explaining the expense array structure ('array of lines with account, amount as NET, memo, department, location, class, taxCode'), clarifying required fields and date format (YYYY-MM-DD), and describing VAT line semantics. This adds significant meaning beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new NetSuite vendor bill with expense lines' and lists required fields, distinguishing it from sibling tools like create_vendor_credit or update_vendor_bill. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use by listing required and optional fields, advising to set department from the cost center map, and explaining when to use vatLines for VAT. It does not explicitly name alternatives or exclusions, but the usage context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavior. It discloses the idempotency-check use case, which is useful. But it doesn't mention potential errors, return behavior when not found, permissions, or any side effects. As a simple 'get' operation, some of this is assumed, but the description lacks explicit behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a useful parenthetical qualifier. It is front-loaded with the core action and includes essential context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with no output schema, this description covers the essential context: what it does, by what identifier, and a key use case. It doesn't explain the return format, but that is likely understood for a 'get' tool. Overall, it is complete for its 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?
The schema has one parameter, externalId, with no description and 0% coverage. The tool description merely restates 'by its externalId', adding no new semantic detail beyond the parameter name itself. It is sufficient for a single self-explanatory parameter but doesn't clarify what an externalId is or any constraints like format.
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 ('Get') and the target resource ('expense report') with a specific identifier ('externalId'). It distinguishes from sibling tools like get_expense_report_by_id, which uses a different identifier, and get_expense_reports, which lists multiple reports.
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 parenthetical 'idempotency check before creating an expense report' provides a clear context for when to use this tool. It implies a pre-creation check to avoid duplicates. However, it doesn't explicitly mention alternative tools or when NOT to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return shape precisely, including a 'found' boolean and a bill object or null, which indicates not-found behavior. The verb 'Get' implies a read-only operation, and the idempotency framing adds context. It does miss potential error handling details, but for a simple getter, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence plus a return-shape annotation. It is front-loaded with the purpose, states the requirement, and specifies the output. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides the essential information: purpose, required parameter, and return structure. It does not include error handling or rate limits, but these are not critical for a basic read operation. The return shape is disclosed, making the behavior predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does identify the single parameter 'externalId' and its requirement, but it largely restates the schema (type string, required). It adds minimal meaning beyond the parameter name, which is self-explanatory. The description does not elaborate on format or provenance, so it provides only baseline compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get a vendor bill by its externalId' with a specific identifier type. This distinguishes it from sibling tools like netsuite_get_vendor_bill (likely by internal ID) and netsuite_get_vendor_bills (list). The term 'idempotency helper' adds useful context about the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'idempotency helper' implies when to use this tool (for idempotent checks by external ID), but it does not explicitly state when not to use it or name alternative tools. This is implied guidance rather than explicit direction, so it meets the 'implied usage' benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key non-obvious behavior of automatic reversal on the specified reversalDate, which is essential for usage. However, it does not mention other behaviors like idempotency, permissions, or what happens on validation failure.
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 core purpose and immediately followed by usage and behavior details. 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?
The tool has 7 parameters, no output schema, and no annotations. The description covers usage context and the auto-reversal behavior, but it omits return value details and potential side effects or failure modes. For a create tool, this is a moderate level of completeness.
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 86%, so the schema already documents most parameters clearly. The description adds some contextual meaning (e.g., 'charges-à-payer (408xxx)' relates to account line content), but it does not significantly extend parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('month-end accrual journal entry'), and clearly distinguishes this tool from the generic netsuite_create_journal_entry by specifying 'automatic NS reversal'. This makes 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 explicitly states when to use it ('Use after spendesk_get_accruals to post charges-à-payer (408xxx) entries'). It provides clear context for the intended workflow, though 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses idempotency behavior via externalId and the ability to apply to bills, which is useful. However, it doesn't mention side effects, permissions, error behavior, or what happens on success, leaving some opacity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose. Every sentence adds value: purpose, idempotency guidance, and applyList option. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core use cases and idempotency, but for a complex tool with 8 parameters, nested objects, and no output schema, it omits mention of expenseList and dryRun. While the schema describes these, the description doesn't guide when to use them or what the response will be, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%), but description adds value by explaining the purpose of externalId ('idempotency') and applyList ('apply to an existing bill'), which goes beyond the schema's field descriptions. It also clarifies the Spendesk credit note context, aiding parameter selection.
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 ('Create a NetSuite vendor credit') with a specific resource and purpose ('for Spendesk credit notes / refunds'). It distinguishes from sibling tools like netsuite_create_vendor_bill by framing this as a credit/refund operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage guidance: 'Use externalId for idempotency' with an example pattern, and 'Optionally apply to an existing bill via applyList'. This implies when to use these features, though it doesn't explicitly exclude alternative tools or state when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure responsibility. It reveals that only active codes are returned and lists the fields, but does not explicitly state read-only behavior, authentication needs, or pagination behavior beyond the schema. The verb 'List' implies safety, but more explicit detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the action, resource, and return fields. The second adds the active-only behavior, the intended use case, and optional parameters. There is no redundancy or unnecessary detail.
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?
No output schema exists, so the description must explain the return values. It does so by listing the fields returned. It also explains the active-only filter and the intended use case. For a simple list tool with two optional parameters, this is complete enough for an agent to select and invoke it correctly.
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 already documents both parameters (limit with default 50, offset with default 0) at 100% coverage. The description merely repeats 'Optional: limit, offset' without adding semantic value, such as how limit interacts with the active-only filter or how offset pagination behaves. This meets the baseline but adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NetSuite sales tax items and enumerates the returned fields (id, name, rate, country, isInactive). The resource is specific and distinct from sibling tools, which focus on vendors, bills, and expenses. The verb 'List' unequivocally indicates a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: 'use results to populate CLIENT_CONFIG.TAX_CODES by rate.' This tells the agent when to invoke the tool. It doesn't mention when not to use it or name alternatives, but no alternative for tax codes exists among siblings, so this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: the 400 failure retry mechanism, the requirement for customForm/customFields in some cases, and externalId for idempotency. It does not mention response format or permissions, but the core mutation behavior is clear from 'Create'.
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 paragraph but logically structured: purpose, error handling, then required/optional lists. It is information-dense with no fluff, though a bulleted list might improve readability. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, low schema coverage, and no output schema, the description covers the main hazard (customForm) and idempotency, but omits format expectations for subsidiary, currency, country, and address fields. It also does not state what the tool returns (e.g., vendor ID). These are meaningful gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description compensates by explaining key non-obvious parameters: externalId 'for idempotency', customForm 'string, custom form ID', customFields 'object, key-value map'. Other params are listed by name, which is acceptable for self-explanatory fields, but formats like subsidiary ID vs name are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new NetSuite vendor (supplier)', providing a specific verb and resource. This clearly distinguishes it from sibling tools like netsuite_update_vendor and netsuite_get_vendors, and the synonym 'supplier' reinforces the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditional guidance: 'If vendor creation fails with 400, first call netsuite_get_vendor_forms to discover the correct customForm ID, then retry'. It also lists required vs optional parameters. However, it does not state when not to use this tool or contrast with other create tools, but the error-recovery workflow is a strong guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses the filter (type='Bank'), the subsidiary scoping, and the exact return fields ({ id, acctnumber, fullname, description }). It doesn't cover edge cases or errors, but for a simple read-only get, this is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both informative: purpose stated first, then expected return shape. No unnecessary words, and the structure is well-suited for quick scanning.
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?
With a single parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, required parameter, and return format. It lacks error/empty-result handling, but for this simple get tool 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?
The schema has zero description coverage and only provides the type 'string' for subsidiaryId. The description adds that it's 'Required' and for 'a given subsidiary', but it doesn't specify whether it's an internal ID or offer an example. This partially compensates for the low schema coverage but lacks depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the specific resource 'bank accounts (type = 'Bank')', and the scope 'for a given subsidiary'. This distinguishes it from siblings like netsuite_get_accounts, which is more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it requires a subsidiaryId and returns only bank accounts. It does not explicitly mention alternatives or when not to use this tool, but the 'type = Bank' and 'by subsidiary' context make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It correctly identifies a read operation ('List') but does not disclose default pagination behavior, search field semantics, or return format. It adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose, use case, parameter list. Front-loaded and every sentence is informative; no waste.
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 annotations and no output schema, so the description must cover purpose, usage, and params. It does well on all three, but omits return value structure and default pagination behavior. Adequate for a simple list tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists all three parameters with types and brief semantics: q is a 'search query', limit and offset are for pagination. This adds meaning beyond the schema's bare type definitions, though it could detail which fields q searches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List NetSuite employees' (specific verb+resource), mentions optional search/pagination, and states its use case (matching Spendesk Members to NetSuite Employees). This clearly distinguishes it from siblings like netsuite_get_employee, which likely fetches a single employee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete scenario ('Used to match Spendesk Members to NetSuite Employees for expense reports'), giving clear context. However, it doesn't explicitly mention alternatives or when not to use it, such as when a single employee is needed via netsuite_get_employee.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns schema details including sub-resources and the items[] format, which is useful behavioral context. It doesn't mention authentication or error behavior, but for a schema lookup, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds value. No unnecessary words 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 simple one-parameter tool with no output schema, the description adequately explains what it returns, why it matters, and when to use it. It could mention the response format explicitly, but the lack of that is minor given the stated purpose.
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 covers the single parameter fully with examples (expenseReport, journalEntry, etc.), so coverage is 100%. The description adds no additional parameter-specific meaning beyond contextualizing recordType in relation to create handlers, keeping it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the exact NetSuite REST API schema for a record type.' It specifies what is returned (required fields, property names, sub-resources) and distinguishes itself from sibling tools, which target specific record data, not schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool 'before implementing or debugging a create handler.' This gives clear contextual guidance, though it doesn't explicitly mention alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states 'Returns full bill details with expanded sub-resources (expense lines, items)', which tells the agent what to expect in the response. However, it does not address potential errors, auth requirements, or rate limits, making it only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a clear parameter explanation. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-get tool with one parameter and no output schema, the description is sufficiently complete. It explains what is returned (full bill details with sub-resources) and what the parameter is. It could include error behavior or response format specifics, but those are not critical for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'id' as a string with no description. The description compensates by stating 'Required parameter: id (string, NetSuite internal vendor bill ID)', adding meaningful semantics about what the parameter represents. This goes beyond the schema's bare type information.
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: 'Get a single NetSuite vendor bill by internal ID.' It uses a specific verb ('Get') and resource ('single NetSuite vendor bill') and scopes it by 'internal ID', which distinguishes it from sibling tools like netsuite_get_vendor_bills (plural) and netsuite_get_vendor_bill_by_external_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you have the internal ID of a specific vendor bill and need full details. It implicitly differentiates from alternatives by emphasizing 'single' and 'by internal ID', though it does not explicitly name alternatives or state when not to 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?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool returns form IDs and mentions their use case, implying a read-only operation. However, it does not detail the output format (e.g., array of strings) or potential edge cases (e.g., no vendors, no custom forms). This is a minor gap for a zero-parameter tool, so a middle 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 two sentences: the first states the action, the second provides the use case. Every sentence earns its place, and it is front-loaded with the primary purpose. No unnecessary details 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 the tool's simplicity (zero parameters, no output schema, no annotations), the description is largely complete. It explains what the tool returns and when to use it. It could be slightly more thorough by mentioning prerequisites or output structure, but given the straightforward nature, it is close to fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, the baseline for zero parameters is 4. The description adds no parameter-specific information because none are needed. It appropriately focuses on the output and usage, so 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: 'Get list of custom form IDs used by existing vendors.' It specifies the resource (custom form IDs) and the action (get list), and it distinguishes itself from sibling tools by tying the output to vendor creation. This is a specific verb+resource combination that is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: 'Use this if vendor creation fails with 400 to discover the correct customForm ID.' This tells the agent when to invoke the tool, but it does not explicitly name alternatives or contrast with other tools. It gives a concrete trigger condition, which is more than adequate for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the use of SuiteQL for searches and the optional parameters, but does not state read-only status, return format, or pagination defaults. It adds some behavioral context but not comprehensive detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every sentence adds value. It wastes no words and covers the essential aspect in a structured manner.
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 list tool with no output schema and 3 optional parameters, the description covers purpose and all parameters clearly. It lacks explicit return value details and pagination behavior, but is adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has no parameter descriptions (0% coverage), but the description compensates by explaining each parameter: limit (number), offset (number), and q (search query on companyName via SuiteQL). It provides semantics beyond the raw schema, though it lacks constraints or examples.
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 NetSuite vendors (suppliers)') and differentiates from siblings like netsuite_get_vendor_by_id or netsuite_get_latest_vendors by explicitly mentioning optional search and pagination. It is specific about the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: use this to list vendors, with optional filtering and pagination. However, it does not explicitly name alternatives or state when not to use it, so it falls short of fully comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It adds important behavioral details beyond the schema, such as using RQL on the vendor list, enriching results with full vendor details, and supporting case-insensitive partial matching. This goes beyond a minimal statement but could further disclose pagination or rate limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both earning their place. The first sentence states the core purpose and matching behavior; the second explains internal mechanism and optional filtering. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by stating that it enriches with full vendor details. It covers the search scope and optional filter, but it does not explicitly mention the default limit behavior or return format (e.g., list vs. single record). This is reasonable for a search tool but leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all three parameters, so the baseline is 3. The description adds meaningful semantics for the 'name' parameter by specifying it's case-insensitive and partial-match, which the schema's 'Vendor name to search for' does not convey. It also mentions the optional subsidiaryId filter, but limit semantics remain schema-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'NetSuite vendors', and the specific scope 'by name' with matching semantics (case-insensitive, partial match). This distinguishes it from sibling tools like netsuite_get_vendors, which likely returns full lists rather than name-based searches.
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 to find vendors by a name fragment, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any when-not scenarios. The context is clear but lacking explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the PATCH method and crucially warns that providing expense[] or item[] triggers full replacement of existing lines via ?replace=expense and ?replace=item. This is valuable behavioral insight. It could also mention error handling or return format, but the key mutation semantics are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured. It leads with the main purpose, then lists supported fields, and then highlights the critical replace behavior. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects) and no output schema, the description provides a solid overview of capabilities and the non-merge replacement behavior. It does not describe the response format or potential failure modes, but for an update tool the essential context is present. The dryRun parameter is also documented in the schema, so its absence in the description is acceptable.
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 93%, so the schema already documents most parameters in detail (e.g., dueDate format, taxCode examples). The description adds a summary of supported field groups but does not significantly enhance parameter meaning beyond the schema. It correctly repeats the replace behavior, but that is already in the schema descriptions for expense and item.
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 as 'Update any field of an existing NetSuite vendor bill via PATCH.' This specifies the verb, resource, and method, distinguishing it from create or get operations. It also enumerates supported fields, reinforcing its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for updating existing vendor bills and hints at behavior when expense/item arrays are provided (replace vs merge). However, it does not explicitly mention alternatives like 'use create_vendor_bill for new bills,' so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the upload side effect, the return value (file internal ID), and parameter requirements (base64 content, folder ID). However, it omits details like file size limits, duplicate-name behavior, or permission requirements, leaving some behavioral ambiguity.
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: the first states the core action, the second lists required and optional parameters. It is front-loaded with the primary purpose and contains no redundant words. All information 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?
Given the tool has 6 parameters, no output schema, and no annotations, the description covers the essential context: purpose, return value, required parameters, and a downstream usage example. It lacks error handling or permission details, but for an upload tool it is reasonably complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic meaning beyond the schema by clarifying that 'content' must be base64-encoded, 'folder' is the NetSuite File Cabinet folder internal ID, and 'fileType' is like 'PDF'. It also notes the optionality of description and isOnline. The schema coverage is 67%, and the description helps fill gaps for the optional fields, though it could explain their meaning more deeply.
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 'Upload a file to NetSuite File Cabinet' with a concrete example ('invoice PDF'). It clearly distinguishes the tool by mentioning it returns the file internal ID for use with netsuite_attach_file_to_record, which separates it from listing or attaching operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is for uploading files that will later be attached to records, evidenced by 'Returns the file internal ID for use with netsuite_attach_file_to_record.' It also lists required and optional parameters, but does not explicitly mention when not to use it or name alternative tools beyond the attach sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'Returns full employee details with expanded sub-resources,' which is useful. However, it does not mention potential errors, authentication requirements, or rate limits. For a read-only get-by-id, this is adequate but not rich.
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 consists of two sentences, with the primary action front-loaded. Every sentence adds useful information: what the tool does and what the required parameter is. There is no wasted text or repetition of schema fields.
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 get-by-id tool with one parameter and no output schema, the description is fairly complete. It states the return behavior ('full details with expanded sub-resources') and the parameter. It could be enhanced by mentioning error cases or response format, but given the low complexity, this is sufficient.
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 provides only 'id' as a string with no description (0% coverage). The description compensates by explaining 'id (string, NetSuite internal employee ID),' which gives the exact meaning and type. Since this is the only parameter and it is fully clarified, the description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a single NetSuite employee by internal ID.' It specifies the resource (employee), the operation (get single), and the identifier type (internal ID). This distinguishes it from the sibling tool netsuite_get_employees (plural) and other NetSuite getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: when you need a single employee and have its internal ID. It does not explicitly name alternatives like netsuite_get_employees for listing, but the 'single' and 'by internal ID' phrasing makes the usage context clear. It lacks an explicit 'when not to use' statement, so it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does add useful details beyond the schema: the date format 'YYYY-MM-DD' and the default limit of 50. However, it does not disclose the return format (e.g., array of vendor bills) or any error/edge-case behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a purpose statement followed by a compact parameter list. Every word is informative, with no fluff or redundancy. It is front-loaded with the action and resource.
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 list tool with no output schema or annotations, the description covers the essential aspects: purpose, required/optional params, and a default behavior (limit). It could be slightly more complete by explicitly stating the response shape, but the tool's simplicity makes this a minor gap.
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 has zero descriptions for its parameters, so the description fully compensates by explaining each parameter: vendorId is required, from/to are dates in a specific format, and limit has a documented default. This is comprehensive parameter documentation over and above the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' plus a resource 'vendor bills' and narrows scope to 'for a specific vendor', clearly distinguishing it from sibling tools like netsuite_get_vendor_bills which likely returns all bills. The required vendorId parameter reinforces that this is a scoped lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving bills of one vendor, and the optional date range gives additional filtering usage. However, it does not explicitly mention when not to use it or point to alternatives (e.g., netsuite_get_vendor_bills for all vendors), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full responsibility for behavioral disclosure. It mentions that the tool returns full vendor details with expanded sub-resources, which is useful behavioral information, but it does not disclose potential errors, authentication requirements, or rate limits. For a read operation, this is minimally adequate but not rich.
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 concise sentences, front-loaded with the primary action, and every sentence adds value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter get tool, the description is nearly complete: it states the input, the output, and the distinguishing aspect of internal ID. However, 'expanded sub-resources' is a bit vague and could benefit from clarification, and the lack of an output schema places slightly more burden on the description.
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 provides a string type for 'id' with no description. The description compensates fully by explaining 'id' is the 'NetSuite internal vendor ID', adding meaningful semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single NetSuite vendor by internal ID, using a specific verb and resource. It distinguishes itself from sibling netsuite_get_vendor_by_external_id by explicitly mentioning 'internal ID'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by internal ID' indicates when this tool should be used versus the external ID variant, providing clear context. However, it does not explicitly name alternatives or state when not to use the tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'inspects' a metadata-catalog and 'returns fields,' which implies a read-only operation. However, it does not describe the return format, whether the catalog is cached or dynamic, or any limitations. This is adequate but lacks some behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action ('Inspect NetSuite vendor metadata-catalog and return fields'), followed by a brief usage note. Every word earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It states what the tool does, what it returns (filterable fields), and why it is useful (for RQL filtering). This is sufficient for an agent to decide when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms 100% coverage with an empty object. The baseline for 0 params is 4. The description does not need to explain parameter semantics because there are none, and it appropriately focuses on the tool's output and purpose.
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: it inspects the NetSuite vendor metadata-catalog and returns fields that are filterable with the REST Record Query Language. It uses a specific verb ('inspect'/'return') and resource ('metadata-catalog'), and it distinguishes itself from sibling tools that fetch actual vendor records by focusing on filterable field names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is useful when one needs to know which field names are valid in RQL filters. It implicitly tells the agent when to use this tool (for filterable field information) and does not conflict with any alternative tools, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return format including the null case, which is important behavioral context. It omits error handling or auth details, but for a simple lookup this is acceptable.
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 a return-type shorthand. Every word is functional, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description includes the return shape and the primary use case. The absence of an output schema is mitigated by the explicit return definition. It's adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (only type string), so the description must compensate. It states 'Required: externalId (string)' and explains the field's role in the tool's purpose. While it doesn't elaborate on externalId's format or domain, the single parameter's meaning is clear 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 uses a specific verb 'Get' with the resource 'vendor credit' and identifies the lookup key 'externalId'. It clearly distinguishes from sibling tools by targeting vendor credit specifically and stating its idempotency-check purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'idempotency check before creating a credit', giving a clear when-to-use scenario. While it doesn't name alternative tools, the context makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behaviors: auto-resolution of account, default currency, idempotence via externalId, and the unapplied payment caveat. However, it does not mention permission requirements, post-save effects, or response format, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the main action is front-loaded, followed by a clear breakdown of required and optional parameters, and a notable caveat. Every sentence is informative and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description covers essential behavioral aspects (defaults, idempotence, unapplied payment). It lacks information on return values, error cases, and permission requirements, but is still substantially complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so excellently by explaining each parameter's purpose, format, optionality, defaults, and the structure of the 'apply' array. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a NetSuite vendor payment (bill payment) and apply it to one or more vendor bills,' with a specific verb and resource. It distinguishes from siblings like create_vendor_bill and create_vendor_credit by specifying the payment context and application to bills.
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 the tool (to create vendor payments) and provides clear parameter usage, but does not explicitly mention alternatives or exclusions. Since the context is clear and no misleading guidance exists, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly specifies the return shape, including a 'found' boolean and null entry, which transparently communicates the not-found behavior. It does not mention potential error conditions or side effects, but for a read-only lookup, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and parameter, followed by the return value. Every part is essential, with no wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is complete. It includes the purpose, required parameter, and return shape, which is all an agent needs to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description compensates by stating 'Required: externalId (string)' and explaining that the lookup is performed 'by its externalId'. This adds meaning beyond the bare schema, though it could have elaborated on the expected format or source of the externalId.
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 'Get a journal entry by its externalId', which is a specific verb and resource, and distinguishes it from sibling tools like netsuite_get_journal_entries by focusing on external ID lookup. The phrase 'idempotency helper' further clarifies its specialized role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by labeling the tool as an 'idempotency helper', implying it is intended for checking existence before creation. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explains the underlying mechanism (RQL on the vendor list, then enrichment with full details) and specifies the return structure, which conveys that this is a read-only lookup. It does not mention error cases or authorization, but for a simple read operation the provided behavioral details are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and packs in the method, enrichment step, and return shape without any filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, this description is complete: it tells the agent what it does, how it works, and exactly what the response looks like. It also fits well alongside sibling tools by making the lookup-by-externalId distinction obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents externalId as a string with an example, and coverage is 100%. The description adds context by explaining that the externalId follows the pattern 'spk_supplier_<spendeskId>' and that it's the NetSuite external ID, which helps the agent understand the intended value format beyond the raw 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 uses a specific verb ('Find') paired with a clear resource ('NetSuite vendor') and a precise lookup key ('by its externalId'), which immediately distinguishes this from sibling tools like netsuite_get_vendor_by_id or netsuite_search_vendors_by_name. The example 'spk_supplier_<spendeskId>' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly conveys the primary use case—finding a vendor when you have the externalId—and provides an example of the expected ID format. However, it does not explicitly mention when not to use it or point to alternatives (e.g., use get_vendor_by_id for internal NetSuite IDs), so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly declares read-only behavior, restricts to SELECT queries, and reveals important behavioral traits: default limit=100, max limit=1000, offset default=0, and the auto-conversion of 'LIMIT N' to 'FETCH FIRST N ROWS ONLY'. The warning about syntax is valuable and beyond the schema. This is thorough for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose statement, parameter summary, important warning, and three practical examples. It is front-loaded with the most critical information and every sentence adds value. The warning and examples are directly useful for correct invocation, and the length is appropriate given the complexity of SQL queries.
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 lack of output schema and annotations, the description provides enough context for an AI agent to select and use the tool: safety constraints, parameter defaults, syntax caveat, and realistic examples. It does not describe the return format, but for a generic query tool the output depends on the query, so this is acceptable. The tool's complexity is moderate and covered well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only query has description). The description compensates by specifying the query as a SQL SELECT statement and adding defaults and maximum for limit (100/1000) and default for offset (0). It does not fully explain pagination semantics (e.g., that limit caps result size), but the examples illustrate usage. This is good compensation for the schema's gaps.
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: 'Execute a read-only SuiteQL query against NetSuite.' It uses a specific verb (execute) and resource (SuiteQL query), and adds crucial constraint 'Only SELECT queries are allowed.' This distinguishes it from sibling tools that target specific record types (e.g., netsuite_get_vendor_by_id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you need to run a read-only SQL query against NetSuite. It provides multiple examples illustrating common use cases. However, it does not explicitly state when not to use it or name alternatives, such as using specific getter tools for well-known records. The guidance is clear but not exhaustive.
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:

[![netsuite-mcp-server MCP server](https://glama.ai/mcp/servers/julienchriqui-okkoer/netsuite-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/julienchriqui-okkoer/netsuite-mcp-server)

Score Badge

Copy to your README.md:

[![netsuite-mcp-server MCP server](https://glama.ai/mcp/servers/julienchriqui-okkoer/netsuite-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/julienchriqui-okkoer/netsuite-mcp-server)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/julienchriqui-okkoer/netsuite-mcp-server'

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