HaloPSA MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some overlap that could cause confusion, particularly between halopsa_list_tables/halopsa_list_columns/halopsa_table_info for database exploration and halopsa_list_api_endpoints/halopsa_search_api_endpoints/halopsa_get_api_endpoint_details for API discovery. However, the descriptions help clarify their specific purposes, preventing complete ambiguity.
Naming Consistency5/5
All tools follow a consistent halopsa_verb_noun naming pattern with clear, descriptive names. The structure is uniform throughout the set, making it easy to predict tool purposes and maintain readability.
Tool Count5/5
With 10 tools, the count is well-scoped for a server focused on database and API interaction for HaloPSA. Each tool serves a distinct role in the workflow, from discovery to execution, without feeling excessive or insufficient.
Completeness4/5
The toolset covers essential workflows for database querying and API interaction, including discovery, schema inspection, and execution. Minor gaps exist, such as no direct tools for data modification (e.g., insert/update) or advanced API operations beyond calls, but agents can work around these using the provided tools.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool 'ensures proper syntax' and is for 'constructing' queries, implying it's a read-only helper without execution. However, it lacks details on behavioral traits such as error handling, output format (e.g., returns a query string), or any limitations (e.g., complexity constraints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence states the core purpose, and the second adds context on utility and scope. Every sentence earns its place without redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects and output (e.g., what the built query looks like). Without annotations or output schema, more context on results would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema, mentioning 'SELECT queries with WHERE conditions, ORDER BY, and LIMIT clauses,' which aligns with parameters like 'conditions,' 'orderBy,' and 'limit.' This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a basic SQL query for HaloPSA with a helper that ensures proper syntax.' It specifies the action (build SQL query) and resource (HaloPSA), and distinguishes it from raw SQL writing. However, it doesn't explicitly differentiate from sibling tools like 'halopsa_query' which might execute queries.
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 provides implied usage guidance: 'Useful for constructing simple SELECT queries with WHERE conditions, ORDER BY, and LIMIT clauses.' This suggests when to use it (for simple queries) but doesn't explicitly state when not to use it or mention alternatives among sibling tools like 'halopsa_query' for execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination behavior and that it 'Shows the structure,' implying a read-only operation, but lacks details on permissions, rate limits, error handling, or response format. It adds some context but leaves significant behavioral traits unspecified.
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 front-loaded with the core purpose in the first sentence, followed by supporting details. It uses three concise sentences with zero waste, though it could be slightly more structured by explicitly separating purpose from features.
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 4 parameters with full schema coverage but no annotations or output schema, the description is adequate for a read operation but incomplete. It covers purpose and pagination but lacks details on authentication, errors, or return values, leaving gaps for an AI agent to invoke it correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific semantics beyond what's in the schema (e.g., no extra examples or constraints), resulting in a baseline score of 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('API schemas/models from the swagger definition') with specific scope ('structure of request/response objects used by the API endpoints'). It distinguishes from siblings like halopsa_list_api_endpoints by focusing on schema structure rather than endpoint listing, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding API object structures, but provides no explicit guidance on when to use this tool versus alternatives like halopsa_get_api_endpoint_details or halopsa_search_api_endpoints. The mention of pagination support hints at context for large datasets, but lacks clear when/when-not directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('detailed column information including data types, max length, and nullable status'), which is helpful behavioral context. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys purpose, method, and return details without waste. It's appropriately sized and front-loaded with the core action.
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 moderate complexity (2 parameters, read-only operation), no annotations, and no output schema, the description is reasonably complete. It covers purpose, method, and return format, but could improve by addressing authentication or error handling. The lack of output schema is partially compensated by describing return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't clarify tableName format beyond examples or columnFilter matching behavior). Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('List columns') and resource ('for a specific table in the HaloPSA database'), and distinguishes from siblings like halopsa_list_tables (which lists tables) and halopsa_table_info (which may provide different table metadata). The mention of 'using information_schema.columns' adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing column details for a table, but doesn't explicitly state when to use this tool versus alternatives like halopsa_get_api_schemas or halopsa_query. It mentions the source (information_schema.columns) which provides some context, but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's behavior by specifying it returns 'full report response with data rows, column metadata, and available filters', which is valuable. However, it lacks details on permissions, rate limits, error handling, or data modification risks (though 'retrieve' implies read-only).
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 efficiently structured in two sentences: the first states the purpose and scope with examples, the second details the return format. Every sentence adds value without redundancy, making it front-loaded and appropriately sized.
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 complexity (executing arbitrary SQL queries) and lack of annotations and output schema, the description is reasonably complete. It covers purpose, usage context, and return structure. However, it could benefit from more behavioral details like safety warnings or limitations, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any parameter-specific information beyond what the schema provides (e.g., no extra syntax details or usage examples for parameters). Baseline 3 is appropriate when schema does all the work.
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 specific action ('Execute a SQL query') and target resource ('against HaloPSA reporting API'), with explicit examples of retrievable tables (tickets, users, sites, etc.). It distinguishes from siblings by focusing on direct SQL execution rather than query building or API endpoint management.
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 clear context for when to use this tool ('to retrieve data from any HaloPSA table'), but does not explicitly state when not to use it or name specific alternatives among the sibling tools. The implied usage is strong but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's function well but lacks details on potential limitations like rate limits, authentication requirements, error handling, or whether it's read-only (implied by 'Get' but not explicit). It adds value by specifying the type of metadata returned, but more behavioral context would be helpful.
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 efficiently structured in two sentences: the first states the purpose and details, and the second provides usage guidance. Every sentence adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
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 moderate complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers the purpose, usage context, and metadata details, but lacks information on output format or behavioral traits like error cases. With no output schema, some guidance on return values would enhance completeness, but it's adequate for a schema inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'tableName' well-documented in the schema. The description doesn't add any additional meaning beyond what the schema provides, such as examples or constraints not in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 specific action ('Get detailed information') and resource ('about a specific HaloPSA table'), with explicit details about what information is retrieved ('all columns, data types, nullable fields, and relationship suggestions'). It distinguishes from siblings like halopsa_list_tables (which lists tables) and halopsa_list_columns (which lists columns without detailed metadata).
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 clear context for when to use this tool ('to understand table structure before writing queries'), which implicitly suggests it's for schema exploration rather than data retrieval. However, it doesn't explicitly state when not to use it or name specific alternatives among the siblings, such as halopsa_get_api_schemas or halopsa_list_columns for different needs.
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 authentication ('authenticated API calls') and hints at behavioral context by referencing schema tools for endpoint discovery. However, it lacks details on rate limits, error handling, response formats, or specific authentication methods, which are important for a general-purpose API call tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, consisting of two sentences that efficiently convey the tool's purpose and usage guidelines without any wasted words. Every sentence adds value, making it easy for an agent to understand the tool's role quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (general API calls with 4 parameters) and lack of annotations and output schema, the description is somewhat complete but has gaps. It covers purpose and usage well but omits details on authentication specifics, response handling, and error scenarios, which are crucial for effective tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (path, method, body, queryParams). The description adds no additional parameter semantics beyond what the schema provides, such as examples of common endpoints or guidance on when to use body vs. queryParams. This meets the baseline of 3 for high 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 the tool's purpose: 'Make authenticated API calls to any HaloPSA endpoint.' It specifies the verb ('Make authenticated API calls') and resource ('any HaloPSA endpoint'), and distinguishes it from siblings by mentioning 'after finding the right endpoint with schema tools,' which references tools like halopsa_get_api_endpoint_details or halopsa_search_api_endpoints.
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 provides explicit usage guidance: 'Use this after finding the right endpoint with schema tools.' This indicates when to use this tool (for making API calls) versus alternatives (schema tools for endpoint discovery), and it names sibling tools implicitly, offering clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's function and workflow context, but lacks information about potential side effects, authentication requirements, rate limits, or error handling. The description doesn't contradict any annotations (none exist), but doesn't provide comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences. The first sentence clearly states the purpose and scope, while the second provides crucial usage guidance. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description provides adequate but not complete context. It explains the tool's purpose and usage timing well, but lacks information about response format, error conditions, or performance characteristics that would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get complete details') and resource ('specific API endpoints'), with explicit mention of what details are included (parameters, schemas, examples). It distinguishes from the sibling tool 'halopsa_list_api_endpoints' by specifying this is for detailed information after using that tool for discovery.
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 provides explicit guidance on when to use this tool ('Use after finding endpoints with halopsa_list_api_endpoints'), creating a clear workflow dependency. It also implies when not to use it (e.g., for initial endpoint discovery rather than detailed examination), though it doesn't name all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that it 'Returns a complete list of all tables that can be queried,' which adds some behavioral context about the output. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with no annotation coverage.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance. Both sentences earn their place by providing essential information without redundancy, making it appropriately sized and efficient.
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 low complexity (1 optional parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and output intent, but could improve by mentioning any limitations or dependencies, though it's adequate for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the optional 'filter' parameter with an example. The description does not add any parameter-specific information beyond what's in the schema, such as how the filter is applied or its impact on results, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available tables in the HaloPSA database'), specifying it queries sys.tables. It distinguishes from siblings like halopsa_list_columns (which lists columns) and halopsa_table_info (which provides table details), making the purpose specific and differentiated.
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?
It explicitly states when to use this tool: 'Use this to discover what data is available before writing queries.' This provides clear context for usage, distinguishing it from querying tools like halopsa_query or halopsa_build_query, and implies it's a preliminary step.
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 of behavioral disclosure. It adds useful context beyond basic functionality: it mentions that results include 'basic info' (not full details), supports pagination, and implies a search scope (keywords). However, it lacks details on permissions, rate limits, error handling, or the exact structure of 'basic info', which are gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by key behavioral details (returns basic info, alternative tool, pagination support) in subsequent sentences. Each sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 moderate complexity (search with pagination), no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage guidelines, and key behaviors (pagination, basic info vs. full details). However, it lacks details on output format or error cases, which could be improved for full completeness in the absence of structured output data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all parameters (query, limit, skip). The description adds minimal value beyond the schema: it implies the 'query' parameter searches across multiple fields (paths, summaries, etc.), but this is not explicitly stated. With high schema coverage, the baseline is 3, and the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for API endpoints by keywords') and resource ('API endpoints'), distinguishing it from siblings like 'halopsa_list_api_endpoints' (which likely lists all without search) and 'halopsa_get_api_endpoint_details' (which provides full details for specific endpoints). The verb 'search' is precise and differentiates the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by stating 'Use halopsa_get_api_endpoint_details for full details of specific endpoints', which clearly indicates when to use this tool (for searching) versus an alternative (for getting full details). This direct comparison to a sibling tool enhances decision-making for the AI agent.
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 of behavioral disclosure. It effectively describes key behaviors: it's a discovery tool for listing endpoints, supports pagination (implying it can handle large result sets), and is non-destructive (implied by 'list'). However, it doesn't specify rate limits, authentication needs, or error handling, which are minor gaps.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance and a key behavioral trait (pagination) in subsequent sentences. Every sentence adds value without redundancy, making it efficient and well-structured.
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 moderate complexity (listing endpoints with filtering and pagination), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and pagination, but lacks details on output format (e.g., structure of returned data) and error cases, which would be helpful for an agent to interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all three parameters (category, limit, skip). The description adds no additional parameter semantics beyond what the schema already covers, such as examples or usage nuances. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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 specific action ('List all API endpoints') and resources involved ('paths, methods, and summaries'), distinguishing it from siblings like halopsa_get_api_endpoint_details (which provides full details) and halopsa_search_api_endpoints (which presumably searches rather than lists all). The verb 'list' is precise and the scope 'all' is explicitly defined.
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 provides explicit guidance on when to use this tool ('Use this first to discover available endpoints') and when to use an alternative ('then use halopsa_get_api_endpoint_details for full details'). It also mentions pagination support, which helps in understanding its context for handling large datasets.
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:

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

Score Badge

Copy to your README.md:

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

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