detection-mcp

by ryan-minato

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource (dataset, category, image, bbox, rotated bbox, export) with clear action verbs. Even the two annotation types are unambiguously separated by bbox vs rotated_bbox in their names.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern, with clear verbs like create, delete, list, edit, add, get, restore, set, preview, export. Minor pluralization inconsistencies (e.g., add_bbox_annotations vs edit_bbox_annotation) do not undermine overall predictability.
Tool Count3/5
At 23 tools, the server sits in the heavy range (16-25). However, the number is justified by the broad domain covering datasets, categories, images, two annotation types, and export, so it feels borderline rather than excessive.
Completeness4/5
The surface covers full CRUD lifecycles for datasets, categories, and both annotation types, plus image status management and export. A notable gap is the lack of a dataset update operation, but core workflows are well-supported.
Average 3.2/5 across 23 of 23 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description mentions 'in one transaction,' hinting at atomicity, but fails to clarify whether the operation is idempotent, whether it overwrites existing annotations, what happens on failure, or any authorization requirements. For a mutation tool adding multiple items, this lack of behavioral context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single line with nine words. It is front-loaded with the core action ('Add normalized xyxy annotations') and adds the qualifier 'in one transaction.' Every word earns its place, but it could be extended slightly to improve other dimensions 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 output schema exists, the description need not explain return values. However, the tool adds multiple annotations, has no annotations providing safety cues, and is part of a family of similar tools. The description fails to explain the 'normalized' coordinate system, the transaction semantics, or how it differs from editing single annotations. It leaves significant gaps for an AI agent to correctly select and invoke the 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 baseline is 3. The description adds no additional meaning beyond what the schema already provides—it does not explain the 'xyxy' format, the normalization convention, or the 'in one transaction' aspect for parameters. The schema itself sufficiently describes the parameters, so the description neither harms nor helps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Add normalized xyxy annotations in one transaction,' which indicates the action is adding bounding box annotations. However, it does not specify the resource clearly—'bbox_annotations' is generic—and given siblings like add_rotated_bbox_annotations, it only faintly distinguishes itself via 'xyxy' (axis-aligned). A more explicit verb+resource (e.g., 'Add axis-aligned bounding box annotations to an image') would improve clarity.
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 its siblings, such as add_rotated_bbox_annotations or edit_bbox_annotation. The description does not mention prerequisites (e.g., dataset and image must exist, categories must be created first) or any alternative tools. Users are left to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only states 'in-memory' (implying no persistence) and 'overlay and metadata' (implying a read operation). It does not mention whether this is a read-only operation, whether it requires special permissions, whether it modifies any state, or what the performance implications are (e.g., large overlays). The description barely scratches the surface of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 7 words). While brevity is valuable, it is too short to convey essential information. The single sentence is front-loaded with the core action, but it lacks structure (no sections, no examples, no elaboration). Every word earns its place, but the description is under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description is insufficient for a tool with 7 parameters and many siblings. It does not explain what an 'overlay' is (e.g., a rendered image, a data structure), how the 'metadata' relates to the overlay, or any constraints (e.g., image format, size limits). The agent would need to rely on the output schema and parameter descriptions to infer behavior, but the high-level intent is too vague. The description is incomplete for the tool's complexity.
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% (all 7 parameters have descriptions in the schema). The tool description adds no additional meaning or context beyond the schema. For example, it does not explain how 'annotation_ids' and 'annotation_type' interact, or what 'max_width' and 'max_height' do together. Baseline score is 3 because the schema is comprehensive, but the description does not enrich the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return an in-memory annotation overlay and metadata,' which clearly indicates a verb (Return) and resource (annotation overlay and metadata). This distinguishes it from sibling tools like 'list_annotations' (returns data) and 'preview_image' (shows raw image). However, the phrase 'overlay and metadata' is slightly vague; it could be more specific about the output format (e.g., rendered image).
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. Siblings include 'list_annotations', 'preview_image', and 'export_metadata_jsonl', but the description does not mention when rendering an overlay is appropriate or when to avoid it. There is no when-not, no prerequisites, and no reference to other tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'validate, correct, and add' but does not specify what corrections are performed (e.g., convexity, ordering, rectangularity are enforced but this is partial—the polygon shape requirements are mentioned in the schema, not the description). The description does not state mutability, idempotency, rate limits, or error behavior. For an atomic write tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (single sentence, 6 words), which is concise but not optimally structured. It front-loads the action well but lacks any details about the atomic validation or correction logic. Two additional sentences could substantially improve clarity without adding bloat.
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 no output schema is shown (though context signals say 'has output schema: true'), and the tool is complex (three required params, nested validation in annotations array), the description is incomplete. It does not describe return values, success/error conditions, or the nature of automatic corrections. Parameter number is modest, but the behavioral complexity demands more explanation.
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 each parameter (dataset_id, image_path, annotations) already has a schema-level description. The annotations schema includes explicit value constraints (normalized vertices, category positivity). The description does not add new semantic value beyond what the schema provides—no examples, no defaults, no edge case guidance. 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 uses a clear verb-resource combination ('add rotated annotations') and specifies the atomic nature ('validate, correct, and add…atomically'). It distinguishes from siblings like add_bbox_annotations by explicitly including 'rotated' and the validation/correction step. However, 'Validate, correct, and add' conflates three actions; the description could be more precise about which corrections are applied.
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 does not provide guidance on when to use this tool versus alternatives. Sibling tools include add_bbox_annotations and edit_rotated_bbox_annotation, but no explicit when/to-use or when-not-to-use information is given. The atomic validation hint is implicit but insufficient for an agent to select among sibling annotation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. The only behavior disclosed is that the tool does not modify source images. It omits critical information such as permission requirements, whether the operation is reversible, any side effects (e.g., creating metadata records), or rate limits. The single behavioral note is insufficient for safe and effective invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core action. There is no wasted text. However, the conciseness comes at the cost of omitting important details, slightly reducing its utility for an agent. A 4 reflects good efficiency but not perfect trade-off between brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and an output schema, which reduces the need to describe return values. However, the description remains incomplete: it does not explain when registration is appropriate, what prerequisites must be met, or any usage context. For a creation operation, the agent would benefit from knowing that a dataset entry is being created in the system without altering source files. The minimal description leaves gaps that could lead to misuse.
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 'name' and 'root_path' already documented in the input schema. The tool description adds no additional semantic meaning beyond what the schema provides. Per guidelines, baseline 3 is appropriate when the schema already covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'register' and the resource 'dataset root', clearly indicating the action of creating a new dataset entry. It adds the specific detail 'without changing any source image', which helps distinguish it from tools that might modify images. However, it does not explicitly state 'create a new dataset' which would be slightly clearer. Given there are no sibling creation tools, the differentiation is adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., that the root_path must exist and be authorized), no context about typical workflows, and no exclusions. The agent receives no help in deciding to invoke this tool over other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the action without revealing side effects (e.g., idempotency), error conditions (e.g., missing category), permissions required, or return behavior. A mutation tool needs significantly more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is highly efficient and front-loaded, stating the core purpose without wasted words. However, the extreme brevity sacrifices necessary detail, trading conciseness for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required, 2 optional) and an output schema, the description is too sparse. It does not explain when to edit vs. other category operations, prerequisites like existing category, or the nature of the return value. The output schema exists but the description omits any behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema—it merely restates the purpose of the 'name' and 'description' parameters. No extra constraints, formats, or relationships are provided.
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 'Change a category name or authoritative description' uses a specific verb ('Change') and resource ('a category name or authoritative description'), clearly distinguishing it from sibling tools like get_category, add_categories, delete_category, and restore_category. No ambiguity exists 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?
The description provides no guidance on when to use this tool versus alternatives (e.g., add_categories for creating, delete_category for removing). It does not mention prerequisites, context, or when not to use it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states that the annotation type is preserved, but offers no information on potential side effects, such as whether editing could affect related data, or require certain permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the core action. However, it could be slightly more informative without increasing length, such as hinting at optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of editing a rotated annotation with optional parameters and the presence of sibling tools for similar operations, the description lacks essential context. It does not clarify the behavior of omitted parameters or the return structure, though an output schema exists.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description does not add additional semantic meaning beyond what the schema provides.
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 'Edit a rotated annotation' and specifies the limitation 'without changing its type'. This distinguishes it from other annotation tools like 'edit_bbox_annotation' and 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 'edit_bbox_annotation' or when to use the optional parameters. The description does not mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions fetching metadata and including deleted datasets. It doesn't state whether the tool is read-only, requires authentication, has rate limits, or returns specific data beyond 'metadata'. The presence of an output schema partially compensates, but the description is too sparse.
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, lean sentence with no wasted words. It front-loads the core purpose. However, given the lack of usage guidelines or behavioral details, it could be considered under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with 1 parameter and a provided output schema, the description is mostly adequate. The output schema likely explains the return structure. However, the lack of any guidance on how this differs from 'list_datasets' or why you'd fetch a deleted dataset makes it slightly incomplete for a complex API.
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?
With 1 parameter and 100% schema description coverage, the schema already documents 'dataset_id' well. The description adds no extra meaning beyond what's in the schema; it merely restates the resource being fetched. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves dataset metadata and explicitly includes deleted datasets. The verb 'get' and resource 'dataset metadata' are unambiguous. However, it doesn't differentiate itself from 'list_datasets' or other querying siblings, which could be clearer.
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 siblings like 'list_datasets', 'get_category', or 'preview_image'. It doesn't specify prerequisites (e.g., does the dataset need to exist? Can it fetch metadata for a deleted dataset without special permissions?) or exclusions. The phrase 'including a deleted dataset' hints at a unique capability but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions 'orientation-corrected' (a useful behavior), but omits critical details: whether the operation is read-only, auth requirements, error handling (e.g., missing image), or performance implications. The description is minimal and leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, which is very concise. It is front-loaded with the key action. However, it could be more structured by separating the preview and metadata aspects, or by adding a second sentence for usage. It earns its place but is slightly underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema exists, the description is too sparse. It does not explain the output (though the output schema may cover that), and it lacks context on when to use this tool versus siblings, prerequisites, or error conditions. The minimal description leaves the agent with many unknowns.
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 100% - every parameter already has a description in the input schema. The tool description adds no additional meaning or context for any parameter. According to the rubric, baseline is 3 when coverage is high, and the description does not compensate or provide extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('orientation-corrected preview and size metadata'), which is specific and actionable. However, it does not distinguish this tool from the sibling 'preview_annotations', which may also return a preview. The phrase 'orientation-corrected' adds useful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., preview_annotations, list_images). There is no mention of prerequisites, context, or exclusions. The description implicitly suggests usage for getting a preview, but lacks explicit directive.
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 bears full responsibility for behavioral disclosure. The description states a 'restore' action, implying mutation and potential destruction of some prior state (e.g., it may undo a deletion), but does not clarify side effects, failure modes, or whether the operation is reversible. No authorization requirements, error conditions, or concurrency issues are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 8 words in a single sentence, making it very concise. There is no wasted text, and the core action is front-loaded. However, the brevity may leave out important context, which is penalized elsewhere but not in conciseness. One could argue for a 5, but the lack of structure (e.g., no bullet points or callouts) for a tool in a large sibling set reduces usability slightly.
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 context (3 parameters, 100% schema coverage, an output schema, and 22 sibling tools), the description is incomplete. It does not reference the output schema, nor does it distinguish this tool from similar operations like 'restore_dataset'. With no annotations, the description should cover behavior more thoroughly. The minimal description leaves the agent guessing about error states, prerequisites, and return values.
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 baseline is 3. The description adds only the optional renaming context ('optionally under a new name'), which clarifies the purpose of new_name beyond the schema. However, it does not elaborate on valid formats for new_name (e.g., is there a length limit, characters allowed?) or whether dataset_id and category_id must refer to existing entities. The schema already describes all parameters, so the description's added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Restore a category, optionally under a new name.' This clearly indicates the verb (restore) and the resource (category), and adds the optional renaming capability. It distinguishes from siblings like 'delete_category' and 'edit_category' implicitly, but does not explicitly contrast with 'restore_dataset' or 'add_categories', missing a clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., the category must be deleted or in a specific state), no context about required dataset ownership, and no indication of when the optional new_name parameter is appropriate. With 22 sibling tools, including restore_dataset and delete_category, this omission is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals key behaviors: a preflight check and atomic export. However, it does not disclose whether the operation is destructive, what permission scope is needed, what happens if the preflight fails, or the format of the output, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded with the key action and resource. While it is not verbose, it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema and 100% parameter coverage, the description is too brief. It does not explain what 'preflight' entails, what 'atomic' means in practice (e.g., rollback behavior), or the structure of the exported metadata. For a complex export operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, achieving 100% coverage. The tool description does not add any parameter-specific information beyond the schema, so it scores the baseline 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 uses the verb 'export' and specifies the resource as 'completed-image metadata', which is clear and distinguishes from siblings like list_images or get_dataset. However, it does not explicitly mention the JSONL format, which is part of the tool name, so it could be slightly more specific.
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 list_images or get_dataset. There is no mention of prerequisites, when-not-to-use, or references to sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It only states the action without detailing side effects, required permissions, behavior on invalid state (e.g., already active dataset), or any irreversible consequences. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key action. It avoids wasted words, though it could include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, lack of annotations, and existence of an output schema (not shown), the description is incomplete. It omits preconditions, error handling, and behavioral details that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter description: 'Dataset identifier to restore.'). The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate. No additional value provided.
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 ('Restore') and the resource ('soft-deleted dataset record'). It directly distinguishes from siblings like delete_dataset (opposite action) and create_dataset (new record), providing unambiguous purpose.
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 (e.g., restore_category for categories). It implies usage for soft-deleted datasets but doesn't mention prerequisites, error scenarios (e.g., dataset not in soft-deleted state), or when not to use.
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 reveals that the deletion is a soft-delete and that annotations are retained, which is useful behavioral context. However, with no annotations provided, additional details (e.g., whether the category becomes hidden or marked as deleted, whether it still appears in list queries, or any permissions needed) would improve transparency. No contradiction exists since annotations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the core action and an important detail (historical annotations retained). It is front-loaded with the verb and resource.
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 two-parameter delete tool with a clear schema and output schema present, the description covers the essential behavior (soft-delete, annotation retention). The output schema likely provides return value shape, so the description doesn't need to. Minor gaps exist around side effects (e.g., impact on linked items), but overall appropriate for the complexity.
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%, and the parameter names and descriptions are self-explanatory ('dataset_id' and 'category_id'). The description adds the context of 'soft-delete' which implies the category still exists in the system, but does not elaborate on the parameter values beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('soft-delete') and the resource ('category'), and also mentions a key behavior ('retain historical annotations'). It distinguishes from a hard delete or a permanent removal, though it doesn't explicitly contrast with sibling tools like delete_dataset or delete_bbox_annotation.
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 does not provide guidance on when to use this tool versus alternatives (e.g., restore_category, edit_category). It lacks any mention of prerequisites (e.g., dataset must exist) or conditions that make soft-deletion appropriate.
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 transparency. The description only says 'edit' which implies modification but gives no detail on effects (e.g., whether changes are irreversible, if it updates timestamps, or if it requires certain permissions). There is no mention of what happens to the existing annotation or if partial updates are supported. No contradiction with annotations exists since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is concise. It front-loads the core action. No padding or redundant information. However, it could be improved by adding a bit more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (with 2 required), an output schema exists, and sibling tools involve similar annotation operations, the description is minimally adequate. It states the purpose but lacks behavioral details like update semantics or side effects. The output schema may describe return values, so the description needn't cover that, but it should explain what 'edit' entails (e.g., partial update or full replacement).
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 baseline is 3. The description itself adds no extra meaning beyond the schema; it does not explain the relationship between 'bbox', 'category_id', and the annotation's existing state. For example, it doesn't specify that leaving 'bbox' as null keeps the current geometry. The description adds no value over the schema for 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 verb 'Edit' and the resource 'bbox annotation', and adds the specific constraint 'without changing its type'. This helps distinguish it from siblings like 'edit_rotated_bbox_annotation' or 'add_bbox_annotations'. However, it does not explicitly differentiate from other edit tools like 'edit_category', though the resource is clearly different.
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 this tool: to modify a bounding box annotation while preserving its type. However, it provides no explicit guidance on when not to use it, or alternatives. For example, it doesn't mention that to change the type, you might need to delete and add a new annotation. No prerequisites or context are given.
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 mentions 'stable filters and pagination', hinting at predictable behavior and pagination support. However, it does not disclose whether the tool is read-only (safe to call multiple times), whether it requires authentication, or what happens with invalid parameters. The description adds some value but misses key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action 'list annotations' and adds key qualifiers. It is efficient and to the point, with no unnecessary words. However, it could be slightly more structured (e.g., separating purpose from usage hints) but overall earns a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (all with schema descriptions), an output schema, and is one of many sibling tools, the description is minimally adequate. It covers the basic purpose but lacks details on return format, limits, or filtering behavior that the output schema might not fully convey. The description is functional but not comprehensive for complex use cases.
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 baseline is 3. The description itself does not add any parameter details beyond what the schema already provides. It mentions 'filters and pagination' generically, but the schema already documents parameters like 'offset', 'max_results', and 'image_path'. The description adds no new semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'annotations' with the qualifier 'with stable filters and pagination'. The purpose is clear and distinguishes it from sibling tools like 'delete_bbox_annotation' or 'add_bbox_annotations' by implying a read-only listing operation. However, the description does not explicitly differentiate it from the sibling 'preview_annotations', which might also list annotations, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'preview_annotations' or the various annotation CRUD siblings. It does not specify prerequisites (e.g., dataset must exist) or when to use filters. The agent must infer usage from the parameter schema alone, which is insufficient for decision-making.
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 disclosing behavior. It does not mention that only non-deleted datasets are returned by default, nor does it address ordering, pagination, or potential rate limits. The schema describes the include_deleted parameter, but the description omits behavioral details that would help an agent understand the tool's 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 three-word sentence that efficiently communicates the tool's purpose. Every word earns its place with no redundancy or filler.
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?
Although an output schema exists (reducing the need to explain return values), the description lacks information on pagination, sorting, or default behavior regarding soft-deleted datasets. For a simple list tool, this is minimally adequate but leaves important context for an agent, especially given the complexity of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single include_deleted parameter has a clear description). The tool description adds no additional parameter context beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List registered datasets' uses a specific verb ('List') and resource ('datasets'), clearly distinguishing it from sibling tools like get_dataset (singular retrieval), create_dataset, and delete_dataset. It immediately conveys the tool's core function.
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, nor does it mention limitations like pagination, sorting, or performance considerations. For a list operation, some implicit understanding exists, but explicit context is absent.
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 fully disclose behavioral traits. It mentions 'atomically' and 'active dataset', but does not state if categories are appended or replaced, if duplicates cause failure, whether the operation is idempotent, or if there are any side effects like metadata synchronization. The agent lacks insight into safety, error handling, or rollback 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, concise sentence with no wasted words. It includes the key qualifier 'atomically' and the condition 'active dataset', which are both critical for correct usage. Every word is meaningful and front-loaded.
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 there is an output schema (not shown but present), the agent may infer return structure. However, the description lacks completeness for a mutation tool with no annotations. It fails to mention error cases (e.g., invalid dataset_id, duplicate names), behavior on non-active datasets, or which sibling tools to use for alternative operations. For a tool with 2 parameters and a clear domain, it is adequate 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?
Schema description coverage is 100%, so the schema already thoroughly documents parameters including type, constraints, uniqueness, and field handling. The description does not add much beyond the schema, but the schema is already rich. The description's term 'atomically' is the only extra semantic value, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add categories' and the resource 'active dataset'. The phrase 'atomically' adds precision ensuring the operation is all-or-nothing. However, among siblings like 'edit_category' and 'delete_category', the purpose is clear but could more explicitly distinguish itself from 'add_bbox_annotations' as adding non-annotation metadata.
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 specifies the tool operates on an 'active dataset', implying only datasets with a certain status qualify. However, it provides no guidance on when to use this versus adding categories individually with another tool, no prerequisites like dataset ownership or existence, and no comparison to sibling tools that manage categories (e.g., 'edit_category', 'list_categories').
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 uses 'hard-delete' and 'atomically' to convey irreversibility and all-or-nothing behavior. However, it omits details about required permissions, error handling for invalid IDs, and whether the operation returns any data. With no annotations, more transparency would help.
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 that is front-loaded with the key verb. Every word serves a purpose (hard-delete, one or more, rotated, atomically). No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full parameter coverage, the description lacks essential context for a destructive operation: it doesn't clarify prerequisites (e.g., annotation must exist), permissions needed, or how errors are handled. For a tool with no annotations and a similar sibling, the context is insufficient for an agent to safely invoke it.
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 documents both parameters fully (100% coverage). The tool description adds no additional meaning or context about the parameters, such as how to obtain annotation_ids or the role of dataset_id. Baseline 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 clearly states the verb 'delete', the resource 'rotated annotations', and adds qualifiers 'hard-delete' and 'atomically', distinguishing it from siblings like 'delete_bbox_annotation'. It is specific 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 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 sibling tools such as 'delete_bbox_annotation'. There is no mention of prerequisites, or scenarios where this tool is preferred. The agent is left to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that soft-deleted categories can be retrieved, which is a key behavioral trait. However, it does not mention error handling (e.g., what happens if the category is permanently deleted or does not exist) or idempotency, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that communicates the core purpose and a key behavioral detail. No wasted words or redundancy.
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 get-by-id tool with an output schema, the description is mostly complete. It captures the important soft-delete behavior. Minor gaps (e.g., error handling, behavior for nonexistent IDs) prevent a perfect score.
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% (both parameters have clear descriptions). The tool description adds no additional meaning or context beyond the schema, so it meets the baseline 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 action ('Get a category') and the resource ('category'), and adds a specific differentiator ('including a soft-deleted category'). This distinguishes it from listing or mutating categories, but does not explicitly contrast with siblings like 'list_categories' or 'restore_category'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_categories' (for multiple categories) or 'restore_category' (for undeleting). The agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It only says 'List categories,' which implies a read operation but adds no context about default exclusion of soft-deleted items, permission needs, or pagination. The schema partially fills this gap, but the description itself contributes no extra behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It front-loads the action and resource, making it immediately understandable. It is appropriately sized for the tool's simplicity.
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, the schema covers all parameters, and an output schema exists, so return types are not the description's responsibility. The description is sufficient for the core operation, though it does not proactively distinguish from get_category or clarify the default filtering behavior. Minor gap but overall complete enough.
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% for both parameters, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides; it simply restates the tool's purpose without elaborating on parameter semantics.
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' with the resource 'categories' and scopes it 'for a dataset,' clearly distinguishing it from sibling tools like get_category (single) or add_categories (creation). It also separates from list_datasets/list_images because the resource and scope are explicit.
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 about when to use this tool versus alternatives such as get_category for a single category, or when to set include_deleted. The description merely states what it does without helping an agent choose among related category operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'stable ordering', which hints at deterministic pagination, and implies reading images. However, it does not disclose that the tool is read-only, how pagination works (offset/max_results), or any edge cases like empty datasets. The schema provides parameter details, but the description adds only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action ('discover dataset images') and immediately specifies two key features. Every word contributes; there is no filler. It is efficient and easily scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (1 required) and a known output schema, the description covers the core functionality (list with filter and ordering) but omits mention of pagination or the output format. Since an output schema exists, return-value details are not required. The description is reasonably complete for an agent that can infer pagination from the parameters. A few more words on usage context would earn a 5.
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 100%, so each parameter already has a description. The overall description adds the term 'stable ordering', which clarifies the intent of the order_by and random_seed parameters. This is a slight addition beyond the schema. Parameters like dataset_id, offset, and max_results are not elaborated further; the schema suffices. 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 uses the verb 'discover' to indicate listing, and clearly identifies the resource as 'dataset images'. It mentions two key features: status filtering and stable ordering, which are accurate. However, it does not explicitly differentiate from sibling tools like list_annotations or list_categories, leaving the agent to infer the resource type from the tool name.
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 does not state prerequisites, when not to use it (e.g., for annotation listing), or compare with siblings. The context signals show sibling tools like list_annotations and preview_image, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'hard-delete' (implying permanent removal) and 'atomically' (all-or-nothing execution). However, it does not clarify side effects (e.g., cascade to dependent data), required permissions, or confirm irreversibility beyond the word 'hard'. This is adequate but not thorough.
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 6 words that front-loads the verb and object. Every word earns its place: 'hard-delete' specifies permanence, 'one or more' indicates batch capability, 'atomically' conveys transactional behavior. No redundancy or fluff.
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 presence of an output schema (return format not needed in description) and the tool's straightforward nature, the description covers the basic action. However, it lacks guidance on when to prefer this tool over similar sibling tools (e.g., delete_rotated_bbox_annotation) and missing precondition hints like 'dataset_id must be active' or 'annotation_ids must exist'. The description is functional but minimally complete.
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%; both parameters are already well-documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., does not explain the relationship between dataset_id and annotation_ids). Baseline 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 'Hard-delete' and the resource 'bbox annotations', clearly stating the action. It also specifies 'one or more' and 'atomically', which adds precision. This distinguishes it from sibling tools like 'delete_rotated_bbox_annotation' which target a different annotation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., batch delete vs. individual delete via edit tools, or differences from deleting rotated annotations). There is no mention of prerequisites such as the dataset existing or the annotations being present. The agent receives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It correctly states that the operation is a 'soft-delete' and that 'all related state' is preserved, which implies reversibility and non-destructiveness. However, it does not elaborate on what 'preserve' means in practice (e.g., whether the dataset becomes invisible, whether annotations are retained), nor does it mention outcomes like the dataset's new status. This is adequate but not richly transparent.
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 that immediately conveys the core action and a key constraint. It is front-loaded and contains no filler. However, it could be improved by adding a brief second sentence about usage context or the restore counterpart, which would increase utility without sacrificing conciseness.
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 (one parameter, no enums, output schema exists). The description covers the essential points: that the delete is soft and state is preserved. It does not mention the restore_dataset sibling or what happens on repeated deletion, but given the existence of an output schema and the straightforward nature of the operation, the description is nearly complete. A small addition about using restore_dataset for reversal would make it fully complete.
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% (the single parameter dataset_id is described in the schema as 'Dataset identifier to soft-delete.'). The tool description adds no new meaning beyond the schema; it merely restates the purpose. According to the guidelines, when coverage is high, the baseline is 3, and the description does not provide extra semantic 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 clearly states the action ('soft-delete') and resource ('dataset'), and adds that it preserves related state. This distinguishes it from sibling tools like delete_bbox_annotation or delete_category, which operate on different resources. The verb+resource+scope is specific 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 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 (e.g., restore_dataset, or other delete operations). It does not mention prerequisites, such as whether the dataset must exist or be active, nor does it indicate that the operation is reversible via restore_dataset. This lack of context leaves the agent without decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explicitly states that the image content is not changed, while indicating that the status is modified. This is useful, though it does not cover potential transition rules, reversibility, or permissions.
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 communicates purpose and a key boundary in just eight words. Every part is meaningful, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three fully documented parameters and an output schema, the description sufficiently covers the tool's purpose and its most important behavioral constraint. Nothing essential seems missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the schema already documents all three parameters clearly. The description adds no additional parameter-level detail, so it meets the baseline without enhancing meaning 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 ('Set') and the target ('annotation workflow status'), and adds the key non-effect 'without changing the image.' This distinguishes it from sibling annotation editing tools like add_bbox_annotations and edit_bbox_annotation.
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 this is for updating workflow status rather than modifying image content, but it never explicitly states when to use it or provides direct alternatives. No exclusions or comparison with sibling tools are given, though the phrase 'without changing the image' offers some contextual hint.
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:

[![detection-mcp MCP server](https://glama.ai/mcp/servers/ryan-minato/detection-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ryan-minato/detection-mcp)

Score Badge

Copy to your README.md:

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

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