nango-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Several tools overlap in purpose, especially connection management (including convention helpers) and session creation. The convention tools (apply, audit, build, describe) may confuse agents with other connection operations.
Naming Consistency4/5
Most tools follow verb_noun pattern (list_connections, get_integration). A few use longer phrases (audit_connection_conventions) but remain consistent in style.
Tool Count4/5
23 tools is slightly high but appropriate for a complex integration platform covering connections, integrations, sessions, environments, and proxy. Each tool serves a distinct purpose.
Completeness4/5
The tool surface covers CRUD for integrations and connections, session management, environment queries, proxy requests, and provider templates. Minor gaps like missing connection credential updates are likely managed via metadata.
Average 2.6/5 across 23 of 23 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description only states it creates a session token, without any mention of side effects, permissions, idempotency, return value, or error conditions. It does not disclose anything beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and concise in length, but it is under-specified rather than effectively concise. The single sentence merely repeats the tool name and provides no additional information. It is not well-structured because it lacks any front-loaded key details that could help an agent decide to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple sibling session tools, no annotations, no output schema), the description is completely inadequate. It provides essentially no information that would enable an agent to call it correctly or differentiate it from alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters (tags, environment, allowed_integrations, integrations_config_defaults). It does not mention any of them. The agent has no idea what values are expected or what each parameter controls, making correct invocation very difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a Nango Connect session token' is a tautology that restates the tool name without adding any specificity. It does not explain what a Nango Connect session token is, what it is used for, or how it differs from sibling tools like create_standard_connect_session or create_reconnect_session. An agent would have no idea what this tool does beyond the literal words.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling session-related tools (create_standard_connect_session, create_reconnect_session, etc.). The description offers no context, prerequisites, or exclusions. The agent must rely solely on the name and schema, which is insufficient for making an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and return type, but does not mention side effects, authentication requirements, idempotency, failure behavior, or any other safety-relevant traits. This is a significant omission for a session-creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise, but it is under-specified to the point of being unhelpful. The brevity is not balanced with the necessary content; it is terse rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is severely incomplete. It fails to explain the 'post-auth finalization contract' return object, the role of any parameters, or any related constraints, leaving the agent with almost no useful context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% description coverage, and the description mentions none of them. It does not explain the meaning or purpose of environment, provider_config_key, principal, owner_kind, purpose, or any other field, leaving agents without essential information to form valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create a Connect session') and mentions returning a contract, which is a concrete action. However, it does not clarify what a Connect session is or how it differs from the sibling create_connect_session, leaving the purpose only partially clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives like create_reconnect_session or create_connect_session. No conditions, contexts, or exclusions are provided, so an agent has no basis for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive operation, but there is no mention of irreversibility, required permissions, cascading effects, or what happens to associated data. The description is silent on all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (six words), which is efficient, but it lacks substantive content that would justify its brevity. It is not bloated, but it is too minimal to be genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with two required parameters and no output schema, this description is critically incomplete. It fails to specify return behavior, error conditions, or deletion semantics, leaving the agent to guess about critical execution details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters 'environment' and 'integration_id'. With schema coverage at 0%, the agent receives no explanation of what these values represent, any format constraints, or how they relate to the deletion. The schema alone is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and a clear resource ('a Nango integration'), making the tool's basic purpose unambiguous. It is distinct from sibling tools like delete_connection by referring to 'integration', though it does not elaborate on scope (e.g., integration definition vs. instances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives such as delete_connection or update_integration. No context, prerequisites, or conditions for use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'patch' without revealing what changes are applied, whether it is destructive, whether it affects active connections, or what the response contains. The presence of reconnect_connection_ids in the schema implies behavioral side-effects, but the description omits any such detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than helpfully concise. Every word is present but insufficient; no structure or additional context is provided to justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, nested objects, and no output schema. A minimal viable description would at least indicate what 'fields' refers to, what the behavior of reconnection is, and what the tool returns. The current description is completely inadequate for an agent to understand how to call it correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it provides zero information. Even though field names like 'environment' and 'integration_id' are somewhat self-explanatory, 'fields' as an arbitrary object and 'reconnect_connection_ids' are ambiguous. The description fails to clarify any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('patch') and resource ('Nango integration'), clearly indicating a modification operation on an existing integration. However, it does not differentiate from sibling tools like create_integration or delete_integration, nor does it specify what aspects of the integration can be patched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it should be used to modify an existing integration's configuration, nor does it warn against using it for creation or deletion. No context about prerequisites (e.g., requiring an existing integration) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It notes the output is a 'protected MCP binary resource', implying some access control, but it does not explain side effects, whether the resource is temporary or persistent, how it can be accessed afterwards, or any authentication or rate-limiting implications. For a streaming/write operation, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified rather than efficiently worded. It omits critical information that would be expected for a tool with 8 parameters and no annotations, so the brevity is a deficiency rather than a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, no output schema, and no explanation of return values or error conditions, the description is vastly incomplete. An agent has no way to know what arguments are needed beyond their schemas, what constitutes a successful call, or how to interpret the result. This falls far short of the minimum viable tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 parameters. Parameters like environment, providerConfigKey, connectionId, and path are left entirely to the schema definitions, which provide no semantic context (e.g., what 'path' refers to or how 'suggestedName' is used). The description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Stream a provider GET response') and a specific outcome ('into a protected MCP binary resource'). It is clear about the core purpose. However, it does not explicitly differentiate from sibling tools like proxy_request or query_response_artifact, relying on terminology that may not be obvious to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as proxy_request or query_response_artifact. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent to infer appropriate usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states that it applies tags and metadata but does not disclose side effects: whether it overwrites existing tags/metadata, whether it is idempotent, if it requires specific permissions, or what the output will be. The mutation nature is implied but not elaborated, leaving an agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and target. There is no unnecessary verbosity or filler. However, it is so brief that it sacrifices clarity and completeness; the conciseness is effective but not balanced with needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 6 required, no schema descriptions, and no annotations), the description is severely incomplete. It does not explain what 'suggested tags' are, how they are generated, what input parameters are expected, what the output schema represents, or any preconditions. The description fails to equip an agent to correctly call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with no descriptions (coverage 0%), and the tool description adds zero meaning to them. It does not explain fields like principal, owner_kind, purpose, patch_metadata, or oauth_app_owner. Since the description is the only source of semantics and it fails to define any parameter, the agent cannot infer what values to supply. This is a critical gap at 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Apply' with a clear resource: 'suggested Nango MCP tags and metadata to an existing connection'. It distinguishes the action from siblings like build_connection_convention (which likely constructs a convention) and describe_connection_convention (which describes it). The intended operation is unambiguous, though 'suggested' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like set_connection_metadata or patch_connection_tags. The description does not state prerequisites, such as whether a connection convention must be built first, or when to prefer this over directly setting metadata/tags. The intended context is only implied by the word 'suggested'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It indicates the output is 'suggested' (not created), but lacks details on side effects, required permissions, or whether it is read-only. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure. It front-loads the purpose but omits important details that could be added without significant verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and an output schema (unavailable in description), the description is incomplete. It mentions output components (connection_id, tags, metadata) but does not explain their types or constraints, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the tool description does not explain any of the 6 parameters (e.g., environment, provider_config_key). The agent receives no guidance on parameter meaning or valid values, failing to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a suggested connection_id, tags, and metadata object for a managed connection. This distinguishes it from sibling tools like apply_connection_convention and describe_connection_convention, but could be more explicit about what 'suggested' implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as apply_connection_convention or create_connect_session. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create' implies mutation, but the description adds little beyond what the name already conveys—it does not state whether the operation is idempotent, what happens if the integration already exists, whether it overwrites, or what the response format is. The only added context, 'using the Nango API payload shape,' is vague about what behavior that entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is appropriately short and front-loaded with the action verb, showing no wasted wording. However, this borders on under-specification rather than genuine conciseness—the 'using the Nango API payload shape' clause is vague and could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with an unconstrained payload object, no annotations, and no output schema, this description is severely inadequate. An agent cannot determine what to put in the payload, what environment values are acceptable, whether the operation is destructive or idempotent, or what a successful response looks like. This is a critical gap for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost nothing about the two parameters. The payload parameter is an unconstrained object (additionalProperties: true) with no shape guidance, and 'environment' is never explained (valid values, format, or relationship to list_environments). The vague hint that the payload follows 'the Nango API payload shape' does not compensate for the total absence of parameter documentation on an open-ended object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('Nango integration'), making the core action clear. However, it does nothing to differentiate from siblings like update_integration, get_integration, or list_integrations beyond the verb itself, and the phrase 'using the Nango API payload shape' is jargon that muddies rather than clarifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., checking the environment first via list_environments or check_environment), no exclusions, and no indication of whether this should be used before creating connections. The agent must infer all usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create a reconnect session' without explaining what that entails—whether it is idempotent, what happens to existing sessions, or any side effects. For a mutation-like tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and therefore concise, but it is under-specified rather than efficiently structured. It lacks any front-loading of key facts beyond the basic action, and there is no attempt to organize additional context (e.g., prerequisites, typical use cases). It is not verbose, but it is also not effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter explanations, the description is far from complete. The tool has several close siblings, and this description does not explain when this variant is needed. An agent has almost no context to invoke the tool correctly, making it severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists three required parameters but provides no descriptions (schema coverage is 0%). The tool description does not explain the meaning or format of 'environment', 'connection_id', or 'provider_config_key'. An agent cannot know what values to pass or how they relate to the session creation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and a specific resource ('a Nango reconnect session for an existing connection'). It is not a tautology and conveys the core action, though it does not differentiate it from sibling tools like create_connect_session or create_standard_connect_session. The word 'reconnect' gives some differentiation, but not enough to fully distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the similar create_connect_session or create_standard_connect_session. No preconditions, context, or exclusions are mentioned. An agent must infer usage solely from the name and minimal description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does indicate a destructive action ('Delete'), but omits critical details such as whether the action is irreversible, what consequences occur (e.g., cascading deletion of associated data), whether it requires special permissions, or how errors are handled. This is insufficient for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence and no fluff. However, it is so skeletal that it borders on under-specification rather than efficient conciseness. While the structure is front-loaded with the action, it lacks any supplementary detail that would make the sentence valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and 0% parameter description coverage, the description is starkly incomplete. An agent cannot determine expected return values, idempotency, failure modes, or side effects. The minimal complexity of a delete action does not excuse the absence of essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention 'environment', 'connection_id', or 'provider_config_key' at all, providing zero additional meaning beyond the schema's bare field names. The agent has no context for what these strings represent or how they interact, making correct invocation uncertain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') and a clear resource ('Nango connection'), making the tool's purpose explicit. It is not a tautology like 'process'. While it does not explicitly distinguish from sibling tools like 'delete_integration', the target resource is different, so the purpose is clear enough for an agent to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_connection' or 'list_connections'. It does not mention any prerequisites, edge cases, or context in which deletion is appropriate. The agent is left to infer usage from the tool name alone, which is inadequate given the large sibling family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is that credential-like fields are redacted. With no annotations, the description carries the burden but lacks details on permissions, rate limits, error handling, or what happens if the integration is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it could be better structured by perhaps separating purpose and behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% schema coverage for 3 parameters, the description is severely incomplete. It does not explain return values, errors, or parameter details, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the parameters beyond their names. The redaction hint is about output, not parameters. The description fails to explain what 'environment' or 'integration_id' are, or the effect of 'include_credentials'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'one Nango integration', and mentions credential redaction. It distinguishes from list_integrations but doesn't explicitly differentiate from other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description is too brief to convey any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Import/create' implies mutation, but it does not state whether the operation is idempotent, what side effects occur, whether it requires specific permissions, or what the response looks like. No information about error conditions or existing connections is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. It is appropriately concise with no fluff. However, it is under-specified, which is a completeness issue rather than a structure issue, so the conciseness itself is well-handled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and zero parameter coverage, the description is severely incomplete. It fails to explain the environment parameter, the payload requirements, the expected outcome, or any constraints. The agent has insufficient information to correctly invoke this tool without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. It only mentions 'payload shape' without specifying the structure or required fields, and it does not clarify how 'environment' is used. With no schema descriptions, the description must compensate but fails to provide any parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Import/create') and resource ('a connection') and adds a specific detail about the payload shape ('using the Nango API payload shape'). It is distinct from sibling tools like list_connections or get_connection, though it could be confused with create_connect_session since both create/import connections. The purpose is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., requires an environment), or scenarios where this is preferred over create_connect_session or other connection-related tools. The agent is left to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It implies a read operation ('Query') but does not state explicitly that it is non-destructive, nor does it mention authentication, rate limits, or side effects. The vague 'bounded, strict camelCase controls' hints at input validation but nothing actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is not bloated, but the phrase 'bounded, strict camelCase controls' is cryptic and wastes space on vague terms instead of useful detail. It is not front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema, no annotations), the description is severely inadequate. An agent cannot determine how to construct a valid request, interpret the response, or understand pagination, filtering, or field selection. The description is nearly useless for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to any of the 10 parameters. It does not explain cursor, fields, filters, describe, pageSize, objectMode, textSearch, responsePath, or even the required environment and artifactId. The phrase 'strict camelCase controls' is too abstract to help an agent understand parameter formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Query a stored provider response.' It does not explicitly distinguish from siblings, but the resource is distinct enough. The phrase 'bounded, strict camelCase controls' hints at parameter constraints but is vague, missing specifics like filtering or pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like proxy_request or download_provider_file. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions token safety, but does not describe error handling, rate limits, pagination behavior, response format, or what happens on non-2xx statuses. For a proxy request tool that can perform arbitrary HTTP calls, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (a single sentence), but this comes at the cost of missing critical information. It is not structured to front-load the most important caveats or usage details. The brevity is negative here because the tool is complex with 15 parameters and no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), this description is drastically incomplete. An agent would need to know which parameters are required for various HTTP methods, how cursor and pageSize interact, the meaning of responseMode/responsePath, and the security implications of the connection. None of this is provided, making the tool nearly unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation for any of the 15 parameters. Parameters like environment, providerConfigKey, responseMode, and cursor are cryptically named and entirely undefined. The description adds zero value beyond the raw schema, leaving the agent without any guidance on how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Call a provider API through the Nango Proxy') and a key differentiator ('without exposing provider tokens'). It clearly distinguishes this tool from sibling tools focused on connection/integration management (e.g., get_connection, create_integration) by targeting direct API invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing an existing connection), no comparison to related tools like get_connection or refresh_connection_credentials, and no exclusions. An agent would have to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the output is 'compact' and 'redacted,' implying read-only behavior and data redaction, but does not explicitly disclose readOnlyHint, side effects, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, which is concise and front-loaded. However, some critical information is omitted, balancing efficiency with adequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too minimal for a tool with 4 parameters and many siblings. It does not explain what 'context view' includes, what is redacted, or how it differs from get_connection. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 4 parameters, and the tool description does not clarify the meaning or format of any parameter (environment, connection_id, provider_config_key, include_raw_provider_template). Since schema coverage is very low, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'compact, redacted context view for one connection,' indicating a specific subset of connection data. However, it does not explicitly differentiate from the sibling 'get_connection' tool, which likely returns full connection details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_connection or other connection-related tools. The description lacks context about preferred use cases or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Explain,' implying a read-only operation, but omits any behavioral traits like auth requirements, rate limits, or side effects. The description adds minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but lacks structure. It is front-loaded but too brief to be maximally helpful. Every word earns its place, but more detail would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters but has an output schema, the description should explain what 'convention helpers' are and what the output provides. It fails to do so, leaving the agent with an ambiguous understanding of what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the description cannot add meaning beyond the schema. Baseline 4 applies as the schema provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'Explain[s] the optional Nango MCP connection convention helpers,' which is a bit vague. It identifies the resource (convention helpers) and action (explain) but doesn't specify what aspect or level of detail, nor does it distinguish from sibling tools like 'apply_connection_convention'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to describe vs. apply a convention). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that 'credential-like response fields are redacted', which is a useful behavioral trait. However, it does not mention other behaviors like read-only nature (though 'Get' implies it), rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but at the cost of omitting necessary details like parameter meanings or output structure. It is not overly verbose but lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required), no output schema, and no annotations, the description is insufficient. It doesn't explain the purpose of the connection, the context of Nango, or what the response contains beyond the redaction note. The agent likely lacks enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain any parameters. Neither 'environment', 'connection_id', 'provider_config_key', nor 'include_credentials' are described. The description adds no meaning beyond the schema's type and name information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a Nango connection', using a specific verb and resource. It distinguishes from sibling tools like 'list_connections' (which lists) and 'get_connection_context' (which gets context). However, it lacks explicit mention of retrieving by identifiers, which could be inferred from required parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_connections' or 'get_connection_context'. Also no indication of prerequisites (e.g., environment must exist) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry behavioral context. It explicitly states that secret material is not returned, which is a key safety behavior. However, it does not mention authentication requirements, side effects, or whether the list is filtered or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates purpose and a key behavioral trait. It is not verbose, but could be improved by adding a brief explanation of the optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description does not explain the 'refresh' parameter or provide enough context for the agent to decide when to use this tool. The purpose is clear, but for a tool with one parameter and many siblings, it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'refresh' is not explained in the description, and the schema has 0% description coverage. The description does not add any meaning beyond the schema, leaving the agent to infer its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'environments', and adds a useful constraint about not returning secret material. It distinguishes from sibling tools like list_connections and list_integrations by its focus on environments, though it could explicitly mention this separation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. Given the many sibling tools, explicit context about when to list environments versus connections or integrations would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It does not mention read-only nature, pagination, request limits, or potential side effects. The description only states 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It efficiently conveys the primary purpose, though it could benefit from additional structure or details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description is minimally complete. It fails to mention return format, pagination, or how the 'refresh_secret' parameter affects the output. However, given the low complexity, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It references the 'environment' parameter but does not explain the 'refresh_secret' boolean parameter at all. The term 'configured' is vague regarding what integrations are included.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists integrations configured in one Nango environment, using a specific verb and resource. It distinguishes from siblings like 'get_integration' (specific) and 'create_integration' (creation). However, it does not specify whether it returns all integrations or a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_integration for a single integration). The context must be inferred from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not indicate whether the operation is read-only, destructive, or requires authentication. The term 'Audit' suggests analysis, but without explicit statement, the agent cannot infer safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks important details about parameters and behavior. It is appropriately sized but under-specified, so it scores in the middle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema, the description is too brief. It does not explain what the audit produces or how to interpret results. The lack of parameter details and behavioral context makes it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any parameters. The meaning of 'environment' and 'limit' is entirely left to the schema's minimal titles, adding no value beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Audit'), resource ('Nango connections'), and purpose ('for suggested MCP tag/metadata conventions'). It effectively distinguishes from sibling tools like 'apply_connection_convention' and 'describe_connection_convention' by emphasizing the auditing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when you want to audit conventions, but it does not provide explicit guidance on when to use it versus alternatives like 'check_environment' or 'describe_connection_convention'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must compensate. It mentions the tool does not return the secret key, indicating a safe read operation. However, it fails to state whether the tool is read-only, requires authentication, or has any side effects like refreshing environment data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. However, it lacks structure such as breaking out parameter details or providing bullet points, which would improve readability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema that may explain the return value, the description neglects parameter guidance and usage context. Given the tool's simplicity (two params, one required), the description is minimally adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameters. It does not mention the 'environment' parameter (which is required) or the 'refresh' parameter (boolean with default false). The agent is left without any understanding of how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a single Nango environment without exposing its secret key. It effectively distinguishes from sibling tools like list_environments, but uses the vague verb 'resolve' rather than a more specific action like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_environments or get_connection. The description does not include any prerequisites, context of use, or warnings about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits like read-only access, rate limits, pagination, or response size. It only hints at filtering but lacks comprehensive behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. It earns its place but could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It lacks return value details, pagination info, and parameter usage guidance, leaving agents under-informed for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only mentions 'tag filters', hinting at the `tags` parameter but fails to describe other parameters like `environment`, `connection_id`, `search`, and `limit`, leading to significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Nango connections', providing a specific verb and resource. While it distinguishes from 'get_connection' for single fetch, it lacks additional context about what a connection represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint: 'Prefer tag filters such as end_user_id and organization_id.' However, it does not specify when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('set or patch') without explaining side effects, whether it overwrites or merges, or what happens to existing metadata. No permissions or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with the primary action front-loaded, followed by a useful caution. No wasted words, though it omits necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no output schema or annotations, the description is minimal. It does not explain the purpose of metadata, how it relates to connections, or what the expected outcome is. The missing behavioral and parameter details make this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds a semantic constraint on the metadata parameter (no credentials/config), but other parameters (environment, connection_id, provider_config_key, patch) are left entirely undocumented, relying on the reader's inference from the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (Set or patch) and resource (connection metadata), which distinguishes it from read-focused siblings like get_connection_context and tag-focused patch_connection_tags. No explicit sibling differentiation, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a negative constraint ('Do not put credentials or required connection config here') which guides content selection, but offers no guidance on when to use this tool versus alternatives such as get_connection_context or patch_connection_tags. No explicit context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is a forced refresh (implying proactive action) and that the output excludes secrets, which is useful. However, with no annotations provided, it does not reveal potential side effects (e.g., invalidation of existing tokens), error behavior, or permission requirements. The description adds some transparency but leaves significant behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action and output constraint. It is concise with no filler words, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return format is partially covered), the description lacks critical context: no parameter semantics, no side-effect warnings, no usage conditions, and no annotation support. For a tool that forces a refresh, an agent would benefit from knowing prerequisites or failure handling. The description is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. The description does not mention environment, connection_id, or provider_config_key at all. Since these parameters are undocumented in both the schema and the description, the agent receives no semantic guidance on what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Force an OAuth refresh') and the output ('return only a non-secret credential summary'). It is specific and distinguishable from siblings like get_connection or delete_connection, which do not force a refresh or restrict output to non-secret data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_connection or delete_connection. No prerequisites, exclusions, or recommended contexts are mentioned. The description solely states the operation without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the basic purpose without disclosing behavioral traits like pagination, search behavior, or what the output contains. This is insufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but given the tool's complexity (4 parameters, no schema descriptions), it is too brief. It sacrifices useful details for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides no guidance on the search behavior, parameter usage, or expected results. It is incomplete for a tool that requires user input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning for the 4 parameters. It does not mention any parameters or their roles, leaving the agent to infer from names alone, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Nango provider templates', with a clear purpose 'before creating an integration'. This distinguishes it from sibling tools like create_integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a prerequisite step before creating an integration, providing context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses that the operation replaces the complete tag set, implying any omitted tags are removed. The 'fetch and merge' instruction reinforces the destructive nature. Could be slightly more explicit about deletion of untracked tags, but the implication is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and scope, the second provides a critical usage caveat. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description covers the essential behavioral details (full replacement and merge-before-single-tag-change). It does not mention return values or error conditions, but those are less critical for this simple operation. The core knowledge needed to call it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to 'tags' by calling it the 'complete tag set', but does not explain 'environment', 'connection_id', or 'provider_config_key', which are standard identifiers. Given the simplicity of these names, the agent can infer their purpose, but the description falls short of fully clarifying all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Replace' and the resource 'a connection's complete tag set', making it unambiguous. It clearly distinguishes from hypothetical per-tag updates by emphasizing replacement of the entire set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'Fetch and merge first when changing one tag', which tells the agent when to use this tool (for full replacement) versus a manual merge workflow. It does not name a specific alternative tool but gives actionable context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LevSky22/nango-mcp-server'

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