obo-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: create sessions, get/list items, list sessions, mark items complete/skip, find next item, get session status, and update item fields. The operations target specific resources and actions without overlap.
Naming Consistency5/5
All tools follow a consistent 'obo_verb' or 'obo_verb_noun' pattern (e.g., obo_create, obo_get_item, obo_list_sessions). The naming is uniform throughout, using snake_case and clear action descriptors.
Tool Count5/5
With 9 tools, the server is well-scoped for managing OBO sessions and items. Each tool serves a distinct function in the workflow, from creation to status tracking, without being excessive or insufficient for the domain.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for OBO sessions and items: create sessions, list/get/update items, mark items as complete/skip, track status, and find next tasks. No obvious gaps exist for the stated purpose of session management.
Average 3.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 6 community issues answered or closed in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions returning 'full detail,' it lacks information about error handling (e.g., item not found), caching behavior, idempotency, or side effects. The existence of an output schema is noted in context signals, but the description doesn't characterize the return value structure beyond the single phrase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a structured Args section. There is minimal waste, though the Args format duplicates structural information already present in the schema (parameter names) rather than integrating descriptions into prose.
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 an output schema (reducing the need for return value description) and only three parameters, the description is reasonably complete. It documents all parameters and states the retrieval purpose. However, it could improve by briefly mentioning the OBO domain context or error scenarios given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively compensates by documenting all three parameters in the Args section: session_file includes path resolution logic relative to {base_dir}/.github/obo_sessions/, item_id clarifies acceptable types (integer or string), and base_dir explains its conditional requirement. This adds significant semantic value beyond the bare schema titles.
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 'Return[s] full detail for a single item,' specifying the verb (return), resource (item), and scope (single, full detail). However, it does not explicitly differentiate from sibling tool obo_list_items or clarify when to use this versus other retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like obo_list_items, nor does it mention prerequisites (such as requiring an existing session) or error conditions. The Args section documents parameters but does not contextualize usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the atomic update behavior and the file path convention ({base_dir}/.github/obo_sessions/). However, it omits critical behavioral details such as error handling (e.g., what happens if the file exists), idempotency guarantees, or permission requirements for file system operations.
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 docstring format is well-structured with a summary line followed by an Args section. Every sentence serves a purpose—either defining the operation or parameter semantics. The length is appropriate given the need to compensate for zero schema coverage.
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 5-parameter tool with an output schema, the description adequately covers inputs and primary behavioral traits (atomicity, file location). Since an output schema exists, the description appropriately omits return value details, focusing instead on input requirements and side effects.
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?
Given 0% schema description coverage, the Args section comprehensively compensates by documenting all 5 parameters. It provides semantic meaning for base_dir (project root with path template), explains the auto-generation logic for session_filename, and details the structure of items (listing optional sub-fields like urgency, importance, effort).
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 opens with a clear action statement ('Create a new OBO session file') and specifies the atomic side effect ('update index.json atomically'). While it clearly distinguishes itself from sibling tools by verb ('Create' vs 'List', 'Mark', 'Update'), it does not explicitly name alternatives or differentiate use cases within the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., when to create a new session vs. updating an existing one with obo_update_field). There are no prerequisites, conditions, or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions data source 'index.json' and explains business logic for 'incomplete' status filtering. Missing safety/disposition info (read-only implied by 'List' but not stated), error handling, or performance characteristics.
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?
Efficiently structured with purpose statement followed by Args block. No redundant sentences. The docstring-style 'Args:' format is slightly technical but serves the same function as front-loaded narrative without excessive verbosity.
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?
Adequate for a listing tool with output schema present (no return value explanation needed). Covers input parameters well given zero schema coverage. Could be improved by clarifying relationship to session management workflow and other list operations.
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?
Excellent compensation for 0% schema description coverage. Documents both parameters: base_dir as 'Project root directory' and status_filter with valid enum values ('active', 'completed', 'incomplete') plus behavioral definition of 'incomplete'. Adds significant value beyond the raw schema types.
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?
States specific verb ('List') and resource ('OBO sessions') with data source ('index.json'). Clearly distinguishes from sibling obo_list_items by targeting sessions rather than items, though it doesn't explicitly reference the sibling differentiation in text.
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?
Provides implicit usage guidance by defining filter values ('active', 'completed', 'incomplete') and explaining the semantics of 'incomplete' status. However, lacks explicit when-to-use guidance relative to siblings like obo_session_status or obo_list_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the core action. It lacks disclosure on persistence (is completion reversible?), side effects (what happens to the item after?), idempotency, or what the output schema contains despite the tool having a return value.
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 appropriately sized with a clear front-loaded purpose statement followed by structured parameter documentation. The Args format is scannable and information-dense, though slightly informal. No wasted words or redundant explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description correctly omits return value details. However, for a state-changing workflow tool with multiple siblings, it lacks context about the OBO session lifecycle, error conditions (e.g., already completed items), and the semantic meaning of 'complete' in this domain.
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?
The schema has 0% description coverage, but the description fully compensates by documenting all 4 parameters in the Args section. It adds critical semantic context: the path relationship between session_file and base_dir, the purpose of resolution text, and conditional requirements for base_dir.
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 (mark as completed), the resource (item), and the distinguishing feature (resolution text). It effectively differentiates from siblings like obo_mark_skip (different outcome) and obo_get_item (read vs. write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus similar alternatives, particularly obo_mark_skip. It fails to mention prerequisites (e.g., item must exist) or when completion is appropriate versus other state changes like obo_update_field.
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?
Without annotations, the description carries the full burden. It adds valuable behavioral context for path resolution (base_dir logic relative to .github/obo_sessions/), but fails to disclose mutation semantics, reversibility, side effects, or what the output schema contains.
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?
Efficient Args-based structure with zero redundancy. Each line documents exactly one parameter with precise constraints. Front-loaded purpose statement followed by detailed parameter specs.
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?
Adequate for a state-change tool with 4 parameters, given the output schema handles return value documentation. However, lacks workflow context (session advancement behavior) and safety implications of the skip action that would help an agent use it correctly in sequence with obo_next or obo_mark_complete.
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?
Critical compensation for 0% schema description coverage. The Args section comprehensively documents all 4 parameters, including conditional requirements (base_dir required if bare filename) and path resolution logic that the schema completely lacks.
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 core action ('Mark') and target state ('skipped') for an 'item'. It implicitly distinguishes from sibling 'obo_mark_complete' via the 'skipped' vs 'complete' state distinction, though it doesn't explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use skip versus complete (obo_mark_complete), or workflow context (e.g., whether this advances to the next item). No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via the word 'Return,' but does not disclose idempotency, error behavior (e.g., what happens if session_file doesn't exist), performance characteristics, or what specific statistics are included in the summary.
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 optimally concise with zero wasted words. It front-loads the purpose statement and uses a structured Args section to document parameters efficiently. Every sentence 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?
Given the presence of an output schema (which obviates the need to describe return values) and the description's coverage of both parameters, the definition is adequately complete for a simple retrieval tool. It could be improved by mentioning error handling for missing files.
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?
With 0% schema description coverage, the description fully compensates by documenting both parameters in the Args section: session_file's path resolution logic (absolute vs. relative to {base_dir}/.github/obo_sessions/) and base_dir's conditional requirement. This adds essential meaning missing from the schema titles.
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 states the tool 'Return[s] summary statistics for an OBO session,' providing a clear verb and resource. However, it does not explicitly differentiate from sibling tool obo_list_sessions, which also deals with sessions but returns a list rather than statistics for a specific session file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like obo_list_sessions or obo_get_item. There are no prerequisites, conditions, or workflow context provided to help the agent select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully documents the selection algorithm (priority_score ordering and status precedence), but fails to disclose critical behavioral traits such as whether calling this tool locks/assigns the item, triggers state transitions, or error conditions when sessions are empty.
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 appropriately front-loaded with the core purpose, followed by behavioral details and an Args section. The formatting is clear despite being embedded in a string, with no redundant or wasted sentences.
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 output schema exists (relieving the description of return value documentation), the description adequately covers the 2 parameters and retrieval logic. It could be improved by noting error states or side effects, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to fully compensate. It successfully documents both parameters: session_file clarifies the path format relative to {base_dir}/.github/obo_sessions/, and base_dir explicitly states its conditional requirement ('Required if session_file is a bare filename').
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 'Return[s] the next item to work on' with specific prioritization logic (in_progress items first by highest priority_score, then pending). This effectively distinguishes it from siblings like obo_list_items (which returns all) or obo_get_item (specific lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the internal prioritization algorithm (which implies when certain items are returned), but lacks explicit guidance on when to use this versus alternatives like obo_get_item or obo_list_items, and does not mention prerequisites such as requiring an existing session.
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 full disclosure burden. It successfully documents important behavioral traits: automatic recalculation of priority_score, string-to-numeric type casting for values, and the conditional path resolution logic for base_dir.
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?
Appropriately structured with purpose stated first, followed by behavioral side effects, then detailed parameter semantics. Dense but necessary given schema deficiencies. No redundant content, though the docstring-style Args format is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (covering return values), the description provides sufficient context for this mutation tool. It covers the 5 parameters, side effects, and path resolution logic. Minor gap regarding explicit sibling relationships prevents a 5.
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?
Input schema has 0% description coverage. The Args block comprehensively compensates by documenting all 5 parameters with specific path semantics (session_file), examples (field names), type handling rules (value casting), and conditional requirements (base_dir).
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?
Clearly states the core action ('Update any field on an item') and identifies the resource. The mention of 'any field' implicitly distinguishes this general-purpose updater from specialized siblings like obo_mark_complete, though explicit differentiation is absent.
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?
Explains when auto-recalculation of priority_score occurs (score component changes), providing useful context for side effects. However, it lacks explicit guidance on when to use this tool versus specialized alternatives like obo_mark_complete or obo_mark_skip for status changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable behavioral context about sorting (priority_score descending) but omits other important traits like whether the operation is read-only, idempotent, or what happens if the session file doesn't exist. It mentions 'List' which implies safety, but doesn't explicitly confirm this.
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 a clear one-sentence purpose statement followed by an Args section. Every sentence earns its place—no filler text, and the parameter documentation is concise yet complete.
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 that an output schema exists (covering return values), the description adequately covers the input parameters and core behavior. It successfully documents the complex path resolution logic. Minor gap: doesn't mention error handling scenarios (e.g., file not found), but this is acceptable given the parameter complexity handled.
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?
With 0% schema description coverage, the description excellently compensates by documenting all three parameters. It explains path resolution logic for session_file (absolute vs relative), conditional requirements for base_dir, and valid enum values for status_filter ('pending', 'in_progress', 'completed', 'skipped').
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 provides a specific verb ('List') and resource ('items in a session'), and explicitly states the sorting behavior ('sorted by priority_score descending'). This clearly distinguishes it from siblings like obo_get_item (single item retrieval) and obo_list_sessions (different resource).
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 implicit usage context through the Args section, explaining when base_dir is required ('Required if session_file is a bare filename'). However, it lacks explicit guidance on when to use this versus alternatives like obo_get_item or obo_next, and doesn't state any prerequisites or exclusions.
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:

[![oboe-mcp MCP server](https://glama.ai/mcp/servers/Warnes-Innovations/oboe-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Warnes-Innovations/oboe-mcp)

Score Badge

Copy to your README.md:

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

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