AARO ERP MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific ERP resources like banks, customers, orders, and inventory, with clear action verbs. However, erp_test_hook and erp_test_webhook overlap significantly in purpose (both for testing webhooks), which could cause confusion for an agent trying to choose between them.
Naming Consistency5/5
All tool names follow a consistent erp_verb_noun pattern in snake_case, with verbs like listele, olustur, duzenle, and ekle applied uniformly across resources. This predictability makes the set easy to navigate and understand.
Tool Count3/5
With 25 tools, the count is on the high side for an ERP server, bordering on heavy. While ERP systems are complex, some tools like erp_test_hook and erp_test_webhook seem redundant, and the set might benefit from consolidation to reduce cognitive load.
Completeness4/5
The toolset covers core ERP operations well, including CRUD for key resources (e.g., cari, stok, dekont), listing functions, and workflow steps like completing documents. Minor gaps exist, such as no update or delete tools for resources like banks or warehouses, but agents can likely work around these with the available tools.
Average 3/5 across 25 of 25 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions sending requests to external URLs but doesn't disclose important behavioral traits: whether this is a read or write operation, what authentication is required, potential side effects, rate limits, error handling, or what the response looks like. For a tool with no annotations and parameters for filtering stock data, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two short sentences that convey the core purpose. There's no unnecessary verbosity or redundant information. However, it could be better structured by front-loading the most critical information about what the tool actually does with the parameters provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of data is returned, how the external URL integration works, what testing scenarios it supports, or how the filtering parameters relate to the testing purpose. For a tool with this complexity and no structured metadata, the description should provide much more 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%, so the schema already documents all 6 parameters with their purposes. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how parameters interact, provide usage examples, or clarify the relationship between parameters like 'EsnekAramaKisiti' and 'StokID'. With complete schema coverage, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for testing purposes and sends requests to external URLs, which provides a basic purpose. However, it's vague about what specifically is being tested ('hooklar test edilir' - hooks are tested) and doesn't clearly distinguish this from sibling tools like 'erp_test_webhook'. The description restates the testing purpose without specifying the resource or operation clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions it's for testing purposes but doesn't specify what scenarios require this tool, what prerequisites exist, or when to choose it over similar tools like 'erp_test_webhook'. There's no mention of when-not-to-use or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action ('getirir') without disclosing behavioral traits such as pagination, rate limits, authentication needs, or what happens if no parameters are provided. For a list operation with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple list tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with full schema coverage, the description is incomplete. It lacks behavioral context (e.g., response format, error handling) and usage guidelines, making it inadequate for a tool that retrieves data from an ERP system.
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%, so the schema already documents all three parameters (StokID, SeriLotKodu, SiralamaKisiti) with descriptions. The description doesn't add any meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ERP sisteminden seri/lot listesini getirir' clearly states the action (getirir/retrieves) and resource (seri/lot listesi/serial-lot list), but it's somewhat vague about scope and doesn't differentiate from sibling tools like 'erp_stok_listele' or 'erp_stok_hareketleri_listele'. It specifies the source (ERP system) which adds some context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, exclusions, or comparisons to sibling tools like 'erp_stok_listele' or 'erp_stok_hareketleri_listele', leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'düzenler' (edits) implies a mutation operation, the description doesn't disclose important behavioral traits: whether this requires specific permissions, if changes are reversible, what happens to unspecified fields, potential side effects, or rate limits. The description adds minimal behavioral context beyond the basic edit action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise (two sentences) but could be more front-loaded. The first sentence states the core purpose, while the second lists document types. However, the second sentence feels somewhat redundant since 'dekont başlıklarını' (receipt headers) already implies these document types in an ERP context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after editing (success/failure responses), error conditions, or important behavioral constraints. The agent would need to guess about the tool's behavior and outcomes based solely on the parameter schema.
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 description coverage is 100%, with each parameter well-documented in Turkish. The description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'edits receipt headers in the ERP system' and lists specific document types (orders, quotes, invoices). This provides a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like 'erp_dekont_olustur' (create receipt) or 'erp_dekont_tamamla' (complete receipt).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing receipt ID), when not to use it (e.g., for creating new receipts), or how it differs from sibling tools such as 'erp_dekont_olustur' or 'erp_dekont_tamamla'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it retrieves a list but provides no information about pagination, rate limits, authentication requirements, response format, error conditions, or whether this is a read-only operation. The description is minimal and lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval operation, though it could potentially be more front-loaded with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 2 parameters, the description is insufficient. It doesn't explain what the returned bank list contains, how results are formatted, whether there are limitations on the data returned, or any error handling. The minimal description leaves too many operational questions unanswered.
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%, so the schema already documents both parameters (BankaID filter and SiralamaKisiti sorting criteria). The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - fetches/retrieves) and resource ('banka listesini' - bank list) from the ERP system. It distinguishes itself from other list tools by specifying the bank domain, but doesn't explicitly differentiate from other list operations like 'erp_depo_listele' or 'erp_doviz_listele' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple other list tools (e.g., erp_cari_listele, erp_depo_listele) but no indication of when to choose bank listing over other entity listings, nor any prerequisites or constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'getirir' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the barcode list takes. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Turkish that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple list operation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'barcode list' contains, how results are structured, whether filtering is required or optional, or what authentication is needed. Given the lack of structured metadata, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has 3 parameters with 100% description coverage. The schema already documents StokID filter, BarkodNo, and SiralamaKisiti with their purposes. Since schema coverage is high, the baseline is 3 even though the description adds no parameter information beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - gets/retrieves) and resource ('barkod listesini' - barcode list) from the ERP system, making the purpose understandable. However, it doesn't distinguish this tool from sibling list tools like 'erp_stok_listele' or 'erp_cari_listele' beyond specifying it's for barcodes specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple list tools available (barcode, stock, customer, etc.), there's no indication of when barcode listing is appropriate versus other listing operations. No prerequisites, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a new customer card and mentions a post-creation URL, but lacks critical behavioral details: whether this is a mutating operation (implied but not explicit), what permissions are required, whether it's idempotent, error handling, or what happens on success/failure. For a creation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence states the core purpose clearly. The second sentence adds useful post-creation context (the URL). There's no unnecessary repetition or fluff. However, it could be slightly more structured by separating behavioral details from the purpose statement.
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 this is a creation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (success/failure indicators, the created object), error conditions, authentication requirements, or system constraints. The URL mention is helpful but doesn't compensate for the missing behavioral context needed for a mutation 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?
The input schema has 100% description coverage with clear parameter documentation (including required fields and defaults). The description adds no parameter-specific information beyond what's already in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'ERP sisteminde yeni cari kartı oluşturur' (creates a new customer card in the ERP system). It specifies the verb ('oluşturur' - creates) and resource ('cari kartı' - customer card), distinguishing it from sibling tools like erp_cari_listele (list customer cards). However, it doesn't explicitly differentiate from other creation tools like erp_stok_olustur (create stock) or erp_dekont_olustur (create payment slip), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid CariKodu), when not to use it (e.g., for updating existing cards), or how it relates to sibling tools like erp_cari_listele. The only contextual information is the post-creation URL, which doesn't constitute usage 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 provided, the description carries full burden for behavioral disclosure. 'Dekonta stok kalemi ekler' implies a write/mutation operation but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens on success/failure. For a tool with 11 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Turkish phrase that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex write operation with 11 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after adding the stock item, what validation occurs, or what the tool returns. The context signals indicate significant complexity that the description doesn't address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what's already in the schema (which has 100% coverage with detailed descriptions for all 11 parameters). The baseline is 3 since the schema does the heavy lifting, but the description doesn't provide additional context about parameter relationships or business logic.
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 'Dekonta stok kalemi ekler' clearly states the action (ekler/adds) and the resource (stok kalemi/stock item to dekont/receipt). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like erp_dekont_duzenle or erp_dekont_olustur.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like erp_dekont_duzenle (edit receipt) and erp_dekont_olustur (create receipt), there's no indication of whether this tool is for adding items to existing receipts or when it should be preferred over other dekont-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it lists receipt headers but doesn't describe the return format, pagination behavior (implied by 'Sayfa' and 'SayfaSatirSayisi' parameters), whether it's read-only, or any rate limits. For a listing tool with 8 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Turkish that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'dekont başlıklarını' (receipt headers) includes in the output, how pagination works with 'Sayfa' and 'SayfaSatirSayisi', or any behavioral traits like being read-only. For a listing tool with filtering parameters, more context is needed.
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%, so the schema already documents all 8 parameters with clear descriptions (e.g., 'DekontID filtresi' for DekontID filter, 'Başlangıç tarihi (YYYY-MM-DD)' for TarihBas). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('listeler' - lists) and resource ('dekont başlıklarını' - receipt headers) from the ERP system. It distinguishes from siblings like 'erp_dekont_duzenle' (edit receipt) and 'erp_dekont_olustur' (create receipt) by focusing on listing rather than modifying. However, it doesn't specify what 'dekont başlıklarını' (receipt headers) includes compared to other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention when to use this versus 'erp_dekont_duzenle' (edit receipt) or 'erp_dekont_olustur' (create receipt), nor does it specify prerequisites or context for filtering receipt headers. Usage is implied by the name and purpose but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates new document headers, implying a write/mutation operation, but doesn't disclose important behavioral traits: whether this requires specific permissions, what happens on success/failure, if the creation is reversible, rate limits, or authentication needs. The URL mention is helpful for post-creation viewing but doesn't cover core behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence clearly states the purpose, and the second provides useful post-creation context (viewing URL). There's no wasted verbiage, and the information is front-loaded with the core purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a creation/mutation tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation, what the tool returns, error conditions, or important behavioral constraints. The URL for viewing is helpful but doesn't compensate for the lack of output information and behavioral context needed for a mutation 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 100%, so the schema already documents all 10 parameters thoroughly with descriptions, required status, and defaults. The description adds no parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'ERP sisteminde yeni dekont başlığı oluşturur (Sipariş, Teklif, Fatura vb.)' which translates to 'creates a new document header in the ERP system (Order, Quote, Invoice, etc.)'. This specifies the verb ('oluşturur' - creates) and resource ('dekont başlığı' - document header) with examples. It distinguishes from siblings like erp_dekont_listele (list) and erp_dekont_duzenle (edit), but doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions a URL for viewing created documents ('Görüntülemek için...'), this is post-creation information, not usage guidance. There's no mention of prerequisites, when to choose this over erp_dekont_duzenle (edit), or any context about the creation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'completes and finalizes the receipt/transaction,' implying a write/mutation operation that likely changes state (e.g., from draft to finalized). However, it doesn't mention whether this action is reversible, what permissions are required, if it triggers side effects (e.g., notifications, accounting entries), or what happens on success/failure. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the core action stated first ('Dekontu tamamlar ve işlemi sonlandırır'). The second sentence provides a useful URL for viewing, which adds value without redundancy. However, the URL could be more integrated (e.g., explaining it's for verification), slightly reducing efficiency.
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 this is a mutation tool (implied by 'tamamlar') with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, updated receipt data), error conditions, or behavioral nuances like idempotency. For a tool that likely alters business data, more context is needed to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'DekontID' documented as mandatory. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples, where to find the ID, or validation rules). With high schema coverage, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('tamamlar' - completes/finalizes) and resource ('Dekontu' - the receipt/voucher). It distinguishes from sibling tools like 'erp_dekont_duzenle' (edit receipt) and 'erp_dekont_olustur' (create receipt) by indicating this is a finalization action. However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions a URL for viewing the receipt, it doesn't specify prerequisites (e.g., must be in draft state), exclusions, or when to choose this over other receipt-related tools like 'erp_dekont_duzenle'. The agent receives no usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states it fetches a warehouse list without mentioning whether this is a read-only operation, if it requires authentication, what the output format might be, or any rate limits. For a tool with no annotation coverage, this leaves significant behavioral 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 a single, efficient sentence that states the core purpose without any unnecessary words. It's appropriately sized and front-loaded with the essential information. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with 3 parameters, the description is incomplete. It doesn't explain what the returned warehouse list contains, how results are formatted, whether there's pagination, or any error conditions. For a list-fetching tool with multiple parameters, more context would be helpful for the agent.
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%, so the schema already documents all three parameters with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - gets/fetches) and resource ('depo listesini' - warehouse list) from the ERP system. It specifies what the tool does in a straightforward manner. However, it doesn't differentiate from sibling tools like 'erp_stok_listele' or 'erp_cari_listele' which also fetch lists of different resources, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for warehouse selection, or comparison with other list-fetching tools in the sibling set. The agent must infer usage purely from the tool name and description without any explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('fetches currency list') without mentioning whether this is a read-only operation, what permissions might be required, whether there are rate limits, pagination behavior, or what format the returned data takes. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Turkish that directly states the tool's purpose. There's zero waste or unnecessary elaboration. It's appropriately sized for a simple list operation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what the return format looks like, whether this is a safe read operation, or provide any context about the ERP system integration. Given the complexity of ERP systems and lack of structured metadata, the description should do more to help an agent understand how to work with this 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 100%, so the schema already documents both parameters (DovizID for filtering and SiralamaKisiti for sorting). The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - fetches) and resource ('döviz listesini' - currency list) from the ERP system. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'erp_banka_listele' or 'erp_kasa_listele' which follow similar patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate, what prerequisites might exist, or how it differs from other list tools in the sibling set like 'erp_cari_listele' or 'erp_stok_listele'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation but doesn't disclose behavioral traits like whether it's paginated (implied by parameters but not stated), rate limits, authentication requirements, error conditions, or what the output format looks like. For a 10-parameter tool with no annotations, 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?
Extremely concise single sentence with zero waste. It's front-loaded with the core purpose and uses minimal words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the return format, pagination behavior, error handling, or authentication needs. For a list tool with extensive filtering options, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema with clear descriptions. The description doesn't add any additional parameter semantics beyond what's in the schema (it doesn't explain how filters combine, default behaviors, or parameter interactions). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('listeler' - lists) and resource ('fatura hareketlerini' - invoice transactions) from the ERP system. It distinguishes from most siblings that list different resources (e.g., bank, customer, stock), though it doesn't explicitly differentiate from other list tools like 'erp_siparis_listele' (order list) which might have similar filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for filtering, or comparison with other list tools (like 'erp_stok_hareketleri_listele' for stock movements). The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the retrieval action without mentioning whether this is a read-only operation, if it requires authentication, what the return format looks like, or any rate limits. For a tool with no annotation coverage, this leaves significant behavioral 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what data is returned, the format, pagination behavior, or error conditions. While the schema covers input parameters well, the overall context for proper tool invocation remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for both parameters. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description doesn't enhance understanding of when or how to use these filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - fetches/retrieves) and resource ('kasa listesini' - cash register list) from the ERP system. It distinguishes the resource type from siblings like 'banka_listele' (bank list) or 'cari_listele' (account list), but doesn't explicitly differentiate the retrieval method from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any specific context, prerequisites, or exclusions, nor does it reference sibling tools like 'erp_cari_listele' for accounts or 'erp_stok_listele' for inventory, leaving the agent to infer usage based on naming patterns alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it retrieves a list but doesn't describe what format the list returns, whether it's paginated, if there are rate limits, authentication requirements, or any side effects. For a read operation with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple list retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for effective tool usage. While it states the basic purpose, it lacks critical information about return format, authentication needs, error conditions, or behavioral constraints. For a tool with 2 parameters and no structured metadata, the description should provide more operational 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%, so the schema already documents both parameters with their descriptions. The description doesn't add any additional parameter context beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('getirir' - gets/fetches) and resource ('personel listesini' - personnel list) from the ERP system. It distinguishes from siblings like 'erp_personel_mesai_hareket' which handles personnel overtime movements, but doesn't explicitly differentiate from other list tools like 'erp_cari_listele' or 'erp_stok_listele' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other personnel-related tools, or any contextual constraints. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the data source (ERP from PDSK devices) and that it lists hours worked, but doesn't describe return format, pagination, authentication needs, rate limits, or whether this is a read-only operation. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that states the core purpose without unnecessary elaboration. It's appropriately sized for the tool's complexity. However, it could be slightly more structured by separating the data source from the 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 no annotations, no output schema, and 4 parameters, the description is incomplete. It doesn't explain what the return data looks like (structure, fields), authentication requirements, error conditions, or how the tool interacts with the ERP system. For a data retrieval tool with multiple filtering parameters, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters with their purposes. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions filtering by personnel and listing hours, which aligns with the parameters but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.
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: it pulls overtime movement data from AARO ERP (specifically from PDSK devices) and lists which personnel worked how many hours. It uses specific verbs ('çeker' - pulls, 'listeler' - lists) and identifies the resource (personnel overtime movements). However, it doesn't explicitly differentiate from sibling tools like 'erp_personel_listele' which might list personnel without overtime data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not scenarios, or compare with sibling tools like 'erp_personel_listele' or other ERP listing tools. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists order movements, but doesn't describe whether this is a read-only operation, if it requires authentication, what the output format looks like, or any rate limits. For a tool with 9 parameters and no annotations, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. There's no wasted verbiage or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'order movements' specifically includes, how results are structured, whether pagination is handled, or any error conditions. For a list tool with multiple filtering parameters, more context about the return format and behavior would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description doesn't add any additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('listeler' - lists) and resource ('sipariş hareketleri' - order movements) from the ERP system. It specifies what is being listed, making the purpose understandable. However, it doesn't differentiate from sibling tools like 'erp_fatura_listele' (invoice listing) or 'erp_stok_hareketleri_listele' (stock movement listing), which would require 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on context, prerequisites, or comparisons to sibling tools like 'erp_fatura_listele' or 'erp_stok_hareketleri_listele'. It merely states what the tool does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('listeler') without mentioning whether it's read-only, requires authentication, has rate limits, pagination behavior, or what format the output takes. For a tool with 10 parameters and no output schema, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, pagination behavior, authentication requirements, or error conditions. The agent would need to guess about important behavioral aspects despite the comprehensive parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters with clear descriptions. The description doesn't add any additional parameter information beyond what's in the schema, making the baseline 3 appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('listeler' - lists) and resource ('stok hareketleri' - stock movements) from the ERP system. It's specific about what it does, though it doesn't differentiate from sibling tools like 'erp_stok_listele' which might list stock items rather than movements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for use, or comparison with sibling tools like 'erp_stok_listele' or 'erp_siparis_listele' that might handle related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool creates a stock card and mentions providing a URL afterward, which hints at a successful creation response. However, it doesn't cover critical behavioral aspects: required permissions, whether the operation is idempotent, error conditions, rate limits, or what happens if duplicate stock codes are used. For a creation tool with 10 parameters, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address core functionality. The first sentence states the primary action, and the second provides useful operational context about the response URL. There's no unnecessary verbiage, though it could be slightly more structured by separating behavioral details from the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns beyond implying an ID is generated for the URL. It lacks information about error handling, authentication requirements, and the relationship between parameters (e.g., how TipID affects the created record). The description should provide more context about the creation operation's behavior and outcomes.
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%, with each parameter documented in the schema (e.g., 'StokKodu' as mandatory stock code, 'TipID' with default value 105001). The description adds no parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'ERP sisteminde yeni stok kartı oluşturur' (creates a new stock card in the ERP system). It specifies the verb ('oluşturur' - creates) and resource ('stok kartı' - stock card), making the action explicit. However, it doesn't differentiate from sibling tools like 'erp_cari_olustur' (create customer) or 'erp_dekont_olustur' (create voucher), which follow similar creation patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), distinguish it from similar creation tools in the sibling list, or indicate scenarios where this tool is preferred over others. The second sentence about providing a URL to the user is operational rather than usage 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 carries full burden. It mentions sending a request to a test endpoint with headers and body, implying a read/write operation, but doesn't disclose critical behavioral traits: whether it's safe (e.g., read-only vs. destructive), authentication needs, rate limits, or response format. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and key usage detail. There's no unnecessary information, making it efficient, though it could benefit from slightly more structure for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, response handling, error cases, and differentiation from similar tools like 'erp_test_hook'. For a testing tool with potential side effects, this leaves significant gaps for an agent.
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%, so the schema already documents all parameters (endpoint, method, body, params). The description adds minimal value beyond the schema by mentioning headers and body usage, but doesn't provide additional semantics like format examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'Test amaçlı webhook URL'sine ERP API request'i gönderir' (Sends an ERP API request to a webhook URL for testing). It specifies the verb (sends request) and resource (webhook URL for ERP API testing). However, it doesn't explicitly differentiate from sibling 'erp_test_hook', which appears similar, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions using the same headers and body for testing endpoints, but offers no explicit when-to-use rules, no alternatives (e.g., vs. 'erp_test_hook'), and no prerequisites. This lack of context makes it unclear when an agent should choose this tool over others.
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. It mentions parsing HTML-formatted token text and caching, but doesn't disclose critical behavioral traits: whether this is a read/write operation, potential side effects (e.g., overwriting existing cache), authentication needs, error handling, or rate limits. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences that directly state the tool's function and a key constraint (HTML format). Every sentence earns its place with no wasted words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a parsing and caching operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or the implications of caching—leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'tokenText' parameter thoroughly. The description adds minimal value by noting that the token text may be in HTML format and should contain user, token, dates, and group information—hinting at expected content but not providing additional syntax or format details beyond the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manuel olarak token bilgilerini parse edip cache'e ekler' (Manually parses token information and adds it to cache). It specifies the verb (parse and add), resource (token information), and destination (cache). However, it doesn't explicitly differentiate from sibling tools like 'erp_token_al' or 'erp_token_sil', which would require 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where manual parsing is needed over automated methods (e.g., 'erp_token_al'), prerequisites, or exclusions. Without such context, the agent lacks clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves/fetches data, implying a read-only operation, but doesn't disclose behavioral traits like pagination behavior (hinted by 'Sayfa' and 'SayfaSatirSayisi' parameters), authentication requirements, rate limits, or what the return format looks like. The description is minimal and lacks necessary context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded: the first states the core purpose, and the second adds filtering capability. There's no wasted text, though it could be slightly more structured (e.g., separating purpose from usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is incomplete. It lacks information on return values, error handling, pagination details, and behavioral constraints. For a list retrieval tool with multiple filtering options, more context is needed to ensure proper usage.
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%, so the schema already documents all 7 parameters with clear descriptions. The description adds minimal value by mentioning 'filtreleme parametreleri' (filtering parameters), which aligns with the schema but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'getirir' (retrieves/fetches) the 'cari listesi' (customer/account list) from the ERP system. It specifies the resource (customer list) and verb (retrieve), but doesn't explicitly differentiate from sibling tools like 'erp_cari_olustur' (create customer) or other list tools beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'filtreleme parametreleri ile arama yapabilirsiniz' (you can search with filtering parameters), suggesting it's for filtered retrieval. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'erp_cari_olustur' for creation or other list tools for different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data and allows filtering, but doesn't disclose important behavioral traits like whether this is a read-only operation (implied but not stated), pagination behavior (though parameters exist), rate limits, authentication requirements, or what format the returned data takes. The description adds minimal value beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's purpose and basic capability. It's front-loaded with the core function and wastes no words. However, it could be slightly more structured by explicitly separating purpose from usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain the return format, pagination behavior (despite having pagination parameters), error conditions, or how filtering parameters interact. For a data retrieval tool with multiple filtering options, more contextual information would be helpful for an AI agent.
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%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond mentioning 'filtreleme parametreleri' (filtering parameters) generically. It doesn't explain parameter interactions, default behaviors, or provide examples beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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: 'ERP sisteminden stok listesini getirir' (retrieves stock list from ERP system). It specifies the verb ('getirir') and resource ('stok listesi'), but doesn't explicitly differentiate from sibling tools like 'erp_stok_hareketleri_listele' or 'erp_stok_olustur', which would require more specific scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by mentioning 'Filtreleme parametreleri ile arama yapabilirsiniz' (you can search with filtering parameters), suggesting this is for filtered retrieval. However, it doesn't explicitly state when to use this tool versus alternatives like 'erp_stok_hareketleri_listele' (stock movements) or 'erp_stok_olustur' (create stock), nor does it mention any prerequisites or 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. It discloses key behavioral traits: opens a browser, waits for user password input, and extracts token from '#anahtar' element. However, it doesn't cover important aspects like error handling, timeout behavior, what happens if password is wrong, or whether this creates persistent sessions. The description is informative but incomplete for a security-sensitive 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 appropriately concise with two sentences that efficiently cover the core functionality and authentication mechanism. It's front-loaded with the main purpose. There's minimal waste, though it could be slightly more structured by separating the authentication steps more clearly.
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 token acquisition tool with no annotations and no output schema, the description provides adequate context about the authentication process but lacks details on return values, error conditions, and security implications. It covers the 'how' (browser interaction) but not the 'what next' (token usage, expiration). Given the complexity of authentication flows, more completeness would be expected.
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 doesn't explicitly mention the 'password' parameter, but with 100% schema description coverage (the schema fully documents the single optional parameter), the baseline is 3. The description adds context about the authentication flow (browser interaction, manual entry fallback) which enhances understanding beyond the schema's technical specification, justifying a score above baseline.
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: 'ERP sisteminden geçici erişim anahtarı (token) alır' (gets a temporary access token from the ERP system). It specifies the verb 'alır' (gets) and resource 'token', but doesn't explicitly differentiate from sibling 'erp_token_manuel_ekle' (manual token add) or 'erp_token_sil' (token delete), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool opens a browser and waits for password entry, implying it's for authentication scenarios. However, it provides no explicit guidance on when to use this versus alternatives like 'erp_token_manuel_ekle' (manual token add) or when not to use it. No prerequisites or comparison to siblings is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the destructive nature (deletes token) and consequence (new token needed for future API calls), which is good behavioral context. However, it doesn't mention authentication requirements, rate limits, or error conditions that might be relevant for a token management operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly concise with two sentences that each earn their place. The first states the action, the second explains the consequence. No wasted words, front-loaded with the core 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?
For a zero-parameter destructive operation with no annotations or output schema, the description provides good context about what gets destroyed and the consequence. It could be more complete by mentioning authentication requirements or error scenarios, but given the simplicity of the operation (delete token), it's reasonably 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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and consequences. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('siler' - deletes) and resource ('Cache'deki token'ı' - token in cache), distinguishing it from siblings like 'erp_token_al' (get token) and 'erp_token_manuel_ekle' (add token manually). It provides a complete purpose statement with verb+resource+consequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Yeni API çağrıları için yeni token alınması gerekecek' - new token will be needed for new API calls) and implies when not to use it (when you want to keep the current token active). It distinguishes from sibling 'erp_token_al' which would be the alternative for obtaining a new token after deletion.
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:

[![aaro-erp-mcp-server MCP server](https://glama.ai/mcp/servers/AaroYazilim/aaro-erp-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/AaroYazilim/aaro-erp-mcp-server)

Score Badge

Copy to your README.md:

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

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