HireSquire Agent Ecosystem
Server Details
Official MCP server for HireSquire. Automate resume screening, candidate ranking, and interview scheduling for autonomous agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 24 of 24 tools scored. Lowest: 2.4/5.
Each tool has a clearly distinct purpose, covering separate aspects like screening, email generation, calendar management, credits, and API info. No overlapping functionalities.
Most tools follow a consistent verb_noun pattern in snake_case (e.g., create_screening, get_credit_balance). The exception is 'whoami', which is a common but nonstandard verb. Overall highly consistent.
24 tools is slightly above the typical sweet spot (3-15) but just below the 25+ threshold. The breadth of the domain (screening, credits, calendar, email, webhooks) justifies the count, though it feels a bit heavy.
The tool set covers core workflows: screening creation/monitoring/results, email generation, calendar integration, credit management, and configuration. Minor gaps like missing update/delete for some entities, but overall sufficient for the ecosystem's purpose.
Available Tools
24 toolsbulk_generate_emailsBInspect
Generate multiple personalized candidate emails in a single call. Use this for high-volume outreach batches (max 50 candidates) after a large screening job.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Common tone for the batch. | |
| type | Yes | Common email type for the batch. | |
| job_id | Yes | The job ID. | |
| candidate_ids | Yes | Array of candidate IDs to process (max 50). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states efficiency and high-volume context, omitting critical behavioral details such as whether emails are drafts or sent, idempotency, rate limits, or error handling for invalid candidate IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, no redundancy. It is front-loaded with the main action. However, it could slightly expand on behavioral context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., generated email texts, success status). It lacks prerequisites, error handling, and post-conditions, making it incomplete for an AI agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description adds no additional parameter-level information beyond what the schema already provides, such as the meaning of 'tone' choices or the impact of 'type'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates personalized emails for multiple candidates, with 'bulk' in the name implying batch processing. However, it does not explicitly differentiate from the sibling tool 'generate_email' (singular), which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'high-volume outreach after screening' implying a specific use case, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'generate_email' for single candidates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_screening_jobBInspect
Immediately stop a running screening job. Use this if the user made a mistake or the job is no longer needed. Note: Credits for already-processed candidates are not refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The ID of the job to cancel. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'running' but does not disclose behavior for non-running jobs, side effects, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is concise and front-loaded. Every word is necessary and contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description lacks completeness. It does not explain error handling, return values, or constraints (e.g., if the job is already cancelled).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for job_id is 'The job ID to cancel,' which is clear. The tool description adds no additional meaning beyond what the schema already provides. Baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Cancel' and the resource 'screening job', clearly indicating the action and target. It distinguishes itself from sibling tools like create_screening and get_screening_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives. It does not mention prerequisites, such as the job must be running, nor does it exclude cases like completed jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_candidatesAInspect
Perform a side-by-side AI comparison of 2-10 candidates. Use this when you need a clear "Delta Analysis" to decide between top-tier applicants for a final interview.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID. | |
| candidate_ids | Yes | List of 2-10 candidate IDs to compare. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions AI-powered analysis, but does not disclose read-only nature, auth needs, or side effects. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Front-loaded with the core action and immediately adds the key differentiator (Delta Analysis). Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers main outputs (Delta Analysis, ranking). Could specify output format or return structure, but for a simple read tool it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional parameter meaning beyond repeating the AI analysis feature. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: compare candidates side-by-side to evaluate relative strengths, with AI-powered Delta Analysis. It distinguishes from sibling tools as the only comparison tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to compare candidates, but lacks explicit when-not-to-use or alternative tools. Since no other sibling tool offers comparison, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_calendar_connectionBInspect
Securely connect a scheduling provider to HireSquire using an API key. Use this during initial user onboarding or when adding a new interview tool.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Valid API key/token from the provider. | |
| provider | Yes | The scheduling tool provider. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., overwriting an existing connection), authentication requirements, or rate limits. It simply states the action without any safety or impact notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. It is concise with no fluff, though it could benefit from a brief mention of the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or output schema, the description should compensate. It lacks details on return value (e.g., connection ID), error scenarios, or behavior when a duplicate connection exists. For a 3-parameter tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds no new meaning beyond what the schema already provides (e.g., 'API key' and 'Calendar provider' are already in the schema). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Connect', the resource 'calendar provider', and specifies the supported providers 'calendly, calcom' and the system 'HireSquire'. This leaves no ambiguity about 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for connecting a new provider but does not explicitly state when to use it versus alternatives like 'list_calendar_connections' or mention prerequisites (e.g., existing account). No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_checkout_sessionAInspect
Generate a Stripe Checkout URL for manual credit purchase. Use this to provide the human user with a secure payment link in the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | The desired credit pack. | |
| amount | No | Custom amount (min $5.00). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it generates a payment link, but lacks details on side effects (e.g., no mention of idempotency or Stripe account requirements). Annotations absent, so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no superfluous information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but sufficient for a simple tool. Lacks output details and relationship to sibling tools like purchase_credits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra meaning. Parameters already described in schema adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (create), resource (Stripe checkout session), and purpose (credit purchase, generates payment link). Distinguishes from siblings like purchase_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., purchase_credits). Missing context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_interviewBInspect
Confirm an interview time, create a calendar event, and notify the candidate. Use this as the final step in the scheduling process once a time is selected.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID. | |
| provider | No | Scheduling provider. | |
| candidate_id | Yes | The candidate ID. | |
| scheduled_at | Yes | ISO 8601 timestamp (e.g., "2024-05-20T14:30:00Z"). | |
| duration_minutes | No | Duration in minutes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior by mentioning calendar event and meeting link creation, but it lacks details on side effects, permissions, or data persistence. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, efficient but could benefit from additional structure or bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the tool returns. It covers the action but not the response format or side effects, leaving some gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions. The description adds no additional parameter meaning beyond the schema, which already provides sufficient detail. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'interview', and specifies that it also creates a calendar event and meeting link. It is distinct from sibling tools like 'create_screening' and 'generate_meeting_link'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. For a tool that creates multiple entities, usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_screeningAInspect
Submit candidate resumes for AI screening against a specific job description. Use this as the entry point for candidate evaluation. It parses resumes, scores them (1-100), and provides reasoning. Side effect: Debits credits from the user account based on the number of resumes.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The official job title for the position. | |
| resumes | Yes | A list of resumes to screen. Each item must include a filename and the content (raw text, base64, or public URL). | |
| description | Yes | The complete job description including requirements and responsibilities (minimum 50 characters). | |
| webhook_url | No | HTTPS URL for asynchronous completion notifications. Recommended for large batches. | |
| leniency_level | No | Strictness scale (1-10). 1 is lenient, 10 is strict. Default is 5. Use 8+ for critical senior roles. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| status | No | |
| message | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses scoring range and input formats but does not mention whether the job is async, any rate limits, or what happens in case of errors. The note on high-accuracy scoring is helpful but insufficiently detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the key action and then additional details. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema (100% covered) and an output schema present, the description covers the essentials. However, it could note that screening is asynchronous and that users should check status via 'get_screening_status'. The sibling tools are not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds meaningful context: 'Supports raw text, base64, or file URLs' and 'High-accuracy scoring (1-100)' which goes beyond the schema definitions. However, it does not elaborate on the 'webhook_conditions' parameter or the scoring methodology.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('resumes for AI screening against a job description'), clearly distinguishing it from siblings like 'get_results' or 'cancel_screening_job'. It also lists supported input formats and scoring details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions input formats and scoring range but provides no explicit guidance on when to use this tool vs alternatives (e.g., 'compare_candidates') or when not to use it. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disable_auto_reloadBInspect
Turn off automatic credit reloading. Use this to revert to manual credit management.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only states the action without disclosing side effects, required permissions, or impact on credit reloading behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that is appropriately concise for a simple action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is mostly complete. However, it could mention that it requires authentication or confirm it has no side effects, but overall it communicates the core function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description does not need to add meaning for parameters, and it correctly avoids mentioning any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Disable) and resource (automatic credit reloading). The purpose is evident, and the presence of a sibling tool 'enable_auto_reload' implies this is the inverse, but no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., enabling auto reload or other credit management tools). The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enable_auto_reloadBInspect
Set up automatic credit purchases when the account balance drops below a specific threshold. Use this to ensure autonomous agents never run out of credits.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to reload each time (min $5.00). | |
| threshold | Yes | Balance threshold in dollars (e.g., 10.00). | |
| payment_method_id | Yes | Saved Stripe payment method ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description carries the burden. It states 'enable' implying a state change, but does not disclose if it's idempotent, whether it overrides existing settings, or any side effects. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct, no extraneous information. Efficiently communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description is too brief; lacks details on error states, confirmation, or interaction with other credit tools. For a tool with 3 required parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (enable) and resource (automatic credit reloading) with a specific condition (when balance drops below threshold). It distinguishes from sibling tools like 'disable_auto_reload' and 'purchase_credits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'disable_auto_reload' or 'purchase_credits'. Lacks prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_screening_costCInspect
Calculate the exact credit cost for a planned screening job based on candidate count. Use this as a pre-flight check before calling "create_screening".
| Name | Required | Description | Default |
|---|---|---|---|
| candidate_count | Yes | Number of resumes you intend to screen. |
Tool Definition Quality
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 says 'Estimate cost' without mentioning whether it is read-only, consumes credits, or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise, but it lacks structure and may be too brief to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter, no output schema, no annotations), the description is incomplete. It does not explain the output format, cost basis, or assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description for candidate_count. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Estimate' and the resource 'cost for screening a number of candidates'. It is distinct from sibling tools that perform screening or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., create_screening). No prerequisites or context for when the estimate is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_emailBInspect
Generate a personalized outreach or follow-up email for a specific candidate. Use this after identifying a strong candidate from "get_results" to move them through the pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | The desired tone of the generated email. | professional |
| type | Yes | Type of email: "invite" for interviews, "rejection" for non-matches, etc. | |
| job_id | Yes | The job ID. | |
| candidate_id | Yes | The specific candidate ID from the results. | |
| custom_message | No | Additional context or instructions to include in the AI-generated email. |
Output Schema
| Name | Required | Description |
|---|---|---|
| body | No | |
| subject | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral context beyond generating emails. It does not disclose whether the tool sends the email, stores it, or requires permissions. Since no annotations are provided, the description carries the full burden, but it only states the action without side effects or outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that covers the core purpose. It is front-loaded and efficient, though it could include a brief statement about output or usage without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema and sibling tools, the description is insufficient. It does not describe the output format, differentiate from 'bulk_generate_emails' beyond the singular nature, or mention prerequisites like screening results being available. The description feels incomplete for a tool with multiple parameters and context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal meaning beyond 'based on screening results', which provides context but does not explain individual parameters beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates professional candidate outreach or follow-up emails based on screening results. It identifies the specific verb-resource combination and implies a single email rather than bulk, distinguishing it from the sibling tool 'bulk_generate_emails'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'based on screening results' which implies context after screening, but it does not explicitly state when to use this tool versus alternatives like 'bulk_generate_emails' or when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_meeting_linkCInspect
Create a one-off virtual meeting link (Zoom, Google Meet, etc.) via a connected provider. Use this when a standalone meeting URL is needed without a full interview event.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Meeting title or topic. | |
| duration | No | Meeting length in minutes. | |
| provider | Yes | The connected provider. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose limited provider options, external service dependency, or required prior setup (e.g., calendar connection).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the inaccuracy detracts from conciseness; it is not front-loaded with essential, correct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description omits return value, prerequisites, and provider limitations, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% parameter descriptions, so baseline is 3, but the description introduces misleading information (Zoom, Google Meet) not matching the enum, reducing its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Generate' and resource 'meeting link', but lists 'Zoom, Google Meet, etc.' which are not in the provider enum (calendly, calcom), causing potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like create_calendar_connection or create_interview; no when-not-to-use or prerequisites specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_schemaAInspect
Fetch the complete OpenAPI 3.0 specification for the HireSquire ecosystem. Use this when you need detailed documentation on REST endpoints or data models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets' the specification, implying a read-only operation, but does not explicitly disclose non-obvious behaviors such as authentication requirements or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that delivers complete information without extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fairly complete. It identifies the resource and standard format (OpenAPI 3.0). However, it could improve by mentioning the output format (e.g., JSON or YAML).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by specifying the scope ('for the HireSquire REST API'), exceeding the baseline expectation for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full OpenAPI 3.0 specification for the HireSquire REST API. This verb+resource specificity distinguishes it from sibling tools like bulk_generate_emails or whoami.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. However, the purpose is self-evident given the clear resource it accesses, so a minimal score is assigned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_available_slotsCInspect
Query a connected calendar for open interview windows on a specific date. Use this to present valid time options to a candidate before scheduling.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Target date in YYYY-MM-DD format. | |
| duration | No | Interview length in minutes. | |
| provider | Yes | The connected provider to query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose behavioral traits like authentication requirements, rate limits, or what happens when no slots are available. The description is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It could benefit from a bit more detail, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description should provide more context about return values, pagination, or error conditions. It lacks this information, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema already documents them well. The description adds no additional context beyond what is in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets available time slots from a calendar provider, specifying a verb and resource. However, it does not differentiate from sibling tools like 'generate_meeting_link' that might also involve time slots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'generate_meeting_link' or 'create_calendar_connection'. The description lacks context about prerequisites 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.
get_credit_balanceAInspect
Check the current credit balance and spending metrics for the account. Use this before starting large jobs to prevent "Insufficient Credits" errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly indicates a read-only operation and the core behavior. However, it omits details like response format or potential edge cases (e.g., insufficient balance), which would be expected for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-crafted sentence that conveys the purpose without any superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose for a simple operation, but lacks details about the return value, which would be helpful since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the schema coverage is 100%, so the description does not need to add parameter info. Per guidelines, baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current credit balance', and adds a secondary purpose 'check if you can afford screening', which distinguishes it from sibling tools like purchase_credits or get_credit_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking available credit before screening, but does not explicitly state when not to use it or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_credit_transactionsCInspect
Fetch a history of credit purchases, spends, and adjustments. Use this for auditing or when a user asks about their recent billing history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent records to return. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as being read-only, pagination behavior, or rate limits. Only the existence of a limit parameter hints at behavior, but it is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence, no waste). It is front-loaded with the action. However, it may be too sparse, missing context that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should provide more context about the return data, sorting, or typical use cases. It is not complete enough for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'limit', which has a clear description. The tool description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get credit transaction history' clearly states the verb and resource, distinguishing it from siblings like get_credit_balance (which shows current balance) and purchase_credits. It is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it does not mention that this shows historical transactions, while get_credit_balance shows the current balance. The agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resultsAInspect
Retrieve detailed candidate scores, AI reasoning, and interview questions for a completed job. Only call this once "get_screening_status" returns a "completed" status.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The unique ID of the completed screening job. | |
| min_score | No | Optional: Minimum score threshold (0-100) to filter results. | |
| only_top_n | No | Optional: Limit results to the top N candidates. |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | No |
Tool Definition Quality
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 correctly implies a read-only operation ('Retrieve'), but does not disclose potential side-effects, authentication requirements, rate limits, or error handling. The description is adequate but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose and content, followed by a key constraint. Every word adds value, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown in input but flagged), so description does not need to explain return values. It covers the essential: what data is returned and when it is available. Given the simple parameter set (3 params, 1 required) and presence of a constraint, the description is nearly complete. Lacks only a mention of related siblings for optimal guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters are already well-described in the input schema (job_id, min_score, only_top_n). The description does not add any additional meaning or usage context for these parameters, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Retrieve' and the resource 'detailed screening results', listing contained data (candidate scores, AI reasoning, interview questions). It also adds a constraint ('only completed jobs'), which distinguishes it from sibling tools like get_screening_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the tool is 'only available for completed jobs', providing a clear condition for use. It does not explicitly exclude other tools or list alternatives, but the constraint is actionable and helps the agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screening_statusAInspect
Check the processing status and progress of a screening job. Use this to poll for completion after calling "create_screening" if a webhook was not provided.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The unique ID returned by create_screening. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | Current status: processing, completed, or failed. |
| progress | No | Percentage of completion (0-100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only vaguely mentions checking status. It does not confirm that the operation is read-only, safe, or idempotent, nor does it describe possible response statuses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It effectively communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and the presence of an output schema (not shown), the description is minimally adequate but lacks additional context such as typical status values or behavior when the job does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter 'job_id'. The tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'current processing status of a screening job'. It distinguishes itself from siblings like 'get_results' (which returns final results) and 'cancel_screening_job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'get_results'). However, the purpose is straightforward, so the omission is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_calendar_connectionsAInspect
List all connected interview scheduling tools (Calendly, Cal.com). Use this to check if a provider is ready before attempting to fetch slots or schedule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It correctly identifies the operation as a list (read-only), but lacks details about potential behavioral traits such as pagination, response size, or whether it returns all connections at once.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action. No unnecessary words, and every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description is minimally adequate. It does not clarify the return format or any potential limitations, leaving some ambiguity about what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is effectively 100%. According to guidelines, this earns a baseline of 4. The description adds no parameter info, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all connected calendar and meeting tools', using a specific verb and resource. It effectively distinguishes this tool from siblings like 'create_calendar_connection' and 'generate_meeting_link'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While the purpose is clear, it does not mention exclusions or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_credit_packsAInspect
Browse available credit bundles and their current pricing. Use this to help the user choose the best pack for their "purchase_credits" call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a simple read operation without side effects, but lacks details on authentication, freshness, or response structure. No annotations are present to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description sufficiently informs the agent of its function. Could optionally mention the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to elaborate. Baseline for zero parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available credit packs for purchase, which is specific and distinguishes it from siblings like 'purchase_credits' and 'get_credit_balance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'purchase_credits' or 'get_credit_balance'. The context of use is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_creditsCInspect
Instantly buy credits using a pre-saved Stripe payment method. CAUTION: This will charge the user's card immediately. Use only when balance is critical.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | The credit pack name (check list_credit_packs for prices). | |
| amount | No | Custom dollar amount (min $5). | |
| payment_method_id | Yes | Stripe PM ID (e.g., "pm_..."). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. Only states 'purchase credits immediately' and 'using saved payment method' – lacks details on side effects (e.g., payment charged, balance updated), reversibility, or failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but undermines completeness. Every word earns its place, but critical usage details are missing, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given sibling tools (e.g., create_checkout_session, enable_auto_reload, get_credit_balance), the description fails to clarify its specific role or what it returns. No output schema and no explanation of pack vs amount interaction leaves the agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description does not explain relationship between optional pack and amount parameters (e.g., whether both can be specified, or if pack implies a fixed amount). The description adds no value beyond schema for payment_method_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purchase credits immediately using saved payment method. Verb and resource are specific, but does not explicitly differentiate from sibling create_checkout_session, though 'immediately' implies a direct purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 create_checkout_session or enable_auto_reload. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_hiring_outcomeCInspect
Submit the final hiring decision (hired/rejected/withdrawn) for a candidate. Use this to close the loop and help refine the specialized AI models for future accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID. | |
| outcome | Yes | The final outcome of the candidate's journey. | |
| candidate_id | Yes | The candidate ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'report,' which suggests a write operation but does not confirm side effects, return values, or required permissions. The lack of detail leaves the agent uncertain about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and resource. While very concise, it sacrifices detail for brevity, which is acceptable for this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters and no output schema or annotations, the description lacks completeness. It does not explain what the tool returns, whether it triggers side effects, or how the outcome is used. The agent lacks sufficient context to predict the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the parameters are documented. The description does not add any additional meaning beyond what the schema provides. For example, it doesn't explain the implications of each outcome enum value. Thus, it meets the baseline but adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'report' and resource 'hiring outcome' clearly. It also mentions the purpose 'improve AI accuracy', which helps the agent understand the tool's goal. However, it could be more specific about what exactly is reported and to whom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions for use. There is no mention of prerequisites, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_webhookBInspect
Verify that a webhook endpoint is properly reachable and responds correctly. Use this during setup to ensure the user's server is ready for async notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The HTTPS webhook URL to test. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the tool tests reachability and response, but omits details like whether it sends a test event, expected HTTP response, error handling, timeouts, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no extraneous information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is partially complete. It explains the goal but lacks specifics about what 'responding' entails, potential error states, or expected outcomes. Could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'url'. The tool description adds no additional meaning beyond the schema's property description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Test' and resource 'webhook endpoint', with specific purpose 'verify it is reachable and responding'. This distinguishes it from all sibling tools, none of which test webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites, no conditions to avoid. The description only states what it does, implying usage solely based on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Validate the current API token and retrieve user profile, credit balance, and agent key limits. Use this as a "Health Check" at the start of every session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is a read operation ('verify', 'get') and returns profile and balance information, providing adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys all necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains the tool's purpose and what it returns, making it complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description needs no additional parameter information. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: verify API token and get profile/balance info. It distinguishes itself from sibling tools that focus on email generation, screening, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification and profile/balance retrieval but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!