Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Polytomic MCP Server trigger the 'Salesforce to Snowflake' sync"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with the Polytomic API.
Tool | Description |
| List all available connection types (connectors) |
| List all data connections |
| Get details for a specific connection |
| Create a new data connection |
| Update an existing connection |
| Delete a connection |
Tool | Description |
| List all data models |
| Get details and fields for a specific model |
| Create a new data model |
| Update an existing model |
| Delete a model |
Tool | Description |
| List all model syncs |
| Get details for a specific sync |
| Create a new model sync |
| Update an existing sync |
| Delete a sync |
| Activate (enable) a sync |
| Manually trigger a sync to run |
| Get the current status of a sync |
| List execution history for a sync |
| Get details for a specific sync execution |
Tool | Description |
| List all bulk syncs |
| Get details for a specific bulk sync |
| Create a new bulk sync |
| Update an existing bulk sync |
| Delete a bulk sync |
| Activate or deactivate a bulk sync |
| Manually trigger a bulk sync to run |
| Get the current status of a bulk sync |
| List execution history for a bulk sync |
| Get available schemas/tables for a bulk sync |
| Update which schemas/tables are enabled for a bulk sync |
Related MCP server: nango-mcp-server
Create and activate a virtual environment:
cd projects/mcp-servers/polytomic
python -m venv venv
source venv/bin/activateInstall the package:
pip install -e .Run the server:
python -m polytomic_mcp.server
# or
polytomic-mcpPOLYTOMIC_API_KEY - Your Polytomic API key (Bearer token)
The server is configured in mcporter and can be used via:
mcporter call polytomic.list_connections
mcporter call polytomic.get_sync id=<sync-id>
mcporter call polytomic.trigger_sync id=<sync-id>Activate or deactivate a bulk sync.
Args: id: The bulk sync ID active: True to activate, False to deactivate
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| active | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 action but does not cover critical aspects like required permissions, whether activation/deactivation is reversible, side effects (e.g., on sync executions), rate limits, or error conditions. This leaves significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a brief purpose statement followed by clear parameter explanations in a simple format. Every sentence adds value without redundancy, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers basic purpose and parameters but lacks behavioral context and usage guidelines, leaving the agent with incomplete information for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining 'id' as 'The bulk sync ID' and 'active' as 'True to activate, False to deactivate', which clarifies beyond the schema's basic types. However, it lacks details like ID format or activation implications, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate or deactivate') and the resource ('a bulk sync'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'activate_sync' or 'trigger_bulk_sync', which might handle similar activation functions for different resources or contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 lacks context about prerequisites (e.g., needing an existing bulk sync ID), exclusions, or comparisons to siblings like 'update_bulk_sync' or 'trigger_bulk_sync', leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate (enable) a sync.
Args: id: The sync ID to activate
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 activation/enablement, implying a state change, but lacks details on permissions, side effects (e.g., if it starts syncing immediately), rate limits, or error conditions. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action, followed by a clear parameter explanation. It avoids unnecessary words, though the structure is simple and could be more polished, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with one parameter), no annotations, and an output schema present, the description is minimally adequate. It explains the action and parameter but lacks behavioral context and usage guidance, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by specifying that 'id' is 'The sync ID to activate', which clarifies the parameter's role. However, with 0% schema description coverage and only one parameter, this provides some value but doesn't fully compensate for the lack of schema details, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate (enable)') and the resource ('a sync'), making the purpose understandable. However, it doesn't differentiate from siblings like 'trigger_sync' or 'update_sync', which might have overlapping functionality, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'trigger_sync' or 'update_sync'. The description only states what it does, without context or exclusions, leaving the agent to infer usage from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new bulk sync (ELT) in Polytomic.
Args: name: Name for the bulk sync source_connection_id: Source connection ID dest_connection_id: Destination connection ID destination_configuration: JSON string with destination config (e.g. {"schema": "public"}) schedule: Optional JSON for schedule source_configuration: Optional JSON string with source-specific config
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| source_connection_id | Yes | ||
| dest_connection_id | Yes | ||
| destination_configuration | Yes | ||
| schedule | No | ||
| source_configuration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'Create a new bulk sync' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether this is idempotent, what happens on failure, rate limits, or what the output contains. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose first, followed by parameter explanations. Every sentence earns its place by clarifying parameter meanings. The structure is logical, though the parameter explanations could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a creation tool with 6 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is moderately complete. It explains parameter semantics well but lacks behavioral context and usage guidelines. The output schema existence means return values don't need description, but other gaps remain for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 6 parameters, explaining what each represents (e.g., 'Name for the bulk sync', 'JSON string with destination config') and indicating which are optional. This adds substantial value beyond the bare schema, though it doesn't provide format examples beyond the destination_configuration hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new bulk sync (ELT) in Polytomic, which is a specific verb (create) and resource (bulk sync/ELT). It distinguishes from siblings like 'create_sync' by specifying 'bulk sync', though it doesn't explicitly contrast with other creation tools like 'create_connection' or 'create_model'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to choose create_bulk_sync over create_sync, or prerequisites like needing existing connections. The context of sibling tools suggests multiple creation options, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new data connection in Polytomic.
Args: name: Name for the connection type: Connection type (e.g. 'postgresql', 'salesforce', 'snowflake') configuration: JSON string with connection config (varies by type)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| configuration | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 it's a write/mutation tool, but doesn't disclose any behavioral traits like authentication requirements, rate limits, side effects, error conditions, or what happens on success (e.g., returns a connection ID). The description is minimal and lacks crucial context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are brief but clear. There's no wasted text, though it could be slightly more structured (e.g., bullet points). Every sentence adds value given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 3 parameters, 0% schema coverage, no annotations, but with an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context, usage guidelines, and detailed parameter semantics. The output schema likely handles return values, but the description doesn't mention this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics for all three parameters: 'name' as the connection name, 'type' as the connection type with examples, and 'configuration' as a JSON string with type-specific config. This compensates partially but doesn't provide format details, validation rules, or examples for the JSON configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new data connection in Polytomic' which specifies the verb (create), resource (data connection), and system context. It distinguishes this from sibling tools like 'update_connection' or 'delete_connection' by focusing on creation. However, it doesn't explicitly differentiate from 'list_connections' or 'get_connection' beyond the obvious create vs. read distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid configuration data), when not to use it (e.g., for updating existing connections), or direct alternatives like 'update_connection' for modifications. 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.
Create a new data model in Polytomic.
Args: name: Name for the model connection_id: The connection ID this model uses configuration: JSON string with model config (e.g. {"query": "SELECT * FROM users"} or {"table": "users"}) identifier: Optional field name to use as unique identifier tracking_columns: Optional JSON array of column names for change tracking
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| connection_id | Yes | ||
| configuration | Yes | ||
| identifier | No | ||
| tracking_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states 'Create a new data model' which implies a write operation, but doesn't disclose permissions required, whether it's idempotent, rate limits, or what happens on success/failure. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter explanations. The structure is front-loaded with the main action. Some redundancy exists (e.g., 'Args:' header might be unnecessary), but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description does well on parameters but lacks behavioral context. The presence of an output schema reduces need to explain return values. However, for a creation tool with multiple parameters, more guidance on usage and error conditions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 5 parameters: name, connection_id, configuration, identifier, and tracking_columns, including examples for configuration. This adds significant value beyond the bare schema, though it could elaborate on format constraints or dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 data model in Polytomic', making the purpose evident. It distinguishes from siblings like 'update_model' or 'delete_model' by specifying creation. However, it doesn't explicitly differentiate from 'create_connection' or 'create_sync' in terms of resource type beyond naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'update_model' or 'create_connection'. The description lists parameters but doesn't indicate prerequisites, such as needing an existing connection. Usage context is implied by the tool name and parameter list but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new model sync (reverse ETL) in Polytomic.
Args: name: Name for the sync mode: Sync mode ('create', 'update', 'updateOrCreate', 'replace', 'append') target: JSON string with target config {"connection_id": "...", "object": "...", "configuration": {...}} fields: JSON array of field mappings [{"source": {"field": "...", "model_id": "..."}, "target": "..."}] identity: Optional JSON for identity mapping (required for update modes) schedule: Optional JSON for schedule {"frequency": "manual|hourly|daily|weekly|monthly", ...} filters: Optional JSON array of filters filter_logic: Optional filter logic string (e.g. "A AND B")
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| mode | Yes | ||
| target | Yes | ||
| fields | Yes | ||
| identity | No | ||
| schedule | No | ||
| filters | No | ||
| filter_logic | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states this creates a sync but doesn't mention permissions needed, whether it's idempotent, rate limits, error conditions, or what happens on success (e.g., returns sync ID). The JSON string requirements for parameters are noted, but overall behavioral disclosure is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement followed by parameter details. Each parameter explanation is brief but informative. No redundant sentences, though the formatting as a code-like block is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, creation operation) and lack of annotations, the description does a decent job on parameters but is weak on behavioral context. The existence of an output schema helps, but the description doesn't reference it or explain what to expect post-creation. For a sync creation tool in a suite with many alternatives, more guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful details for all 8 parameters: explaining what each represents, listing mode enum values, noting JSON formats for target/fields/identity/schedule/filters, and specifying when identity is required. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new model sync (reverse ETL) in Polytomic' which specifies the verb (create), resource (model sync), and domain context (Polytomic). It distinguishes from siblings like create_bulk_sync by specifying 'model sync' rather than 'bulk sync', though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 create_bulk_sync or update_sync. The description mentions that identity is 'required for update modes', which is a minor usage note, but lacks broader context about prerequisites, typical workflows, or tool selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a bulk sync from Polytomic.
Args: id: The bulk sync ID to delete
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states it's a deletion operation, implying it's destructive, but doesn't specify if it's reversible, requires permissions, has side effects (e.g., cascading deletions), or rate limits. This is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the purpose, followed by a brief parameter explanation. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with no annotations) and the presence of an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic action and parameter but lacks critical behavioral context like safety warnings or usage prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining that the 'id' parameter is 'The bulk sync ID to delete', which clarifies its purpose beyond the schema's minimal title ('Id'). With 0% schema description coverage and only one parameter, this compensates well, though it could specify format or sourcing details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a bulk sync from Polytomic'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_sync' or 'delete_connection', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 an existing bulk sync), exclusions, or comparisons to similar deletion tools like 'delete_sync' or 'delete_connection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a connection from Polytomic.
Args: id: The connection ID to delete
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 deletion operation but provides no information about consequences (e.g., whether this is irreversible, whether it affects related syncs or models, what permissions are required, or what happens on success/failure). For a destructive operation, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and front-loaded with the core purpose. The Args section is efficiently formatted. No unnecessary words or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, the description is minimally adequate but incomplete. It explains the basic purpose and parameter, but lacks critical behavioral context about consequences, permissions, or error conditions. The presence of an output schema helps, but the description should do more for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides the parameter 'id' with semantic context ('The connection ID to delete'), which is valuable since schema description coverage is 0%. While it doesn't specify format or constraints, it clearly explains what the parameter represents. With only one parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a connection from Polytomic'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like delete_bulk_sync or delete_model, but the resource specificity provides adequate distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like update_connection or list_connections, nor about prerequisites (e.g., whether the connection must be inactive). The description only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a model from Polytomic.
Args: id: The model ID to delete
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 deletes a model, implying a destructive mutation, but doesn't clarify if deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting associated syncs). The description lacks critical behavioral details needed for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. Every sentence earns its place with no redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and presence of an output schema (which handles return values), the description is minimally adequate but incomplete. It covers the basic action and parameter but misses critical context like deletion implications, permissions, or error conditions. For a mutation tool with no safety annotations, more detail is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'id' by specifying it as 'The model ID to delete', which clarifies its purpose beyond the schema's minimal title 'Id'. With 0% schema description coverage and only one parameter, this compensates adequately. However, it doesn't explain where to obtain the ID or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a model from Polytomic'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_bulk_sync' or 'delete_connection' by specifying the resource type. However, it doesn't explicitly mention what 'delete' entails (e.g., permanent removal vs. soft delete), 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.
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 the model ID from 'get_model' or 'list_models'), consequences of deletion, or when not to use it (e.g., if the model is active in a sync). The presence of sibling tools like 'delete_bulk_sync' and 'delete_connection' suggests a need for differentiation, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a sync from Polytomic.
Args: id: The sync ID to delete
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 deletes a sync, implying a destructive mutation, but doesn't disclose critical behavioral traits like whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting related data), or returns confirmation details. This is inadequate for a destructive operation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another documenting the parameter. It's front-loaded with the core action, though the parameter documentation could be integrated more seamlessly. There's no wasted text, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive delete operation, no annotations, and an output schema that exists but isn't described, the description is incomplete. It lacks crucial context like confirmation requirements, error handling, or return values, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics for the single parameter 'id' by stating it's 'The sync ID to delete', which clarifies its role. However, with 0% schema description coverage and no output schema referenced, it doesn't explain where to obtain the ID or what format it expects. The baseline is 3 since the schema covers the parameter structure, but the description doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a sync from Polytomic'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_bulk_sync' or 'delete_model', which would require specifying what distinguishes a 'sync' from other deletable entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sync ID from 'get_sync' or 'list_syncs'), when deletion is appropriate, or what happens post-deletion. With multiple delete tools in the sibling list, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific bulk sync.
Args: id: The bulk sync ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'gets details,' implying a read-only operation, but doesn't specify permissions needed, rate limits, error conditions, or what the output entails. This leaves significant gaps for a tool that likely involves data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by a simple parameter explanation. It avoids unnecessary words, but the 'Args:' section could be integrated more seamlessly. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and multiple sibling tools, the description is incomplete—it lacks behavioral context and usage differentiation, making it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 0% description coverage. It only notes that 'id' is 'The bulk sync ID,' which is basic and doesn't elaborate on format, sourcing, or constraints. Since there's only one parameter, the baseline is 4, but the lack of additional context reduces it to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get details for a specific bulk sync,' which clearly indicates a retrieval action on a bulk sync resource. However, it lacks specificity about what 'details' include and doesn't differentiate from sibling tools like 'get_bulk_sync_status' or 'list_bulk_syncs,' making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_bulk_syncs' for multiple syncs or 'get_bulk_sync_status' for status-specific details. The description only mentions retrieving details by ID, offering no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available schemas/tables for a bulk sync.
Args: id: The bulk sync ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 it 'Get[s] available schemas/tables', implying a read operation, but lacks details on permissions, rate limits, error handling, or what 'available' means. This is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by parameter details. It avoids unnecessary words, though the structure could be improved by integrating the 'Args' section more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), one parameter, and no annotations, the description is reasonably complete for its simplicity. It covers the purpose and parameter, though behavioral aspects are lacking, which is partially mitigated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section explaining 'id: The bulk sync ID', adding meaning beyond the schema (which has 0% description coverage). However, it only covers the single parameter without details like format or constraints, so it partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available schemas/tables for a bulk sync', making the purpose understandable. It distinguishes from siblings like 'get_bulk_sync' or 'get_bulk_sync_status' by specifying schemas/tables, though it could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_bulk_sync' or 'update_bulk_sync_schemas', there is no indication of prerequisites, context, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status of a bulk sync.
Args: id: The bulk sync ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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' status without clarifying what 'status' includes (e.g., progress, errors, completion), whether it's read-only (implied but not explicit), or any rate limits/authentication needs. It's minimally adequate but lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a clear parameter explanation. No wasted words, though the structure with 'Args:' is slightly informal but functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic purpose and parameter semantics, though more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds essential meaning beyond the schema's 0% coverage by explaining that 'id' refers to 'The bulk sync ID'. This clarifies the parameter's purpose, though it doesn't specify format or where to obtain the ID. With only one parameter, this is sufficient for effective use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the current status') and resource ('of a bulk sync'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling 'get_sync_status' or explain what 'bulk sync' means in this context, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_sync_status' or 'get_bulk_sync', nor does it mention prerequisites or typical workflows. The agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific connection.
Args: id: The connection ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 details but doesn't mention whether it's read-only, if it requires authentication, rate limits, error handling, or what the output looks like. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose clearly, followed by a brief 'Args' section. There's no wasted text, and it's front-loaded with essential information. It could be slightly improved by integrating the parameter info more seamlessly, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and the presence of an output schema (which handles return values), the description is minimally complete. However, with no annotations and incomplete behavioral details, it leaves gaps in understanding the tool's full context and usage. It's adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics: it explains that 'id' is 'The connection ID,' which provides basic meaning beyond the schema's title 'Id.' However, with 0% schema description coverage and only one parameter, this is adequate but not comprehensive. It doesn't clarify format, constraints, or examples for the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details for a specific connection.' It specifies the verb ('Get details') and resource ('connection'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_connections' or 'get_sync', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_connections' (for multiple connections) or 'get_sync' (for sync details), nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details and fields for a specific model.
Args: id: The model ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'details and fields,' implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated data, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and front-loaded, with the main purpose stated first ('Get details and fields for a specific model.') followed by a brief parameter explanation. The two-sentence structure is efficient, though the parameter section could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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), the presence of an output schema (which handles return values), and no annotations, the description is reasonably complete. It covers the core purpose and parameter meaning, but could improve by adding usage context or behavioral details to fully compensate for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains that 'id' is 'The model ID,' which clarifies the parameter's purpose, but with 0% schema description coverage and only one parameter, this provides basic value. The schema already defines 'id' as a required string, so the description compensates slightly but not richly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details and fields for a specific model.' It uses a specific verb ('Get') and resource ('model'), and distinguishes it from siblings like 'list_models' by focusing on a single model. However, it doesn't explicitly contrast with other 'get_' siblings (e.g., 'get_connection'), which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to prefer 'get_model' over 'list_models' for retrieving model information, nor does it reference other sibling tools like 'create_model' or 'update_model' for context. Usage is implied only by 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.
Get details for a specific sync.
Args: id: The sync ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'Get details' operation, implying it's likely a read-only fetch, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens on errors. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated clearly in the first sentence and parameter details following in a structured format. There's no wasted text, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and the presence of an output schema, the description is somewhat complete. However, with no annotations and many sibling tools, it lacks context on usage and behavior, making it only minimally adequate for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics: it explains that 'id' is 'The sync ID', which provides basic meaning beyond the schema's title 'Id'. However, with 0% schema description coverage and only one parameter, this doesn't fully compensate for the lack of schema details, but it meets the baseline since the schema coverage is low and the description adds some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details for a specific sync.' This is a specific verb ('Get details') and resource ('sync'), making it understandable. However, it doesn't explicitly distinguish it from similar sibling tools like 'get_bulk_sync' or 'get_sync_status', which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 many sibling tools like 'get_bulk_sync', 'get_sync_status', and 'list_syncs', there's no indication of context, prerequisites, or exclusions. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific sync execution.
Args: sync_id: The sync ID execution_id: The execution ID
| Name | Required | Description | Default |
|---|---|---|---|
| sync_id | Yes | ||
| execution_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'Get details' implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'details' include. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose in the first sentence. The parameter list is clear but minimal. No unnecessary information is included, though it could be slightly more structured (e.g., separating purpose from args more distinctly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters) and the presence of an output schema, the description is reasonably complete. The output schema will handle return values, so the description doesn't need to explain them. However, with no annotations and low schema coverage, it could better address behavioral aspects and parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics by listing 'sync_id' and 'execution_id' with brief explanations, but doesn't clarify format, constraints, or where to obtain these IDs. This partially compensates but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details for a specific sync execution.' It uses a specific verb ('Get details') and resource ('sync execution'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_sync' or 'list_sync_executions', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_sync' (for sync details) and 'list_sync_executions' (for multiple executions), the agent must infer usage from the name alone. No explicit when/when-not statements 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.
Get the current status of a sync.
Args: id: The sync ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'gets' status, implying a read-only operation, but doesn't clarify what 'status' entails (e.g., running, failed, pending), whether it requires specific permissions, or if there are rate limits. The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by a parameter explanation. Every sentence earns its place with no wasted words, and the information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and the presence of an output schema (which likely defines the status structure), the description is reasonably complete. It covers the purpose and parameter basics, though it could benefit from more behavioral context. The output schema reduces the need to explain return values in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the single parameter 'id' as 'The sync ID', adding meaning beyond the schema (which has 0% description coverage). However, it doesn't explain the format or source of the sync ID, leaving gaps. With one parameter and low schema coverage, this provides basic but incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('status of a sync'), making it immediately understandable. It distinguishes from siblings like 'get_sync' (which likely retrieves sync metadata) by focusing specifically on status, though it doesn't explicitly contrast with 'get_bulk_sync_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose implies it's for checking sync status, there's no mention of prerequisites (e.g., needing an existing sync ID), comparison to similar tools like 'get_bulk_sync_status', or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List execution history for a bulk sync.
Args: id: The bulk sync ID limit: Maximum number of executions to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that the tool lists execution history, implying a read-only operation, but doesn't specify whether it's paginated, the format of returned data, rate limits, authentication requirements, or error conditions. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a single sentence states the purpose, followed by a bullet-point list of parameters with brief explanations. Every sentence earns its place, and there's no unnecessary information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, but lacks behavioral details like pagination or error handling. The presence of an output schema means the description doesn't need to explain return values, but it should still address usage context and operational traits to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters: 'id' is explained as 'The bulk sync ID', and 'limit' as 'Maximum number of executions to return (default 10)'. This compensates for the 0% schema description coverage, providing clear semantics beyond the basic schema. However, it doesn't detail constraints like ID format or limit ranges, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 execution history for a bulk sync.' It specifies the verb ('List') and resource ('execution history for a bulk sync'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_sync_executions' or 'get_bulk_sync_status', which could provide similar historical or status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_sync_executions' (for individual syncs) or 'get_bulk_sync_status' (for current status), nor does it specify prerequisites such as needing an existing bulk sync ID. This lack of context makes it harder for an agent to choose correctly among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all bulk syncs in Polytomic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 doesn't mention whether this is a read-only operation, if it requires authentication, how results are paginated, or what the output format looks like. The description is too basic for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks context about behavioral traits and differentiation that would help an agent use it correctly in this rich environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to compensate, and baseline for 0 parameters is 4, as it appropriately doesn't discuss non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('all bulk syncs in Polytomic'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'list_bulk_sync_executions', which could cause confusion about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_bulk_sync' (for a single sync) or 'list_bulk_sync_executions' (for executions). The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data connections in Polytomic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't mention whether it's paginated, what authentication is required, rate limits, or the format/structure of returned data. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 no wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema) and lack of annotations, the description is minimally adequate. The output schema should document return values, so the description doesn't need to explain those. However, for a list operation with sibling alternatives, more contextual guidance would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though empty). With no parameters to document, the description doesn't need to compensate for any schema gaps. The baseline for zero parameters is 4, as there's no parameter semantics to explain beyond what's already covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('data connections in Polytomic'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'list_connection_types' or 'get_connection', which would require more specific differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_connection' (for retrieving a specific connection) and 'list_connection_types' (for listing types rather than instances), the agent receives no help in choosing between them. No prerequisites or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available connection types (connectors) in Polytomic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 it's a list operation but doesn't mention whether it's paginated, sorted, filtered, or what format the output takes. The existence of an output schema helps, but the description itself lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. Every word contributes to understanding the tool's purpose with zero wasted verbiage. It's appropriately sized for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with 0 parameters and an output schema, the description is minimally adequate. It states what the tool does but lacks context about when to use it versus alternatives. The output schema will handle return values, but the description doesn't provide enough guidance for optimal tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all available') and resource ('connection types (connectors) in Polytomic'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_connections' or 'list_models', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for usage, or comparison to sibling tools like 'list_connections' or 'get_connection' that might serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data models in Polytomic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic function without mentioning pagination behavior, rate limits, authentication requirements, or what 'all' means in practice (e.g., complete list vs limited). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists (so return values are documented elsewhere), the description covers the basic purpose adequately. However, as a list operation with no annotations, it should ideally mention behavioral aspects like pagination or filtering capabilities to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('data models in Polytomic'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_model' or 'list_connections', but the specificity of 'data models' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_model' (for a specific model) or other list tools. It simply states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List execution history for a sync.
Args: id: The sync ID limit: Maximum number of executions to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool lists execution history with a default limit, but lacks critical behavioral details such as whether it's read-only, pagination behavior, error handling, authentication needs, rate limits, or what 'execution history' entails (e.g., statuses, timestamps). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by parameter details. It avoids unnecessary fluff, but the structure could be slightly improved by integrating parameter explanations more seamlessly rather than as a separate 'Args' section, though this is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. For a tool with 2 parameters and no annotations, it should provide more guidance on behavior and alternatives to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'id' as 'The sync ID' and 'limit' as 'Maximum number of executions to return (default 10)', which clarifies purpose beyond the schema's basic types. However, it does not cover parameter constraints (e.g., format of 'id', range for 'limit') or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 execution history for a sync,' which is a specific verb ('List') and resource ('execution history for a sync'). It distinguishes from siblings like 'get_sync_execution' (singular) and 'list_bulk_sync_executions' (bulk variant), but could be more explicit about the distinction from 'list_bulk_sync_executions' to reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_sync_execution' (for a single execution) or 'list_bulk_sync_executions' (for bulk syncs). It mentions the 'id' parameter but does not specify prerequisites or context for usage, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all model syncs in Polytomic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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, rate limits, authentication needs, or what 'all' entails (e.g., active vs. inactive syncs). This leaves significant gaps for a tool that likely returns multiple items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 earns its place, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description doesn't need to explain parameters or return values. However, as a list tool with no annotations, it lacks context on behavior (e.g., pagination, filtering) and usage guidelines compared to siblings, making it minimally adequate but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add any parameter details, which is appropriate here, but it doesn't compensate for any gaps since there are none. A baseline of 4 is given as it meets the requirement for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('model syncs in Polytomic'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_bulk_syncs' or 'list_sync_executions', which would require specifying what distinguishes a 'model sync' from other sync types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like 'list_bulk_syncs' and 'list_sync_executions', the description doesn't clarify if this is for all syncs, only model-specific syncs, or another scope, 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.
Manually trigger a bulk sync to run.
Args: id: The bulk sync ID to trigger
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'manually trigger' but doesn't explain what happens during the sync, whether it's idempotent, what permissions are required, or how it interacts with other operations. This leaves significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences: one stating the purpose and another documenting the parameter. It's front-loaded with the main functionality, though the 'Args' section could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, one parameter, and an output schema, the description covers the basic purpose and parameter meaning. However, it lacks details about behavioral implications, error conditions, and relationship to sibling tools, making it minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the single parameter 'id' as 'The bulk sync ID to trigger'. With 0% schema description coverage and only one parameter, this provides essential semantic context beyond the bare schema, though it doesn't specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'manually trigger[s] a bulk sync to run', which provides a clear verb ('trigger') and resource ('bulk sync'). However, it doesn't differentiate from sibling tools like 'trigger_sync' or 'activate_bulk_sync', leaving ambiguity about when to use this specific tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'trigger_sync' or 'activate_bulk_sync'. The description only states what the tool does without context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger a sync to run.
Args: id: The sync ID to trigger
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 'Manually trigger' but does not explain what happens during the sync (e.g., data transfer, side effects), whether it's idempotent, or any rate limits. This leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with the core purpose stated in the first sentence and parameter details in a clear 'Args' section. There is no wasted text, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only one parameter, the description is minimally complete. However, it lacks details on behavioral aspects and usage context, which are important for a mutation tool with no annotations, leaving gaps in overall understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by stating 'id: The sync ID to trigger', which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, this is adequate but not insightful—it meets the baseline for low coverage without fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Manually trigger a sync to run') and specifies the resource ('a sync'), making the purpose understandable. However, it does not explicitly differentiate this tool from its sibling 'trigger_bulk_sync', which is a missed opportunity for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'trigger_bulk_sync' or other sync-related tools. It lacks context about prerequisites, such as whether the sync must be active or configured, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing bulk sync in Polytomic.
Args: id: The bulk sync ID to update name: Optional new name schedule: Optional JSON for schedule destination_configuration: Optional JSON string with destination config source_configuration: Optional JSON string with source config
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| schedule | No | ||
| destination_configuration | No | ||
| source_configuration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 updates a bulk sync, implying a mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, or what the update entails (e.g., partial vs. full updates). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a parameter list. Every sentence serves a purpose, with no wasted words. However, the parameter explanations are minimal and could be more informative, slightly reducing effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 5 parameters), lack of annotations, and 0% schema description coverage, the description is incomplete. It covers the basic purpose and parameters but misses behavioral context, usage guidelines, and detailed parameter semantics. The presence of an output schema helps, but the description doesn't leverage it to explain return values or outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 5 parameters with brief explanations (e.g., 'Optional new name'), adding basic semantics beyond the schema's titles. However, it doesn't provide details on format (e.g., what JSON structure 'schedule' expects) or constraints, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing bulk sync in Polytomic.' It specifies the verb ('Update') and resource ('bulk sync'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'update_sync' or 'update_bulk_sync_schemas', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 bulk sync ID), compare it to sibling tools like 'create_bulk_sync' or 'update_sync', or specify use cases. This leaves the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update which schemas/tables are enabled for a bulk sync.
Args: id: The bulk sync ID schemas: JSON array of schema configurations
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| schemas | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states this is an update operation, implying mutation, but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what the output contains. The description lacks critical context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The 'Args:' section is clear but could be integrated more seamlessly. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is partially complete. It covers the basic purpose and parameters but lacks usage guidelines, behavioral details, and deeper parameter semantics, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds basic meaning for both parameters ('id' as bulk sync ID, 'schemas' as JSON array of schema configurations), which helps beyond the bare schema. However, it doesn't detail the format of 'schemas' (e.g., structure, allowed values) or provide examples, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update which schemas/tables are enabled') and the target resource ('for a bulk sync'), making the purpose understandable. It distinguishes this from siblings like 'update_bulk_sync' (which likely updates general settings) and 'get_bulk_sync_schemas' (which reads them), but doesn't explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 an existing bulk sync), exclusions, or specific scenarios where this update is appropriate compared to other update operations in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing connection in Polytomic.
Args: id: The connection ID to update name: Optional new name for the connection configuration: Optional JSON string with connection config
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| configuration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. The parameter explanations are efficient, though the structure could be slightly improved by integrating usage context. There's minimal waste, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 3 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is moderately complete. It covers the purpose and parameters but misses behavioral details and usage guidelines. The presence of an output schema reduces the need to explain return values, but gaps remain for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the three parameters and provides basic semantics: 'id' is the connection ID to update, 'name' is an optional new name, and 'configuration' is an optional JSON string with config. This adds meaning beyond the bare schema but lacks details like format constraints or examples, keeping it at a baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing connection in Polytomic.' It specifies the verb ('Update') and resource ('connection'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'create_connection' or 'update_model', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 connection ID), compare it to 'create_connection' or 'update_model', or specify any context for usage. This leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing data model in Polytomic.
Args: id: The model ID to update name: Optional new name for the model configuration: Optional JSON string with model config (e.g. {"query": "SELECT * FROM users"}) identifier: Optional field name to use as unique identifier tracking_columns: Optional JSON array of column names for change tracking
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| configuration | No | ||
| identifier | No | ||
| tracking_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Update' implying mutation, but lacks details on permissions, side effects (e.g., impact on syncs), error handling, or response format. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a structured 'Args' list. It's efficient with minimal fluff, though the parameter explanations could be slightly more concise (e.g., combining JSON format notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature, 5 parameters, 0% schema coverage, and no annotations, the description is moderately complete: it covers parameters well but lacks behavioral and usage details. The presence of an output schema reduces the need to explain return values, but gaps in guidelines and transparency remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all 5 parameters in the 'Args' section, including examples (e.g., JSON format for 'configuration'). This adds significant meaning beyond the bare schema, though it could elaborate on constraints or interactions between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 data model in Polytomic'), making the purpose evident. However, it doesn't explicitly differentiate this from sibling tools like 'update_connection' or 'update_sync', which would require a more specific scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 model ID), compare it to 'create_model' or other update tools, or specify scenarios where it's appropriate, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing sync in Polytomic.
Args: id: The sync ID to update name: Optional new name mode: Optional sync mode fields: Optional JSON array of field mappings identity: Optional JSON for identity mapping schedule: Optional JSON for schedule filters: Optional JSON array of filters filter_logic: Optional filter logic string active: Optional boolean to enable/disable sync
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| mode | No | ||
| fields | No | ||
| identity | No | ||
| schedule | No | ||
| filters | No | ||
| filter_logic | No | ||
| active | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 what happens when fields are updated (e.g., whether changes are immediate, reversible, or require validation). It also doesn't mention authentication needs, rate limits, error conditions, or what the output contains. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a parameter list. Every sentence serves a purpose: the first states what the tool does, and the parameter list documents inputs. However, the parameter explanations could be more concise (e.g., 'Optional JSON array of field mappings' is wordy for each optional field).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, mutation operation, no annotations), the description is moderately complete. It covers the purpose and parameters but lacks behavioral details (e.g., side effects, error handling) and usage context. The presence of an output schema means the description doesn't need to explain return values, but it should still address mutation-specific concerns like permissions or idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all 9 parameters with brief explanations (e.g., 'id: The sync ID to update'), but schema description coverage is 0%, so the schema provides no additional context. The parameter explanations are minimal—they identify what each parameter represents but don't explain format constraints (e.g., what valid 'mode' values are, JSON structure for 'fields'), so the description adds some value but doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing sync in Polytomic.' This is a specific verb ('Update') with a resource ('sync'), though it doesn't differentiate from sibling tools like 'update_bulk_sync' or 'update_model' which have similar update patterns. The description avoids tautology by explaining what the tool does rather than just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'update_bulk_sync' or 'create_sync'. It doesn't mention prerequisites (e.g., needing an existing sync ID) or context for when updates are appropriate. The agent must infer usage from the parameter list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0activate_bulk_syncactivate_synccreate_bulk_synccreate_connectioncreate_modelcreate_syncdelete_bulk_syncdelete_connectiondelete_modeldelete_syncget_bulk_syncget_bulk_sync_schemasget_bulk_sync_statusget_connectionget_modelget_syncget_sync_executionget_sync_statuslist_bulk_sync_executionslist_bulk_syncslist_connection_typeslist_connectionslist_modelslist_sync_executionslist_syncstrigger_bulk_synctrigger_syncupdate_bulk_syncupdate_bulk_sync_schemasupdate_connectionupdate_modelupdate_syncTools are well-organized around distinct resources (bulk syncs, syncs, connections, models) with clear action differentiation. Minor overlap exists between 'activate_sync' and 'update_sync' with active parameter, but descriptions clarify their distinct purposes (activation vs. full update).
Perfectly consistent verb_noun pattern throughout (e.g., create_bulk_sync, get_connection, list_models). All tools use snake_case with clear action prefixes (create, get, list, update, delete, activate, trigger) followed by resource names.
32 tools is borderline heavy for a data integration server, though it covers multiple resource types comprehensively. The count feels slightly inflated due to parallel tools for bulk syncs and syncs, but remains manageable given the domain complexity.
Excellent CRUD/lifecycle coverage for all core resources (connections, models, bulk syncs, syncs). Includes activation, triggering, status checks, execution history, and schema management. No apparent gaps for the data integration domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Authenticated MCP server for ClearPolicy policy and compliance workflows.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Unified.to MCP server — one API for 500+ B2B SaaS integrations across 28+ categories
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/therevenueengineer/polytomic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server