Volkern MCP Server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation4/5
Most tools have distinct purposes targeting specific CRM/ERP resources and actions, with clear boundaries like create_contact vs. update_contact. However, some overlap exists: volkern_create_cita and volkern_update_cita could be confused with volkern_cita_accion (which handles confirm/cancel/reschedule), and volkern_create_lead's update behavior on duplicate email might blur with volkern_update_lead. Descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case, using clear action verbs like create, get, list, update, send, and complete. The naming is highly predictable and readable across all 40 tools, with no deviations in style or convention, making it easy for agents to infer functionality.
Tool Count2/5
With 40 tools, the count feels excessive for a CRM/ERP server, likely leading to cognitive overload and reduced usability. While the domain is broad, many tools could be consolidated (e.g., separate list tools for each resource) or parameterized. This heavy toolset may overwhelm agents and slow down decision-making.
Completeness5/5
The toolset provides comprehensive coverage for CRM/ERP workflows, including full CRUD operations for leads, contacts, appointments, deals, contracts, and quotations, plus lifecycle actions like sending documents and logging interactions. No obvious gaps exist; agents can handle end-to-end processes from lead creation to contract signing and task management.
Average 3/5 across 40 of 40 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

Behavior1/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 only states it updates contact information, but doesn't disclose critical behavioral traits such as required permissions, whether the update is partial or full, what happens to unspecified fields, error handling, or any rate limits. This is inadequate for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Update an existing contact's information'), making it easy to parse quickly. Every word earns its place, though it could benefit from 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?
Given the complexity (a mutation tool with 9 parameters, low schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects, parameter meanings, usage context, or expected outcomes. For a tool that modifies data, this level of detail is insufficient to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 11%, with only 'contactId' having a description. The description adds no parameter semantics beyond what's implied by the tool name (e.g., it doesn't explain what fields like 'nombre', 'cargo', or 'tags' represent, their formats, or constraints). This fails to compensate for the poor schema coverage, leaving most parameters undocumented.
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 'Update an existing contact's information' clearly states the action (update) and resource (contact), but it's vague about what specific information can be updated. It distinguishes from sibling tools like 'volkern_create_contact' by specifying 'existing', but doesn't differentiate from other update tools like 'volkern_update_cita' or 'volkern_update_lead' 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. It doesn't mention prerequisites (e.g., needing a contactId), when not to use it (e.g., for creating new contacts), or how it compares to similar tools like 'volkern_create_contact' or 'volkern_get_contact'. The description only states the basic function without 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?
No annotations are provided, so the description carries the full burden. It mentions 'Get' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns real-time or cached data, or if it's a heavy computational query. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Get sales forecast and pipeline analytics'), making it easy to scan and understand quickly.
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 simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., forecast values, pipeline stages, metrics), behavioral constraints, or how it fits with sibling tools. For a data retrieval tool, this leaves critical gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'periodo' clearly documented as 'Forecast period' with enum values. The description adds no additional meaning beyond what the schema provides, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sales forecast and pipeline analytics' states the general purpose (retrieving forecast data) but lacks specificity about what exactly is retrieved (e.g., metrics, visualizations, raw data) and doesn't differentiate from sibling tools like 'volkern_get_deal' or 'volkern_list_deals' that might provide related sales data. It's vague about the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for sales data (e.g., 'volkern_get_deal', 'volkern_list_deals'), the description doesn't indicate if this is for aggregated analytics, future projections, or how it relates to other tools, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a new contract' implies a write/mutation operation but provides no information about permissions required, whether this is an irreversible action, what happens on success/failure, or any rate limits. The description is minimal and fails to address critical behavioral aspects for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words. While this represents under-specification rather than ideal conciseness, within the scoring framework it earns full points for having zero wasted words and being front-loaded with the essential 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?
For a 10-parameter creation tool with no annotations and no output schema, the description is severely inadequate. It doesn't explain what constitutes a successful creation, what gets returned, how errors are handled, or any prerequisites. The description fails to provide the contextual information needed for an agent to use this tool effectively in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter information beyond the tool name implying 'contract' creation. However, with 70% schema description coverage, the input schema documents most parameters well (e.g., 'titulo' as required contract title, date formats, payment method enums). The baseline of 3 is appropriate since the schema does substantial documentation work, though the description adds no value 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 action ('Create') and resource ('contract'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'volkern_create_contrato_from_cotizacion' or explain what makes this contract creation tool different from others in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With sibling tools like 'volkern_create_contrato_from_cotizacion' (which creates contracts from quotations) and 'volkern_send_contrato' (which sends contracts), there's no indication of when this basic creation tool is appropriate versus those specialized alternatives.
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 this is an update operation (implying mutation), but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. The description is minimal and lacks crucial context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core purpose.
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 9 parameters, low schema coverage (22%), no annotations, and no output schema, the description is inadequate. It doesn't explain the update behavior, error conditions, or return values, leaving the agent with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (22%), with only 'dealId' and 'etapa' having descriptions. The description mentions 'stage, value, status' which partially maps to parameters like 'etapa', 'valor', and 'estado', but doesn't explain the meaning of other parameters (e.g., 'titulo', 'prioridad', 'probabilidad'). It adds some value but doesn't compensate for the significant coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing deal'), and provides examples of what can be updated ('change stage, value, status, etc.'). It distinguishes from sibling 'volkern_create_deal' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'volkern_update_cita' or 'volkern_update_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a deal ID), when not to use it (e.g., for creating deals), or refer to sibling tools like 'volkern_get_deal' for checking existing deals first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with 9 parameters, 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 and front-loaded, with every word contributing to the core meaning.
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 9 parameters, 11% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't compensate for the lack of structured data by explaining behavioral traits, parameter meanings, or expected outcomes, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only leadId has a description), leaving 8 parameters undocumented. The description adds no parameter semantics beyond the schema, failing to explain what fields like 'canal', 'estado', or 'etiquetas' represent or their expected formats, which is inadequate given the low 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 verb ('Update') and resource ('an existing lead's information'), making the purpose unambiguous. It distinguishes this as an update operation rather than creation or retrieval, though it doesn't explicitly differentiate from sibling update tools like volkern_update_contact or volkern_update_deal.
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 an existing lead ID), when not to use it, or how it differs from sibling tools like volkern_update_contact or volkern_create_lead, leaving the agent to infer 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 but only states the action types without behavioral details. It doesn't disclose whether these actions are reversible, require specific permissions, have side effects (e.g., notifications), or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important behavioral context (e.g., that 'nuevaFecha' is required only for 'reprogramar', 'motivo' might be optional for 'cancelar').
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 fully documents all parameters. The description adds no additional parameter semantics beyond implying 'accion' has specific values, which is already covered by the enum 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 verb ('perform') and resource ('appointment'), and specifies the three possible actions (confirm, cancel, reschedule). However, it doesn't differentiate from sibling tools like 'volkern_update_cita' or 'volkern_list_citas', which could handle similar appointment operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'volkern_update_cita' for specific actions, or mention prerequisites like needing an existing appointment ID.
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. 'Mark a task as completed' implies a write/mutation operation but doesn't specify whether this requires special permissions, if the action is reversible, what happens to dependent items, or what confirmation/response to expect. For a mutation tool with zero annotation coverage, 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 extremely concise at just four words, front-loading the essential action without any wasted words. Every word earns its place by conveying the core functionality directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what happens after marking completion (success response, error conditions), whether this affects other system states, or any behavioral nuances. The description alone doesn't provide enough context for confident tool invocation despite the simple 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?
Schema description coverage is 100% with the single parameter 'taskId' well-documented in the schema. The description adds no additional parameter information beyond what's already in the structured 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 'Mark a task as completed' clearly states the action (mark as completed) and resource (task), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'volkern_update_task' (if it existed) or explain how this differs from simply updating a task's status field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'volkern_list_tasks' and 'volkern_create_task', there's no indication whether this is the primary method for task completion or if tasks should be completed through other means. No prerequisites, constraints, 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 full burden for behavioral disclosure. It states this is a creation operation but doesn't mention whether it requires authentication, what permissions are needed, if it's idempotent, what happens on duplicate data, or what the response looks like. For a mutation tool 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.
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 for a creation 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 mutation tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like error conditions, response format, or system constraints. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
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. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., 'cargo' only applies when 'tipo' is 'person'), nor does it provide examples or formatting guidance. 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 ('create') and resource ('new contact'), specifying it can be for a person or company. It distinguishes from sibling tools like 'volkern_update_contact' by indicating creation rather than modification, but doesn't explicitly differentiate from other creation tools like 'volkern_create_lead' or 'volkern_create_deal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'volkern_create_lead' or 'volkern_create_deal', nor does it mention prerequisites, dependencies, or contextual constraints. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation (implying mutation/write), but doesn't disclose any behavioral traits like required permissions, whether it's idempotent, what happens if the quotation isn't accepted, or what the response contains. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for this tool's purpose 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 mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, error conditions, response format, or relationships with other tools. Given the complexity of contract creation and the lack of structured metadata, the description should provide more context about how this operation works.
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 80% (4 of 5 parameters have descriptions), so the baseline is 3. The description doesn't add any parameter semantics beyond what the schema provides - it doesn't explain relationships between parameters, format requirements for dates, or the significance of 'metodoPago' choices. It relies entirely on the schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a contract') and the source ('from an accepted quotation'), providing a specific verb+resource combination. It distinguishes from sibling 'volkern_create_contrato' by specifying the quotation source, though it doesn't explicitly contrast with other contract-related tools like 'volkern_send_contrato'.
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., the quotation must be accepted), when not to use it, or how it differs from 'volkern_create_contrato' which appears to create contracts without a quotation source. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new quotation/quote' implies a write operation, but it doesn't specify permissions required, whether the creation is irreversible, what happens on success/failure, or if there are rate limits. This leaves significant gaps for a mutation tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, making it front-loaded and efficient. Every word contributes directly to stating the tool's purpose without any redundancy or unnecessary elaboration, which is ideal for brevity.
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 of a creation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like error handling, return values, or prerequisites, leaving the agent with incomplete guidance for proper invocation in a system with many sibling tools.
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 fully documents all 5 parameters. The description adds no additional parameter information beyond what's in the schema, such as explaining relationships between 'leadId' and 'dealId' or clarifying 'validezDias' usage. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 ('create') and resource ('quotation/quote'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'volkern_create_contrato_from_cotizacion' or 'volkern_send_cotizacion', which would require more specificity about when to create versus convert or send a quotation.
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 'volkern_create_contrato_from_cotizacion' (which creates a contract from a quotation) and 'volkern_update_cotizacion' (which updates an existing quotation), the agent lacks context on whether to create a new quotation or modify an existing one, or how this relates to other creation tools like 'volkern_create_deal'.
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 creates a deal, implying a write operation, but lacks details on permissions, side effects (e.g., impact on pipeline stages), or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain behavioral aspects like error handling, default values beyond the schema, or how the deal integrates with the sales pipeline, leaving significant gaps in understanding.
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-specific information beyond what's in the schema, which has high coverage (91%). Parameters like 'titulo', 'valor', and 'etapa' are well-documented in the schema, so the baseline score of 3 is appropriate as the schema does the heavy lifting without extra value from 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 action ('Create') and resource ('new deal/opportunity in the sales pipeline'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'volkern_create_lead' or 'volkern_create_contact', which also create sales-related entities, missing an opportunity for full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like needing a lead or contact first, or clarify its role in the sales pipeline relative to tools like 'volkern_create_lead' or 'volkern_update_deal', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Log an interaction') without disclosing behavioral traits. It doesn't mention permissions needed, whether this is a write operation, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It uses parentheses to clarify interaction types without redundancy, making it appropriately sized with zero waste for a simple logging 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral context like whether logging is idempotent or requires specific lead states. Given the complexity of creating data with nested objects, more guidance 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 5 parameters with descriptions and enums. The description adds no additional meaning beyond implying parameters like 'tipo' and 'contenido' through the example interaction types, but doesn't clarify syntax or usage beyond what the schema provides. 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 ('Log') and resource ('an interaction with a lead'), specifying interaction types like call, email, meeting. It distinguishes from siblings like volkern_create_note or volkern_create_task by focusing on logging interactions, but doesn't explicitly differentiate from volkern_list_interactions or other create operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like volkern_create_note or volkern_create_task, which might overlap for note-taking. It mentions logging interactions with leads but doesn't specify prerequisites, exclusions, or when to choose other tools like volkern_list_interactions for viewing logs.
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 'Create' which implies a write operation, but doesn't address permissions, side effects (e.g., whether notes are editable or permanent), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks behavioral details (e.g., what happens on success/failure), usage context, and output expectations, leaving significant gaps in understanding how to invoke and interpret results from 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?
The schema description coverage is 100%, with clear descriptions for 'leadId', 'contenido', and 'titulo'. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a note for a lead' clearly states the verb ('Create') and resource ('note for a lead'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'volkern_create_contact' or 'volkern_create_task' beyond specifying the resource type, 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. There's no mention of prerequisites (e.g., needing an existing lead), exclusions, or comparisons to similar tools like 'volkern_create_interaction' or 'volkern_list_notes', leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'create' but does not explain whether this is a write operation, what permissions are required, if it's idempotent, or what happens on success/failure. This leaves critical behavioral traits unspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits like side effects, error handling, or return values, leaving gaps in understanding how to use the tool effectively in 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 input schema has 100% description coverage, so the schema fully documents all parameters. The description adds no additional semantic context beyond implying a 'follow-up' context, which is minimal. Baseline 3 is appropriate as the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('follow-up task for a lead'), which is specific and actionable. However, it does not differentiate this tool from sibling tools like 'volkern_create_cita' or 'volkern_create_note', which also create related entities for leads, leaving some ambiguity about when to choose this over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'volkern_create_cita' for appointments or 'volkern_create_note' for notes, nor does it mention prerequisites like lead existence or user permissions. It lacks explicit context for selection among sibling 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?
No annotations are provided, so the description carries full burden. It states the tool retrieves information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'detailed information' includes. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get detailed information'). There is zero waste—every word contributes directly to the purpose without redundancy or unnecessary elaboration.
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 a tool that retrieves data. It doesn't explain what 'detailed information' includes, potential response formats, or error cases. For a read operation with no structured output documentation, this leaves the agent guessing about return values and behavior.
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 the single parameter 'contactId' documented as 'The contact's unique ID'. The description adds no additional meaning beyond this, such as format examples or sourcing details. With high schema coverage, the baseline score of 3 is appropriate as 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 verb ('Get') and resource ('detailed information about a specific contact'), making the purpose explicit. It distinguishes from sibling 'volkern_list_contacts' by specifying retrieval of a single contact by ID rather than listing multiple contacts. However, it doesn't fully differentiate from other 'get_' tools like 'volkern_get_lead' 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. It doesn't mention prerequisites (e.g., needing a valid contact ID), when not to use it (e.g., for bulk retrieval), or explicit alternatives like 'volkern_list_contacts' for listing multiple contacts. Usage is implied 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 but only states it 'gets' information without disclosing behavioral traits. It doesn't mention if this is a read-only operation, requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps for a tool that likely interacts with a CRM system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get detailed information') without unnecessary words. Every part earns its place by specifying the resource and scope, making it appropriately sized for a simple 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 the tool's complexity (likely a CRM deal lookup), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, return format, error cases, or authentication needs, leaving the agent with insufficient context to use it effectively beyond basic parameter passing.
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 the input schema, which has 100% coverage and clearly documents the 'dealId' parameter. Since schema coverage is high, the baseline score is 3, as the description doesn't need to compensate but also doesn't provide extra context like ID format examples or sourcing tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific deal'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'volkern_list_deals' or 'volkern_update_deal', which would require mentioning it's for retrieving a single deal's details rather than listing or modifying.
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 a deal ID), contrast with 'volkern_list_deals' for multiple deals, or specify scenarios like viewing deal status versus updating it with 'volkern_update_deal'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists appointments with optional filters, implying a read-only operation, but doesn't clarify critical behaviors like pagination, default sorting, error handling, or authentication requirements. For a list tool with 5 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—and front-loaded with the core purpose. There is no wasted language, making it easy for an agent to parse quickly. It efficiently communicates the essential action without unnecessary elaboration.
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 (5 optional parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the output looks like (e.g., list format, fields included), how filters interact, or any limitations (e.g., date range constraints). For a tool with multiple filtering options and no structured output documentation, more context is needed to guide 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?
The description mentions 'optional filters' but doesn't elaborate on parameter meanings beyond what the schema provides. Since schema description coverage is 100% (each parameter has a clear description, including enums for 'estado' and 'tipo'), the baseline score is 3. The description adds no additional semantic context about how filters combine or their impact on results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'List appointments with optional filters', which specifies the verb ('list') and resource ('appointments'). It distinguishes from sibling tools like 'volkern_create_cita' (create) and 'volkern_update_cita' (update), but doesn't explicitly differentiate from other list tools like 'volkern_list_contacts' or 'volkern_list_tasks' beyond the appointment focus.
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 mentions 'optional filters' but doesn't specify scenarios for filtering (e.g., when to filter by status vs. date) or compare it to other list tools (e.g., 'volkern_list_interactions' for broader records). Without explicit usage context, the agent must infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation (listing) but doesn't disclose pagination behavior (implied by 'page'/'limit' parameters), rate limits, authentication needs, or what happens with no filters. The mention of 'optional filters' hints at flexibility but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) and front-loaded with the core action ('List contracts'). There is zero wasted language, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values (e.g., contract fields, pagination metadata), error conditions, or usage context. The lack of behavioral transparency and parameter guidance leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (3 of 5 parameters have descriptions), so the baseline is 3. The description adds marginal value by hinting at filtering ('optional filters'), but doesn't elaborate on parameter interactions (e.g., combining 'estado' and 'search') or default behaviors. It doesn't compensate for the undocumented 'page' and 'limit' parameters beyond what the schema implies.
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 ('List') and resource ('contracts'), making the purpose understandable. It distinguishes itself from sibling tools like 'volkern_get_contrato' (singular retrieval) by implying it returns multiple contracts. However, it doesn't explicitly differentiate from other list tools (e.g., 'volkern_list_cotizaciones'), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives. It doesn't specify if this is for browsing all contracts versus filtered searches, or when to prefer it over other list tools (e.g., 'volkern_list_deals'). No exclusions or prerequisites 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 this is a list operation with filters, implying it's likely read-only and non-destructive, but doesn't confirm this or address other behaviors like pagination (implied by page/limit parameters), rate limits, authentication needs, or what the output looks like. This leaves significant gaps for a tool with 4 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List quotations/quotes') and adds qualifying information ('with optional filters') without unnecessary words. Every element serves a purpose, making it appropriately concise for a listing 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, no output schema, and 4 parameters with only 50% schema description coverage, the description is incomplete. It doesn't address key contextual aspects like return format, pagination behavior, error handling, or how filters interact, which are crucial for an agent to use this tool effectively in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (2 of 4 parameters have descriptions: estado and search). The description adds minimal value by mentioning 'optional filters' but doesn't elaborate on parameter usage, relationships, or examples. It partially compensates for the lack of schema descriptions for page and limit, but not sufficiently to elevate the 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 action ('List') and resource ('quotations/quotes') with the addition of 'with optional filters' which provides context about functionality. It distinguishes this as a listing operation among siblings that include creation, update, and get operations, though it doesn't explicitly differentiate from other list tools like volkern_list_contacts or volkern_list_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives like volkern_get_cotizacion (for a single quote) or other list tools. There's no indication of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'optional filters' but doesn't disclose pagination behavior (implied by 'page' and 'limit' parameters), rate limits, authentication requirements, or what the response format looks like (no output schema). This leaves significant gaps for a listing tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List deals/opportunities') and adds essential context ('in the sales pipeline with optional filters'). There's no wasted wording, making it appropriately concise for a straightforward listing 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 the tool's complexity (6 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain return values, pagination behavior, error conditions, or how filters interact. For a list operation with multiple filtering options, more contextual guidance is needed to complement the partial schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 out of 6 parameters have descriptions), providing solid baseline documentation. The description adds marginal value by mentioning 'optional filters' in general, but doesn't elaborate on parameter usage, relationships, or constraints beyond what the schema already covers for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('deals/opportunities in the sales pipeline'), and mentions optional filters. It distinguishes this as a listing operation, but doesn't explicitly differentiate from other list tools like 'volkern_list_leads' or 'volkern_list_contacts' 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. It doesn't mention sibling tools like 'volkern_get_deal' (for single deal retrieval) or 'volkern_list_pipeline_stages' (for stage listing), nor does it specify prerequisites or contextual constraints for filtering deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't mention any behavioral traits such as pagination, rate limits, authentication requirements, or what 'interactions' entail (e.g., types, formats). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and target, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. It doesn't explain what 'interactions' include (e.g., calls, emails, meetings), the return format, or any constraints like date ranges or filtering options. For a list tool with rich sibling tools, this leaves significant gaps in understanding its full 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 input schema has 100% description coverage, with the 'leadId' parameter fully documented in the schema. The description adds no additional meaning beyond implying the parameter is required for filtering, which is already clear from the schema. This meets the baseline score of 3 when schema coverage is high.
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 ('List all interactions') and the target resource ('for a specific lead'), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'volkern_list_conversaciones' or 'volkern_list_notes' which might also list related entities, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'volkern_get_lead' for lead details or 'volkern_create_interaction' for creating interactions, leaving the agent to infer usage context without explicit 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 it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits such as pagination, sorting, error handling, or authentication requirements. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to parse quickly.
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. It doesn't explain what the output looks like (e.g., list format, fields included), behavioral aspects like rate limits, or error conditions. For a tool with no structured metadata, this leaves the agent under-informed.
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 'leadId' parameter. The description adds no additional meaning beyond implying the parameter is used to filter notes by lead, which is already clear from 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 verb ('List') and resource ('notes'), specifying it's for a 'specific lead'. It distinguishes from general note-listing tools but doesn't explicitly differentiate from sibling tools like 'volkern_list_interactions' or 'volkern_list_tasks' which might also relate to leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this should be used instead of 'volkern_get_lead' for note retrieval or clarify its role among other list tools like 'volkern_list_interactions'.
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 a read operation ('List'), but doesn't cover aspects like authentication needs, rate limits, pagination, error handling, or what the output looks like (e.g., list format, fields included). This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 front-loaded and wastes no space, making it easy to parse quickly.
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 simple parameter, the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), output format, and usage context, which are crucial for an AI agent to invoke this tool effectively in a server with many sibling tools.
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 'leadId' clearly documented as 'ID of the lead'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it 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 action ('List') and resource ('tasks') with a specific scope ('for a specific lead'), which distinguishes it from generic list tools. However, it doesn't explicitly differentiate from sibling tools like 'volkern_list_notes' or 'volkern_list_interactions' that also list items for leads, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare to other list tools like 'volkern_list_leads' or 'volkern_list_citas', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('send') but lacks details on side effects (e.g., triggers email, updates contract status), permissions required, rate limits, or error conditions. This is a significant gap for a mutation tool that likely interacts with external systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('send a contract', 'to the client', 'for signature') contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what happens after sending (e.g., contract status changes, email delivery confirmation), error handling, or response format. For a tool that likely involves external communication, 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 both parameters ('contratoId' and 'mensaje') adequately. The description adds no additional meaning beyond implying these parameters are used to send a contract, which is already clear from the tool name and 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 action ('send') and resource ('contract') with the purpose ('for signature'), making the tool's function immediately understandable. It distinguishes itself from siblings like 'volkern_get_contrato' (retrieve) and 'volkern_create_contrato' (create), though it doesn't explicitly differentiate from 'volkern_send_cotizacion' (send quote) 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. It doesn't mention prerequisites (e.g., contract must exist), exclusions (e.g., cannot send if already signed), or related tools like 'volkern_get_contrato' for checking contract status before sending. The agent must infer usage from the name and description 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, the description carries full burden but only states the basic action. It lacks details on behavioral traits such as whether the email is sent immediately or queued, if it requires specific permissions, potential rate limits, or what happens on failure (e.g., error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's complexity and front-loaded with the essential 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 and no output schema, the description is incomplete for a mutation tool. It doesn't cover behavioral aspects like side effects (e.g., email sent, status updated), error conditions, or response format, leaving significant gaps for an AI agent to understand the tool fully.
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 fully documents both parameters ('cotizacionId' and 'mensaje'). The description doesn't add any meaning beyond this, such as explaining the email format or how the custom message integrates, but the schema provides adequate baseline information.
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 ('send') and target ('quotation to the client via email'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'volkern_send_contrato' or 'volkern_send_whatsapp', which also involve sending documents via different channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a created quotation), exclusions, or comparisons to siblings like 'volkern_send_contrato' for contracts or 'volkern_send_whatsapp' for WhatsApp messages.
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 'Update' implies mutation, it doesn't specify required permissions, whether changes are reversible, error conditions, or what happens to unspecified fields. For a mutation 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 that communicates the core purpose without unnecessary words. It's appropriately sized for a basic tool description 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 mutation tool with 5 parameters, 40% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the update operation returns, what fields are optional versus required beyond the schema, or how the tool behaves in edge cases. The context demands more comprehensive guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, with 3 of 5 parameters lacking descriptions in the schema. The tool description adds no parameter-specific information beyond the general 'update' concept, failing to compensate for the schema gaps. However, the schema does document the required 'citaId' and provides an enum for 'estado', establishing a 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 action ('Update') and resource ('an existing appointment'), making the purpose immediately understandable. It distinguishes this from creation tools like 'volkern_create_cita', but doesn't specify what aspects can be updated beyond the general concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'volkern_cita_accion' or 'volkern_complete_task'. There's no mention of prerequisites, constraints, or appropriate contexts for updating appointments versus other appointment-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists conversations, implying a read-only operation, but does not disclose any behavioral traits such as pagination behavior (implied by 'page' and 'limit' parameters but not explained), rate limits, authentication needs, or what happens when no lead filter is applied. This leaves significant gaps for an agent to understand how to invoke it effectively.
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 is front-loaded with the core purpose ('List WhatsApp conversations') and includes an optional filter detail. There is no wasted language, and it is appropriately sized for the tool's complexity.
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 3 parameters with low schema coverage (33%), no annotations, and no output schema, the description is incomplete. It does not provide enough context for an agent to fully understand how to use the tool, such as explaining pagination behavior, response format, or error conditions. The description alone is insufficient for a list tool with multiple parameters and no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 'leadId' has a description), and the description adds minimal value beyond the schema. It mentions 'optionally filtered by lead', which aligns with 'leadId', but does not explain the semantics of 'page' and 'limit' parameters (e.g., pagination details, default values, or constraints). With low schema coverage, the description fails to compensate adequately for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List WhatsApp conversations') and resource ('WhatsApp conversations'), which is specific and unambiguous. It distinguishes from siblings like 'volkern_list_contacts' or 'volkern_list_leads' by focusing on WhatsApp conversations. However, it doesn't explicitly differentiate from other list tools in terms of scope or verb specificity 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 by mentioning optional filtering by lead ('optionally filtered by lead'), which suggests a context for when to apply this filter. However, it lacks explicit guidance on when to use this tool versus alternatives like 'volkern_list_leads' or 'volkern_list_interactions', and does not specify any exclusions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't clarify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by directly conveying the tool's function, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output format. Without annotations or output schema, more completeness would be beneficial, but it meets a basic threshold.
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 the parameter 'contratoId' clearly documented as 'The contract's unique ID'. The description adds no additional meaning beyond this, such as format examples or sourcing instructions. Since the schema does the heavy lifting, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific contract'), making the purpose immediately understandable. It distinguishes from sibling tools like 'volkern_list_contratos' by focusing on a single contract rather than listing multiple. However, it doesn't specify what 'detailed information' includes, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a contract ID), contrast with 'volkern_list_contratos' for browsing contracts, or specify use cases like retrieving contract details for review or updates. This leaves the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify whether this requires authentication, what format the information returns in, potential error conditions, or any rate limits. For a tool with zero 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, clear sentence that immediately communicates the core function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, without annotations covering safety/behavior and no output schema to describe return values, it leaves the agent guessing about important aspects like response format, error handling, and authentication requirements.
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 'a specific quotation' which implies the need for an identifier, but doesn't explicitly reference the 'cotizacionId' parameter. With 100% schema description coverage (the schema fully documents the single required parameter), the description adds minimal value beyond what's already in the structured schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific quotation'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar siblings like 'volkern_get_contact' or 'volkern_get_contrato' beyond specifying 'quotation' as 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. With siblings like 'volkern_list_cotizaciones' (for listing multiple quotations) and 'volkern_create_cotizacion' (for creating new ones), there's no indication that this tool is specifically for retrieving detailed information about a single, existing quotation identified by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' which implies a read-only operation, but doesn't specify aspects like authentication requirements, rate limits, error handling, or what constitutes 'detailed' information. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about a specific service'). There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single required parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., safety, performance) and return values, which are important for a read operation. The description covers the basic purpose but doesn't fully compensate for missing structured data.
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 parameter 'servicioId' documented as 'The service's unique ID.' The description doesn't add any meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific service'), making the purpose understandable. It distinguishes from siblings like 'volkern_list_servicios' by specifying retrieval of a single service rather than listing multiple. However, it doesn't explicitly contrast with other 'get' tools (e.g., 'volkern_get_contact'), leaving some ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a service ID), exclusions, or comparisons to siblings like 'volkern_list_servicios' for listing services or other 'get' tools for different resources. Usage is implied only through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns paginated results,' which is useful for understanding output behavior. However, it lacks critical details such as whether this is a read-only operation (implied but not stated), any rate limits, authentication requirements, or error handling. For a list tool with no annotations, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences: 'List leads with optional filters. Returns paginated results.' Every word earns its place by covering the core action, scope, and a key behavioral trait (pagination) without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and pagination but misses details like response format, error cases, or how filters combine. Without annotations or output schema, more context on behavior and results would improve completeness, making this minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter details including enums for 'estado' and 'canal.' The description adds minimal value beyond the schema, only implying filtering via 'optional filters' without elaborating on parameter interactions or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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: 'List leads with optional filters.' It specifies the verb ('List') and resource ('leads'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this tool from sibling list tools like 'volkern_list_contacts' or 'volkern_list_deals' beyond the resource type, which is why it doesn't reach 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 mentions 'optional filters' but doesn't specify scenarios or prerequisites, such as whether it should be used for broad queries versus specific lookups (e.g., compared to 'volkern_get_lead'). There's no mention of when-not-to-use or explicit alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'lists available services' but doesn't describe what 'available' means (e.g., based on user permissions, catalog status), whether it's read-only, if there are rate limits, or the format of the output. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, with no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details (e.g., output format, pagination, error handling) that would help an agent use it correctly, especially with no annotations to fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'activo' clearly documented as filtering for active services with a default of true. The description adds no additional parameter information beyond what the schema provides, 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 action ('List') and resource ('available services from the catalog'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'volkern_get_servicio' by indicating it returns multiple items rather than a single one, though it doesn't explicitly contrast with other list tools like 'volkern_list_citas' or 'volkern_list_contacts'.
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 sibling tools like 'volkern_get_servicio' for retrieving a specific service or clarify if this is for browsing versus detailed queries. Usage is implied by the name 'list' but lacks explicit context or exclusions.
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 'optional filters' but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, pagination behavior beyond parameters, rate limits, or what the output looks like. For a list tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List contacts') and adds qualifying details ('people or companies' and 'optional filters') without waste. Every word earns its place, making it easy to parse quickly.
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 a tool with 4 parameters and list functionality. It doesn't explain return values, pagination behavior, error handling, or authentication needs. For a read operation in a CRM context, more context on output format and constraints 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?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds minimal value beyond the schema by mentioning 'optional filters', which aligns with the parameters but doesn't provide additional semantics like filter combinations or search syntax. 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 ('List') and resource ('contacts'), specifying they can be 'people or companies'. It distinguishes the tool's purpose from siblings like 'volkern_get_contact' (single contact retrieval) and 'volkern_create_contact' (creation). However, it doesn't explicitly differentiate from other list tools (e.g., 'volkern_list_leads'), which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'optional filters', suggesting it's for browsing or searching contacts. It doesn't provide explicit guidance on when to use this versus alternatives like 'volkern_get_contact' for single contacts or 'volkern_list_leads' for leads. No exclusions or prerequisites 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?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits such as pagination, rate limits, authentication requirements, or what 'configured for the tenant' entails. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It specifies what resource is listed and the scope ('for the tenant'), but lacks details on output format, behavioral constraints, or differentiation from siblings, which could be helpful despite the simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is applied since it doesn't add unnecessary information.
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 ('List all') and resource ('pipeline stages configured for the tenant'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'volkern_list_deals' or 'volkern_list_contacts', which follow a similar pattern for other resources.
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, context, or compare it to other list tools in the sibling set, leaving the agent to infer usage based on naming conventions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the WhatsApp integration requirement but doesn't describe what happens when sending fails, whether messages are queued or sent immediately, rate limits, delivery confirmation, or what the tool returns. For a messaging tool with zero 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 perfectly concise - two short sentences that communicate essential information with zero wasted words. It's front-loaded with the core purpose followed by an important constraint.
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 messaging tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after sending (success/failure response, delivery status), doesn't mention authentication requirements beyond the integration note, and provides minimal behavioral context. The tool needs more complete operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific 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 action ('Send a WhatsApp message') and target ('to a lead'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling messaging tools (though none are listed among siblings).
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 one important usage constraint ('Requires active WhatsApp integration'), which gives context about prerequisites. However, it offers no guidance on when to use this vs. other communication methods or when WhatsApp messaging is appropriate vs. inappropriate.
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 status precondition ('only if status is 'borrador''), which is useful, but lacks details on permissions required, whether updates are reversible, error handling, or what happens to unchanged fields. For a mutation tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and key constraint. There is no wasted wording, making it easy to parse quickly for an AI agent.
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 (5 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks information on return values, error conditions, side effects, and detailed parameter usage, leaving the agent with insufficient context to use the tool effectively beyond the basic precondition.
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 40% (only cotizacionId and items have descriptions), so the description must compensate but doesn't add parameter details. It implies that 'estado' can be updated (via the 'borrador' reference) but doesn't explain the enum values or other parameters like validezDias and notas. The description adds minimal value beyond the schema, meeting the baseline for moderate 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 action ('Update') and resource ('a quotation'), making the purpose evident. However, it doesn't distinguish this tool from sibling update tools like volkern_update_cita or volkern_update_contact, which follow similar patterns for different resources.
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 an implicit usage guideline by stating 'only if status is 'borrador'', which suggests this tool should be used for draft quotations. However, it doesn't explicitly mention when to use alternatives (e.g., volkern_create_cotizacion for new quotations or volkern_send_cotizacion for sending) or other constraints like authentication needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying it's a read-only operation, but doesn't specify permissions required, rate limits, error handling, or what 'detailed information' includes (e.g., fields returned). This leaves gaps in understanding the tool's behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about a specific lead by ID') with zero wasted words. Every part of the sentence earns its place by specifying the action, resource, and key input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., read-only nature, error cases) and return values, leaving the agent to infer or guess these aspects.
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 the single parameter 'leadId' fully documented in the schema as 'The lead's unique ID'. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. 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 ('Get') and resource ('detailed information about a specific lead'), making the purpose unambiguous. It distinguishes this tool from sibling list tools like 'volkern_list_leads' by specifying retrieval of a single lead by ID. However, it doesn't explicitly differentiate from other get tools like 'volkern_get_contact' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need detailed information about a known lead ID, which is clear from the context. However, it provides no explicit guidance on when to use this versus alternatives like 'volkern_list_leads' for browsing or 'volkern_update_lead' for modifications, 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.
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. While 'Create' implies a write/mutation operation, the description doesn't mention permissions required, whether the appointment is confirmed immediately, error conditions (e.g., if the time slot is taken despite checking), or what happens on success/failure. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the core purpose, and the second provides critical usage guidance. It's front-loaded with the main action and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, creation operation) and lack of annotations or output schema, the description is minimally adequate. It covers purpose and a key prerequisite but misses behavioral details like what the tool returns or error handling. The usage guideline is helpful, but overall completeness is limited for a mutation tool without structured support.
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 input schema itself. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain relationships like 'servicioId' being required only for 'tipo=servicio', though the schema covers this). With high schema coverage, the baseline is 3 even without param details 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 ('Create') and resource ('new appointment'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'volkern_list_citas' (list) and 'volkern_update_cita' (update), though it doesn't explicitly differentiate from other creation tools like 'volkern_create_contact' or 'volkern_create_lead' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'Check availability first with volkern_check_disponibilidad.' This directly tells the agent when to use this tool (after checking availability) and names the specific alternative tool to use beforehand, which is ideal for preventing errors.
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 the key behavioral trait of upsert logic (create-or-update based on email), which is valuable beyond basic creation. However, it doesn't mention other important behaviors like required permissions, rate limits, what happens with duplicate non-email fields, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the primary purpose, the second adds crucial behavioral context. No wasted words, and the most important information (the upsert behavior) is front-loaded in the second sentence.
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 mutation tool with 9 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the core purpose and key behavior (upsert), but lacks information about permissions, error conditions, response format, or how it differs from similar tools like volkern_create_contact, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly with descriptions, enums, and required fields. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new lead') and resource ('in the CRM'), and distinguishes it from siblings by mentioning the unique upsert behavior ('If email already exists, updates the existing lead'), which differentiates it from tools like volkern_update_lead that presumably only update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating leads, with upsert logic based on email), but doesn't explicitly state when not to use it or name alternatives like volkern_create_contact for contacts instead of leads, or volkern_update_lead for updates without creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool checks availability, which implies a read-only operation, but doesn't disclose behavioral details like whether it requires authentication, how it handles errors, or if it has rate limits. The description adds basic context but lacks depth for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place with zero waste, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (availability checking), no annotations, and no output schema, the description is reasonably complete. It covers purpose and usage well but lacks details on return values (e.g., format of time slots) and behavioral constraints, which would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('fecha' as date in YYYY-MM-DD format, 'duracion' as duration in minutes with default 60). The description doesn't add meaning beyond this, such as explaining what 'available time slots' represent or how duration affects results. 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.
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 ('Check available time slots') and resource ('for a specific date'), distinguishing it from sibling tools like 'volkern_create_cita' (booking) and 'volkern_list_citas' (listing appointments). It uses a precise verb ('Check') rather than a generic term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance: 'Always call this before booking.' This directly addresses the relationship with booking tools (e.g., 'volkern_create_cita'), making it clear this is a prerequisite step.
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:

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

Score Badge

Copy to your README.md:

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

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/DeXpertmx/mcp-volkern'

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