aidoo-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between list/get/create/update/cancel/delete operations. Even the convenience get_member_bookings and get_expiring_contracts are clearly distinct from their list counterparts by specific filtering intent.
Naming Consistency4/5
Tools follow a consistent aidoo_verb_noun pattern, but get is used for both single-item fetches and list-returning queries (e.g., get_expiring_contracts, get_member_bookings), while list is reserved for standard collection listings. This is a minor deviation from the ideal verb-per-action style.
Tool Count3/5
With 25 tools, the server is on the heavier side, covering multiple domain areas (members, contracts, bookings, checkins, etc.). While each tool has a purpose, the count feels large for a single server and might benefit from splitting into focused services.
Completeness3/5
The surface provides solid read coverage for all major resources and write operations for members, bookings, checkins, and webhooks. However, there is no create/update/delete for contracts, classes, trainers, or gyms, leaving notable lifecycle gaps for core domain objects.
Average 3.2/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for disclosing behavior. It does not mention pagination, default limits, filtering by class_attendee_id, or what constitutes 'alle Trainer' (all trainers) in terms of scope and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it adds little beyond the tool name itself. It is efficient but under-specified, lacking context that would make the sentence earn 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?
For a tool with three parameters, no output schema, and no annotations, the description is too minimal. It does not explain the default behavior, how filtering works, or any caveats, leaving significant gaps for the agent.
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 parameters are already documented in the schema. The description adds no additional semantic information, maintaining 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 'Liste alle Trainer auf' clearly states the action (list) and resource (trainers), which is specific enough. It does not explicitly distinguish from the sibling aidoo_get_trainer, but the plural 'Trainer' and the use of 'list' vs 'get' provide some 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 is provided on when to use this tool versus alternatives like aidoo_get_trainer or aidoo_list_members. The description simply states the action without 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 states 'retrieves statistics' but does not clarify whether the operation is read-only, what statistics are included, how the default gym is determined, or what the response structure looks like. The schema mentions optional gym_id and default gym, but the description adds no behavioral context beyond the verb.
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 immediately conveys the core purpose. It is well-structured and front-loaded, with no wasted words. However, it is perhaps too terse to cover necessary context, but for conciseness alone it scores high.
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 presence of multiple sibling tools and the absence of annotations and output schema, the description is incomplete. It does not specify what statistics are returned, how to interpret results, or how this tool relates to similar tools like aidoo_get_member_statistics. This leaves significant gaps for an agent trying to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter (gym_id) 100%, including that it is optional and uses a default gym. The description does not add any additional parameter meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rufe ab' = retrieve) and clearly identifies the resource ('Statistiken für ein Studio'). It is unambiguous that this tool retrieves statistics for a gym. However, it does not explicitly differentiate from sibling tools like aidoo_get_gym or aidoo_get_member_statistics, so it lacks explicit 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 alternatives. It does not mention contexts, prerequisites, or alternatives. The description provides only a bare statement of function without any 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?
Annotations are none, so the description must carry the full burden of behavioral disclosure. It implies a read-only listing but does not state it explicitly. No mention of output format, default ordering, pagination behavior beyond the schema defaults, or any side effects. The description is too sparse to disclose behavioral traits beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to scan. It could include a bit more useful detail, but it remains appropriately concise 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?
For a list tool with no output schema and no annotations, the description gives the core purpose but lacks complete context. It does not describe return values, pagination behavior, or default sorting. However, the schema covers parameters, so the tool is minimally usable. The description is adequate but leaves clear gaps that a user might need to infer.
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 minimal extra meaning: 'oder filtere nach Kriterien' hints at the existence of filter parameters but does not enumerate them. The schema already documents limit, offset, max_date, min_date, and member_id, so the description does not significantly improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource clearly: 'Liste alle Check-ins auf' (list all check-ins). It also mentions optional filtering. This distinguishes it from siblings like aidoo_create_checkin or aidoo_list_bookings, though it doesn't explicitly name alternatives. The purpose is clear, but the phrasing 'oder filtere nach Kriterien' is somewhat generic without naming the specific criteria.
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, nor any exclusions or prerequisites. The description only states what the tool does ('List or filter check-ins') without providing context for when filtering is appropriate or how it relates to other list tools. No explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'update an existing member.' It does not explain partial update semantics, permission requirements, return values, or what happens to unspecified fields.
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 concise single sentence with no unnecessary words, making it easy to parse. However, it is so brief that it omits important behavioral details, which slightly reduces its structural value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is critically incomplete. It fails to disclose update behavior, side effects, or return values, leaving the agent with insufficient context for correct 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?
The schema provides 100% coverage for all 8 parameters with descriptive names and descriptions, so the baseline is 3. The tool description adds no extra parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and resource ('existing member'), which distinguishes it from sibling tools like create, get, or list member. However, it lacks any additional context or scope beyond the basic action.
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 aidoo_create_member or aidoo_get_member. It does not mention prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'create a new course booking' without describing side effects, validations, permissions, error behavior, or whether the booking can fail. This adds nothing beyond the tool's name and the obvious intent of 'create'.
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, short sentence in German that is front-loaded and contains no redundant wording. It is as concise as possible while still conveying the core purpose.
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 with two fully documented parameters and no output schema, so the description is minimally viable. However, it lacks behavioral transparency and usage guidelines, making it incomplete for an agent to fully understand the tool's side effects and when to use 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 provides 100% coverage with clear descriptions for both parameters ('Kurs-ID' and 'Mitglieds-ID'). The tool description does not add any additional parameter context or examples, so the baseline 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 clearly states the action ('create') and the resource ('course booking') with an explicit beneficiary ('for a member'). It distinguishes from sibling tools like cancel_booking and create_checkin by specifying 'Kursbuchung'.
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 create_checkin or cancel_booking. It only states what the tool does, 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning error handling, return format, or whether the trainer must exist, which is minimal for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It is appropriately sized for a simple getter and front-loads the essential verb and resource.
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 one-parameter getter, the description covers the basic purpose. However, with no output schema and no annotations, it does not clarify the content of 'details' or any edge cases, leaving a minor but acceptable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information, but the schema already fully documents the sole parameter 'trainer_id' with a description. Given 100% schema coverage, the baseline of 3 applies.
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 'Rufe Details eines Trainers ab' clearly indicates a read operation to fetch details of a specific trainer. It distinguishes from sibling tools by resource type, though it doesn't explicitly mention its scope relative to list_trainers.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, any exclusions, or prerequisites, leaving the agent to infer from the 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 are provided, so the description carries the full burden. It only says 'List all contracts or filter by criteria' and does not disclose any behavioral traits such as read-only nature, pagination behavior, return format, or default limits. This is a significant gap for a list tool with 8 parameters, so a score of 2 is appropriate.
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 immediately states the tool's purpose. It is front-loaded and contains no fluff. However, it is somewhat terse and could incorporate a bit more context without sacrificing conciseness, so it earns a 4 rather than a 5.
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?
With 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the various filter criteria, the purpose of extensions, or what the response looks like. The schema covers parameters, but the overall context is too thin for a tool of this complexity, so a score of 2 is warranted.
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 all 8 parameters having descriptions (e.g., 'Vertrags-ID', 'Offset für Paging'). Per the baseline rule, when schema coverage is high, a 3 is the default. The description itself adds no parameter semantics beyond 'filter by criteria', so it neither enhances nor compensates for 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 function: 'List all contracts or filter by criteria' (German). It uses a specific verb (list) and resource (contracts), and the scope 'all' distinguishes it from sibling tools like aidoo_get_contract (single contract) and aidoo_get_expiring_contracts (expiring only). However, it does not explicitly name these alternatives, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to list contracts, optionally with filters. There is no explicit guidance on when not to use it (e.g., for a single contract, use aidoo_get_contract) or comparisons with siblings. This is implied usage, not explicit, so it merits a 3.
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 states the action ('create') and gives no information about side effects, success/failure responses, idempotency, or required permissions. This is a minimal disclosure that does not reveal any underlying behavior beyond the obvious mutation.
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 in German, front-loaded with the essential action. There is no redundant information or filler, making it very efficient for an agent to parse.
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 9 parameters and no output schema, the description only says 'create a new member'. It does not explain what the tool returns, how to handle possible errors, or any business rules for members. The schema covers parameter fields, but the overall tool context is incomplete for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters have individual descriptions in the schema. The tool description adds no additional meaning about the parameters, but the schema already provides clear labels like 'Vorname' and 'Nachname'. This meets the baseline for schema-covered 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 'Erstelle ein neues Mitglied im System' clearly states the action (create) and the resource (member). It distinguishes itself from sibling tools like update_member, get_member, and list_members by focusing solely on 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?
No guidance is provided on when to use this tool versus alternatives such as update_member or check if a member already exists. The description lacks any context about prerequisites or typical use cases, leaving the agent without 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?
No annotations are provided, so the description carries the full burden. It only states that details are retrieved, without disclosing what 'details' include, whether a missing gym_id yields an error, or any access requirements. For a read tool, this is minimal information.
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 action. It is front-loaded and contains no filler, making it efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should provide some insight into return values or behavior. The phrase 'Details eines Studios' is vague; it does not mention specific fields (e.g., address, contact info, hours) or error handling. Given the simple getter nature, a bit more context would be expected.
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 has one parameter with 100% coverage ('gym_id' described as 'Studio-ID'), so the schema already explains the parameter. The description adds no extra semantics beyond the schema's field label, which is expected per the 100% coverage baseline.
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 'Rufe Details eines Studios ab' ('Retrieve details of a studio') uses a specific verb ('Rufe ab' = retrieve) and resource ('Details eines Studios' = details of a studio). It clearly distinguishes from sibling tools like aidoo_list_gyms (listing) and aidoo_get_gym_statistics (statistics).
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 does not mention that it requires a gym_id obtained from aidoo_list_gyms, nor does it contrast with other gym-related tools. The usage context is only implied by the 'get' pattern.
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 'retrieve details of a single member,' which implies a read operation but does not explicitly state that it has no side effects, what data is returned, how extensions affect the response, or any potential errors. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse.
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 high parameter schema coverage, the description lacks context about the response structure or behavior of extensions. There is no output schema, and the description does not explain what 'details' includes, leaving the agent to guess. For a simple tool this might be tolerable, but the description could be more 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 coverage is 100%, with both member_id and extensions having descriptions. The tool description itself adds no additional parameter meaning, but since the schema fully documents the parameters, the baseline 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 'Rufe Details eines einzelnen Mitglieds ab.' clearly states the action (retrieve details) and the target (a single member), distinguishing it from sibling tools like aidoo_list_members or aidoo_get_gym. The verb 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. It does not mention prerequisites (e.g., needing a member_id) or context in which to prefer this over other member-related tools. The schema implies member_id is required, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It only says 'retrieve' which implies a read operation, but does not explain return format, pagination behavior, authentication needs, or any side effects. This is insufficient for a tool with no structured transparency metadata.
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 clearly conveys the tool's purpose without redundancy. It is front-loaded and every word is meaningful.
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?
With no output schema, the description should explain what the response contains. It does not. The tool is simple, but the lack of any return-value information makes it incomplete, especially given the absence of annotations.
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 provides 100% coverage with descriptions for all four parameters (start_date, end_date, limit, offset). The description adds no additional semantic value beyond the schema, so the baseline of 3 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 tool retrieves (abrufen) a course schedule (Kursplan) for a specific date range, which is a distinct resource and action compared to siblings like aidoo_list_classes and aidoo_get_class. The German phrasing 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 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 implies usage for a time period but does not mention sibling tools, exclusions, or prerequisites. It simply states the function without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, default limits, filtering semantics, or return format. It only states the basic action without any extra 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, concise sentence that front-loads the core function. Every word adds value, and there is no wasted phrasing. It is appropriately brief for a simple list operation.
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 8 optional parameters and no output schema, yet the description provides no information about return values, pagination, or filtering behavior. The one-sentence description is insufficient for an agent to use this tool effectively without additional assumptions.
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 parameters are fully documented. The description adds no extra meaning beyond the schema, merely referencing 'criteria' without detailing any specific parameters. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all classes or filters by criteria, which is a specific action on a resource. It implicitly distinguishes from aidoo_get_class by using 'list' rather than 'get', but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: list all classes or filter by criteria. It provides no explicit guidance on when to prefer this over related tools like aidoo_get_schedule or aidoo_get_class, nor does it mention exclusions. The context is somewhat implied but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic list operation and does not mention pagination, sorting, or the read-only nature of the call. The optional limit/offset parameters hint at pagination, but this is not explicit.
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 wasted words. It is appropriately concise for a simple list operation, delivering the core purpose without redundancy.
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 description is minimal and lacks valuable context. There is no output schema, so the agent does not know the structure of the returned list, and no behavioral or usage details are provided. This leaves the tool under-specified for real-world use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (limit and offset) with helpful descriptions, giving 100% schema description coverage. The tool description adds no extra meaning to the parameters, 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 'Liste alle Studios auf.' clearly states the action (list) and the resource (studios), and the word 'alle' (all) specifies the full scope. This distinguishes it from siblings like aidoo_get_gym, which retrieves a single gym.
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 typical use cases or exclusions, leaving the agent 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.
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 only restates that the tool creates a check-in, without mentioning side effects, permissions, idempotency, or what happens on duplicate or invalid member IDs. This is minimal disclosure.
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 essential information. Every word earns its place, and there is no wasted text.
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 with one well-documented parameter, but the description lacks behavioral context such as what a check-in represents or any output. Given the absence of annotations and output schema, this is a minimum viable description but leaves gaps about side effects.
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 the single parameter (member_id) with a clear description, so the tool description adds no additional parameter semantics. Since schema coverage is 100%, 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 'Erstelle einen Check-in für ein Mitglied' clearly states the action (create) and resource (check-in for a member), making the tool's purpose unambiguous. It distinguishes from sibling tools like list_checkins or create_booking.
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 usage guidance is provided. The description does not specify when to use this tool over alternatives, such as create_booking or list_checkins, nor 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, permanence, error behavior, or whether special permissions are required. For a delete operation, this is 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, direct sentence that is appropriately front-loaded and contains no unnecessary words. It conveys the tool's purpose efficiently.
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 delete tool with one parameter, the description is minimally adequate but lacks additional context such as expected outcomes, relationship to list_webhooks for obtaining IDs, or any caveats. It does not mislead but is 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 documents the webhook_id parameter with a description ('Webhook-ID'), so schema coverage is 100%. The description does not add any further meaning about the parameter, keeping it at the baseline level.
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 ('registered webhook'), which differentiates it from sibling tools like create_webhook and list_webhooks. Even in German, the verb and object are 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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., webhook must exist), and no indication of what happens after deletion. The description provides no contextual usage 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?
No annotations are present, so the description carries the full burden. It states a read operation but does not disclose pagination behavior (despite limit/offset parameters) or clarify that 'alle' (all) may be limited by pagination. This is a notable gap for a tool with no structured safety annotations.
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, short sentence that is front-loaded with the action 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with a fully described schema and no output schema, the description conveys the core scope. However, it lacks any mention of pagination semantics, sorting, or what 'all' means given the limit/offset parameters, preventing it from being 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%: all three parameters (member_id, limit, offset) have individual descriptions. The tool description adds no extra meaning beyond mapping 'bestimmten Mitglieds' to member_id, 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 a specific verb ('Rufe ab' = retrieve) and a specific resource ('Buchungen eines bestimmten Mitglieds' = bookings of a specific member). It clearly distinguishes itself from sibling tools like aidoo_list_bookings by scoping to a single member.
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 aidoo_list_bookings or aidoo_get_member. The sibling tools are not mentioned, and there is no context about prerequisites or 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?
There are no annotations, so the description must fully disclose behavioral traits. It only states the action and examples but does not mention whether the operation is read-only, whether it returns aggregated data, requires specific permissions, or how it handles invalid member IDs. 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, concise sentence that front-loads the verb and resource, with no unnecessary words or repetition. It is appropriately sized for a simple 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?
The description gives a basic idea of what the tool returns (visits, courses, etc.) but is vague about the full scope of statistics. With no output schema and no annotations, the description should more clearly specify the response content and edge cases, making it adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents member_id with a description (Mitglieds-ID), and schema coverage is 100%. The tool description adds no parameter-specific details, so the baseline score of 3 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 a specific action ('Rufe ... ab' = retrieve) and a specific resource ('Statistiken für ein Mitglied' = member statistics), with examples (visits, courses). This distinguishes it from sibling tools like aidoo_get_member (member details) and aidoo_get_gym_statistics (gym-level stats).
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 aidoo_get_member_bookings or aidoo_get_gym_statistics. The description lacks selection criteria, prerequisites, or exclusions, leaving the agent without context for tool choice.
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 only says 'list or filter' without disclosing behavior like pagination (limit/offset), default result size, how filters combine (AND/OR), or that extensions modify response content. This is insufficient for a tool with 8 parameters and no output 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, concise sentence in German that quickly conveys the primary purpose. It is not overly verbose, but given the tool's complexity, it could arguably include more structure. However, it is clean and front-loaded, earning a 4.
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?
With 8 parameters, no annotations, and no output schema, the one-line description is wholly inadequate for understanding the tool's full behavior. It does not explain how filters work, what the response format is, or the meaning of the 'extensions' parameter, making it incomplete for real-world use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (id, limit, offset, etc.) has a meaningful description. The tool description adds only generic 'filter by criteria' which does not enrich the schema. Since the schema already provides full parameter semantics, 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 clearly states it lists bookings ('Liste alle Buchungen auf') with optional filtering ('oder filtere nach Kriterien'). This distinguishes it from sibling tools like aidoo_get_member_bookings (specific member), aidoo_create_booking, and aidoo_cancel_booking by emphasizing the general listing capability.
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 use cases (list all or filter), but does not explicitly mention when to choose this over alternatives such as aidoo_get_member_bookings or aidoo_get_schedule. There is no exclusion or comparative guidance, so it meets the bare minimum but lacks direct sibling differentiation.
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 behavioral traits. While 'list' implies a read-only operation, the description does not explicitly state this, nor does it mention return format, authentication needs, or side effects. It adds no value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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. It is appropriately sized for a simple list tool and contains no unnecessary words.
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 simplicity of the tool (zero parameters, no annotations, no output schema), the description provides a sufficient basic purpose. However, it does not explicitly state the return value or any edge cases, so it is not fully complete, though it is close for such a simple operation.
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 fully covered. The baseline for a 0-parameter tool is 4, and the description does not need to explain parameter details. It is clear that no inputs are required.
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 'Liste alle registrierten Webhooks auf' clearly states the action (list) and resource (registered webhooks), distinguishing it from sibling tools like create_webhook and delete_webhook. However, it is essentially a restatement of the tool name with minimal additional context, so it stops 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or any exclusions, leaving the agent without context for selecting it over similar list 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?
Es gibt keine Annotationen, daher muss die Beschreibung allein über Verhaltensweisen informieren. Sie erwähnt weder die Irreversibilität der Stornierung noch mögliche Nebeneffekte oder Berechtigungen. Für eine mutierende Operation ist das zu wenig.
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?
Ein einzelner, klarer Satz ohne unnötige Informationen. Die Beschreibung ist effizient und 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?
Für ein einfaches Tool mit einem Parameter ist die Beschreibung minimal. Es fehlen Hinweise auf Voraussetzungen (z.B. nur zukünftige Buchungen) oder das Ergebnis. Ohne Output-Schema wäre mehr Kontext hilfreich, aber insgesamt noch angemessen.
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?
Das Schema beschreibt booking_id bereits mit 'Buchungs-ID' (100% Abdeckung). Die Beschreibung fügt keine zusätzliche Bedeutung hinzu, daher bleibt es bei der Baseline 3.
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?
Die Beschreibung verwendet das spezifische Verb 'Storniere' und die Ressource 'bestehende Buchung', wodurch klar ist, was das Tool tut. Sie grenzt sich deutlich von Sibling-Tools wie create_booking oder list_bookings ab.
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?
Die Beschreibung gibt keinen expliziten Hinweis, wann das Tool verwendet werden soll oder welche Alternativen es gibt. Der Verwendungszweck ergibt sich nur implizit aus dem Verb 'Storniere' und dem Kontext der Sibling-Tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions creation and notification, but fails to disclose side effects, authentication requirements, idempotency, or what happens after creation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in German that immediately communicates the tool's purpose. There is no filler or redundant information.
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 schema covers all parameters, but the tool has no output schema and no annotations. The description only states the core purpose and omits return values, behavioral consequences, or usage constraints, making it minimal but not fully complete for a mutation 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%, with each parameter already having a clear German description. The tool description adds no additional meaning about parameters, so it neither improves nor harms the understanding beyond the schema. 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 action (create), the resource (webhook), and the purpose (to be notified about changes). It distinguishes from sibling tools like list_webhooks and delete_webhook by making the creation intent explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new webhook is needed for change notifications, but it does not explicitly mention alternatives or exclusions. There is no guidance on when not to use the tool or how it relates to list_webhooks or delete_webhook.
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 states 'retrieve details' without disclosing what data is returned, error behavior, or the effect of the 'extensions' parameter. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action and resource.
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 retrieval tool, but the description lacks context on return values and extension behavior. No output schema exists to compensate. The minimal description is adequate for a basic fetch but incomplete for nuanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the description does not need to add parameter info. Baseline of 3 is appropriate as the description adds no extra 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 'Rufe Details eines einzelnen Kurses ab' clearly specifies the action (retrieve) and resource (details of a single course). It distinguishes from siblings like aidoo_list_classes by focusing on a single class, not a list.
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?
Usage is implied: use when you need details of a single course. However, there is no explicit guidance on when not to use it or clear comparisons to alternatives like aidoo_list_classes or aidoo_get_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'abrufen' (retrieve), implying a read operation, but gives no details about side effects, errors, or what data is included. For a tool with no annotation safety hints, 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 core action. No wasted words or irrelevant information.
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 get-by-id tool, the description is minimally viable. However, the absence of an output schema and any mention of return value or error behavior leaves the agent with limited context. The description is adequate but not enriched.
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 'contract_id' and 'extensions' documented. The description itself adds no additional parameter semantics, so the baseline score of 3 is appropriate since the schema fully handles parameter understanding.
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 function: 'Rufe Details eines einzelnen Vertrags ab' (retrieve details of a single contract). It specifies a verb (abrufen) and a resource (Vertrag), and it distinguishes itself from sibling tools like list_contracts by emphasizing 'eines einzelnen' (a single).
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 the tool is for fetching one contract by ID, but it does not explicitly state when to use it over alternatives like list_contracts or get_expiring_contracts. No exclusions or alternative suggestions are provided, leaving usage to be inferred from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only states the basic purpose. It does not disclose any behavioral traits such as read-only nature, default limits, pagination behavior, or how date boundaries 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 a single sentence that is front-loaded and directly states the tool's purpose. It contains no unnecessary information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is concise and sufficient for a basic query tool, with all parameters documented in the schema. However, it omits details about return format and pagination behavior, and there is no output schema to compensate. The implicit return of a list of contracts is clear from the verb 'finde alle', but a bit more detail would make it 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?
The input schema provides full descriptions for all four parameters (min_end_date, max_end_date, limit, offset), covering 100% of the parameters. The description adds no additional parameter-specific meaning 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 'Finde alle Verträge die in einem bestimmten Zeitraum auslaufen' clearly specifies the action (find) and resource (contracts) with a specific filter (expiration date range). This distinguishes it from sibling tools like list_contracts or get_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding expiring contracts in a date range, but it does not explicitly mention when to use this tool over alternatives such as aidoo_list_contracts. No exclusions or preconditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the extension mechanism for linked data, which is useful, but does not mention pagination, rate limits, or explicitly state that it is a read-only operation. The term 'list' inherently suggests safety, so it is not misleading.
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 efficient sentences, front-loaded with the core purpose and followed by a relevant detail about extensions. There is no redundancy or wasted words.
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 list tool with no output schema and no annotations, the description covers the main capabilities: listing all, filtering, and using extensions. It does not explicitly mention pagination or defaults, but the schema's parameter descriptions fill that gap. Overall, it is adequate for agent decision-making.
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%, meaning each parameter is already described in the schema. The description adds minimal extra meaning, only clarifying that extensions include linked data like contracts, which aligns with the schema. No additional parameter semantics 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 explicitly states the tool lists all members or filters by criteria, using the specific verb 'list' and resource 'members'. This distinguishes it clearly from aidoo_get_member (single member) and other list tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving member lists and optionally including linked data via extensions, but does not explicitly contrast with aidoo_get_member or other alternatives. It provides context for extensions but lacks clear exclusions or when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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