FogBugz

Server Quality Checklist

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

Latest release: v0.9.8
Disambiguation5/5
Every tool has a clearly distinct purpose focused on specific resources and actions in the FogBugz domain. For example, create_case, update_case, close_case, and resolve_case handle different case lifecycle states without overlap, while list_projects, view_project, and create_project cover distinct project-related operations. The generic api_request is explicitly marked as an escape hatch, preventing confusion with dedicated tools.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_case, list_projects, update_case, and view_area. All tools use snake_case without deviation, and verbs like 'list', 'get', 'create', 'update', 'close', and 'search' are applied predictably across resources. This uniformity makes the toolset easy to navigate and understand.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a comprehensive issue-tracking system like FogBugz. It covers core CRUD operations for cases, projects, and areas, plus supporting functions like search, status/category listing, and user management. The scope is well-defined, though it borders on being extensive; each tool appears to earn its place without obvious redundancy.
Completeness5/5
The toolset provides complete CRUD and lifecycle coverage for the FogBugz domain. It includes create, read (get, list, search), update, and delete-like actions (close, resolve) for cases, along with project and area management. Supporting tools for categories, milestones, statuses, and people ensure no dead ends, and the generic api_request fills any potential gaps, making the surface highly complete for issue-tracking workflows.
Average 4.1/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about filtering by project ID and the purpose of finding target releases, but doesn't disclose additional behavioral traits like pagination, rate limits, or authentication needs. With annotations covering safety, this meets the baseline for adding some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and optional filter, and the second provides a concrete example. It's appropriately sized and front-loaded, making it easy to scan and understand quickly.
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 (one optional parameter, read-only, no output schema), the description is complete enough for basic use. It explains the purpose, filtering, and provides an example. However, it could benefit from mentioning output format or any limitations, though not strictly required since annotations cover safety.
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 the optional project ID parameter. The description mentions filtering by project ID and provides an example, but doesn't add significant meaning beyond what the schema provides (e.g., format details or constraints). Baseline 3 is appropriate when 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 ('Lists') and resource ('milestones (fix-for versions) in FogBugz'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling list tools like list_categories or list_projects, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example ('list all milestones for project 5 to find the right target release') that implies usage for release planning, but it doesn't explicitly state when to use this tool versus alternatives like search_cases or list_my_cases. No exclusions or clear alternatives are mentioned.
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?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the return content ('status names and whether each status counts as resolved') and an example of filtering, which are not covered by annotations. It does not disclose rate limits or auth needs, but with annotations, the bar is lower, and this adds useful 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 front-loaded with the core purpose, followed by optional features and an example. It uses two sentences efficiently, with no wasted words, making it easy to scan and understand quickly.
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, read-only), annotations cover safety, and the description adds return details and an example. However, there is no output schema, and the description does not fully explain return values like structure or pagination, leaving minor gaps. It is mostly complete 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 fully documents the optional 'ixCategory' parameter. The description adds minimal semantics by mentioning 'filter by category ID' and an example, but does not provide additional details like format or constraints beyond what the schema states. Baseline 3 is appropriate as the schema handles most of the burden.
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 ('Lists') and resource ('all case statuses defined in FogBugz'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_categories' or 'list_milestones' beyond the resource name, which is implied but not stated.
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 by mentioning optional filtering by category ID and provides an example ('list statuses for category 1 (Bug)'), which suggests context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'list_categories' or 'search_cases', and does not state 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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying it retrieves 'detailed information' and uses an example, but does not disclose additional behavioral traits like error handling, response format, or data scope beyond what annotations cover. No contradiction with 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 a brief, relevant example. Both sentences earn their place by clarifying the tool's function and usage, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, read-only, no output schema), the description is mostly complete. It covers the purpose and provides an example, but could improve by mentioning what 'detailed information' includes or potential errors. Annotations handle safety, so gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'ixArea' fully documented in the schema. The description adds minimal semantics by mentioning 'numeric ID' and providing an example, but does not significantly enhance understanding beyond the schema's description of 'The area ID to view'. Baseline score due to 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 verb ('Gets detailed information') and resource ('about a specific FogBugz area'), and distinguishes it from siblings like 'view_project' by specifying the resource type (area vs project). It provides a concrete example with ID 7, enhancing clarity.
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 details for a specific area ID, but does not explicitly state when to use this tool versus alternatives (e.g., 'list_projects' for broader listings) or any exclusions. It provides basic context but lacks explicit guidance on alternatives or edge cases.
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?
Annotations indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true), which the description aligns with by stating 'Creates'. The description adds context with an example but doesn't detail behavioral aspects like permissions needed, rate limits, or what happens on failure, though annotations cover the core safety profile.
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 a concise example that illustrates usage without unnecessary details. Every sentence adds value, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description provides basic purpose and an example but lacks details on return values, error handling, or system constraints. Annotations cover safety, but more context on outcomes or limitations would improve completeness given the tool's complexity.
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 parameters. The description's example mentions 'name' and 'primaryContact', adding minimal semantic context but not compensating for any gaps since there are none. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates a new project') and resource ('in FogBugz'), distinguishing it from siblings like 'list_projects' or 'view_project'. The example further clarifies the tool's function by showing typical usage.
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 through the example, suggesting this tool is for creating projects rather than listing or viewing them. However, it lacks explicit guidance on when to use this tool versus alternatives like 'api_request' or prerequisites for project creation.
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?
Annotations indicate this is a destructive write operation (readOnlyHint=false, destructiveHint=true). The description adds valuable context by specifying what 'resolves' means ('marks as fixed/completed') and provides an example showing comment usage, though it doesn't mention permissions, side effects, or rate limits.
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: one declarative statement of purpose, one concrete example. Zero waste, front-loaded with the core action, and the example efficiently demonstrates multiple parameters in context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 3 parameters and no output schema, the description adequately covers the basic operation but lacks details on response format, error conditions, or relationship to sibling tools. The example helps, but more context would be beneficial given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description's example mentions 'case 42' and comment 'Fixed in commit abc123', which reinforces parameter usage but doesn't add significant semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('resolves'), resource ('a FogBugz case'), and specific action ('marks as fixed/completed'). It distinguishes from siblings like 'close_case', 'reopen_case', and 'update_case' by specifying this is for resolution with status changes and comments.
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 an example that implies usage for marking cases as fixed/completed, but doesn't explicitly state when to use this vs. alternatives like 'close_case' or 'update_case'. No guidance on prerequisites or exclusions is given.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a mutation ('assigns'). The description adds context beyond annotations by specifying that the assignee can be identified by name or email, which is useful for understanding input format. However, it doesn't detail side effects like notifications or permission requirements.
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 a concise example. Both sentences earn their place by clarifying usage 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 (destructive mutation with 2 parameters), annotations cover safety aspects, and schema fully describes inputs. The description adds practical usage context with an example. However, without an output schema, it doesn't explain return values (e.g., success confirmation), leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal value by mentioning 'name or email' for the assignee, which is already covered in the schema's description. No additional syntax or constraints are provided beyond what the schema offers.
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 ('assigns') and resource ('a FogBugz case'), specifying it assigns to a specific user. It distinguishes from siblings like 'update_case' or 'resolve_case' by focusing solely on assignment functionality.
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 an example that implies usage when needing to assign a case, but it doesn't explicitly state when to use this tool versus alternatives like 'update_case' (which might handle assignments among other updates) or mention prerequisites (e.g., case must be open). No explicit exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true). The description adds value by specifying it's for FogBugz cases and includes an example, but doesn't disclose additional behavioral traits like authentication needs, rate limits, or what 'destructive' entails (e.g., irreversible creation). No contradiction with 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 a concise, illustrative example that reinforces usage. Every sentence earns its place 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 complexity (7 parameters, destructive write), annotations cover safety, and schema covers inputs well. However, without an output schema, the description doesn't explain return values (e.g., case ID or confirmation). It's mostly complete but could benefit from mentioning response details.
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 7 parameters. The description adds minimal semantics through the example (e.g., 'priority 2'), but doesn't provide extra meaning beyond what's in the schema. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates a new FogBugz case') and resource ('case'), and the example provides concrete differentiation from sibling tools like 'update_case' or 'assign_case' by showing it's for initial creation. It goes beyond just restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new cases, with the example suggesting typical scenarios (e.g., bug creation). However, it lacks explicit guidance on when to use this versus alternatives like 'update_case' for modifications or prerequisites (e.g., required permissions). The context is clear but not comprehensive.
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?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying it includes 'full event/comment history', which gives context on what data is returned beyond basic case info. However, it lacks details on behavioral traits like rate limits, authentication needs, or pagination, which are not covered by 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 and includes a practical example in the second sentence. Every sentence adds value without redundancy, making it efficient and 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 tool's low complexity (2 parameters, 1 required), 100% schema coverage, and readOnlyHint annotation, the description is mostly complete. It specifies the scope of returned data (details and history), but without an output schema, it could benefit from more detail on the return format. However, it adequately covers the tool's purpose and usage.
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 both parameters (caseId and cols). The description does not add any parameter-specific details beyond what the schema provides, such as explaining the default columns or format of 'cols'. Baseline 3 is appropriate as the schema handles 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 verb 'Gets' and resource 'detailed information about a specific FogBugz case', specifying it includes 'full event/comment history'. It distinguishes from siblings like 'list_my_cases' or 'search_cases' by focusing on a single case's details rather than listing or searching multiple cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'specific FogBugz case' and the example 'fetch all details and comments for case 42', suggesting it's for retrieving comprehensive data on an individual case. However, it does not explicitly state when not to use it or name alternatives like 'search_cases' for broader queries, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the output is a 'direct URL' for sharing, which is useful context beyond the annotations. However, it does not disclose additional behavioral traits like rate limits, authentication needs, or URL format specifics, keeping it at a baseline level.
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 a concise example. Both sentences earn their place by clarifying usage without redundancy, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, read-only), no output schema, and good annotations, the description is mostly complete. It covers the purpose and usage well but could benefit from minor additions like mentioning the URL format or any sharing constraints, slightly limiting 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%, with the parameter 'caseId' fully documented in the schema. The description adds minimal semantic context by implying the parameter is used to 'get the link for case 42', but does not provide additional details beyond what the schema already covers, aligning with the baseline 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 verb ('Returns') and resource ('a direct URL to a FogBugz case'), with a specific example that distinguishes it from siblings like 'get_case' (which likely returns case details rather than a URL). It explicitly mentions the sharing purpose ('can be shared with teammates'), making the purpose distinct and actionable.
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 get a link for case 42'), implying it's for sharing URLs rather than retrieving case data. However, it does not explicitly state when not to use it or name alternatives (e.g., 'get_case' for case details), which prevents a perfect score.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about default behavior (assignee defaults to current user if empty) and example usage, but does not disclose other behavioral traits like pagination, rate limits, or error handling beyond what annotations provide.
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 appropriately sized and front-loaded, with a clear purpose statement followed by specific examples. Every sentence earns its place by enhancing understanding without redundancy or unnecessary details.
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, rich schema coverage, and read-only annotation, the description is mostly complete. However, without an output schema, it could benefit from mentioning the return format (e.g., list of cases with key fields) to fully guide the agent, though the examples partially compensate.
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 documents all parameters thoroughly. The description adds minimal value by implying usage examples (e.g., 'active' for status, up to 20 for limit), but does not provide additional syntax or format details beyond the schema, meeting the baseline for high 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 specific action ('Lists FogBugz cases') and resource ('assigned to a specific user'), with explicit examples that distinguish it from sibling tools like 'search_cases' or 'get_case' by focusing on user-assigned listings rather than general searches or single-case retrieval.
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 usage with examples (e.g., listing active cases for a user or up to 20 for current user), but does not explicitly state when to use this tool versus alternatives like 'search_cases' or mention any exclusions, leaving some ambiguity in 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutation with destructive potential. The description adds context that it reopens cases, but does not disclose additional behavioral traits like permissions needed, rate limits, or what 'destructive' entails beyond the annotation. No contradiction with 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 a concise example that reinforces usage. Every sentence earns its place without waste, 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 complexity (a mutation with destructive hint), no output schema, and rich annotations, the description is mostly complete. It covers the purpose and provides an example, but could improve by adding more behavioral context (e.g., effects of reopening, error conditions). However, it adequately supports the structured data provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (caseId and comment). The description adds minimal value beyond the schema by providing an example ('reopen case 42 with comment "Issue reproduced on v2.1"'), but does not explain parameter interactions or constraints not in the schema. Baseline 3 is appropriate 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reopens' and the resource 'a previously closed or resolved FogBugz case,' making the action specific. It distinguishes from siblings like 'close_case' and 'resolve_case' by specifying the opposite operation on cases with those states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'previously closed or resolved' cases, providing clear context for when to use it. However, it does not explicitly state when not to use it (e.g., for open cases) or name alternatives like 'update_case' for other modifications, missing full 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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about search syntax and examples, but doesn't disclose behavioral traits like pagination, rate limits, or authentication requirements beyond what annotations provide.
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 front-loaded with the core purpose, followed by three specific examples that each demonstrate different search patterns. Every sentence earns its place by illustrating practical usage without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with good annotations (readOnlyHint) and comprehensive schema coverage, the description provides sufficient context about search syntax and examples. The main gap is the lack of output schema, but the description compensates somewhat by showing what types of results to expect through the examples.
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 provides helpful examples of query syntax but doesn't add significant semantic meaning beyond what's in the schema descriptions. 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.
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 ('Searches for FogBugz cases') and resource ('FogBugz cases'), distinguishing it from siblings like get_case (single case retrieval) or list_my_cases (pre-filtered list). It explicitly mentions the search syntax, which differentiates it from simpler listing 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?
The description provides clear context about when to use this tool (searching with FogBugz syntax) through multiple examples. However, it doesn't explicitly state when NOT to use it or mention alternatives like list_my_cases for a user's own cases or get_case for single-case retrieval by ID.
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?
Annotations already declare readOnlyHint=true, indicating this is a safe read operation. The description adds value by specifying it retrieves 'detailed information' and provides an example, but doesn't disclose additional behavioral traits like error handling, response format, or authentication needs. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a helpful example. Every sentence earns its place by clarifying the tool's function and usage without unnecessary details.
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 (single required parameter), high schema coverage, and read-only annotation, the description is mostly complete. It lacks output schema, so it doesn't explain return values, but for a simple lookup tool, the description adequately covers purpose and usage without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'ixProject' fully documented in the schema as 'The project ID to view'. The description adds minimal value beyond this by mentioning it's a 'numeric ID' and giving an example, but doesn't provide additional semantics like valid ranges or constraints.
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 ('Gets detailed information') and resource ('about a specific FogBugz project'), specifying it requires a numeric ID. It distinguishes from siblings like 'list_projects' (which lists multiple projects) and 'get_case' (which retrieves case information rather than project 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?
The description provides clear context by stating this tool is for viewing a specific project by its ID, implying it should be used when you need details for one known project. It doesn't explicitly mention when not to use it or name alternatives, but the context differentiates it from list_projects (for browsing) and create_project (for creation).
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by describing a write operation that changes case status. The description adds context beyond annotations by specifying the closure status ('will not fix / done') and providing an example with a comment, though it lacks details on permissions 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?
The description is front-loaded with the core action, followed by a concise example that illustrates usage. Both sentences are necessary and efficient, with no redundant information, making it easy to scan and understand quickly.
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 (destructive mutation with 2 parameters), annotations cover safety aspects, and schema fully describes inputs. The description adds useful context on closure status and an example, but lacks output details (no schema) and could clarify more on behavioral traits like error conditions.
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 both parameters. The description adds minimal value by mentioning a comment example, but does not provide additional semantics or constraints beyond what the schema already states (e.g., caseId is numeric, comment is plain text).
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 ('Closes') and resource ('a FogBugz case'), and specifies the action's effect ('marks it as will not fix / done'). It distinguishes from siblings like 'reopen_case' and 'resolve_case' by focusing on final closure with specific status implications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for final case closure (e.g., 'will not fix / done'), suggesting it's for completed or abandoned cases. However, it does not explicitly state when to use this versus alternatives like 'resolve_case' or 'update_case', nor does it mention prerequisites or exclusions.
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?
Annotations provide readOnlyHint=true, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations by specifying what gets returned (category IDs and names) and providing example categories. However, it doesn't mention potential limitations like pagination or rate limits.
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 zero waste: first states purpose with examples, second specifies return values. Perfectly front-loaded and appropriately sized for a simple list operation with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and good annotations, the description is nearly complete. It covers purpose, examples, and return format. The main gap is lack of output schema, but the description compensates by specifying return values. Slightly more context about ordering or completeness would make it perfect.
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 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on output semantics. This is efficient and avoids redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('all case categories defined in FogBugz'), provides specific examples (Bug, Feature Request, Inquiry), and distinguishes from siblings by focusing on categories rather than cases, projects, or people. This is a specific verb+resource combination with clear differentiation.
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 category IDs and names, but doesn't explicitly state when to use this tool versus alternatives like list_statuses or list_milestones. There's no guidance on prerequisites or exclusions, leaving usage context to inference rather than explicit direction.
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?
Annotations indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true). The description adds valuable context beyond annotations by specifying that it updates 'existing' cases (implying caseId is required) and provides concrete examples of field changes. It also mentions API limitations (plain text only for description, no HTML/Markdown), which isn't covered by 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 two sentences: the first states the purpose clearly, and the second provides concrete, relevant examples. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, 100% schema coverage, and destructive annotations, the description is reasonably complete. It covers the tool's purpose, examples of use, and API constraints. However, without an output schema, it doesn't describe what the tool returns (e.g., success confirmation or updated case data), which is a minor gap given the 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%, with each parameter well-documented in the schema itself. The description adds minimal parameter semantics beyond the schema—it mentions examples like changing title or milestone, which align with schema fields but don't provide additional syntax or format details. Baseline 3 is appropriate given 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 verb ('Updates') and resource ('an existing FogBugz case') with specific examples of what can be changed (title, milestone, comment). It distinguishes from sibling tools like create_case (for new cases) and close_case/reopen_case/resolve_case (for state changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through examples (changing title, moving to milestone, adding comments), which suggests this is for modifying case properties. However, it doesn't explicitly state when to use this vs. alternatives like assign_case (for reassignment) or close_case (for state transitions), nor does it mention prerequisites like required permissions.
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?
Annotations provide readOnlyHint=true, which the description aligns with by describing a listing operation. The description adds valuable behavioral context beyond annotations: it specifies that only 'active (non-deleted)' projects are included, which is not inferable from annotations alone. However, it doesn't mention pagination, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the tool's purpose and scope, and the second provides a practical usage example. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
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 (0 parameters, read-only), annotations cover safety, and the description provides clear purpose, usage, and behavioral details (active projects only). However, without an output schema, the description doesn't specify the exact return format (e.g., array structure, pagination), leaving a minor gap for an agent invoking it.
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 0 parameters, and schema description coverage is 100%. The description correctly states no parameters are needed ('Lists all...'), which aligns with the empty schema. Since there are no parameters, the baseline is 4, and the description doesn't add or detract from 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 action ('Lists'), resource ('all active (non-deleted) projects in FogBugz'), and output format ('with their IDs and names'). It distinguishes from siblings like 'view_project' (detailed view) and 'create_project' (write operation) by specifying it's a comprehensive listing of active projects only.
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 when to use this tool: 'to find the correct project ID before creating a case.' This gives a clear use case and distinguishes it from alternatives like 'view_project' (for detailed info on a specific project) or 'search_cases' (for filtering cases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. While annotations indicate destructiveHint=true and readOnlyHint=false, the description explicitly warns: 'WARNING: Can execute any API command the configured key permits, including destructive operations (delete, edit users, bulk modify).' This provides concrete examples of destructive operations and clarifies the broad permission scope, which annotations alone don't specify.
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 with zero waste: it opens with the core purpose, immediately provides critical warnings, gives usage guidelines, and concludes with concrete examples. Every sentence serves a distinct purpose, and the information is appropriately front-loaded with the most important warnings first.
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 as a generic API escape hatch with destructive capabilities and no output schema, the description provides excellent contextual completeness. It covers purpose, warnings, usage boundaries, and examples, compensating for the lack of output schema by illustrating potential use cases. The combination with annotations creates a comprehensive understanding.
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?
With 100% schema description coverage, the baseline is 3. The description adds some value by providing examples of cmd values (listProjects, listCategories, search) and params usage, but doesn't fundamentally enhance understanding beyond what's already documented in the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'generic XML API escape-hatch for FogBugz commands not covered by dedicated tools,' specifying both the verb (execute API commands) and resource (FogBugz). It explicitly distinguishes this from sibling tools by mentioning 'commands not covered by dedicated tools' and listing specific sibling tools in examples.
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 vs alternatives: 'Prefer specific tools when available; use this only when no dedicated tool fits the need.' It includes examples of commands that might be used with this tool, reinforcing the boundary between dedicated and generic tools.
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?
Annotations declare readOnlyHint=true, which the description aligns with by implying a safe read operation ('Lists'). The description adds value by specifying the returned fields (IDs, names, emails) and the tool's utility for assignee lookup, which annotations don't cover. No contradictions exist, and it provides useful behavioral context beyond 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?
Two sentences with zero waste: the first states what the tool does and what it returns, the second explains when to use it. It's front-loaded with core functionality and efficiently structured, making every sentence earn its place.
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 low complexity (0 parameters, read-only), annotations cover safety, and the description clearly explains purpose, usage, and output fields. No output schema exists, but the description specifies returned data (IDs, names, emails), making it complete for this context without over-explaining.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. A baseline of 4 is applied for zero parameters, as it avoids unnecessary details and focuses on the tool's purpose.
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 ('Lists') and resource ('all people (users) in FogBugz'), specifies the returned fields ('IDs, names, and email addresses'), and distinguishes from siblings by focusing on user data rather than cases, projects, or other entities. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: 'Useful for finding the correct assignee name or ID before creating or updating a case.' This provides clear context and ties usage to sibling tools like create_case or update_case, offering practical guidance without being misleading.
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:

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

Score Badge

Copy to your README.md:

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

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