@sixty-sh/mcp

Official

by sixty-sh

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct phase of the finding lifecycle: list, view, claim, close, plus service health and installation. No overlap exists between the six tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (list_findings, get_finding, claim_finding, close_finding, check_service, install_sixty). This is a model of uniform naming.
Tool Count5/5
Six tools perfectly cover the core workflow of a performance-findings service: listing, inspecting, claiming, closing, plus setup and telemetry checks. None are redundant and none are missing.
Completeness5/5
The tool surface provides complete lifecycle coverage for findings (list, get, claim, close) and addresses operational needs (service health, installation). The only theoretical gap would be manual finding creation, which is outside the product's purpose since findings are auto-generated.
Average 4.4/5 across 6 of 6 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains that the tool fetches instructions rather than performing an install, and it warns that 'putting it in the wrong place fails silently'. However, it does not explicitly state whether the operation is read-only, what the output format is, or any error conditions. The warning about silent failure 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 two sentences long and front-loads the primary action. The second sentence provides important context about how to use the fetched instructions, including a failure mode warning, without any filler. Every phrase earns its place.
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 tool that fetches instructions, the description covers the key contextual nuances: the instructions are project-kind dependent, they should be followed against a readable repository, and they name outcomes rather than file paths. It does not describe the output format or handling of edge cases, but the tool's simplicity and lack of output schema make the description reasonably complete.
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 already provides extensive detail for both parameters (100% coverage), so the description does not repeat that. It adds value by advising to omit 'kind' to list options, which enhances parameter usability. It does not add anything for 'service', but the schema already covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches install instructions from the collector for the project kind, which distinguishes it from the sibling tools that manage findings and services. The verb is specific ('Fetch') and the resource is 'install instructions', though the title 'Install the sixty agent' suggests a more direct action than fetching instructions, slightly muddying the purpose.
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 a practical usage hint ('Call with no kind to see the options') and explains how the instructions are meant to be followed, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tools are clearly about findings, so the differentiation is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses behavioral details like ranking by severity and returning IDs, but does not explicitly state whether the operation is read-only or has side effects, nor mention pagination or limits beyond what the schema provides.
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 front-loaded, with each sentence earning its place: it defines the resource, gives a ranking detail, specifies when to use it, and notes the return value. No fluff 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 has 6 parameters and no output schema, the description provides sufficient context for a list operation: what it lists, how it's ranked, when to use it, and that it returns IDs for subsequent lookups. It does not detail the full response shape, but the mention of IDs is a key missing piece, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the baseline is 3. The tool description adds conceptual context for the 'class' parameter by explaining drift vs. pattern in plain language, but the schema already provides similar detail for each parameter, so the description adds limited incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists performance findings surfaced by sixty, distinguishing between regressions and standing problems. It also notes findings are ranked by severity and returns IDs, making its purpose unmistakable and differentiating it from siblings.
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 explicitly says 'Start here when asked to find or fix performance problems, N+1 queries, slow endpoints, or regressions,' providing clear when-to-use guidance. It also suggests passing returned IDs to get_finding, implying a workflow, though it lacks explicit when-not-to-use or alternative exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses three diagnostic outcomes (never reported, stopped, no release attached) and warns about a misleading healthy-looking case. However, it does not describe the exact output format or side effects, but being a check, it is likely 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?
Two concise, information-dense sentences. The first sentence states the core purpose; the second adds crucial diagnostic detail and usage context. Every word earns its place.
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?
The tool has a simple one-parameter signature, and the description covers typical usage scenarios and caveats. It lacks an output schema but the description explains the diagnostic categories, making it fairly complete for its simplicity.
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% and thoroughly explains the parameter, so the description does not need to add param details. The description adds no additional parameter semantics, which is acceptable given the rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether telemetry is arriving and diagnosing why it isn't. It distinguishes from siblings by focusing on service telemetry health, not findings or installation.
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?
Explicitly tells when to use: 'after installing, and any time the feed is empty and that seems surprising.' This provides strong contextual guidance and implies alternatives are for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It details what information will be returned (exact measurement, every stack frame, normalized SQL, child operations, related root causes, and typical causes). However, it does not explicitly state that it is read-only or mention error handling, though the informative nature is clear.
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 front-loads the comprehensive content list, and the second gives actionable guidance. No unnecessary words; every phrase earns 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 simplicity of the tool (one parameter, no output schema), the description is remarkably complete. It enumerates the key content categories and provides usage context, making it sufficient for an agent to understand what will be returned and when to call the 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 single parameter 'id' is fully documented in the schema as the finding id from list_findings, so schema coverage is 100%. The description adds no additional parameter-specific meaning beyond what the schema provides, which meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a full finding with specific content (measurement, stack frames, SQL, child operations, related findings). It distinguishes itself from list_findings by contrasting the list view's 'symptom' with the full context needed to fix.
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?
Explicitly tells the agent to read this before changing any code and warns that the file shown in the list view is often the symptom, not the cause. This provides a clear directive on when to use this tool versus relying on the list view.
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?
With no annotations provided, the description fully discloses behavior: the claim lasts 30 minutes, auto-releases on close or expiry, renewing by claiming again is safe, and release:true gives the finding back without closing. It also covers what happens on contention (someone else holds it). This is comprehensive transparency for a lease-mutating 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 appropriately sized for the tool's complexity. It starts with the core action, then seamlessly covers sequencing, conflict handling, lease mechanics, renewal, and release. No sentence is wasted; all information contributes to correct usage.
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?
For a 3-parameter tool with no output schema, the description fully covers when to use it, how to handle contention, lease duration and renewal, and the release semantics. It also aligns with siblings by referencing list_findings and close_finding. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema description coverage is 100%, the description adds significant practical meaning: id is sourced from list_findings, minutes has a default of 30 with a caution to only request more for genuinely long fixes, and release is tied to the explicit abandonment scenario. This enriches the schema with usage intent and 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 action: 'Take a finding so no other agent starts on the same one.' It uses a specific verb and resource, and it distinguishes itself from siblings like list_findings and get_finding by establishing this as the locking/claiming step before work begins.
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?
Explicit when-to-use guidance: 'Call this after get_finding and before writing any code.' It also gives a clear exclusion: if someone else holds it, do not work on it and 'pick the next finding from the list instead.' The release parameter is also explained as the abandonment path, providing workflow direction.
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?
With no annotations, the description fully carries the transparency burden. It explains the note requirement for resolve/dismiss, the rationale (the note is 'the only record of why'), and the consequences of misusing statuses ('a wrongly closed one costs an incident'). This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, front-loaded with the core purpose and then branching into conditional usage. Every sentence provides actionable guidance; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of status transitions and the lack of annotations/output schema, the description is remarkably complete. It covers decision criteria, prerequisites (note), fallback guidance, and the reasoning behind each choice, leaving no significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only note has a description), so the description must compensate. It explains the semantic meaning of each status value, the conditional requirement for note, and the importance of id (implicitly). The description adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record what happened to a finding, and describe the solution.' It specifies the three statuses (resolved, dismissed, open) and distinguishes each, making it distinct from sibling tools like claim_finding or list_findings.
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 gives explicit when-to-use instructions with conditions: 'Use resolved only once a release carrying the fix has reported and the numbers have moved,' 'Use dismissed only for something that is genuinely not a problem,' and 'Use open to undo either.' It also advises on uncertainty and the trade-offs, exceeding typical guidance.
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:

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

Score Badge

Copy to your README.md:

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

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