Specif-ai MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have clear distinctions based on document types (e.g., BPS, BRDs, NFRS, PRDs, UIRs) and resource levels (e.g., tasks vs. user stories), but there is some overlap between 'get-task' and 'get-tasks' that could cause confusion about when to use each. The 'set-project-path' tool is distinct in purpose but stands out from the retrieval-focused tools.
Naming Consistency4/5
The naming follows a consistent verb-object pattern with hyphens (e.g., 'get-bps', 'get-brds'), which is clear and predictable across most tools. However, 'set-project-path' deviates slightly by using 'set' instead of 'get', but it still maintains the same hyphenated structure, keeping it mostly consistent.
Tool Count5/5
With 9 tools, the count is well-scoped for a document and project management server, covering various requirement documents, tasks, and user stories without being overwhelming. Each tool appears to serve a specific purpose, making the set manageable and focused.
Completeness3/5
The toolset provides good retrieval coverage for documents, tasks, and user stories, but there are notable gaps in CRUD operations, such as creating, updating, or deleting these resources. For a server focused on project requirements, the lack of write operations limits its completeness for full lifecycle management.
Average 2.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get' but doesn't clarify if this is a read-only operation, how it accesses documents (e.g., from a file system or database), potential side effects, or error handling. The description lacks details on permissions, rate limits, or what 'Get' entails beyond the basic action.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'Get' returns (e.g., a list of documents, their contents, or metadata), how results are formatted, or any behavioral nuances. For a tool with no structured context, this leaves significant gaps for an AI agent.
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 description coverage is 100%, with the single parameter 'cwd' well-documented in the schema as an absolute path for auto-inferring the project path. The description adds no additional meaning beyond the schema, such as explaining why this parameter is needed or how it affects the tool's behavior, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Business Requirement Documents for this project' states a clear verb ('Get') and resource ('Business Requirement Documents'), but it's vague about scope and mechanism. It doesn't specify whether this retrieves all BRDs, specific ones, or how they're returned, nor does it distinguish from siblings like 'get-uirs' or 'get-user-stories' which likely retrieve similar document types.
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 is provided on when to use this tool versus alternatives. It mentions 'for this project' but doesn't explain prerequisites like needing a project context or how it relates to siblings such as 'get-bps' or 'set-project-path'. There's no explicit when/when-not or alternative usage instructions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' documents but doesn't clarify whether this is a read-only operation, what format the output takes (e.g., list of files, document content), potential errors, or any side effects. This leaves critical behavioral traits unspecified for a tool with no annotation coverage.
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, straightforward sentence that efficiently states the tool's purpose. It is appropriately sized for a simple tool, with no redundant or verbose language. However, it could be more front-loaded with critical details like output format or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'get' returns (e.g., file paths, document content, metadata), error conditions, or how it interacts with the inferred project path. For a tool with no structured output documentation, the description should provide more context about the expected behavior and results.
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 description coverage is 100%, with the single parameter 'cwd' fully documented in the schema as an absolute path for auto-inferring the project path. The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves Product Requirement Documents for a project, which is a clear purpose. However, it doesn't specify what 'get' entails (list, fetch content, metadata) or distinguish this from sibling tools like get-brds or get-uirs that likely retrieve similar document types. The description is somewhat vague about the exact nature of the retrieval 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a project path), exclusions, or comparisons to siblings like get-bps or get-nfrs. The agent must infer usage from the tool name alone, which is insufficient for informed selection.
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?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits such as what format the documents are returned in, whether there are rate limits, authentication needs, or error conditions. The description is too minimal for a tool with no annotation coverage.
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, clear sentence with zero waste. It's appropriately sized and front-loaded, making it easy to understand the core purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what 'Business Process Documents' are, how they're returned, or any behavioral context, leaving significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter cwd. The description adds no parameter-specific information beyond implying the tool infers the project path from cwd, which is already covered in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'Business Process Documents for this project', making the purpose understandable. However, it doesn't differentiate from sibling tools like get-brds, get-nfrs, etc., which presumably retrieve different document types, so it misses full sibling distinction.
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 get-brds or get-nfrs. It mentions 'for this project' but doesn't explain how that relates to the cwd parameter or when other tools might be more appropriate.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' documents, implying a read-only operation, but doesn't specify whether it retrieves all NFRs, a subset, or if there are limitations like pagination or file format constraints. It also doesn't describe the return format (e.g., list of files, document contents) or error conditions, leaving significant gaps in understanding how the tool behaves.
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, efficient sentence: 'Get Non-Functional Requirement Documents for this project.' It's front-loaded with the core purpose, has zero redundant words, and earns its place by clearly stating the tool's function. No structural issues or verbosity detract from its clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that presumably returns document data. It doesn't explain what 'gets' entails (e.g., file paths, content, metadata), how NFRs are identified, or potential outputs. For a document retrieval tool with no structured output information, more detail is needed to guide the agent effectively.
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 description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage, fully documenting the single 'cwd' parameter with its purpose and type. Since the description doesn't elaborate on parameters, it meets the baseline score of 3 for high schema coverage, but doesn't compensate with additional context like examples or edge cases.
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's purpose: 'Get Non-Functional Requirement Documents for this project.' It specifies the verb ('Get') and resource ('Non-Functional Requirement Documents'), and distinguishes it from siblings like get-bps, get-brds, and get-prds that handle different document types. However, it doesn't explicitly mention that it's for the current project or how it determines the project context beyond the cwd parameter.
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. It doesn't mention prerequisites (e.g., needing a project path set), exclusions (e.g., not for functional requirements), or compare it to siblings like get-bps or get-uirs. The agent must infer usage from the tool name alone, which is insufficient for clear decision-making.
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 full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose permissions, error handling, rate limits, or what happens if IDs are invalid. For a tool with four required parameters and no annotation coverage, this is inadequate.
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, efficient sentence with zero wasted words. It front-loads the core purpose ('Get a Task') and succinctly adds necessary context, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, no output schema, no annotations), the description is incomplete. It lacks guidance on usage, behavioral details, and output expectations, leaving significant gaps for an AI agent to infer correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying hierarchical relationships (Task → User Story → PRD), but doesn't clarify parameter interactions or formats. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a Task') and specifies the resource context ('for a particular User Story in a particular PRD'), which distinguishes it from generic task retrieval. However, it doesn't explicitly differentiate from sibling tools like 'get-tasks' (plural) that might retrieve multiple tasks, leaving some ambiguity.
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. It doesn't mention sibling tools like 'get-tasks' or explain prerequisites (e.g., needing specific IDs), nor does it specify exclusions or contextual constraints beyond the implied scope.
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 full burden for behavioral disclosure. It states 'Get Tasks' which implies a read operation, but doesn't mention permissions, rate limits, pagination, or what happens if parameters are invalid. For a tool with 3 required parameters and no annotation coverage, this is insufficient.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'Tasks' are in this context, what format they're returned in, or any behavioral constraints. For a retrieval tool with this complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional meaning about parameters beyond implying they're needed to identify the user story. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Tasks for a particular User Story', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-task' (singular) or explain how this differs from other retrieval tools in the server, which prevents a perfect score.
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 'get-task' or other sibling tools. It mentions 'for a particular User Story' but doesn't specify prerequisites, exclusions, or contextual usage scenarios, leaving the agent with minimal direction.
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 of behavioral disclosure. It states a read operation ('Get') but doesn't cover aspects like permissions, rate limits, or what happens if no documents exist. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., document list, content, or metadata) or address potential errors. For a tool with such minimal structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'cwd'. The description adds no parameter-specific information beyond implying project context, which the schema already covers. Baseline 3 is appropriate as the schema handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('User Interface Requirement Documents') with context ('for this project'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-brds' or 'get-nfrs' which likely retrieve different document types, so it misses full sibling distinction.
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. It doesn't mention sibling tools or specify scenarios where UI requirement documents are needed over other document types, leaving the agent without usage context.
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 full burden for behavioral disclosure but offers minimal information. It doesn't specify whether this is a read-only operation, what format the user stories are returned in, potential errors (e.g., invalid PRD ID), or any rate limits. The description merely restates the tool's purpose without adding operational 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'User Stories' entail (e.g., structured data, text descriptions), how results are returned, or error conditions. For a tool that likely returns complex data, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond implying 'prdId' identifies the PRD, which is already clear from the schema. This meets the baseline score of 3 since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'User Stories' with scope 'for a particular PRD', making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get-brds' or 'get-nfrs' which likely retrieve other document types, missing an opportunity to clarify its specific domain.
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. It doesn't mention prerequisites (e.g., needing a valid PRD ID), exclusions, or relationships to sibling tools like 'get-prds' (which might list PRDs before selecting one). This leaves the agent without context for proper tool selection.
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?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'reload[s] the solution,' which implies a state-changing operation, but doesn't disclose critical behavioral traits such as whether this requires specific permissions, what happens to existing project data, error conditions, or side effects. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence with awkward phrasing ('when we not automatically able to infer') and redundancy ('or asked by the user or us'). It could be more structured and concise, but it does front-load the core purpose. Some sentences could be trimmed for clarity without losing meaning.
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 tool's complexity (a mutation operation with no annotations and no output schema), the description is moderately complete. It covers the purpose and usage guidelines adequately but lacks details on behavioral transparency, error handling, or return values. The schema covers parameters well, but overall completeness is limited by the missing behavioral context for a state-changing 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 input schema has 100% description coverage, with the 'path' parameter well-documented as 'The absolute path to the project directory containing specification files.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Set the project path and reload the solution.' It specifies the verb ('set') and resource ('project path'), and includes an additional action ('reload the solution'). However, it doesn't distinguish this tool from its siblings (all 'get-' tools), which are clearly read-only operations, making this distinction implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'use this tool only when we not automatically able to infer the project path or asked by the user or us.' It also mentions an alternative approach ('we will try to auto infer it from the environment first'), giving clear context for when to use this tool. However, it doesn't explicitly state when NOT to use it or name specific sibling alternatives, though the context implies it's for setup vs. data retrieval tools.
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:

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

Score Badge

Copy to your README.md:

[![specif-ai-mcp-server MCP server](https://glama.ai/mcp/servers/doso/specif-ai-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/doso/specif-ai-mcp-server)

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/doso/specif-ai-mcp-server'

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