hawksoft-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: create_attachment, create_log_note, create_receipts for different logging operations; get_client and get_clients_bulk for client retrieval (single vs. bulk); list_agencies, list_channels_tool, list_offices for different listings; search_client_by_policy for policy-based search; and list_changed_clients for sync. No two tools have overlapping purposes.
Naming Consistency4/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., create_log_note, get_client, list_agencies). The only minor deviation is list_channels_tool which appends '_tool', but it is still readable and clearly indicates its purpose.
Tool Count5/5
With 10 tools, the set is well-scoped for a HawkSoft server covering client retrieval, logging activities (notes, attachments, receipts), and listing utilities (agencies, offices, channels, changed clients). Each tool earns its place without being excessive or sparse.
Completeness4/5
The core workflows are covered: retrieving clients (single, bulk, by policy), adding log notes, attachments, and receipts, and listing supporting entities. Minor gaps exist, such as no update or delete operations for logs or client data, but agents can likely accomplish typical tasks without dead ends.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as read-only nature, pagination, or error conditions. The description carries full burden but offers minimal transparency beyond the basic listing 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?
Extremely concise with a clear structure. The description is front-loaded with the core action, followed by a parameter explanation in a single line. 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?
Given the presence of an output schema, return values are covered. The description covers the single parameter adequately but lacks behavioral and usage guidance. For a simple list tool, it is minimally complete but could be better.
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%, but the description adds value by indicating agency_id comes from list_agencies. However, it does not fully compensate for the lack of parameter detail, as the schema already shows type and requirement.
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 'List offices configured under an agency,' providing a specific verb and resource. It distinguishes from sibling tools like list_agencies or list_changed_clients, but without explicit differentiation, it is very clear but not maximally distinct.
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 (e.g., list_agencies). The description does not specify prerequisites or exclusions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that by default it returns all sections and that 'include' can narrow the response. However, it does not mention permissions, rate limits, or any side effects, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. Every sentence adds value, and the Args section provides necessary parameter details. It is well-structured for quick understanding.
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 existence of an output schema, the description adequately covers return behavior (full client object by default). It also provides context via siblings, making it clear when to use this tool. Minor omissions like error handling are acceptable for a single-fetch tool.
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?
With 0% schema description coverage, the description explains all three parameters: agency_id as 'HawkSoft agency ID', client_id as 'HawkSoft client number', and include listing possible sections (details, people, contacts, claims, policies, invoices). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch full details for a single client', using a specific verb and resource. It distinguishes itself from the sibling 'get_clients_bulk' by focusing on a single client.
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 clearly indicates this tool is for a single client, implicitly contrasting with 'get_clients_bulk'. It also provides guidance on using 'include' to narrow responses and save bandwidth. No explicit exclusions are given, but the context is sufficient.
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?
The description discloses key behaviors: returns all clients (usually 1) holding the policy, exact match only. Since no annotations are provided, the description carries the full burden, and it adequately covers the tool's safety (read-only search) and result characteristics. It does not mention authentication or rate limits, but those are less critical for a search 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 concise, with a clear opening sentence and a bulleted Args section. It is front-loaded with the core purpose and constraints. Every sentence adds value, though the Args descriptions could be slightly more structured (e.g., using a list format is already good).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, 2 required, output schema present), the description covers the essential aspects: purpose, exact match behavior, typical result count, and parameter explanations. It lacks detail on the 'include' parameter's possible values, but otherwise is complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The 'Args' block briefly explains agency_id and policy_number, adding context beyond schema titles (e.g., 'HawkSoft agency ID', 'Exact policy number'). However, the 'include' parameter is only described as 'Sections to include,' which is vague and adds little meaning. More detail on what values 'include' accepts would improve semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Find a client by exact policy number match.' It specifies the exact match requirement and the use case (agent has policy number but not HawkSoft client number). This distinguishes it from sibling tools like get_client which require a client number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful when an agent has a policy number from a carrier but not the HawkSoft client number.' It also specifies limitations ('Exact match only — no partial or fuzzy search'). However, it does not explicitly mention when not to use or suggest alternative tools, which would elevate the score to 5.
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 provided; description mentions the request limit but omits read-only nature, error handling, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus parameter list: front-loaded and concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values need not be described; description covers key aspects but could add error handling or auth requirements.
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?
Adds domain context for agency_id ('HawkSoft agency ID') and client_numbers range (1-200), despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches multiple clients in one call with a limit of 200, distinguishing it from sibling 'get_client' for single records.
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 implicitly guides usage via the 'bulk' vs 'get_client' naming, but lacks explicit when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns client IDs (not full objects) and the effect of omitting `as_of`. However, it lacks details on potential rate limits, authentication needs, or behavior on invalid inputs. Adequate but not comprehensive.
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?
Concise and well-structured: starts with a one-line summary, then expands on usage and parameters in a docstring format. No extraneous information; every sentence adds value.
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 existence of an output schema, the description does not need to explain return values. It covers all four parameters and the core use case. Could mention pagination or error handling, but overall complete for a list tool with sibling references.
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 coverage is 0%, so the description compensates well. It explains the purpose of each parameter: `as_of` as an ISO 8601 timestamp (optional for full list), `office_id` to restrict to an office, and `include_deleted` for soft-deleted clients. The description adds meaning beyond the schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists client IDs changed since a timestamp, using specific verb 'list' and resource 'client IDs that changed'. It distinguishes itself from siblings like `get_client` and `get_clients_bulk` by indicating the output is IDs only, and suggests using those tools for full details.
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?
Explicitly identifies it as 'The workhorse for syncing' and instructs to pass an `as_of` timestamp for incremental changes or omit for full list. It also directs to use `get_client` or `get_clients_bulk` on each ID afterward, providing clear usage context. Does not explicitly state when not to use, but the guidance is sufficient.
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?
No annotations, so description carries full burden. Discloses important behavioral details: file_b64 must not have 'data:' URL prefix; ref_id is optional and auto-generated; lists all optional task-related fields. Could mention idempotency behavior or side effects, but overall effective.
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?
Starts with a one-sentence purpose, then uses a clear 'Args:' list format. Each parameter is explained concisely. No extraneous text.
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?
Covers all 16 parameters with meaningful descriptions. Output schema exists, so return values are not needed. Lacks file size limits or accepted MIME types, but overall complete for an attachment creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description provides explicit purpose for each of the 16 parameters (e.g., 'channel: Channel name or LogAction int ...', 'file_b64: Base64-encoded file contents — NO data: URL prefix'). This fully compensates for missing 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?
Clearly states the action ('attach'), input type ('base64-encoded file'), allowed file types ('PDF, image, doc'), and target ('client record'). Distinguishes from sibling tools like create_log_note and create_receipts by focusing on file attachment.
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?
Does not explicitly state when to use this tool versus alternatives. The purpose is implied (when attaching a file), but no 'when not to use' or comparison to siblings is provided.
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?
No annotations are provided, so the description fully carries the burden. It states the tool is read-only (returns a list) and explains the return value (array of integer agency IDs representing subscribed agencies). This is transparent enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second adds return format and meaning. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no annotations, and an output schema, the description sufficiently explains what the tool does and what it returns. It covers the essential context for selecting and invoking this tool.
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?
There are zero parameters, so the description doesn't need to add parameter information. According to calibration, 0 params warrants a baseline of 4.
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 ('List') and resource ('agency IDs that have subscribed'), clearly distinguishing it from sibling tools like 'list_offices' (likely lists offices within an agency) and 'list_channels_tool' (likely lists channels).
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 should be used to retrieve subscribed agency IDs, but does not explicitly state when to use it versus alternatives like 'list_offices' or list_changed_clients.
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?
No annotations provided, so description carries full burden. It reveals that the tool appends a log note, can create follow-up tasks, and supports idempotency via ref_id. It does not detail auth requirements or failure modes, but provides sufficient behavioral context for an agent.
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?
Description is moderately long but well-structured: purpose first, then usage guidance, then parameter list. The parameter list is in plain text but clear. Could be more structured (e.g., bullets), but not verbose.
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?
With 16 parameters and 5 required, the description covers each parameter and provides usage context. Since an output schema exists, return values don't need explaining. Some behavioral details are missing but overall complete enough for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description includes an 'Args' section that explains all 16 parameters with context (e.g., 'Unique UUID for idempotency', 'Friendly channel name'). This fully compensates for the lack of schema descriptions, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool appends a log note and optional follow-up task to a client record. It is explicit that this is the primary write tool for logging agent actions, distinguishing it from other tools.
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?
Description explicitly says 'call this whenever the agent does anything that should be visible in HawkSoft' and lists examples (phone call, email, etc.). However, it does not contrast with sibling tools like create_attachment, so some differentiation is missing. Strong guidance overall.
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 full burden. It discloses that a log note is automatically created and linked, and optionally a task. This is good behavioral disclosure. However, it does not mention potential side effects like idempotency, validation rules, or whether receipts can be modified after creation. Still, the provided information is solid for a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The main purpose is front-loaded, followed by a bulleted Args section that organizes parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating multiple receipts with nested objects and side effects) and the presence of an output schema, the description is very complete. It covers all required and optional parameters, the receipt structure, and automatic behaviors. It lacks only minor details like error conditions, but overall it's sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 thoroughly describes the `receipts` parameter structure: required fields (channel, logNote, total, invoices) and optional fields (refId, ts, policyId, officeId, payMethod, task). It also explains `agency_id` and `client_id` as HawkSoft identifiers. This provides crucial meaning beyond the bare 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 tool's purpose: 'Record one or more payments received by a client.' It specifies that each receipt applies to invoices, automatically creates a log note, and optionally creates a follow-up task. This distinguishes it from sibling tools like create_log_note or create_attachment, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives. It implies usage for recording payments, but lacks guidance on when not to use it (e.g., for simple note logging, use create_log_note). Context is clear but no exclusions or alternatives are provided.
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, the description carries full burden. It accurately describes the tool as read-only (returning data) and specifies the exact count and content (codes, names, categories). It does not mention authentication or rate limits, but given the simplicity, it is sufficiently transparent.
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 sentences. The first states what the tool returns, the second explains usage. No unnecessary words, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (as indicated by context signals), the description is fully complete. It explains the purpose, the data returned, and how to use the result with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. The description adds no additional parameter info, but none is needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all 56 HawkSoft channel codes with friendly names and categories. It uses a specific verb ('return') and resource ('channel codes'), and distinguishes from sibling tools which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool to discover the channel value for create_log_note, create_attachment, or create_receipts. This provides clear when-to-use guidance with concrete examples.
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:

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

Score Badge

Copy to your README.md:

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

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