Swapcard MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clear distinct resource+action pairs, but some overlap exists between community-level documents (create_document, update_document) and event-specific documents (create_event_document, update_event_document), which could cause misselection. Similarly, get_my_exhibitors vs list_exhibitors have ambiguous boundaries, though descriptions clarify them somewhat.
Naming Consistency4/5
All tools share the swapcard_ prefix and generally follow a verb_noun pattern (e.g., get_event, list_exhibitors, delete_webhook). Minor inconsistencies include variant names for similar operations (e.g., upsert_exhibitors vs create/update), pluralization differences (delete_event_documents vs delete_exhibitors), and mixing 'get_my' with 'list', but the overall pattern remains predictable.
Tool Count3/5
With 32 tools, this server is on the heavier side, but the count is justified by the breadth of domains covered (events, people, documents, custom fields, webhooks, exhibitors, sessions, analytics). Some tools seem redundant (e.g., two document creation/update pairs), making the surface feel bloated, but each tool has a distinct role within its domain.
Completeness3/5
The toolset covers extensive CRUD for people, documents, custom fields, webhooks, and exhibitors, but notable gaps exist: no create/update/delete operations for events (only get), no mutation for meetings (only list), and limited lead management (only get_my_leads and scan_badges, no direct lead updates). These gaps may force agents to work around missing lifecycle operations.
Average 3.1/5 across 31 of 32 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds only an authentication-scope detail ('accessible to the authenticated Leads API token') but does not mention pagination behavior, ordering, result format, rate limits, or error conditions. This is minimal and leaves important behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy, making it efficient and front-loaded. The only issue is that it is under-specified, but that is penalized elsewhere; structurally it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and zero-parameter descriptions, yet the description offers only a one-line purpose. It does not explain the pagination parameters, the response shape, or how this tool relates to swapcard_list_exhibitors, so the context is far from complete 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the two parameters 'after' and 'first'. No meaning is added beyond the raw type information already in the schema; the likely pagination semantics of these parameters are left entirely undeclared.
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 a specific action ('Get the list of exhibitors') and a scope ('accessible to the authenticated Leads API token'). However, it does not explicitly differentiate this from the sibling tool swapcard_list_exhibitors, relying on the 'my' in the name and the token qualifier to imply the 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?
No guidance is given about when to use this tool versus alternatives such as swapcard_list_exhibitors, nor are any prerequisites or exclusions mentioned. The token-scope hint is implicit but not actionable as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the burden. It states 'List or search' but does not disclose behavior like pagination limits, sort capabilities, filtering semantics, or response format. No mention of read-only nature or complexity implications.
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, compact sentence with no filler. It is appropriately sized, but may be under-specified, leading to a trade-off between conciseness and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, nested objects, no output schema, and no behavioral guidance, the description is significantly incomplete. It does not address pagination (after, first), sorting, filtering options, or what data is returned, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any parameters. The schema itself has nested objects like sort, filter, and search, but the description does not clarify their meaning, usage, or relationships. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List or search exhibitors in a community' clearly states the action (list/search) and the resource (exhibitors) with a community scope. It distinguishes from 'swapcard_get_my_exhibitors' and 'swapcard_upsert_exhibitors' by community context, but does not explicitly name alternatives or contrast with partner tools like 'swapcard_list_event_people'.
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 such as 'swapcard_get_my_exhibitors' or 'swapcard_list_event_people'. No mention of search vs filter usage, pagination needs, or when to prefer listing over other operations.
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 absent, so the description alone must disclose behavioral traits. It only states 'Update' which implies mutation, but gives no detail on partial vs. full update, error handling, permissions, or any side effects. This is insufficient for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or repetition. It is front-loaded with the core action. However, it is so minimal that it borders on under-specification, but for pure conciseness, it earns a high score. The brevity is not a flaw in itself, but it does limit usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema, 0% schema description coverage), the description is severely inadequate. It does not explain parameter roles, expected behavior, or any side effects. It is far from complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description adds zero parameter meaning—it does not explain the purpose of 'url', 'name', 'description', or 'documentId' beyond what the property names imply. With 4 parameters, this is a significant gap that the description fails to bridge.
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 an existing event document.' It identifies the resource (event document) and the operation (update). However, it does not explicitly differentiate from sibling tool 'swapcard_update_document', though the name implies event-specificity. It is clear but not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'swapcard_create_event_document' or 'swapcard_update_document'. There are no prerequisites, exclusions, or contextual cues provided. The description is a bare statement of function without 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 must disclose behavior. It states 'Create or update' but does not clarify upsert semantics, conflict handling, validation outcomes, rate limits, or idempotency. It mentions supported features but not the side effects or requirements (e.g., whether existing records are overwritten silently, how errors are reported). This leaves the agent uncertain about the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length. However, it is vague and lacks structure; it doesn't front-load critical information like the primary action or key parameters. It lists features without explaining how they are used. While compact, it fails to be informative enough to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested 'data' array, the presence of 'force' and 'validateOnly' parameters, and the absence of annotations, this description is severely incomplete. It does not explain the purpose of these parameters, the expected behavior on validation, or how to construct the data structure. The tool is not usable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. It references high-level capabilities (groups, barcodes, speaker roles, exhibitor memberships, custom fields) but does not map them to specific parameters like 'data' or 'force'. The essentials (eventId, data, validateOnly) are undocumented. The description adds minimal semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create or update attendees/people in bulk.' It identifies the resource (attendees/people) and the operation (create/update in bulk), and it mentions additional capabilities (groups, barcodes, speaker roles) that help distinguish it from list/delete tools. However, it doesn't explicitly contrast with siblings like swapcard_delete_event_people or swapcard_list_event_people, though the bulk import purpose is evident.
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 gives no context for when bulk import is appropriate, no exclusions, and no mention of alternatives like individual create/update or session import tools. The 'bulk' wording implies batch scenarios, but there's no explicit when-not or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that it registers a subscription but does not disclose what happens upon registration (e.g., immediate activation, verification of endpoint, potential side effects like sending a test payload). No details about permissions or rate limits 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks a critical structure: it doesn't front-load any usage context or parameter hints. It is not overlong, but the sentence is too sparse to be fully useful, so it doesn't earn a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, no annotations, no output schema) and the presence of sibling webhook tools, the description is incomplete. It omits information about parameter semantics, return value, and any side effects. It fails to cover the knowledge gap left by the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter explanations. The schema defines four parameters with types and enums for 'hooks', but the meaning of 'secret', 'eventId', and 'endpoint' is not elaborated. For instance, it doesn't clarify that 'secret' is the signing secret for webhook payloads or that 'endpoint' is the HTTPS URL for delivery.
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 ('Register a new webhook subscription') and the resource ('an event'). It distinguishes from siblings like swapcard_list_webhooks, swapcard_update_webhook, and swapcard_delete_webhook, though it doesn't explicitly mention these alternatives. The purpose 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 the sibling webhook tools (list/update/delete). The context of registering a subscription is implied but not explicitly contrasted with updating or listing. Missing information about prerequisites like having an eventId or endpoint readiness.
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 states the basic action. It does not reveal whether the update is partial/patch, what happens to omitted fields, whether fieldDefinitionId must exist, or any side effects on existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It is front-loaded and easy to parse, though it may err on the side of oversimplicity for a tool with several 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 no output schema, no annotations, and 0% parameter documentation, the description is too thin to give an agent sufficient context. It lacks information about required fields, update semantics, error behavior, and relationship to sibling custom-field tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. The four parameters (isVisible, isEditable, maxCharacters, fieldDefinitionId) are entirely unexplained, so the agent cannot infer which fields are updatable or what values are valid.
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 ('Update') and the resource ('custom field definition'), and the word 'existing' distinguishes it from create/delete siblings. However, it does not explicitly name alternative tools or clarify whether this applies to field metadata rather than field values.
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 explain when to use this tool versus swapcard_create_custom_field, swapcard_get_custom_fields, or swapcard_delete_custom_fields, nor does it mention prerequisites or lifecycle 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 disclosing behavioral traits. It only says 'create', which implies a mutation, but does not mention permissions required, reversibility, idempotency, or any side effects. It lacks transparency about what happens on creation or any constraints.
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 effectively communicates the primary purpose. It is front-loaded and contains no fluff, making it easy 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 description is too sparse for a tool with six parameters, no output schema, and no annotations. It does not explain return values, parameter formats, or the actionType enum, leaving the agent with insufficient information to confidently invoke the tool. The optional event scoping is mentioned but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It only hints at community-level (communityId) and optional event scoping (eventId) but does not explicitly name or describe any of the six parameters, including the required name, url, and the actionType enum. This provides no added value beyond the raw 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 action (create) and the resource (community-level document), and distinguishes it from the sibling create_event_document by noting the community-level scope with optional event scoping. It conveys the core purpose effectively, though it could be more specific about what 'community-level' means or what document types are supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives minimal guidance on when to use this tool versus alternatives. It implies community-level vs event-level scope but does not explicitize when to choose this over swapcard_create_event_document or when to use update_document. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'update' implying mutation, but doesn't disclose whether it's a partial or full update, whether unspecified fields are reset, or any permission requirements. It also doesn't mention what happens if the exhibitor doesn't exist.
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, concise and front-loaded with the main action. However, it could be slightly more informative 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 8 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the update semantics, the meaning of the features object, or any constraints. The tool is moderately complex, and the description leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'features and background image' but doesn't explain the other parameters like name, logoUrl, websiteUrl, description. The nested 'features' object is not explained. The description adds minimal value beyond the schema's property names.
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 updates a single exhibitor's details, including features and background image. It distinguishes from siblings like swapcard_upsert_exhibitors (which likely creates or updates in bulk) and swapcard_delete_exhibitors, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like swapcard_upsert_exhibitors or swapcard_list_exhibitors. The description implies it's for updating an existing exhibitor, but doesn't state prerequisites (e.g., exhibitor must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic create action. It does not disclose side effects, idempotency, permission requirements, or behavior on duplicate names. 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 with no unnecessary words. It front-loads the verb and object, making it easy to parse, though it 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?
For a tool with 7 parameters and no output schema, the description is highly incomplete. It provides no parameter semantics, constraints, or related context, making it difficult for an agent to use correctly without significant external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any parameters. The meaning of target, type, isVisible, isEditable, and translations is left entirely to the raw schema, which is insufficient.
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 ('custom field definition'), and the scope ('on an event'). It is specific enough to distinguish from sibling operations like update_custom_field and delete_custom_fields.
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 the sibling custom field operations (get, update, delete). The description lacks any context about prerequisites, alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It adds that the document is URL-based but does not disclose permissions, idempotency, error behavior, or any side effects beyond creating a new attachment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the key purpose. Every word contributes meaning, and there is no redundant or filler content.
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?
This create tool has no output schema or annotations, yet the description does not mention return values, validation constraints (e.g., URL format), or behavior when the event is missing. Like the update_drive example, it leaves important operational context unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters in detail. While 'URL-based' and 'to an event' hint at url and eventId, the meaning of name and description, and optionality versus requirements, are left to the schema names alone.
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 'Attach a new document (URL-based) to an event' clearly identifies the action, resource, and target. It distinguishes this from list/update/delete document siblings, though it does not explicitly differentiate it from the generic swapcard_create_document sibling.
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 like swapcard_create_document, nor does it mention prerequisites such as the event existing. Context must be inferred entirely from the tool name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does not mention whether this operation is read-only, any rate limits, or what happens if some IDs are invalid. The description only states a basic action without safety 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, front-loaded, and contains no redundant information. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is thin. It does not specify the return format (e.g., list of events) or any error handling, which is a gap for a batch operation. A more detailed description would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the single parameter, and the description restates the purpose of 'eventIds' without adding new format or usage details. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches multiple Swapcard events by their IDs, but it does not explicitly distinguish it from the sibling 'swapcard_get_event' (singular), though the plural nature is implied.
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. It does not mention when to prefer this over 'swapcard_get_event' (e.g., for batch fetching) or when not to use it (e.g., single event).
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 provided, so the description carries the full burden of behavioral disclosure. It doesn't mention pagination behavior, authentication requirements, rate limits, or what happens when no documents exist. The 'List all' wording could suggest it returns all at once, but with a 'page' parameter available, pagination is implied but not explained.
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?
Single sentence, direct, and to the point with no fluff or unnecessary words. Extremely concise, though it could argue that it's under-specified rather than concise.
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, no annotations, and a very brief description, the description provides minimal context. It's a simple list operation, but with pagination parameter available, the description could have added clarity on page size, pagination format, or whether it returns metadata like total count. The absence of such details makes it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description adds no documentation for the parameters beyond their basic schema (page: number, eventId: string). It doesn't clarify the format of 'page' (e.g., 1-indexed, page size) or what 'eventId' references. The description could have explained the meaning of 'page' in the context of listing, but it remains silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all documents attached to an event' clearly states the verb (List) and the resource (documents attached to an event). It distinguishes itself from sibling tools like swapcard_create_event_document and swapcard_delete_event_documents by indicating this is the read operation, though it doesn't explicitly name them as 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?
It implies usage for listing documents but doesn't elaborate on when to use this versus alternatives. The description does not specify when not to use it or name alternative tools that could achieve document retrieval. It serves the basic purpose without offering additional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the entire burden of disclosing behavioral traits. It mentions updating but omits any side effects (e.g., potential for breaking an existing integration), idempotency semantics, or whether fields not mentioned (like webhookId) are untouched or reset. This is a mutation tool, so more disclosure of destructive potential or preconditions would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary verbiage. It front-loads the action ('Update') and the core targets ('endpoint or event types'), which is efficient. However, it could have added critical caveats (e.g., 'This does not update other fields') in the same concise style, so it misses a perfect score.
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 moderate complexity (3 parameters, no annotations, no output schema), the description is too thin. It does not explain the update semantics: whether omitted parameters are left unchanged or reset, whether endpoints must be a valid URL, or what the response contains. This leaves the agent to guess critical behavioral aspects, making the description inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description needed to compensate, but it only vaguely refers to 'endpoint or event types.' It does not explain that webhookId identifies the resource, nor does it describe the format or allowed values for endpoint or hooks. The description adds minimal value over the bare schema, focusing on two of three parameters without naming them.
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 ('Update') and a clear resource ('webhook subscription'), and specifies the exact aspects that can be updated ('endpoint or event types'). This clearly distinguishes it from sibling tools like swapcard_create_webhook and swapcard_delete_webhook, making the purpose unmistakable.
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 that creation or deletion is handled by sibling tools, nor does it state any prerequisites or scenarios where updating would be inappropriate. The context is entirely implicit from the name and phrase 'existing webhook subscription.'
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 says 'Delete' and identifies what is removed, but does not mention permanence, cascading effects on existing field values, permission requirements, or possible failure modes. For a destructive tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It earns its place by concisely conveying the core action and target resource.
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 that there are no annotations, no output schema, and zero parameter descriptions, this one-sentence description is incomplete for a destructive multi-parameter tool. It lacks usage context, deletion consequences, and clear parameter role clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain eventId or fieldDefinitionIds. The phrase 'from an event' only weakly implies eventId; fieldDefinitionIds is not elaborated beyond the general word 'definitions.' The description does not compensate for the missing schema-level parameter documentation.
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 custom field definitions from an event.' It identifies a specific resource (custom field definitions) and scope (event), which distinguishes it from siblings like swapcard_delete_event_people, swapcard_delete_event_documents, and CRUD custom-field 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 given on when to use this tool versus alternatives, no prerequisites are mentioned, and no exclusions are stated. The description simply asserts the action without explaining when deletion is appropriate relative to update/create custom field tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The word 'permanently' indicates irreversibility, but there is no mention of side effects, auth requirements, rate limits, or what happens to related data (e.g., meetings, documents). This is minimal coverage for a destructive 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?
Single sentence, front-loaded with the primary verb and resource. No fluff or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is under-specified. It does not mention expected outcomes, error handling, or any behavioral caveats. While the action is simple, the lack of guidance leaves the agent with significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only clarifies that eventPeopleIds are 'Swapcard person IDs', but does not explain eventId or provide format, constraints, or additional context. The description adds minimal value over the bare names.
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 (permanently delete), the resource (people from an event), and the targeting mechanism (by Swapcard person IDs). It effectively distinguishes from sibling tools like list_event_people or import_event_people.
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, when not to use it, or any prerequisites. It lacks information about required permissions, implications of deletion, or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update' and provides no details on patch semantics, whether unspecified fields are cleared, permissions needed, ID format, or what happens if the document does not exist.
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 filler. It conveys the core operation, resource type, and key parameter in an efficient manner.
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 too sparse. It does not explain update behavior, optional-field handling, authorization expectations, or relationship to sibling document tools, leaving the agent without enough operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions the ID. The semantics of url, name, and description are not explained, nor whether they represent partial updates or full replacements. The property names are somewhat self-explanatory, but the description adds little 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 ('Update'), the resource ('community-level document'), the API version ('v2'), and the lookup method ('by its ID'). It also differentiates from siblings like swapcard_update_event_document by specifying 'community-level'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs. alternatives. It does not mention when to prefer swapcard_update_event_document, swapcard_create_document, or any related document tools, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'create or update' without detailing side effects, idempotency, permissions, or error handling. The mutating nature is implicit but other important aspects like whether it replaces or merges data are omitted.
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 unnecessary words. It is appropriately concise and front-loaded, immediately conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema (nested objects, arrays), the description is too brief. It does not mention that 'exhibitors' is an array, that it supports multiple records, or explain the structure of each exhibitor object. This leaves significant gaps for a tool with such a rich input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides field names but no descriptions. The description does not add any semantic meaning to parameters like 'clientId', 'membersIds', or 'socialNetworks'. Since schema coverage is 0%, the description fails to compensate by explaining these fields.
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: creating or updating exhibitors within an event. It uses a specific verb ('create or update') and identifies the resource ('exhibitors') and context ('in an event'), which distinguishes it from related tools like list or delete exhibitors.
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 explicit guidance on when to use this tool versus alternatives such as update_exhibitor or import_exhibitors. It does not mention that it handles bulk operations or that it serves as an upsert, leaving the user to infer its use case.
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 disclose behavioral consequences. It only mentions that documents are deleted, without noting irreversibility, partial failure behavior, permissions, or impact on related data.
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 one short, front-loaded sentence with no filler. Every word adds meaning related to the tool's core action.
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 and no annotations, deleting multiple documents by IDs needs more context about return values, failure semantics, or destructive consequences. The description is too minimal to fully prepare an agent for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. 'By their IDs' clarifies that documentIds are the identifiers, and 'event documents' implies eventId scopes the operation, but no extra detail on format or relationships is 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 uses a specific action verb 'Delete' with a clear resource 'event documents' and the scope 'by their IDs.' It distinguishes itself from sibling tools like swapcard_delete_event_people and swapcard_delete_exhibitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives or any prerequisites/exclusions. It only states the action, leaving the agent to infer usage context from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden but only states the basic action. It does not disclose whether scanning overwrites existing ratings/notes, how duplicate scans are handled, or what authentication/authorization is implied beyond 'on behalf of an exhibitor'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no fluff. Every word contributes to clarifying the tool's purpose and key 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 moderate complexity (array parameter, no output schema), the description omits critical context such as return values, error behavior, idempotency, or how partial failures are handled. It is functional but leaves many runtime aspects ambiguous.
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 0%, so the description partially compensates by explaining the rating range (1-5) and optionality of notes/rating per badge. However, eventId and exhibitorId are left undefined, and code is not explicitly explained.
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 'Scan' targeting 'attendee badges' and adds context 'on behalf of an exhibitor', clearly distinguishing it from siblings like list/import operations. The optional rating and note detail further clarify the tool's 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?
No guidance is provided on when to use this tool versus alternatives such as swapcard_import_event_people or swapcard_list_event_people. There are no exclusions, conditions, or references to related tools, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Delete exhibitors' without mentioning irreversibility, cascading effects, or permissions required. This is insufficient for a destructive operation, leaving the agent unaware of potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and to the point, making it efficient for quick comprehension.
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 delete operation complexity, lack of annotations, and no output schema, the description is incomplete. It does not inform about result feedback, error handling, or confirmations, which are critical for a safe invocation. The description needs more detail to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by their IDs' but does not clarify that 'IDs' refers to exhibitorIds only, nor does it explain the purpose or format of eventId. The parameter names are self-explanatory, but the description adds minimal value 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 (delete) and the target resource (exhibitors from an event), with a specific method (by IDs). It distinguishes from sibling tools like swapcard_list_exhibitors or swapcard_upsert_exhibitors by making the destructive 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 for when deletion of exhibitors is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or scenarios to avoid. It falls short of providing explicit guidance on choosing this over other exhibitor-related 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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only mentions create/update and supported features like formats and access control, but does not disclose idempotency, error handling, permissions, or rate limits. This is minimal 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 two sentences, direct and front-loaded with the core action. There is no filler or irrelevant information, making it appropriately concise.
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 complex nested schema, no annotations, and no output schema, the description is insufficient. It fails to explain the structure of the plannings array, expected return values, or operational constraints, making it hard for an agent to construct valid input or anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely references 'formats, video types, access control, and custom fields.' It does not map to specific parameters like eventId or plannings, nor explain the structure of the plannings array or required fields like clientId, beginsAt, etc. The description adds little value beyond what the schema already shows.
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 that it creates or updates sessions/plannings in bulk, using a specific verb (create/update) and resource (sessions/plannings). It distinguishes from sibling tools like swapcard_list_sessions or swapcard_delete_sessions by focusing on bulk mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in bulk' implies it is for batch operations, but there is no explicit guidance on when to use this tool versus alternatives like swapcard_import_event_people or swapcard_list_sessions. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It states the tool deletes sessions, which is obviously destructive, but it doesn't disclose whether the deletion is permanent, whether it requires specific permissions, or what happens if the provided IDs don't exist. This is a significant gap for a destructive 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 sentence that conveys the core purpose without any redundant phrases. It is front-loaded and economically expresses the tool's function, earning every word.
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 operation with only two parameters and no output schema, the description provides the basic purpose but lacks important context like irreversibility, required IDs format, or any note on error handling. It is adequate but leaves room for elaboration to fully prepare an agent for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explicitly explain the parameters. It mentions 'by their IDs' and 'from an event', which hints that eventId corresponds to the event and planningsIds are the session identifiers, but it doesn't clarify that planningsIds is an array or provide any format details. The description adds only minimal meaning beyond the schema, insufficient to fully compensate for the lack of schema descriptions.
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), the resource (sessions/plannings), and the context (from an event by their IDs). It distinguishes from sibling tools like list_sessions and import_sessions by specifying deletion, making the purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to delete sessions), but it doesn't explicitly contrast with alternative deletion tools like swapcard_delete_event_people or swapcard_delete_custom_fields, nor does it mention prerequisites such as needing the event ID and planning IDs from a prior list call. Usage guidance is minimal and mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It does not mention side effects, permissions, rate limits, or whether the operation is read-only. The word 'get' implies a read, but it is not explicit, and there is no disclosure of any potential side effects or limitations.
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 conveys the essential information without any redundant or verbose language. It is well-structured and 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?
Given the simple nature of the tool (two string parameters, no output schema), the description is sufficient to understand the basic operation. It mentions what it returns (leads) and the scope (exhibitor and event). However, it does not elaborate on the response structure or any additional context, but this is acceptable for a straightforward retrieval 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 description clarifies that eventId and exhibitorId are identifiers for the event and exhibitor, respectively, which adds some meaning beyond the bare schema. However, it does not provide details on expected formats, examples, or whether they are required in a specific context, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving leads (scanned contacts) for a specific exhibitor and event. It uses a specific verb ('get') and resource ('leads'), and the context of exhibitor and event distinguishes it from other tools in the set.
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 explicitly state when to use this tool over alternatives or provide any usage conditions. While the purpose is clear, there is no guidance on scenarios where this tool is preferred or not, which is a gap for a tool with many siblings.
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 burden. It states the tool returns definitions and option values, which is a read operation, but it doesn't disclose any additional behavioral traits like pagination, rate limits, or whether it returns all fields or only those with options. The description is adequate but not rich.
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 key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description is relatively complete for a simple read operation. However, it doesn't mention what the response looks like or any edge cases (e.g., what happens if no select fields exist). Given the simplicity, a 3 is appropriate.
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 0%, so the description must compensate. It mentions 'eventId' implicitly by context but doesn't explain the parameter's meaning or format. The description adds some value by specifying the resource type (Select/MultipleSelect custom fields) but doesn't detail the eventId parameter beyond what the schema shows.
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 Select and MultipleSelect custom field definitions with option values, which is specific and distinguishes it from sibling tools like swapcard_get_custom_fields (which likely retrieves all custom fields). However, it doesn't explicitly name the sibling tool for comparison.
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 fetching select-type custom field options, but it doesn't explicitly state when to use this tool versus swapcard_get_custom_fields or other alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the delete action but does not mention whether deletion is permanent, whether special permissions are required, or what happens if the webhook ID does not exist. This is a meaningful gap for a destructive 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, front-loaded sentence with no filler or redundant detail. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, this is minimally viable: it identifies the action and the required identifier. However, it omits any mention of return behavior, error cases, or irreversible side effects, leaving some ambiguity for an agent deciding how to handle the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'by its ID,' which merely restates the schema's webhookId property and adds no guidance on where to obtain the ID, expected format, or validation rules.
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 ('Delete') with a clear resource ('a webhook subscription') and scoping ('by its ID'), which clearly distinguishes it from sibling tools like create_webhook, update_webhook, and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear enough that an agent can determine when to use it: when a webhook subscription needs to be removed. It does not explicitly name alternatives or exclusions, but the sibling set and verb make the usage context obvious.
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 disclose behavioral traits. It neither states that the operation is read-only nor covers error handling, authentication, or side effects. Although 'get' suggests non-destructive behavior, the description does not add any transparency beyond the operation name.
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 leads with the action and resource, then lists the returned fields. It contains no redundant information and is well-front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description sufficiently outlines what fields will be returned. It does not cover error cases or explicitly state that the returned object is complete, but given the low complexity, it is nearly 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 schema provides full coverage for the only parameter (eventId) with a description 'The event ID'. The description's phrase 'by ID' adds no new meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 applies; no additional parameter details are offered.
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 'Get a single Swapcard event by ID', specifying the verb, resource, and identifier. It also enumerates expected fields (title, dates, description, address, groups, community, stats), distinguishing it from sibling tool swapcard_get_events which lists multiple events.
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: the description indicates this retrieves a single event when an ID is available. However, it does not explicitly contrast with swapcard_get_events or mention when not to use it, so guidance is only implicit.
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 behavioral transparency burden. It discloses read-only intent ('List or search') and important behavior like cursor-based pagination and optional email filtering. It does not mention return format, pagination limits, or required auth, but for a list operation this is minimally adequate.
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 core purpose and packs in the main optional capabilities without wasted words. It is appropriately concise.
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 and no annotations, the description should provide more context about what is returned, how pagination behaves, and how the parameters interact. The single sentence covers the high-level purpose but leaves significant gaps for a 5-parameter 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 0%, so the description must compensate. It does mention search, email filtering, and cursor-based pagination, which map to the search, emails, after, and first parameters. However, it does not explain specific formats, defaults, or how the cursor works, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List or search') and the resource ('attendees/people in an event'), and mentions key capabilities like email filtering and cursor-based pagination. This distinguishes it from sibling tools like swapcard_delete_event_people and swapcard_import_event_people.
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 retrieving or searching event attendees, which is enough for a basic list tool. However, it does not explicitly state when to use it over sibling list tools (e.g., list_meetings, list_sessions) or provide exclusion criteria.
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 exist, so the description carries the burden. It states the tool lists/searches sessions, indicating a read operation. However, it does not disclose pagination behavior, return format, or any constraints like rate limits, which an agent might need to know. It adds only slightly beyond the name.
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 fluff, front-loading the primary action. However, it could be slightly more structured to list parameters, but the brevity is acceptable for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify return values or pagination. It does neither. It also fails to describe the 'search' and pagination parameters, making the tool incomplete for an agent to use effectively. The 6 parameters and nested objects demand a more thorough explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for parameters, so the description must compensate. It mentions filtering by event, format, and speaker, and sorting by various fields, but does not explain key parameters like 'search', 'after', 'first', or the full filter object. Many parameters (placeIds, clientIds) are omitted, leaving the agent to infer from names.
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 lists or searches sessions/plannings within a community, and explicitly mentions filtering by event, format, and speaker, as well as sorting. This distinguishes it from sibling tools like swapcard_list_meetings or swapcard_list_exhibitors, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is unambiguous: use it to retrieve sessions. It implies filtering and sorting capabilities, which are also reflected in the schema. However, it does not explicitly state when not to use it or mention alternatives, though the context of 'sessions' separates it from peers.
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 and does disclose two meaningful behavioral traits not visible elsewhere: the ~10-minute data delay and the fact that results are cursor-paginated. However, it omits other potentially relevant behavior like rate limits, authentication, or data scope details, so a perfect score is not warranted.
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?
Three short, front-loaded sentences with no wasted words. Every sentence adds value: what it does, the data delay, and pagination. Perfectly concise.
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 tool's complexity (9 parameters, no schema descriptions, no annotations, no output schema), the description is too brief. It covers only high-level behavior and omits parameter semantics, required parameters, response format, and edge-case guidance. The description is adequate only for the most basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 9 parameters, yet the description adds zero information about any of them. It does not clarify what 'events', 'cursor', 'time_gt', or 'user_ids' mean or how they should be used. The description fails to compensate for the complete lack of schema documentation.
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 ('Export') with a clear resource ('raw analytics event records') and scope ('for one or more events'). It also adds distinguishing details like the ~10-minute delay and cursor-based pagination, which helps differentiate it from other tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when exporting raw analytics events. It provides useful context (data delay, pagination) but does not explicitly state when not to use it or name alternatives. This fits 'clear context, no exclusions.'
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 transparency burden. It reveals that the operation is a list with optional filters and cursor pagination, but it does not mention response format, authentication requirements, default page size, or any notable behavior beyond the basic read 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 entire description is one efficient, front-loaded sentence. It states the core purpose and the two main enhancement areas without filler, making it easy to scan.
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 five-parameter list tool with no annotations and no output schema, the description is functional but lean. It covers the query inputs and pagination concept, yet omits return value shape, pagination mechanics, and any operational caveats, so it is not fully self-sufficient.
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 0%, so the description must compensate. It groups the parameters meaningfully: 'ID filters' maps to ids, 'date filters' to lastUpdatedSince, and 'cursor pagination' to after/first, plus the required eventId. This adds valuable context, though individual parameter formats are not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List'), the resource ('meetings'), and the scope ('in an event'), while also mentioning key capabilities (ID/date filters and cursor pagination). It reads distinctly from sibling tools like list_sessions or list_exhibitors.
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 retrieving meetings with filtering/pagination, but it gives no explicit guidance on when to choose it over alternatives such as list_sessions or list_event_people. There are no exclusions or alternative tool references.
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 transparency burden. The description honestly indicates a read operation ('get') and mentions the optional filter, but does not disclose additional behavioral details such as authorization requirements, pagination, or whether the response contains only metadata. It is not misleading but is thin on 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, well-structured sentence that front-loads the primary action and then states the optional modifier. Every word is informative, with no redundancy or irrelevant detail.
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 retrieval tool with only two parameters and no output schema, the description covers the essential information: what is retrieved, the scope (event), and the optional filter. It is sufficiently complete for an agent to invoke the tool correctly, though it could mention response format or error conditions.
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 0%, so the description must compensate. It does explain the context for both parameters: 'for an event' clarifies eventId, and 'optionally filtered by target entity type' clarifies target. This adds meaningful semantic context beyond the raw schema, though it could be more explicit about the allowed target values.
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 all custom field definitions for an event with an optional filter by target entity type. The verb 'get' and resource 'custom field definitions' make the purpose unambiguous, and it is differentiated from sibling tools that create, update, or delete custom fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: it is the read operation for custom field definitions, distinct from create/update/delete siblings. However, no explicit guidance is given on when to choose this over alternatives like get_select_field_options, nor any exclusions.
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, and the description only states the action without detailing side effects, return format, or any potential limitations. As a list operation, it is likely safe, but this is not explicitly disclosed.
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 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?
Given the simplicity of the operation, the description provides adequate context. It does not explain the return structure, but as this is a list endpoint, the expectation of a list is implied. No complex behavior is involved.
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 single parameter 'eventId' is clearly implied by the description 'configured for an event'. The schema's meaning is self-evident, and the description adds sufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (webhook subscriptions for an event), which distinguishes it from sibling tools that create, update, or delete webhooks.
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 does not explicitly indicate when to use this tool versus alternatives, though the verb 'list' implies read-only retrieval. It lacks guidance on when not to use it, but it is straightforward.
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:

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

Score Badge

Copy to your README.md:

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

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