Skip to main content
Glama
Gunsmith-Academy

woody-mcp

by Gunsmith-Academy
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Server Quality Checklist

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

  • Latest release: v1.0.3

  • Disambiguation5/5

    Each tool has a clearly distinct purpose: ask_woody for asking questions, check_woody_status for system status, and search_knowledge_base for direct KB retrieval. There is no overlap or ambiguity.

    Naming Consistency5/5

    All tools follow a consistent verb_noun pattern with underscores: ask_woody, check_woody_status, search_knowledge_base. The naming is predictable and readable.

    Tool Count5/5

    3 tools is appropriate for a specialized firearms assistant. It covers the essential interactions without excess or deficiency.

    Completeness4/5

    The tool set covers the core workflows: asking questions, checking system status, and searching the knowledge base. A minor gap is the lack of a tool to list available topics or help, but the overall surface is sufficient for the domain.

  • Average 4.4/5 across 3 of 3 tools scored. Lowest: 3.9/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 7 commits 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

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the full burden. It mentions returning expert answers with citations and handling legal disclaimers, but lacks details on latency, synchronous behavior, or any limitations. Basic behavior is clear but deeper transparency is missing.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise and well-structured: a single-purpose opening sentence, a bullet list of covered topics, and a clear Args section. Every sentence adds value without 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 3 parameters (0% schema coverage), no annotations, and an output schema, the description adequately covers parameters and return behavior (legal disclaimer handling). It could mention more about the output format, but the provided guidance is sufficient for agent 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 coverage is 0%, yet the description thoroughly explains all three parameters: question (max 2000 chars), state (US state for jurisdiction), and user_tier (values 'free', 'operator', 'patriot', 'armorer' affecting depth and model). This adds significant meaning beyond the 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 function: 'Ask Woody any firearms question and get an expert answer with citations.' It distinguishes itself from siblings (check_woody_status and search_knowledge_base) by focusing on expert Q&A.

    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 lists covered topics (builds, legal, etc.) implying appropriate use cases, but does not explicitly state when to use alternatives or when not to use this tool. With siblings available, explicit guidance would be helpful.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations, the description carries full burden. It discloses that the tool is read-only and returns status information, which is sufficient. No side effects are implied, making it transparent.

    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 very concise: two sentences plus a returns line. It is front-loaded with the main purpose and contains no unnecessary words.

    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 no parameters and an output schema present, the description adequately explains what the tool returns and its purpose, making it complete for a status check 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?

    There are no parameters, so the schema covers 100% trivially. The description adds no parameter info, but per guidelines, 0 parameters yields a baseline of 4.

    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 checks Woody's capabilities, KB version, and API status. It uses a specific verb ('check') and resource ('Woody's status'), and distinguishes from siblings like 'ask_woody' and 'search_knowledge_base' which serve different purposes.

    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 to use this tool to verify connection or see what Woody supports. It does not mention when not to use it or provide alternatives, but the context of sibling tools implies differentiation.

    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?

    The description discloses key behavioral traits: it uses pure vector retrieval with no AI inference or extra token cost, and returns raw document chunks with relevance scores. While it covers the main behavior, it does not mention edge cases like empty results or error handling. Given no annotations, this is adequate but not exhaustive.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise and well-structured. It uses a clear front-loaded sentence for purpose, then a brief explanation of benefits, followed by bullet-pointed args and returns. No redundant information.

    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 simplicity (2 parameters, no annotations, and an output schema), the description covers purpose, usage, parameter details, and return format. It does not discuss authentication or errors, but for a search tool this is sufficient.

    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 0%, but the description provides detailed examples and constraints for both parameters: query (with example 'Geissele SSA-E trigger pull weight') and top_k (range 1-10, default 3). This adds significant meaning beyond the schema titles.

    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: 'Search Woody's verified firearms knowledge base directly.' It specifies a verb (Search) and a resource (knowledge base), and distinguishes itself from sibling 'ask_woody' by noting it uses pure vector retrieval without AI inference.

    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 states when to use ('good for fact-checking, looking up specific specs, or finding source material') and when not to use it (before asking a follow-up question with ask_woody). It also names the alternative tool 'ask_woody'.

    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

woody-mcp MCP server

Copy to your README.md:

Score Badge

woody-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/Gunsmith-Academy/woody-mcp'

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