MCP Instruct
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools have distinct purposes, with clear separation between agent management (agent_*) and knowledge base operations (kb_*). However, some overlap exists: kb_initialize and mcp_instruct_onboarding both handle setup, and kb_get_context vs kb_get_all might cause confusion about which provides LLM-ready data. Descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5Tool names follow a highly consistent snake_case pattern with clear verb_noun structure throughout. All agent tools use 'agent_' prefix and all knowledge base tools use 'kb_' prefix, making them easily scannable and predictable. No deviations in naming conventions are present.
Tool Count3/527 tools is borderline heavy for the apparent scope of agent management and knowledge base operations. While the domain justifies multiple tools, the count feels excessive with many specialized get/update operations that could potentially be consolidated. It may overwhelm agents with choice without proportional utility gain.
Completeness5/5The tool surface provides comprehensive coverage for both domains. Agent management includes activation, switching, listing, and tool access. Knowledge base operations cover full CRUD lifecycle (add, get, update, remove, search), import/export, onboarding, and specialized access by category. No obvious gaps exist for the stated purposes.
Average 2.8/5 across 27 of 27 tools scored. Lowest: 1.8/5.
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.jsonto 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
- Behavior1/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. 'Get project context' implies a read operation but reveals nothing about what 'context' entails, whether it requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with zero annotation coverage, this description fails to provide essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only three words, the description is under-specified rather than efficiently structured. It lacks front-loaded clarity and fails to earn its place by providing meaningful information beyond the tool name. True conciseness balances brevity with usefulness, which is not achieved here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'project context' and the lack of annotations and output schema, the description is completely inadequate. It does not explain what 'context' means, what format it returns, or how it relates to other knowledge base tools. For a tool that likely retrieves structured project data, this leaves critical gaps in understanding its function and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not add parameter information, which is appropriate here. Baseline is 4 for zero-parameter tools, as there is no need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get project context' is a tautology that essentially restates the tool name 'kb_get_projects' without adding meaningful specificity. It uses a generic verb 'Get' and vague resource 'project context' without distinguishing what type of context or how it differs from sibling tools like 'kb_get_all', 'kb_get_context', or 'kb_update_projects'. The purpose remains unclear beyond the obvious from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There are multiple sibling tools that might retrieve project-related information (e.g., 'kb_get_all', 'kb_get_context', 'kb_update_projects'), but the description offers no context, prerequisites, or exclusions to help an agent choose appropriately. This leaves the agent with no usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but it doesn't specify if this requires authentication, has rate limits, returns structured data, or what happens on failure. For a tool with zero annotation coverage, this is inadequate as it misses key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get personal information'), which could be seen as efficient. However, it's under-specified rather than appropriately sized—it lacks necessary details like what 'personal information' entails. It's front-loaded but doesn't earn its place with meaningful content, making it borderline between concise and incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (retrieving personal information), no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what 'personal information' includes, the return format, or any behavioral context. For a tool in a knowledge base context with siblings like 'kb_update_personal', more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, but with no parameters, the baseline is 4 as it doesn't need to compensate for schema gaps. It implicitly suggests no inputs are required, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get personal information' is a tautology that essentially restates the tool name 'kb_get_personal'. It doesn't specify what type of personal information (e.g., contact details, preferences, identification) or from what source. While it distinguishes from siblings like 'kb_get_professional' by mentioning 'personal', it lacks the specific verb+resource clarity needed for a higher 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after initialization), or compare to siblings like 'kb_get_all' or 'kb_get_preferences'. The description provides no usage context, leaving the agent to infer based on the name alone.
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. 'Get professional information' implies a read-only operation, but it doesn't specify whether this requires authentication, involves rate limits, returns structured or unstructured data, or has any side effects. For a tool with zero annotation coverage, this lack of behavioral detail is a significant gap, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, 'Get professional information', which is concise but under-specified. While it avoids unnecessary verbosity, it fails to provide essential context that would help an agent understand the tool's scope or differentiate it from siblings. The brevity comes at the cost of clarity, making it inefficient rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'professional information' entails, how it's formatted, or how it relates to other knowledge base tools. Without annotations or output schema, the description should provide more context about the return value and usage scenarios, but it does not, leaving gaps for agent interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for missing parameter information, and it appropriately avoids discussing nonexistent inputs. A baseline score of 4 is assigned since no parameter semantics are required, and the description doesn't introduce confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get professional information' is a tautology that restates the tool name 'kb_get_professional' without adding meaningful specificity. It doesn't clarify what type of professional information is retrieved (e.g., contact details, work history, credentials) or how it differs from sibling tools like 'kb_get_personal' or 'kb_get_all'. While it indicates a retrieval action, the purpose remains vague and undifferentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, context for usage, or comparisons to sibling tools such as 'kb_get_personal' for personal data or 'kb_get_all' for comprehensive information. Without any usage context, the agent must infer applicability 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 mentions 'AI-ready context string' but doesn't disclose behavioral traits such as format, size limits, freshness, or whether it's cached. For a tool with no annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It's front-loaded with the core purpose, though it could be slightly more specific to improve clarity without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 'AI-ready context string' contains, its structure, or how it differs from sibling tools. For a tool with one parameter but significant contextual ambiguity, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'categories' documented as 'Categories to include (default: all)' and a default list. The description adds no additional meaning beyond what the schema provides, so it meets the baseline for high coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get AI-ready context string for LLM consumption' states the action ('Get') and resource ('context string'), but it's vague about what specific context is retrieved. It doesn't distinguish from sibling tools like kb_get_personal or kb_get_professional, which likely fetch more specific context subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like kb_get_personal and kb_get_professional that fetch specific categories, the description lacks any indication of scope, prerequisites, or comparative use cases.
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. 'Remove' implies a destructive mutation, but it doesn't disclose if this is permanent, requires specific permissions, affects related data, or has side effects. For a deletion tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase with no wasted words. It's appropriately sized for a simple tool name and front-loaded with the core action, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deletion operation, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what 'custom knowledge' is, how removal works, what happens on success/failure, or return values, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'custom knowledge' but doesn't explain what 'category' and 'key' parameters represent, their formats, or examples. Without this, the schema's two required parameters remain undocumented, leaving the agent guessing about their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove custom knowledge' states the action (remove) and resource (custom knowledge), but is vague about what 'custom knowledge' refers to and doesn't differentiate from sibling tools like kb_get_custom or kb_update_*. It's better than a tautology but lacks specificity about the scope of removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like kb_get_custom (retrieve), kb_update_* (modify), and kb_export/import (manage data), the description offers no context for choosing removal over other operations or prerequisites for deletion.
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 mentions 'semantic search' but doesn't explain what that entails (e.g., natural language processing, relevance scoring, or limitations). It lacks details on permissions, rate limits, error handling, or output format. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function. However, it could be more structured by including key details, but as-is, it's appropriately concise for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (search tool with semantic aspects), lack of annotations, no output schema, and many sibling tools, the description is incomplete. It doesn't cover behavioral traits, usage context, or output expectations. For a tool with 2 parameters and no structured support, it should provide more guidance to be effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 parameters (query and limit). The description adds no meaning beyond the schema—it doesn't clarify query syntax, semantic aspects, or result ordering. With high schema coverage, the baseline is 3, and the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search knowledge base using semantic search' states the verb (search) and resource (knowledge base) but is vague about scope and differentiation. It doesn't specify what type of content is searched (e.g., articles, documents, entries) or how it differs from sibling tools like kb_get_context or kb_get_all. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools (e.g., kb_get_context, kb_get_all, kb_get_personal), the description doesn't indicate if this is for general queries, specific contexts, or filtered searches. There's no mention of prerequisites, exclusions, or comparative use cases.
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 describe what 'custom knowledge' includes, how results are returned (e.g., format, pagination), error conditions, or any permissions required. This leaves significant gaps for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core action and filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 tool that retrieves 'custom knowledge' (which could be complex), the description is incomplete. It doesn't explain what 'custom knowledge' is, how it's structured, or what the return format looks like, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'category' documented as optional and returning all if not specified. The description adds no additional meaning beyond this, simply restating 'by category'. Baseline 3 is appropriate since the schema adequately covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get custom knowledge by category' states a verb ('Get') and resource ('custom knowledge'), but is vague about what 'custom knowledge' entails and doesn't distinguish it from sibling tools like kb_get_all, kb_get_context, or kb_get_personal. It lacks specificity about what type of knowledge is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like kb_get_all (which might retrieve all knowledge without filtering) or kb_get_personal/professional (which might filter by knowledge type). The description implies filtering by category but doesn't specify when this is preferred over other retrieval methods.
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 'quick setup' but doesn't disclose behavioral traits such as whether this is a read-only or mutating operation, what permissions are required, if it's idempotent, or what happens on failure. This is inadequate for a tool likely involving configuration changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without redundancy. It's appropriately sized and front-loaded, with no wasted words, 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/5Given 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, and the tool's likely complexity (setup with forms and data), the description is insufficient. It doesn't explain what 'setup' entails, what the common scenarios are, or what the tool returns, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 two parameters (formType with enum values, and data as key-value pairs). The description adds no additional meaning beyond the schema, such as examples of form data or scenarios for each formType, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'Quick setup using predefined forms for common scenarios,' which indicates a setup/configuration action with forms. However, it's vague about what exactly is being set up (knowledge base? system?), doesn't specify the resource clearly, and doesn't distinguish from siblings like 'kb_initialize' or 'kb_onboard' that might also handle setup tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, timing (e.g., initial setup vs. updates), or differentiate from sibling tools like 'kb_initialize' or 'kb_onboard,' leaving the agent with no context for 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't specify whether this requires authentication, what permissions are needed, whether changes are persistent or reversible, or what happens if only partial parameters are provided. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence that gets straight to the point with no wasted words. It's front-loaded with the core action and provides specific examples. However, it could be slightly more structured by explicitly mentioning it's for user preferences rather than just 'preferences'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after the update, whether there's confirmation, what format the response takes, or how to handle partial updates. The description should do much more to compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 7 parameters, the description provides minimal help. It mentions 'communication style' and 'technical level' which map to two parameters, but doesn't explain the other 5 parameters (learningStyle, workingHours, responseDetail, favoriteTools, interests) or provide context about what values are expected, how arrays should be formatted, or what the enums represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('user preferences'), with specific examples of what can be updated ('communication style, technical level, etc.'). It distinguishes from siblings like kb_update_personal or kb_update_professional by focusing specifically on preferences rather than other user data categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 kb_update_personal or kb_update_professional. It doesn't mention prerequisites, dependencies, or any context about when this update operation is appropriate versus other preference-related tools.
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. 'Update' implies a mutation operation, but the description doesn't specify whether this requires authentication, what happens to existing data, if changes are reversible, or any rate limits. It lacks critical behavioral details needed for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a tool with many parameters, though it could be more structured by front-loading key details about the update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral risks, parameter details, or expected outcomes, leaving significant gaps for the agent to navigate without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% description coverage, meaning all parameters are undocumented in the schema. The description only vaguely references 'professional information (job, skills, experience, etc.)', which maps to some parameters but doesn't explain their semantics, formats, or relationships. It fails to compensate for the poor schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('professional information') with specific examples (job, skills, experience, etc.), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'kb_update_personal' or 'kb_update_projects' beyond the 'professional' qualifier, which is why it doesn't reach 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/5Does 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, context, or relationships with sibling tools like 'kb_get_professional' (for retrieval) or other update tools, leaving the agent to infer usage based solely on the tool name.
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 'update' which implies mutation, but doesn't disclose behavioral traits like permissions needed, whether changes are reversible, side effects, or response format. This is a significant gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, full parameter details, or return values, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists examples (name, location, languages, etc.) that map to some parameters, but doesn't explain semantics for all 8 parameters (e.g., birthYear format, languages array structure, timezone format). It adds marginal value but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'personal information', with examples of specific fields (name, location, languages). It distinguishes from siblings like kb_update_preferences or kb_update_professional by focusing on personal data, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, such as whether personal information must already exist, or contrast with siblings like kb_get_personal for retrieval. Usage is implied but not explicitly defined.
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 action ('Activate') but doesn't explain what activation entails—e.g., whether it changes system state, requires permissions, has side effects (like deactivating other agents), or what happens post-activation (e.g., agent availability or response format). This leaves critical behavioral traits unspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Activate') and lists agent types without unnecessary details. Every word contributes to understanding the tool's scope, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 or output schema), the description is incomplete. It lacks information on behavioral outcomes (e.g., what activation means, success indicators, or error conditions) and doesn't address usage context relative to siblings. For a tool that likely changes system state, more detail is needed to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'agent' parameter fully documented via enum values. The description adds no additional parameter semantics beyond what the schema provides—it lists agent types that match the enum but doesn't explain their roles or differences. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate') and the resource ('specialized AI agent'), listing specific agent types (IT Expert, Hacker, Sales, Blue/Red/Purple Team). It distinguishes the tool's purpose from siblings like agent_list (list agents) or agent_get_active (get active agent), though it doesn't explicitly contrast them in the description 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/5Does 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., whether agents must be available or configured), when not to use it, or direct comparisons to siblings like agent_switch_quick (which might offer a quicker activation method). Usage is implied by the action 'activate,' but no explicit context is given.
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 a read operation ('Get') but does not cover aspects like permissions needed, rate limits, response format, or whether it returns all tools or only specific ones. This leaves significant gaps in understanding the tool's behavior 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 does not explain what 'available tools' entails (e.g., format, scope, or limitations), which is crucial for a tool that likely returns a list. For a read operation with no structured output guidance, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter details, so it appropriately avoids redundancy. A baseline of 4 is given as it efficiently handles the lack of parameters without unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get available tools for current agent' clearly states the verb ('Get') and resource ('available tools for current agent'), making the purpose understandable. However, it lacks specificity about what 'available tools' means (e.g., all tools, only accessible ones) and does not differentiate from siblings like 'agent_list' or 'kb_get_all', which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention prerequisites (e.g., agent activation), exclusions, or comparisons to sibling tools like 'agent_list' or 'kb_get_all', leaving the agent to infer usage context without explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Quick switch agent', implying a mutation operation that changes the active agent, but doesn't specify whether this requires permissions, what happens to the previous agent, if the switch is reversible, or any side effects like rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, efficient sentence that conveys the core action and key details (shorthand options). Every word earns its place, with no redundant or unnecessary information, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (implied by 'switch') with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), doesn't explain the return values or what 'quick switch' entails operationally, and offers minimal guidance on usage relative to siblings. For a tool that changes system state, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'type' parameter fully documented via an enum and description. The description adds value by listing the enum values ('it/hacker/sales/blue/red/purple') and implying they are shorthand options, but doesn't provide additional context like what each type represents or how they differ. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Quick switch agent') and the resource ('agent'), making the purpose understandable. It specifies the method ('using shorthand') and lists the available shorthand options, which helps distinguish it from other agent-related tools like 'agent_activate' or 'agent_get_active'. However, it doesn't explicitly differentiate from all siblings beyond the shorthand aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'agent_activate' or 'agent_list'. It mentions 'quick switch' and 'shorthand', implying it's for fast agent changes, but offers no explicit context, prerequisites, or exclusions for usage compared to other tools.
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 'Add custom knowledge' which implies a write/mutation operation, but doesn't disclose permissions needed, whether it overwrites existing entries, rate limits, or response format. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (implied by 'Add') with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, whether the operation is idempotent, or how conflicts with existing entries are handled. For a tool that modifies persistent data, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific semantics beyond implying 'category' is flexible ('any category') and 'value' can be complex. Since the schema already covers parameter purposes thoroughly, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add custom knowledge to any category' clearly states the action (add) and resource (custom knowledge) with scope (any category). It distinguishes from siblings like kb_remove_custom (remove) and kb_get_custom (retrieve), though it doesn't explicitly contrast with kb_update_* tools which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like kb_update_personal or kb_import. The description implies it's for adding new custom knowledge, but it doesn't specify prerequisites, constraints, or when-not-to-use scenarios, leaving the agent to infer usage from context alone.
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 retrieves data ('Get'), implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what happens if the knowledge base is empty. For a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get complete knowledge base') and adds necessary detail ('as formatted JSON'). There's no wasted wording, and it's appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving an entire knowledge base), lack of annotations, no output schema, and low parameter schema coverage, the description is incomplete. It doesn't explain the return structure, error conditions, or how the 'format' parameter affects output. For a tool that could return large datasets, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage and an enum of values. The description doesn't mention the 'format' parameter or explain what 'full', 'summary', or 'categories' mean in context. Since schema coverage is low (<50%), the description should compensate but doesn't, leaving parameter semantics unclear. However, with only one optional parameter, the baseline is slightly higher than minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'complete knowledge base', specifying the output format 'as formatted JSON'. It distinguishes from siblings like kb_get_context or kb_get_custom by indicating it retrieves the entire knowledge base, not subsets. However, it doesn't explicitly contrast with all siblings like kb_export or kb_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when to prefer kb_get_all over kb_get_context for context-specific data, kb_search for filtered results, or kb_export for different output formats. There's no context about prerequisites, such as whether the knowledge base must be initialized first.
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. While 'Get' implies a read-only operation, the description doesn't specify what 'recent' means (time window? last N entries?), what format the history entries have, whether there's pagination, authentication requirements, or rate limits. For a tool with zero annotation coverage, this leaves significant behavioral aspects undocumented that an agent would need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential information ('Get recent history of knowledge base changes') and contains no redundant phrases. Every word earns its place in conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description is incomplete for effective tool use. While the purpose is clear, the description doesn't explain what the history entries contain, their format, or what 'changes' specifically refers to (edits, additions, deletions?). For a history retrieval tool with no structured output documentation, the description should provide more context about what information is returned and in what structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'limit' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema - it mentions 'recent history' but doesn't clarify how this relates to the 'limit' parameter or if there are other implicit parameters. The description provides no additional parameter semantics, but doesn't need to since the schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recent history of knowledge base changes'), making the purpose immediately understandable. It distinguishes from siblings like kb_get_all (which retrieves all knowledge base content) or kb_search (which searches content) by focusing specifically on change history. However, it doesn't specify what constitutes 'recent' or the exact nature of 'changes' beyond the knowledge base context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when this tool is appropriate (e.g., for auditing changes, tracking updates) or when not to use it (e.g., for retrieving actual knowledge base content). With siblings like kb_get_all, kb_get_context, and kb_search that also retrieve knowledge base information, the lack of differentiation leaves the agent guessing about the appropriate context for this specific history-focused tool.
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 a read operation ('Get'), implying it's likely safe, but doesn't disclose behavioral traits like authentication needs, rate limits, or what 'preferences' encompasses (e.g., defaults vs. custom settings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, though it could benefit from more detail given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't clarify what 'preferences' includes or how it differs from other 'kb_get_*' tools, leaving gaps for an agent to understand context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is high. The description adds no parameter details, but since there are no parameters to document, this is acceptable. It implies no inputs are needed, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user preferences' clearly states the action (Get) and resource (user preferences), but it's vague about scope or format. It doesn't differentiate from sibling tools like 'kb_get_personal' or 'kb_get_professional', which likely retrieve specific preference subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like 'kb_get_personal' and 'kb_get_professional', the description doesn't indicate if this retrieves all preferences or a specific category, leaving usage unclear.
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, the description carries full burden but provides minimal behavioral context. It states it's an import operation (implies mutation/write) but doesn't disclose critical details: whether this overwrites existing data, merges, requires specific permissions, has side effects, or returns any result. For a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single, clear sentence that front-loads the core purpose. Every word earns its place with no redundancy or fluff, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after import (e.g., success/failure response, side effects), how it interacts with existing data, or error conditions. Given the complexity of importing knowledge bases, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'data' fully documented in the schema as 'JSON string of knowledge base data'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('import') and resource ('knowledge base'), specifying the source format ('from JSON string'). It distinguishes from obvious siblings like 'kb_export' (export vs import) but doesn't differentiate from other import-like tools like 'kb_initialize' or 'kb_quick_setup' that might also create knowledge bases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'kb_initialize', 'kb_quick_setup', or 'kb_add_custom'. The description implies it's for bulk import from JSON, but doesn't specify prerequisites (e.g., whether a knowledge base must exist first) or when to choose other tools for similar tasks.
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 mentions the tool 'Returns current profile summary and whether onboarding is needed', which gives some output context, but lacks details on side effects (e.g., does initialization create resources?), permissions, error handling, or rate limits. For a tool with 'initialize' in its name and no annotations, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Initialize or check knowledge base status') and adds key output details. Every word earns its place, though it could be slightly more structured (e.g., separating initialization from checking).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (initialization/status check with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and output but lacks behavioral context and usage guidelines. With no output schema, it should ideally describe the return format more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 'profileId'. The description adds no parameter-specific information beyond what's in the schema, but with high coverage and only one parameter, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Initialize or check') and resource ('knowledge base status'), distinguishing it from siblings like 'kb_onboard' or 'kb_quick_setup'. However, it doesn't explicitly differentiate from 'kb_get_all' or 'kb_get_context', which might also provide status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'kb_onboard' (for onboarding), 'kb_quick_setup', or other 'kb_get_*' tools. It mentions 'whether onboarding is needed' but doesn't clarify if this is the primary use case or how it relates to sibling tools.
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 it's a list operation, implying read-only behavior, but doesn't mention any constraints like pagination, rate limits, authentication needs, or what 'structures' entails in the return. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by clearly stating what the tool does, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 0% schema description coverage for the parameter, the description is incomplete. It doesn't explain what 'structures' means in the output, how results are formatted, or any behavioral constraints, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'forms' but doesn't explain the 'type' parameter or its enum values ('onboarding', 'quick', 'all'). With 0% schema description coverage and 1 parameter, the description adds minimal value beyond the schema. The baseline is 3 since it doesn't compensate for the coverage gap but doesn't worsen understanding either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available forms and their structures'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'kb_get_all' or 'kb_search' that might also retrieve form information, 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/5Does 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 'kb_get_all' or 'kb_search' from the sibling list. It also doesn't mention prerequisites, context requirements, or any 'when-not-to-use' scenarios, leaving the agent with minimal usage 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 the tool 'Returns questions for the specified category,' which implies a read-only, non-destructive operation, but lacks details on interactivity (e.g., user prompts, session handling), response format, or potential side effects. This is inadequate for a tool that initiates an interactive process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and output. There's no wasted language or redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive onboarding with no output schema) and lack of annotations, the description is incomplete. It doesn't explain the interactive nature (e.g., how questions are presented or answered), return format, or how it integrates with other tools like kb_update_* for storing responses. This leaves significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specified category,' aligning with the single parameter 'category' in the input schema. With 100% schema description coverage, the schema fully documents the parameter's enum values and default. The description adds minimal semantic context (e.g., that categories relate to 'questions to ask'), but doesn't elaborate beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Start interactive onboarding') and resource ('collect initial information'), specifying what the tool does. It distinguishes from siblings like kb_quick_setup or mcp_instruct_onboarding by focusing on question collection rather than setup or instruction. However, it doesn't explicitly differentiate from all siblings (e.g., kb_get_* tools), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when to choose it over siblings like kb_quick_setup for setup, kb_get_* tools for retrieving information, or mcp_instruct_onboarding for instruction. There's no context on prerequisites, timing, or exclusions, leaving usage unclear.
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 only states it's an update operation. It doesn't disclose behavioral traits such as permissions needed, whether it overwrites or merges data, error conditions, or what happens if parameters are omitted. This is inadequate for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It should explain more about the update behavior, parameter interactions, and expected outcomes to compensate for the lack of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists three parameters (currentProjects, technologies, goals) but the schema has six parameters total with 0% coverage. It adds some meaning by naming these fields, but doesn't explain the other three parameters (challenges, teamSize, methodology) or provide format details, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('project context'), specifying the fields being updated (current projects, technologies, goals). It distinguishes from some siblings like kb_get_projects (read vs. write) but doesn't explicitly differentiate from other update tools like kb_update_personal or kb_update_professional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites, timing, or compare with sibling tools like kb_update_personal or kb_get_projects, leaving the agent to infer 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. While it mentions 'sets up personal profile and AI agent' which implies a write/mutation operation, it doesn't describe what this setup entails, whether it's reversible, what permissions are required, or what happens if onboarding fails. For a tool that presumably modifies user state, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that front-loads the main purpose. Every word earns its place, though it could potentially benefit from slightly more context given the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that presumably performs user onboarding (a potentially complex, state-changing operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what 'onboarding process' entails, what gets set up, what the expected outcomes are, or how this differs from related sibling tools. The context signals show nested objects and multiple action types, suggesting more complexity than the description addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain what 'quick_setup' action entails versus 'start', or provide context about the data fields. Baseline 3 is appropriate when 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Start') and resource ('MCP Instruct onboarding process'), and explains what it does ('sets up personal profile and AI agent'). However, it doesn't explicitly differentiate from sibling tools like 'kb_onboard' or 'kb_quick_setup', which appear related to onboarding/knowledge base 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/5Does 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. With multiple sibling tools like 'kb_onboard', 'kb_quick_setup', 'agent_activate', and others that might overlap in functionality, there's no indication of when this specific onboarding tool is appropriate versus those other options.
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 retrieves information ('Get'), implying a read-only operation, but doesn't specify what data is returned (e.g., agent ID, name, status), whether it requires authentication, or if there are rate limits. For a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose ('Get the currently active agent'), making it immediately understandable. Every word earns its place, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 'active agent' means in this context, what information is returned, or how this tool fits into the broader agent management system. For a tool that likely returns structured data about an agent, more context is needed to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets the baseline expectation. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the target resource ('the currently active agent'), making the purpose immediately understandable. It distinguishes from siblings like agent_list (which presumably lists all agents) and agent_switch_quick (which changes the active agent). However, it doesn't specify what information about the active agent is retrieved, 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/5Does 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., whether an agent must be active), compare it to agent_list for broader listings, or explain its role in workflows with tools like agent_activate or agent_switch_quick. Usage is implied but not explicitly stated.
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 the tool exports data but doesn't specify whether this is a read-only operation, if it requires permissions, what the export scope is (e.g., all data or filtered), or any side effects like file generation. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 any fluff or redundancy. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description is minimally complete for a simple export operation. However, it lacks details on behavioral aspects (e.g., export format specifics, error handling) and doesn't differentiate from siblings, which could be important in a server with many knowledge base tools. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the action and output. A baseline of 4 is applied since no parameters exist, and the description doesn't add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('knowledge base') with the output format ('as JSON string'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'kb_import' or 'kb_get_all', which would require a more detailed comparison to achieve 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/5Does 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 such as 'kb_get_all' (which might retrieve knowledge base data in a different format) or 'kb_export' versus 'kb_import'. There's no mention of prerequisites, timing, or exclusions, leaving usage context entirely implicit.
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 only states what the tool does ('List all available AI agent personas') without describing how it behaves—such as whether it returns a paginated list, the format of the output, any permissions required, or error conditions. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundant information. It is front-loaded and efficiently communicates the essential function, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers the basic purpose. However, it lacks details on behavioral aspects like output format or usage context, which are important for a tool that likely returns a list. With no annotations and no output schema, the description should do more to compensate, but it only meets the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented because none exist. The description does not mention any parameters, which is appropriate and adds no unnecessary information. Baseline is 4 for 0 parameters, as the description correctly aligns with the schema's lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and the resource ('all available AI agent personas'), distinguishing it from sibling tools like agent_activate (activate), agent_get_active (get active), and agent_get_tools (get tools). It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists 'all available' personas, suggesting it should be used when needing a comprehensive overview. However, it does not explicitly state when to use this tool versus alternatives like agent_get_active (which might list only active ones) or provide any exclusions or prerequisites for usage.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/hlsitechio/mcp-instruct'
If you have feedback or need assistance with the MCP directory API, please join our Discord server