frontier-mcp

by 51ck

Overview Schema Related Servers Score Discussions

TypeScript

Local

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 resource and action: listing efforts, fetching ticket bodies, viewing a board, creating tickets, updating a ticket, editing a map, getting/putting a spec, and migrating legacy tickets. There is no overlap or ambiguity between them.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (list_efforts, get_tickets, create_tickets). The exception is 'spec', which is a short noun rather than a verb_noun, and there is some singular/plural inconsistency (update_ticket vs create_tickets). Overall, the pattern is predictable.
Tool Count5/5
With 8 tools, the set is well-scoped and each tool serves a clear purpose. This is within the ideal 3-15 range and covers the domain without unnecessary bloat.
Completeness4/5
The core workflows (create/update tickets, view board, edit map, manage specs, migrate legacy data) are covered well. Minor gaps include lack of an explicit create_effort tool and no delete operations for tickets or efforts, but these are workable or perhaps intentionally omitted.
Average 4.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 147 commits in the last 12 weeks
- Last stable release on August 20, 2026
- 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?
The readOnlyHint annotation already signals this is a safe read operation. The description adds context by stating the output includes Ticket counts and header docs, which is useful since there is no output schema. However, it does not disclose other behavioral aspects such as ordering, pagination, or how the root parameter affects the result.
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 sentence that front-loads the main action ('List the Efforts') and includes the most important qualifiers without any unnecessary words. It earns its place entirely.
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 list tool with one optional parameter and read-only annotation, the description is sufficient. It specifies the key return values (Ticket count and header docs), which compensates for the lack of an output schema. A minor gap is that it does not mention whether results are sorted or limited, but this is not critical for basic 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?
The schema covers the single optional parameter (root) with a clear description of its default behavior. Since schema coverage is 100%, the baseline is 3. The description adds no parameter-specific details, but that is acceptable given the schema's completeness.
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 Efforts in a repo and includes what each entry contains (Ticket count and header docs). It uses a specific verb and resource, and the mention of Ticket counts and header docs distinguishes it from sibling tools like get_tickets or get_board.
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 this tool is for getting an overview of Efforts at the repo level, but it does not explicitly state when to use it instead of alternatives like get_tickets or edit_map. There is no mention of when not to use it or how it differs in scope.
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 already declare readOnlyHint=true, and the description adds meaningful behavioral context: the tool never returns full bodies, and the output includes specific ticket fields with a Frontier marker. This goes beyond the annotation and helps set expectations about the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and lists key output fields efficiently. While 'Destination' is not immediately clear, the rest of the sentence is concise and free of 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 simple parameter set, readOnly annotation, and lack of an output schema, the description adequately explains the return value structure (lines per ticket with fields) and explicitly notes the absence of bodies. It could mention error conditions or ordering, but for this tool's complexity the description is sufficiently 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?
The input schema fully describes both parameters (effort and root) with 100% coverage, so the description doesn't need to explain them. The description adds no additional meaning about parameter formats or defaulting behaviors, making the baseline score of 3 appropriate.
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 it returns a board representation of an Effort with one line per Ticket (id, title, kind, status, Edges) and distinguishes itself from get_tickets by noting it never returns bodies. However, the opening phrase 'An Effort's Destination' is somewhat cryptic and may confuse users unfamiliar with the domain terminology.
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 tells users to use get_tickets for bodies, providing a clear alternative and an exclusion criterion. It doesn't specify other conditions or when to prefer this tool over list_efforts, but for a read-only board view this guidance is sufficient.
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 richly discloses critical behaviors: atomic creation with partial failure rolling back, key resolution, cycle rejection, and the requirement for the 'create' flag. This goes far beyond the annotations (readOnlyHint=false, idempotentHint=false) and gives the agent a clear mental model of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every clause contributes essential information. There is no redundancy or filler.
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, the description covers core behaviors thoroughly. However, it does not specify the return value or error handling, and since there is no output schema, the agent must infer what a successful call returns. This is a minor gap in an otherwise strong description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explaining the role of temporary keys, id minting, and the atomicity semantics. It enriches understanding of parameters like 'key' and 'tickets' even though the schema already documents them well.
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 publishes a whole breakdown in one call, which is a specific verb and resource. It distinguishes from sibling tools like update_ticket and edit_map by emphasizing batch creation, though the metaphorical 'publish' may not be immediately obvious.
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?
It implies usage for bulk ticket creation and mentions the need for the 'create' flag, but it does not explicitly state when to prefer this over alternatives or when not to use it. There is no comparison with sibling tools, so guidance is largely implicit.
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, establishing safety. The description adds behavioral context about being a bulk call and advising selective use, which goes beyond the annotation. It does not mention error conditions or response format, but for a read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and followed by practical usage guidance. Every word earns its place with no redundancy or filler.
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 straightforward bulk-read tool, the description adequately conveys purpose and usage. The absence of an output schema is mitigated by the phrase 'full bodies' indicating what is returned. The guidance is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (ids and root) with full descriptions, including an example for ids and default for root. The description adds no additional parameter-level detail, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full bodies for a list of Ticket ids in one call, distinguishing it from siblings like get_board and list_efforts by emphasizing bulk retrieval. The verb 'get' and resource 'Ticket' are 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?
Explicitly instructs to use after get_board and only for tickets actually worked, providing clear sequencing and scope. This helps the agent decide when to invoke this tool versus alternatives like listing efforts or retrieving the board.
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?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses that the document is treated as opaque, that puts require an expected_revision to prevent clobbering, and that an Effort may hold both a Map and a Spec. This adds meaningful operational context without contradicting the 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 compactly convey the core purpose, the opaque-document convention, the lack of section editing, and the concurrency safeguard. The structure is front-loaded and every clause earns its place, avoiding redundancy with the schema.
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?
The description provides sufficient context for an agent to select and invoke the tool: it explains the operation type, document format, the relationship to Effort/Map, and the concurrency control. With no output schema, the description still makes clear that omitting content returns the current document, and the schema fills in the rest. It is complete for its complexity.
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?
While the schema gives 100% coverage for all 5 parameters, the description adds contextual meaning by explicitly tying expected_revision to the concurrency mechanism and describing content as a wholesale replacement. This goes beyond the schema's per-field descriptions and aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Get or put a Spec as a whole opaque document') and clearly distinguishes the tool from siblings like edit_map by noting that nothing edits a Spec section by section. It also reveals the conventional format (YAML frontmatter), making the purpose unmistakable.
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 clarifies when to use this tool (whole-document get/put) and explicitly states that section-by-section editing is not supported, implying a contrast with tools like edit_map. It also provides a key usage constraint (expected_revision for concurrency), though it does not explicitly name alternative tools or provide when-not-to-use examples beyond the section-editing point.
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?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses partial-update behavior ('without rewriting the others'), the impossibility of setting Decisions-so-far, and the optimistic concurrency mechanism using expected_revision. These are meaningful behavioral details not captured elsewhere.
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?
Three sentences, front-loaded with the primary purpose, then two critical behavioral constraints. Every sentence earns its place with no filler 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?
The description covers read/edit operations, partial updates, the auto-generated status of Decisions-so-far, and concurrency control. However, it omits the create capability (starting a missing Effort/Map), which is a notable use case, though the schema documents it. Overall, it is largely complete for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all nine parameters. The description adds semantic grouping by mapping operations to parameter families and clarifies the role of expected_revision, supplementing the schema without 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 tool reads a Map's Destination and Notes, or edits one typed section (Destination, Notes, fog patches, out-of-scope items) without rewriting others. This specific verb+resource combination distinguishes it from sibling tools like update_ticket or get_board.
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 explains when to use the tool: to read a Map or edit specific sections without touching others. It also provides important usage constraints—Decisions-so-far is never accepted as input, and mutations require expected_revision from a prior read. However, it does not explicitly name alternative tools for related operations.
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?
Annotations only state readOnlyHint=false and idempotentHint=false. The description adds crucial behavioral details: preview mode writes nothing, filename rewriting is opt-in and off by default, and unrecognized files are ignored. It also explains id preservation and minting, giving the agent a clear picture of runtime 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 two sentences with no filler. It front-loads the main purpose followed by critical safety/write behaviors, making every sentence earn 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?
Given there is no output schema, the description covers the essential behaviors: what operations occur, preview safety, opt-in renaming, and ignored files. It is slightly thin on post-conditions or return value, but sufficient for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by clarifying the 'rename' parameter is opt-in and off by default to preserve relative links, and that 'preview' writes nothing. This is meaningful context beyond the raw 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 uses a specific verb ('Normalize') and clearly identifies the resource ('Legacy Tickets in an Effort'), detailing exact transformations (schema frontmatter, id preservation/minting, prose Edges to blocked_by). This clearly distinguishes it from sibling tools like create_tickets or update_ticket, which deal with current tickets.
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: it's for normalizing legacy tickets within an effort, and mentions opt-in filename rewriting and preview behavior. However, it does not explicitly provide exclusions or alternative tool references, so it stops short of a full 5.
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?
It reveals that graph changes replace edges and are 'refused if they close a cycle', that annotation changes 'touch no part of the graph', and that lifecycle actions are exclusive within a call. These go beyond the readOnly/idempotent hints.
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?
Three sentences, zero fluff, structured with colon-separated labels. Front-loads the core purpose.
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 tool with 10 params and nested objects, the description covers the key behavioral categories and constraints. Combined with rich schema descriptions, it provides a complete operational picture; no output schema means no return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed per-parameter descriptions. The description adds high-level grouping (lifecycle, graph, annotations) and interaction rules, which enhances understanding without duplicating schema details.
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 opens with 'Change one Ticket', a specific verb-resource pair, and enumerates the three change groups (Lifecycle, Graph, Annotations), which clearly distinguishes it from sibling tools like create_tickets and get_tickets.
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?
It explains the tool is for changing a single ticket and details constraints like 'at most one lifecycle per call' and 'Any of the three groups may accompany the others or stand alone.' It doesn't explicitly compare to siblings, but the usage context is clear.
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:

[![frontier-mcp MCP server](https://glama.ai/mcp/servers/51ck/frontier-mcp/badges/card.svg)](https://glama.ai/mcp/servers/51ck/frontier-mcp)

Score Badge

Copy to your README.md:

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

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