apidog-mcp

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation2/5
Multiple tools overlap significantly: create_api_detail, add_request, and add_endpoint all create API endpoints; update_api_detail, update_request, update_endpoint, and patch_openapi all handle updates; delete_api_detail, delete_request, and delete_endpoint are near-duplicates. Agents will struggle to choose the correct tool without deep inspection.
Naming Consistency3/5
All tools share a consistent 'apidog_' prefix and snake_case format, mostly following verb_noun. However, there are inconsistencies: 'add' vs 'create' for similar operations, 'get_openapi' is an alias for 'export_openapi', and 'update_module' overlaps with 'rename_module'.
Tool Count2/5
With 36 tools, the surface is too large for a single MCP server. Many tools are aliases or redundant variants (e.g., three creation methods, three update methods, three delete methods), inflating the count without adding distinct capability.
Completeness2/5
The API lifecycle is covered through multiple overlapping paths, but there are notable gaps: no environment CRUD beyond listing, no test case management beyond listing tags/categories, and the export-modify-validate-import cycle suggests missing native mutation endpoints. The surface is broad but not cleanly complete.
Average 3.1/5 across 36 of 36 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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. 'Alias for apidog_export_openapi' reveals nothing about side effects, permissions, return values, or operational characteristics.
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 but under-specified. It is not conciseness with substance; it omits almost all meaningful content while providing only a cross-reference.
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?
This is an 8-parameter tool with no output schema, no annotations, and a one-line description that adds no behavioral, parametric, or return-value context. The definition is grossly insufficient for correct selection and invocation.
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 only 25%, and the description adds zero parameter information. None of the 8 parameters (e.g., branchId, oasVersion, environmentIds) are explained or contextualized, leaving the agent without meaningful guidance for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Alias for apidog_export_openapi,' which identifies the tool as an alias but does not state what it does. The actual purpose of exporting an OpenAPI specification is implicit and depends on knowledge of another tool.
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 apidog_export_openapi or other sibling tools. The alias reference implies substitutability but provides no explicit 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 provided, the description carries the full burden of behavioral disclosure. It only says 'create', which implies a mutation, but does not disclose potential side effects, required permissions, branch/project fallback behavior, or what happens on success. Minimal behavioral information is conveyed.
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 short sentence with no wasted words, so it is concise. However, it is under-specified and essentially repeats the tool name, which undermines the value of the sentence. It is not misleading, but it does not enrich understanding.
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 has 6 parameters, no annotations, no output schema, and many sibling tools, this one-sentence description is severely incomplete. It lacks information about the folder's purpose, required context (e.g., moduleId), optional fields (branches, parents), and any nesting or fallback behavior, making it inadequate for correct tool selection and 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?
Schema description coverage is only 33%, and the tool description adds no parameter information whatsoever. It does not explain the meaning or usage of moduleId, parentId, type, or other fields, leaving a significant gap for the agent to interpret the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an API detail folder' is a direct restatement of the tool name 'apidog_create_api_detail_folder', making it tautological. It does not add detail about what an 'API detail folder' is or how it differs from creating a module or API detail, so it fails to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like apidog_create_module or apidog_create_api_detail. There is no mention of prerequisites, required fields, or typical scenarios, leaving the agent without direction.
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?
No annotations are provided, so the description carries the full burden of disclosing side effects, output behavior, or permissions. The phrase 'Export OpenAPI' is simply a restatement of the tool's name without additional behavioral detail.
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 with no wasted words. While extremely concise, it provides minimal information; it could benefit from a bit more detail while remaining concise.
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 8 parameters, no annotations, and no output schema, yet the description only states the basic action. It fails to explain what the export produces (file? string?), fallback behavior, or any constraints. This is a significant gap for such a complex 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 description does not mention any parameters. With only 25% schema description coverage, the tool description should compensate by explaining key parameters like exportFormat or addFoldersToTags, but it remains silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and the resource ('OpenAPI from Apidog'), making the basic purpose understandable. However, it does not differentiate from the sibling tool 'apidog_get_openapi', which also deals with OpenAPI retrieval, so it is not fully distinctive.
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 instead of alternatives like 'apidog_get_openapi' or 'apidog_import_openapi'. It lacks any context about prerequisites, use cases, 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 full burden for behavioral disclosure. It states the action ('rename') but does not disclose side effects, permission requirements, return values, or impact on child resources. Minimal behavioral insight beyond the verb itself.
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, clear sentence with no wasted words. It is front-loaded with the core action. However, given the tool has four parameters and no other context, a bit more structure (e.g., listing key parameters) would improve usefulness without bloating.
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?
This is a mutation tool with four parameters, no output schema, and no annotations. The description only states the action, failing to explain return behavior, parameter semantics, or use cases. It is inadequate for an agent to select and invoke correctly without guessing.
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 information about parameters. Schema coverage is only 50% (branchId and projectId have descriptions), and critical required params name and folderId are undocumented in both schema and description, leaving the agent to guess their meaning and format.
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 ('Rename') and resource ('API detail folder'), clearly stating what the tool does. It distinguishes the target resource from siblings like 'rename_module' or 'delete_api_detail_folder', though it does not explicitly call out alternatives.
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, nor are prerequisites (e.g., needing folderId, projectId) mentioned. The only implication is that the tool is for renaming, but without clear context or exclusions.
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?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. The description only says 'Rename a module' and fails to mention any side effects, requirements (e.g., module must exist), or what happens to existing data. This is a bare statement with no 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?
The description is a single sentence with no unnecessary words, so it is concise. However, it is under-specified; while brief, it sacrifices useful detail that could be added without bloat, making it merely adequate.
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?
There are no annotations and no output schema, so the description needs to provide more context. It does not mention the optional fallback behavior for branchId/projectId, any prerequisites, or what the tool returns. The description is too minimal to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes branchId and projectId, but the tool description does not explain the required parameters moduleId and name. It adds no meaning beyond the schema's partial coverage (50%), and it does not compensate for the undefined parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the resource ('a module in an Apidog project'), which is specific and understandable. However, it does not distinguish this tool from sibling tools like update_module or create_module, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention that this is specifically for renaming only, nor does it reference update_module for other module modifications. It provides no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions that null values remove fields and that the patch goes through export-modify-validate-import, but it omits critical side effects, permission requirements, reversibility, and response behavior 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence that front-loads the core action and key behavior. However, it is too terse for a tool with 12 parameters and nested options, and it sacrifices necessary detail in favor of 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?
For a complex mutation tool with no annotations, no output schema, and many parameters, this description is severely incomplete. It does not explain return values, side effects, the actual processing workflow, or any of the important option fields, making it inadequate for an agent to use safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (3 of 12 parameters have descriptions). The description adds the important nuance that null values remove fields for the patch parameter, but it does not compensate for the other undocumented parameters like path, method, options, branchId, or projectId, leaving 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 uses the specific verb 'patch' and identifies the resource as 'an existing endpoint operation', which is clear. It hints at a workflow (export-modify-validate-import) but does not explicitly differentiate from sibling tools like upsert_endpoint or patch_openapi, so it loses a point for lack of sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus add_endpoint, upsert_endpoint, delete_endpoint, or patch_openapi. It implies the endpoint exists, but it does not state exclusions, prerequisites, or alternative tool selection 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?
With no annotations, the description carries the full burden of disclosing side effects and safety traits. It reveals a multi-step process (export-modify-validate-import), but does not explain whether existing endpoints are overwritten, if validation failures are handled gracefully, or what happens to unmatched resources. This leaves significant ambiguity for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no padding. Every word contributes to the basic purpose, though the hyphenated 'export-modify-validate-import' could be clearer. It is concise, but not overly terse to the point of being meaningless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, nested objects, no output schema, no annotations), the description is grossly insufficient. It provides only a high-level workflow and omits crucial context about parameter purposes, preconditions, side effects, or return values. The agent would need to infer too much.
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 only 25% (3 of 12 parameters have any description), and the tool description offers no parameter-level semantics. It does not explain the meaning or role of required parameters (path, method, operation) or the numerous options (schemaOverwriteBehavior, deleteUnmatchedResources, etc.), failing to compensate for the schema's sparse coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add an endpoint') and hints at a specific workflow ('export-modify-validate-import'). However, it does not distinguish this tool from siblings like apidog_upsert_endpoint or apidog_import_openapi, leaving the agent to infer the unique value proposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The terse phrase 'by export-modify-validate-import' implies a round-trip process, but there is no mention of prerequisites, exclusions, or selection criteria, leaving the agent without adequate 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 bears full responsibility for disclosing behavior. It mentions 'practical defaults' but does not specify what those defaults are, nor does it describe side effects, permissions, or return values. The mutation nature is implied by 'Create', but key behavioral details are absent.
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 is efficient in length. However, it lacks substance and structure, providing minimal information despite being front-loaded. It is concise but under-specifies the tool's behavior.
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?
The tool has 15 parameters, no output schema, and no annotations, yet the description is extremely brief. It does not explain the required parameters, the meaning of the 'practical defaults', or any return behavior. This is insufficient for an agent to use the tool correctly without relying on the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), so the description must compensate by explaining parameters. It does not mention any specific parameters or defaults beyond the vague 'practical defaults'. The schema already contains defaults for fields like 'path', 'status', and 'folderId', but the description fails to clarify their use or 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 clearly states the tool creates an Apidog HTTP request/API detail, using a specific verb and resource. However, it does not distinguish itself from sibling tools like 'apidog_create_api_detail' or 'apidog_add_endpoint', and the phrase 'request/API detail' is slightly ambiguous.
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 any exclusions, prerequisites, or context for selection, leaving the agent without enough information to choose correctly among many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only hints at the process ('export-modify-validate-import'). It doesn't mention potential side effects such as overwriting existing endpoints, modifying schemas, or the `deleteUnmatchedResources` option that could lead to destructive changes. The mutating and possibly irreversible nature of an upsert is not adequately warned about.
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, compact sentence with no redundant words. It front-loads the primary action and the workflow, making it highly efficient. Every word contributes to conveying the core purpose, so it scores high on conciseness.
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?
This tool is complex (12 params, nested objects, no output schema, no annotations), yet the description provides only a two-word intent and a workflow phrase. It lacks critical context like return values, error behavior, how to obtain projectId/branchId, or what happens during the import phase. The description is wholly inadequate for confident 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?
Schema description coverage is only 25%, yet the description provides zero parameter explanations. It doesn't clarify required parameters like `path`, `method`, or `operation`, nor the numerous optional parameters and their nested options. This is a severe gap for an agent needing to construct a correct invocation.
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 core action: 'Create or update an endpoint operation', which is specific and identifies the resource. The added workflow 'export-modify-validate-import' helps differentiate it from sibling tools like `apidog_add_endpoint` and `apidog_update_endpoint`, though the description doesn't explicitly contrast those alternatives.
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 gives no explicit when-to-use guidance or alternative tool references. It only implies a workflow (export-modify-validate-import), leaving the agent to infer that this might be for syncing changes. No prerequisites, exclusions, or recommendations are provided, making this a weak area.
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?
Without annotations, the description carries the full burden of disclosing side effects. It only repeats the schema's confirmDelete constraint and provides no information about irreversibility, cascading effects, permissions, or what happens after deletion.
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 with no fluff. However, the 'Requires confirmDelete=true' clause is redundant with the schema and does not earn its place fully.
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 delete tool with no annotations or output schema, the description omits critical context such as how to obtain apiDetailId, whether deletion is permanent, and what the response indicates. It is inadequate for safe usage.
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 coverage is only 50%, so the description should compensate for undocumented parameters like apiDetailId and confirmDelete. It only restates the confirmDelete requirement and does not clarify the role of apiDetailId beyond the tool's action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Delete an Apidog API detail/request') with a specific verb and resource. It distinguishes from sibling delete tools by naming 'API detail/request', though ambiguity with 'delete_request' prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like delete_request or delete_endpoint. The only usage hint is 'Requires confirmDelete=true', which is a constraint, not a contextual recommendation.
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 is the sole source of behavioral disclosure. It only states 'Validate and import', which is a minimal description of the operation. It fails to disclose that importing can overwrite existing endpoints (via 'endpointOverwriteBehavior'), delete unmatched resources ('deleteUnmatchedResources'), or perform other side effects. The description is not misleading, but it is highly incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and every word is relevant, making it highly efficient even though it is minimal.
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?
The tool has 5 parameters, nested objects, no output schema, and no annotations, yet the description only provides the high-level action. It omits essential context such as how the validation behaves, the fallback behavior for projectId/branchId (partially covered in schema), potential side effects, and required setup. This is insufficient for a tool of this complexity.
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?
Only 40% of the parameters have descriptions in the schema (branchId and projectId), and the description text adds no parameter semantics at all. The nested 'options' object with its many properties is entirely undocumented, and the description fails to compensate for this low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Validate and import' with the resource 'OpenAPI' into 'Apidog', clearly stating the tool's core action. However, it does not differentiate from the sibling tool 'apidog_validate_openapi', which also validates, or 'apidog_patch_openapi', which may have overlapping import-like functionality.
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 gives no guidance on when to use this tool over alternatives. It does not mention that validation-only is available via 'apidog_validate_openapi' or mention any prerequisites, so the agent has no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action and input format, omitting side effects, authentication requirements, or the branch/project fallback behavior that the schema briefly mentions. The description adds minimal value beyond the structured 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 short sentence, highly concise with no filler. However, it sacrifices needed contextual information for brevity, making it less informative than it could be.
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?
The tool has a required nested object parameter and no output schema, but the description does not explain the expected result, prerequisites, or when to use it. Sibling tools provide context, but this description is insufficient for a create operation with complex input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds the phrase 'raw Apidog form fields,' which reinforces the apiDetail parameter's format but does not materially add beyond what the schema states.
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 the specific verb 'Create' and identifies the resource as 'Apidog API detail', which clearly distinguishes it from siblings like apidog_update_api_detail and apidog_create_api_detail_folder. The phrase 'using raw Apidog form fields' hints at the input format, though it could be more explicit about what an API detail entails.
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 apidog_update_api_detail or apidog_create_api_detail_folder. The description lacks any context for selection and does not mention any preconditions or fallback behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the indirect export-modify-validate-import workflow and the mandatory confirmDelete=true, which adds some context. However, it fails to mention permanent deletion, side effects on related resources, or failure behavior. Score 3 for partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, both informative. It front-loads the action and then states a key requirement. No fluff or repetition. Score 5 for concise structure that earns its place.
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 13 parameters, nested objects, low schema coverage, and no annotations or output schema, this description is grossly incomplete. It provides only the basic action and one parameter, leaving the agent without enough context for safe invocation. Score 1 for inadequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 23%, and the description adds minimal parameter insight. It only reiterates the confirmDelete requirement, which is already specified in the schema as a const true field. Other parameters like path, method, options, and deleteUnmatchedResources remain largely undocumented. Score 2 for failing to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an endpoint, using a specific verb and resource. It doesn't distinguish from sibling tools like update_endpoint or delete_api_detail, but the resource (endpoint) is distinct enough. Score 4 for clear purpose without sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_endpoint or upsert_endpoint. The only usage hint is the confirmDelete requirement, which is a prerequisite, not a usage context. Score 2 for lack of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure, but it only states 'List...' without mentioning whether authentication is required, whether the operation is read-only, or whether pagination or filtering exists. This absence of behavioral context leaves the agent uncertain about side effects and data volume.
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 brief sentence, which is efficient and front-loaded. It earns its place by stating the core function, but could easily include additional context (e.g., return format, default branch behavior) without becoming 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 the lack of an output schema and minimal annotations, the description should explain what the list contains, any defaults, and return structure. It does none of this, making the tool functionally underspecified for an agent attempting to use it correctly, despite the schema's helpful parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters, with descriptions for branchId and projectId explaining fallback behavior. The tool description adds no parameter-level information, so the baseline of 3 applies as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List reusable API response components' clearly states a specific action (list) and a specific resource (reusable API response components). It distinguishes itself from sibling tools like 'apidog_list_api_tree' and 'apidog_list_modules' by naming the resource type, though it doesn't clarify what constitutes 'reusable API response components' in Apidog's context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of other list tools, nor are any prerequisites mentioned. The optional branchId/projectId fallback is only implied by the schema descriptions, but the tool description itself gives no context about how these parameters affect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only operation by the word 'List', but gives no details about response structure, pagination, potential size, or authentication requirements. For a tool with no annotations, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, directly stating the tool's core function. It is front-loaded with the action and resource, contains no fluff, and is appropriately sized for a tool with a simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should compensate by explaining what the API tree is, what it includes, and any notable behaviors. It does none of that. For a tool that likely returns a complex hierarchical structure, the one-line description is insufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly, including fallback behavior. The description adds only the phrase 'configured or specified project', which aligns with the schema but doesn't provide additional meaning or clarification beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('the Apidog API tree'), with scope ('for the configured or specified project'). It distinguishes itself from sibling tools like list_modules or list_api_detail_folders by implying a complete tree structure, though it doesn't explicitly enumerate what the tree contains.
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 explicit guidance on when to use this tool versus alternatives. It mentions fallback behavior for projectId/branchId to apidog.json, but that is parameter context, not usage context. Sibling tools such as list_modules or list_api_detail_folders are not referenced, leaving the agent to infer which tool is appropriate for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. 'Update' implies mutation, but it does not explain side effects, authentication requirements, whether the update is partial or full, or what the response contains. The schema partially covers patch semantics, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences. The first states the general function, the second provides a specific use case; neither is redundant. However, there is no structured breakdown (e.g., prerequisites, examples), so it is efficient but not exemplary in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a nested patch object, no output schema, and no annotations, this description is too sparse. It lacks essential context such as how the patch object is applied, whether updates are partial, the role of moduleId, and any return value information. A more complete description would address these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with patch, branchId, and projectId documented, but moduleId lacks a description. The description adds no parameter-level information and does not compensate for the missing moduleId explanation. It merely restates the general purpose already evident from the tool name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource ('Update module fields') and adds a concrete use case ('Use for renaming modules'). However, it does not distinguish itself from the sibling tool 'apidog_rename_module', which likely overlaps in purpose, preventing a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use for renaming modules' provides a specific scenario, implying when to use this tool. However, it does not mention alternatives, exclusions, or how it differs from 'apidog_rename_module' or other module-related tools, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that it writes a file and modifies .gitignore, which are concrete side effects. However, it does not disclose whether it overwrites an existing apidog.json, appends to .gitignore, or requires any authentication or directory context. The transparency is partial but not deceptive.
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, tight sentence that conveys the core action without filler. Every word contributes to understanding the tool's behavior, making it highly concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (writes a config file), but the description omits critical contextual information: parameter semantics, whether the operation is idempotent, and any return value. Given the absence of an output schema and annotations, the description alone is insufficient for an agent to fully understand the tool's behavior and usage.
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 of the parameters. The schema shows projectId (required) and branchId (optional), but the description does not indicate what these values represent or how they are used. An agent selecting values would have no guidance on what to pass for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action: 'Write apidog.json in the current directory and add it to .gitignore.' This provides a specific verb (Write/add) and resource (apidog.json/.gitignore), which clearly distinguishes it from sibling tools that focus on API objects, modules, or test cases.
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 gives no guidance on when to use this tool, prerequisites, or alternatives. It does not mention that this should be run before other apidog commands, nor does it explain any context such as what apidog.json is used for. The agent is left to infer the tool's purpose 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'List modules', implying a read-only operation, but does not disclose details such as authentication requirements, pagination, return format, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no unnecessary padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple list tool with no output schema, and the description covers the basic purpose. However, it lacks context about what 'modules' means in Apidog, whether there are any prerequisites (like a configured apidog.json), or what the return structure is. Given the simplicity, it is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both branchId and projectId documented in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, warranting the baseline score of 3.
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 the resource 'modules in an Apidog project', making the tool's function obvious. However, it does not explicitly differentiate from sibling tools like apidog_list_api_tree or apidog_list_api_detail_folders, so it misses full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or comparisons are provided. The description simply states the action without contextual usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Create a module'. It does not disclose whether the operation is mutating, what authentication or project setup is required, what happens on error, or what the return value is. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence: 'Create a module in an Apidog project.' It is front-loaded with the verb and resource, contains no filler, and is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema, yet the description omits return value details, preconditions, and how it relates to similar tools. It does not mention that projectId/branchId can be resolved from apidog.json (that information is only in the schema). Overall, the description is too terse to fully support correct invocation in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters (branchId and projectId have descriptions mentioning fallback to apidog.json). The description adds no parameter semantics beyond the schema. The 'name' parameter is self-explanatory from the tool name and required status, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the target resource ('a module in an Apidog project'). It does not get confused with siblings like apidog_list_modules, apidog_update_module, or apidog_rename_module because it specifies creation.
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 apidog_update_module or apidog_rename_module. It also does not mention prerequisites or context like needing an existing project (though the schema hints at fallback behavior).
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 behavioral burden. It only repeats the schema's confirmDelete constraint, which is already visible. It does not disclose whether the deletion is permanent, whether it cascades to child items, or whether special permissions are required. 'Requires confirmDelete=true' adds minimal value beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the action ('Delete a module') before the requirement. It is appropriately concise for a simple delete operation, though it could include additional safety context without bloating much.
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 and no output schema, the description is too thin. It does not mention permanence, effect on dependent data, or what happens on success/failure. The confirmDelete requirement is a useful hint but leaves critical context absent, especially for an AI agent deciding whether this tool is safe to invoke.
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 50% (branchId and projectId have descriptions in the schema, moduleId and confirmDelete do not). The tool description does not explain moduleId or confirmDelete semantics beyond what the schema shows, nor does it mention the fallback behavior for optional parameters. It fails to compensate for the uncovered 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 'Delete a module in an Apidog project' uses a specific verb (delete) and resource (module), clearly distinguishing it from sibling tools like create_module, update_module, rename_module, and list_modules. It also immediately states the confirmation requirement, making the tool's primary function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a module needs to be removed from an Apidog project. It also states a necessary precondition (confirmDelete=true) but provides no explicit guidance on when not to use it or how it differs from update/rename alternatives. The purpose alone makes the use case clear, but there is no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the confirmDelete=true prerequisite, which is a meaningful behavioral guard. With no annotations provided, it carries the full burden but does not mention side effects, permissions, or reversibility. The 'alias' hint suggests it behaves like another tool but without specifying which one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences that front-load the core purpose and a critical requirement. Every word adds value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is minimal. It lacks information about return values, prerequisites, side effects, or how it differs from closely related tools. The confirmation guard is the only additional context beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (branchId and projectId have descriptions). The description adds the confirmDelete requirement but does not explain apiDetailId beyond implying it identifies the resource. This partially compensates for the missing schema descriptions but falls short of full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deleting') and the target resource ('Apidog HTTP API detail/request'), making the purpose understandable. However, it does not explicitly differentiate this from sibling tools like apidog_delete_api_detail, and the word 'Alias' adds slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other delete-focused siblings (e.g., delete_module, delete_endpoint). The description only mentions the tool's function and a confirmation requirement, but no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the destructive nature ('Delete') and the confirmation requirement, but does not mention permanence, cascading effects, authorization needs, or other behavioral consequences. This is a minimal disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. Every word contributes value, and it is appropriately sized for a simple deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description covers the essential action and confirmation requirement. However, without annotations or an output schema, it leaves out potentially important context such as whether deletion is permanent or affects child resources. It is minimally complete but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for branchId and projectId, but folderId lacks a description. The description adds no direct explanation of folderId beyond the tool name, and repeats the confirmDelete=true requirement already present in the schema via 'const'. With 50% schema coverage, the description only partially compensates.
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 ('Delete') and the target ('API detail folder'), distinguishing it from sibling delete tools like apidog_delete_module or apidog_delete_api_detail. The inclusion of 'Requires confirmDelete=true' provides a precise condition for the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the action and the confirmDelete requirement, but offers no context about prerequisites, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'List environments' which adds little beyond the tool name and gives no information about authentication, return format, fallback behavior, or other operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. There is zero wasted phrasing and it is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and schema covers parameters fully. However, there is no output schema and annotations are absent, so the description could have mentioned what is returned or any fallback behavior. It is minimally adequate for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (branchId and projectId) having their own descriptions, so the baseline is 3. The tool description adds nothing about the parameters, and no extra value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('environments in an Apidog project'). It is specific and distinguishes this tool from all listed siblings, none of which mention environments.
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, and no exclusions or context are given. The description simply states the function without any 'when to use' or 'when not to use' information.
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. 'List' implies a read-only operation, but there is no mention of pagination, output format, authentication needs, or how projectId/branchId fallback works. This is minimal disclosure beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words or redundancies. It efficiently states the purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers parameters fully. However, the description lacks usage guidelines and behavioral context, and with no output schema, a bit more detail would make it more complete. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters, including their optional nature and fallback to apidog.json. The tool description adds no parameter-specific context, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List), the resource (test case tags), and the scope (for a project). This distinguishes it from siblings like apidog_list_test_case_categories and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. No mention of prerequisites, configuration steps, or when to choose this over apidog_list_test_case_categories. The schema hints at fallback behavior, but the description itself is silent.
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, and the description does not disclose any behavioral context such as authentication requirements, response format, or error handling. It only states the action without elaborating on side effects or preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the operation, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple fetch tool, the description provides the basic purpose, but lacks context on return values, optional parameters' fallback behavior, or when to prefer this tool over sibling listing tools. The absence of an output schema places more burden on the description, which it only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the parameters beyond the schema. The schema describes projectId and branchId with fallback notes, but apiDetailId lacks a description in the schema and the description does not clarify it further, providing minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'HTTP API detail' and specifies lookup by ID, which distinguishes it from sibling tools like listing APIs or creating modules.
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?
No explicit guidance on when to use this tool versus alternatives such as apidog_list_api_tree or apidog_get_openapi; usage is only implied by the need to fetch a specific API detail by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key behavior that omitted fields are replaced with practical defaults, and that all existing fields must be included to persist. However, it does not mention other behavioral traits such as return values, side effects, or how nested objects are handled.
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 exceptionally concise: two sentences, no filler, and front-loaded with the primary purpose. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, nested objects, no output schema, no annotations), the description is far from complete. It provides the critical preserve-all-fields warning but lacks context about response format, error conditions, project/branch fallbacks, and how to differentiate from sibling update tools. This leaves an agent under-informed for safe and correct 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?
Schema description coverage is only 19%, and the description adds no parameter-specific meaning. The general warning to include all fields does not explain what parameters like apiDetailId, moduleId, method, or nested objects like auth and parameters mean or how to construct them. The description fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an Apidog HTTP request/API detail, providing a specific verb+resource. However, it does not explicitly distinguish from the similarly named sibling apidog_update_api_detail, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Include all fields you want preserved' gives crucial usage guidance, implying that omitted fields may be reset to defaults. This effectively communicates when to use the tool versus create operations, though it does not name alternatives or exclusions explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it disclose any authorization requirements or return-behavior details. It adds minimal behavioral context beyond the name, but the verb is unambiguous enough to infer safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's function. No wasted words, and the 'for endpoint placement reference' qualifier adds purposeful context.
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?
This is a simple list tool with no output schema and no annotations. The description is terse and leaves out important context like what fields are returned, whether the list is paginated, or how 'API detail folders' differ from other folder types. It is adequate for a basic list tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (branchId, projectId) are already documented in the schema with their fallback behavior. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'API detail folders' and indicates its purpose 'for endpoint placement reference'. It uses a specific verb and resource, and it's distinct from sibling tools like list_modules or list_api_tree, though it doesn't explicitly disambiguate from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for endpoint placement reference' provides some usage context (e.g., when you need to decide where to place an endpoint). However, it does not explicitly mention when to prefer this over other list tools like list_api_tree or list_modules, nor any exclusions or prerequisites.
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 burden of disclosing side effects. It states the sequence 'validate, then import' which is a useful behavioral detail, but it does not mention that importing may overwrite existing endpoints or resources, nor any prerequisites like project configuration. The schema options (e.g., deleteUnmatchedResources, OVERWRITE_EXISTING) hint at destructive behavior, but the description omits this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, front-loading the core purpose. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 10 parameters, nested options, and no output schema. The description is too minimal: it does not explain the full workflow (whether it exports the current spec or expects an input), prerequisites, potential side effects, or error behavior. The sparse description is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only branchId and projectId have descriptions). The tool description mentions 'RFC 6902 JSON Patch', which gives context for the patch parameter, but it does not explain the many options (schemaOverwriteBehavior, endpointOverwriteBehavior, deleteUnmatchedResources, etc.). With low schema coverage, the description should compensate, but it does not.
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 applies an RFC 6902 JSON Patch to exported OpenAPI, validates it, then imports it. It uses a specific verb ('Apply') and resource ('exported OpenAPI'), and the combined validate-import sequence distinguishes it from sibling tools like apidog_validate_openapi and apidog_import_openapi.
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 the tool is for patching an exported OpenAPI and then importing it, which gives clear context for when to use it. However, it does not explicitly contrast with using separate export, validate, and import tools, nor does it mention exclusions or prerequisites. It provides just enough context to infer usage.
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 must carry the behavioral disclosure burden. It implies a read-only operation through the verb 'List,' but does not explicitly state that no modifications occur, nor does it mention authentication requirements or the fallback behavior for unset projectId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It states the core purpose clearly and efficiently, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two optional parameters and no output schema, the description provides the essential purpose. However, it doesn't explain the structure of the returned categories or how the project context is resolved when projectId is absent, leaving some minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, including descriptions for branchId and projectId with fallback behavior. The description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'test case categories' with the scope 'for a project.' This clearly distinguishes it from sibling tools such as apidog_list_test_case_tags, which target a different resource.
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 apidog_list_test_case_tags or apidog_list_runners. It neither provides context for use nor mentions any exclusions, so the agent receives no decision support.
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 carry the burden of behavioral disclosure. It states the mechanism (calling an endpoint) but does not disclose the outcome: what is returned on success or failure, whether it throws exceptions, or whether it is read-only. This lack of detail leaves the agent uncertain about how to interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains no unnecessary words or tangential information. It is appropriately concise for the tool's simplicity.
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 zero-parameter tool, the description provides the essential purpose but lacks information about return values or error handling. With no output schema and no annotations, the agent cannot predict whether verification returns a boolean, throws, or returns user data. This is a minimal viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (zero parameters), so schema coverage is trivial. The description mentions the token as context, not as a parameter, and with no parameters, the description need not explain parameter semantics. The baseline of 4 for zero-parameter tools applies.
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: verify the APIDOG_ACCESS_TOKEN by calling the current user endpoint. The verb 'verify' and the specific resource make the purpose unambiguous and distinguish it from sibling tools that perform CRUD or import/export operations.
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 usage is implied: a check for token validity before making other API calls. However, there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no mention of whether it should be called proactively or only after an auth error.
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 alone must disclose behavioral traits. It indicates a read operation ('List') but does not explain the meaning of APIDOG_TEAM_ID, error handling, or side effects. This leaves significant ambiguity about the default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates both the purpose and the key parameter behavior.
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 one-parameter list tool, the description covers the core action and parameter distinction, but leaves the APIDOG_TEAM_ID concept unexplained and does not mention response format, pagination, or error behavior. Given no output schema or annotations, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the bare schema by explaining that teamId is optional and that an explicit value overrides the default APIDOG_TEAM_ID. This goes beyond the schema's simple integer type, giving the agent critical usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'projects' with a scoping condition: either the configured APIDOG_TEAM_ID or an explicit teamId. This distinguishes it from sibling tools like apidog_list_user_projects, which list projects for the current user.
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 presents two usage modes (default team vs explicit teamId) but does not explicitly compare with alternatives or state when not to use this tool. The context implies it is the team-scoped listing tool, but without exclusions or references to sibling tools, guidance is only partially clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'raw Apidog form fields' and the preference for a full detail body, but does not disclose whether the update is a full replacement or partial merge, what permissions are needed, or any side effects. This is a significant gap for an update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, followed by a concise usage tip. No filler or redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with a nested object and no output schema, the description offers helpful guidance to use a full detail body, but it lacks critical context such as whether the update replaces the entire object, what the response looks like, and any error conditions. It is adequately informative but not fully complete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, which is high, so the baseline is 3. The description adds some context by implying that apiDetail should be a full detail body from apidog_get_http_api, which is useful, but it does not meaningfully explain the fallback behavior of branchId/projectId or other parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an Apidog API detail') and the resource ('API detail'), distinguishing it from sibling tools like create/delete/update request. The mention of 'raw Apidog form fields' and the explicit preference for using output from apidog_get_http_api further clarifies its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by recommending 'passing a full detail body from apidog_get_http_api', which tells the agent how to prepare the request. However, it does not explicitly state when not to use this tool or mention alternatives for similar operations, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' clearly implies a read-only operation, but the description does not explicitly state that no modifications occur or mention any authentication, pagination, or filtering behavior. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description accurately conveys the purpose and scope, and while it does not describe the return shape, 'List ... runners' sufficiently implies the result for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds 'for a project' but does not elaborate on the fallback behavior or branch/project relationship beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('self-hosted general runners for a project'), making it clearly distinct from sibling list tools such as apidog_list_modules or apidog_list_user_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a project' provides context, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Since no sibling tool focuses on runners, the usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the safety burden. 'List' signals a read-only operation and 'accessible by the current user' clarifies auth-based scope, but the description does not mention pagination, sort order, or explicit authentication requirements, leaving minor behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is entirely relevant and contains no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description adequately conveys that the tool returns projects accessible by the current user. It would benefit from mentioning the output shape or common use cases, but the tool's simplicity makes it mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description needs no parameter elaboration. The baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and identifies the resource 'projects' scoped to 'the current user', clearly distinguishing it from sibling tools like apidog_list_team_projects. This is a specific verb+resource+scope combination that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 choose this tool over alternatives such as apidog_list_team_projects or apidog_list_user_teams. The single sentence gives no context, exclusions, or references to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It transparently implies a read-only listing of teams scoped to the current user, but provides no additional behavioral context such as pagination, sorting, or authentication requirements. This is adequate for a simple list, but minimal.
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 immediately communicates the core function. No extraneous words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description sufficiently conveys its purpose and scope. It is not missing any critical details that would impair an agent's ability to invoke the tool correctly, though it does not add extra context about return format or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the description does not need to elaborate on parameter details. The baseline of 4 applies here, and the description adds a clear semantic scope ('accessible by the current user').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('teams') with a useful scope ('accessible by the current user'). This distinguishes it from sibling tools like apidog_list_user_projects and apidog_list_team_projects, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states what the tool does, without mentioning exclusions or when to prefer sibling tools like apidog_list_team_projects or apidog_list_user_projects.
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 adds a useful behavioral trait (no import, implying no side effects), but with no annotations provided, it fails to disclose return values, error behavior, or validation specifics. It leaves the agent uncertain about what success/failure looks like, which is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for an agent to use confidently. It does not explain what the tool returns (e.g., boolean, errors, report) or whether validation is syntax-only or semantic. This is a significant gap for a validation tool, as the agent cannot predict the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a parameter named 'document' with no description, and schema coverage is 0%. The description compensates by clarifying that the document is an OpenAPI document and can be JSON or YAML, adding meaning beyond the bare schema. However, it does not specify whether a string is file content or a file path, leaving minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Validate') and resource ('OpenAPI document'), and the qualifier 'without importing it' distinguishes it from sibling tools like import_openapi. It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to validate an OpenAPI document) and implicitly differentiates it from import by noting 'without importing it.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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/ixlammm/apidog-mcp'

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