Works With Agents MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Most tools target clearly distinct resources and actions, with the wwa_ prefix helping to group them. However, wwa_handoff_verify and wwa_handoff_validate_schema both validate handoffs and could be confused, as could wwa_bid_search and wwa_bid_list despite their differing purposes.
Naming Consistency4/5
All tools share the wwa_ prefix, and the majority follow a noun_verb pattern (e.g., wwa_bid_search, wwa_sla_validate). The main deviation is wwa_generate_key, which uses verb_noun ordering, and a few compound names like wwa_facts_list_categories add minor complexity.
Tool Count3/5
With 22 tools, the server is on the heavier side (16-25 tools per the rubric) but not extreme. The wide range of domains (tenders, bids, facts, skills, handoffs, blueprints, etc.) makes the count feel somewhat bloated, though each tool does have a distinct role.
Completeness3/5
Several resources have incomplete lifecycles: bids can be indexed and retrieved but not updated or deleted; facts and skills only support querying/list categories, with no create/update/delete; handoffs have create and validation but no retrieval or management operations. These gaps are notable but not critical, as the server may focus on specific workflows rather than full CRUD.
Average 3.9/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention what the search returns, how it matches queries, pagination, or any other operational behavior. The licensing note about blueprints is informational but does not clarify 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, economically written, and front-loaded with the core purpose. The second sentence adds relevant context about blueprint content and licensing without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what results look like or any usage context. It lacks return format information and alternative tool guidance. For a simple search tool, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The description adds examples of blueprints (e.g., 'handoff protocols', 'trust scoring') which may help infer query context, but does not add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the Works With Agents blueprint registry.' This provides a specific verb and resource. However, it does not explicitly differentiate from sibling tools like wwa_blueprint_validate, though the resource name 'blueprint' helps distinguish it from other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as wwa_blueprint_validate or other search tools. It only explains what blueprints are, not the conditions or context for choosing this search 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that results are combined and deduplicated, but it also claims a 'status' filter that is not present in the input schema, which is misleading. It omits important details such as return format, pagination, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with three sentences covering source, deduplication, and filters. The inclusion of the unsupported 'status' filter is unnecessary, but the overall structure is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable overview of the tool's function and sources, but it lacks details about the return structure, default behavior, and how the include flags interact. The unsupported 'status' claim further highlights incompleteness, as it suggests a capability that is not backed by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all 6 parameters, so the baseline is 3. However, the description adds no meaningful semantics beyond the schema and incorrectly mentions a 'status' filter that has no corresponding parameter. This mismatch reduces clarity and can mislead an agent about available filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and clearly identifies the resource: UK public-sector tender opportunities from Contracts Finder and Find a Tender. It further notes deduplication, which helps distinguish it from sibling search tools like wwa_bid_search, though the unsupported 'status' filter introduces minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for searching UK public-sector tenders, but it does not explicitly state when to prefer this over sibling search tools such as wwa_bid_search or wwa_blueprint_search. There is no exclusion guidance or alternative recommendation, so the usage guidance is implied rather than explicit.
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. It discloses a read/list operation but misleadingly says 'all bids' while the schema shows a default limit of 20. No mention of ordering, pagination, auth requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded verb and resource. No filler or redundant phrasing; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 optional params and no output schema, it's mostly adequate. However, the default-limit mismatch and lack of usage guidance leave gaps in behavioral and contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value by calling status/client 'optional filters' but provides no extra semantics beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List all bids in the library' with a specific verb and resource, and mentions optional filters. However, it doesn't explicitly differentiate from sibling tools like wwa_bid_index or wwa_bid_search, though the 'list all' scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance. The phrase 'List all bids' implies use for broad listing, and the optional status/client filter hints at use cases, but there is no exclusion or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool reads from "directories under ~/.hermes/skills/" and that it returns counts, offering some insight into the operation. However, it does not explicitly state side-effect-free or read-only nature, nor any potential limitations, which is a moderate gap given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the core function and the underlying data source. Every word adds value, and there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool, the description is largely complete. It conveys that the output includes categories and counts, and it explains the source (directories under ~/.hermes/skills/). The lack of an explicit return format is a minor omission, but given the tool's simplicity, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds no parameter-specific details, but none are needed. Per the rubric, a baseline of 4 applies for tools with 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "List all available skill categories and their counts." This uses a specific verb and resource, and while it doesn't explicitly distinguish from sibling tools like wwa_facts_list_categories, the term 'skill categories' unambiguously scopes the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any preconditions, context, or exclusions, leaving the agent to infer usage solely from the tool's name and sibling set.
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?
There are no annotations, so the description must carry the burden. It does not disclose whether the operation is read-only, what the return value is, or whether any state changes occur. The only behavioral hint is 'Validates' and 'Implements... Framework', which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No wasted words; the framework reference adds context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, yet the description does not explain expected return values or error behavior. It gives a clear purpose but lacks depth for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it only mentions the tier names that match the schema's enum-like description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate'), identifies the resource ('agent fleet metrics'), and scopes it to SLA tier thresholds ('best-effort, production, or regulated tiers'). It distinguishes itself from sibling tools like wwa_compliance_check by referencing the Works With Agents SLA Framework v1.0.0-draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to check SLA compliance but does not explicitly state when to use this over alternatives or when not to use it. It provides context ('Checks whether your agent fleet meets service level guarantees') but no exclusions.
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 does not mention whether the operation is read-only, side effects, authentication requirements, or the return format. The only added context is the spec version, which is insufficient for an agent to anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear verb-first structure. The regulation examples and spec mention are useful but make the description slightly denser than necessary. Still, every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and inputs, but with no output schema and no annotations, it fails to state the result or return format. The agent knows it validates, but not what a validation outcome looks like. This is a notable gap, though not fatal for a straightforward check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with all three parameters described. The description adds some context by referring to 'ruleset' and 'implementation config' and listing example regulations, but it does not add syntax or nested structure details beyond what the schema already provides. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates an agent implementation against a Compliance-as-Code ruleset, naming specific regulations and emphasizing its regulation-agnostic nature. This distinguishes it from sibling validation tools focused on SLA, blueprint, or handoff validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: supply any ruleset and implementation config to perform compliance validation. It implies when to use the tool through examples like 'DTAC, FCA, GDS, GDPR, SOC2, ISO 27001', but it does not explicitly exclude alternatives or state when not to use it.
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 that the tool validates and checks conformance, but does not disclose whether this is read-only, what side effects occur, whether it requires specific permissions, or what the result/return payload looks like. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action. Every sentence contributes meaningful information, with no filler or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool validates implementations and has nested parameters, but the description does not mention the return format or success/failure indicators, and no output schema is provided. It gives enough context to understand the tool's purpose but not enough to fully anticipate invocation results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds useful context by naming blueprint types like 'handoff' and 'deployment manifest', which aligns with schema examples, but it does not substantially deepen parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate') and resource ('implementation against a blueprint specification'), and gives concrete examples ('handoff, deployment manifest, or trust score implementation'). This makes the tool's purpose unambiguous and distinguishes it from related validation tools like wwa_sla_validate and wwa_handoff_validate_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool: when checking whether a handoff, deployment manifest, or trust score implementation conforms to the spec. It does not explicitly mention when not to use it or point to alternatives, but the examples provide enough contextual guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that the tool validates structure, required fields, and completeness, and it highlights the benefit of preventing context loss. However, it does not disclose whether the operation is read-only, what the return value or error behavior looks like, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with each sentence contributing value. The first sentence states the core purpose, the second specifies what is validated, and the third explains the consequence. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter with schema descriptions, but no output schema or annotations. The description explains what the tool validates and why, but it does not describe the return value or outcome of verification, nor does it contrast the tool with closely related siblings like wwa_handoff_validate_schema. This leaves gaps for an agent deciding whether to use this tool and interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the 'handoff' parameter with 100% coverage. The tool description adds no additional meaning about the parameter beyond stating it is the handoff document to verify, so 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a handoff document before accepting it, specifying the action (verify), resource (handoff document), and context (before accepting). However, it does not explicitly distinguish itself from the sibling tool wwa_handoff_validate_schema, which likely has overlapping validation responsibilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before accepting it' provides clear context for when to use the tool: when an agent is about to accept a handoff document. While it does not mention alternatives or exclusions, this timing guidance is explicit enough to guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It does disclose that results include 'snippets with relevance scores' and that matching is semantic. However, it does not mention potential limitations, auth requirements, rate limits, or whether the operation is read-only (though this is likely implied for a search 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero fluff. Every sentence provides meaningful information: what it does and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with no output schema, the description explains purpose, return format (snippets and relevance scores), and gives an example query. It is complete enough for an AI agent to use effectively, though it could mention result ordering or default limit behavior (though limit is in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds an illustrative example for the query parameter ('social value methodology', 'pricing approach') which aids understanding but does not fundamentally change parameter semantics. Baseline 3 applies since the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'semantic search across the bid content library' and 'finds relevant past bids by matching against stored content.' This is a specific verb+resource combination that distinguishes it from sibling tools like wwa_bid_list (listing) and wwa_bid_get (retrieval of a specific bid).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding past bids via semantic matching but does not explicitly state when to use this over alternatives like wwa_tender_search or wwa_blueprint_search. There is no exclusion or guidance on when not to use, making usage partially implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does disclose a key conditional behavior: 'Can use AI analysis if API key provided.' However, it does not mention any side effects, prerequisites (e.g., whether a profile is required), or what happens when the optional profile is omitted. The statement 'against your bidder profile' conflicts with schema-marking profile as optional, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output. Every clause adds value (purpose, evaluation method, output details, optional AI behavior). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential return values and hints at AI capability, but it leaves gaps: it does not explain the optional profile behavior, what 'AI analysis' entails beyond a score, or error conditions. The lack of an output schema makes the return-value mention useful, but the inconsistency about profile usage reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds minimal extra meaning beyond the schema: it mentions 'bidder profile' and the AI conditional, but these are already partially covered in the parameter descriptions (e.g., use_ai description mentions 'AI-powered analysis'). It does not clarify the 'tender' format beyond the schema's reference to wwa_tender_search results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Go/no-go scoring for a tender opportunity' and specifies the outputs ('score (0-100), verdict, risks, and strengths'). It uses a specific verb ('scoring') and identifies the resource ('tender opportunity'), which distinguishes it from sibling tools like wwa_tender_search (searching) or wwa_compliance_check (compliance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used to evaluate a tender for go/no-go decisions by comparing against a bidder profile. However, it does not explicitly mention when to avoid this tool or provide alternative tool names. This is a minor gap, but the context is unambiguous enough for an agent to decide.
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 for behavioral disclosure. It only states 'Query' and what facts are, but does not mention that the tool is read-only, how results are returned, pagination behavior, or any side effects. The description adds context about content but not about the tool's operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the action and resource, the second gives essential context on what facts are. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (4 optional params, no output schema), but the description does not explain what the query returns (e.g., a list of matching facts) or how filters combine. It is adequate for understanding the core purpose but incomplete for an agent to fully anticipate the tool's output without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions (100% coverage), but the description enriches the meaning by giving examples like 'Python paths, project structures, preferences, deployment targets', which help agents map the 'entity' and 'category' parameters to concrete values. This goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Query' with a clear resource ('shared agent knowledge base') and defines what facts are ('structured environment truths'), which distinguishes it from sibling tools like wwa_facts_list_categories or wwa_skills_search. It is not a tautology and gives concrete examples of fact content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Agents discover facts without re-asking users or searching blindly.' This implies the tool is for retrieving known environment truths. However, it does not explicitly name alternatives or explain when not to use it, such as when listing categories is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return contents but does not state operational traits such as read-only nature, error behavior when the ID is not found, or any required permissions. For a simple get operation, the risk is low, but the description could still add a note about not modifying data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the primary action, and includes the key return details without any fluff. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with 100% schema coverage, the description is largely complete. It states input (ID), output (full content), and return structure (text, metadata, sections). It does not mention error handling or what happens for invalid IDs, but given the low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'id' with a clear description ('Bid ID from wwa_bid_search or wwa_bid_list'). The tool description adds no new meaning beyond confirming the ID is used to fetch the bid, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to fetch the full content of a specific bid by ID, and explicitly lists what is returned (text, metadata, sections). This is a specific verb+resource description that distinguishes it from sibling search/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its ID' and the mention of returning full content imply this is the retrieval step after obtaining an ID from wwa_bid_search or wwa_bid_list. However, it does not explicitly name alternatives or exclusions, so a dedicated usage note would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that content is stored locally with full-text search, which is useful. But it omits details about whether the operation is idempotent, overwrites existing entries, requires authentication, or returns a reference/ID for the indexed bid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema, the description adequately explains the purpose and storage behavior, making it clear how the tool fits into the workflow. It could mention what happens after indexing, but full-text search is already noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional information about parameters, remaining at baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Index' and the resource 'past bid or proposal into the bid content library.' It distinguishes this write operation from sibling search/list/get tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Use this to build a library of past responses for future drafting') and implies it is a write operation distinct from the sibling bid_search/bid_list/bid_get. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by listing what checks are performed (types, UUIDs, status values, protocol compliance) and mentions the strictness relative to verify. However, it does not disclose return format, error behavior, or whether the operation is read-only, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds meaningful information. No filler or repetition of schema/annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with no output schema and no annotations, the description is fairly complete: it names the protocol version, lists the validation aspects, and contrasts with the verify tool. It could be more complete by describing the return/pass-fail behavior, but as a tool-invocation aid it gives sufficient context for an agent to select and use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter fully with 'The handoff document to validate' at 100% coverage, so a baseline of 3 is warranted. The description adds context about the protocol version and validation criteria, but does not explain the document structure or provide parameter-level syntax beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific action: full schema validation of a handoff document against a named protocol version. It also distinguishes itself from sibling tool wwa_handoff_verify by explicitly noting it is stricter, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Stricter than verify' provides a clear comparison to a sibling tool, giving context for when this tool is more appropriate. It does not explicitly list exclusions or when-not-to-use scenarios, but the alternative is named and the stricter scope is communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'Search' implies a read-only operation, and the description adds context about the nature of skills ('exact commands, known pitfalls, verification steps'), but it does not disclose details like result format, pagination, or rate limits. It is not misleading, but it offers only minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the action, the second describes the content domain, and the third gives usage guidance. The description is front-loaded and free of redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple search tool with well-documented parameters, the description adequately covers what the tool does, the nature of the data, and when to use it. The lack of an output schema means return structure is not described, but the domain context ('skill library', 'procedures') gives the agent a reasonable expectation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (query, limit, category) have explicit schema descriptions with 100% coverage. The description adds no parameter-specific semantics beyond what the schema already provides, so the baseline score stands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search the agent skill library for reusable workflows' – a specific verb and resource that clearly distinguishes this from sibling search tools like wwa_bid_search or wwa_blueprint_search. It further clarifies that skills are 'battle-tested procedures', establishing a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Before tackling a new task, search here – the procedure might already exist', giving clear usage context. However, it does not name alternative tools or state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the weighted calculation and return values, which adds transparency, but it does not explicitly state whether the operation is read-only or if it has side effects. For a calculation tool, this is a minor gap, but still leaves some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences with no filler. The first sentence front-loads the core purpose, and the second efficiently lists the formula weights and output types. Every word contributes to agent understanding, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, computation method, and output (score, tier, autonomy level, recommendations). Given there is no output schema, this return-value disclosure is crucial and well-handled. The only omitted element is a statement about operational side effects, but this is likely implicit for a read-only calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes each parameter, giving a baseline of 3. The description adds extra semantic value by mapping parameters to their weights (e.g., success_rate 30%, uptime_percentage 15%), explaining the relative importance of each input. This goes beyond the schema's simple range descriptions, justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Calculate an AI agent trust score using the Works With Agents Trust Score spec v1.0.0-draft.' It names the specific verb, resource, and spec version, distinguishing it from sibling tools like wwa_bidmate_score which focus on bid scoring. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage by stating what it does and the formula, but it does not explicitly say when to use this tool over alternatives. No exclusions, prerequisites, or alternative tool references are provided. The context is clear enough for an agent to infer, but it lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It states that the call requires no authentication, returns a key with 'free' tier, and that the key is used via 'x-api-key' in later calls. This is meaningful behavioral context that goes beyond the schema. It doesn't detail rate limits or key expiration, but for a simple key-generation tool, the provided transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, with the primary verb and object up front. Every clause adds value: purpose, auth behavior, return tier, and usage instruction. No redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essential workflow: what the tool does, that no auth is needed, what the response includes ('free' tier key), and how to use the key. The only slight omission is the exact return format (e.g., JSON shape), but the usage instruction via 'x-api-key' partially compensates. Overall it's complete enough for the agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'name' with a description and default, covering 100% of parameters. The schema already explains the label's meaning with examples. The main description adds no additional parameter semantics, but the baseline of 3 applies because schema coverage is high and the parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a new API key for accessing Works With Agents MCP tools.' This clearly distinguishes the tool from its siblings, none of which handle key generation. The purpose is unambiguous across the full description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage context: 'No authentication required' and instructs to 'Use the returned key in subsequent calls via the 'x-api-key' argument.' While it doesn't name alternative tools (because none exist for key generation), it tells the agent exactly when and how to use the tool in a workflow. The only minor gap is not stating when not to use it, but that is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the structured nature, data integrity guarantees, and protocol compliance (Works With Agents Handoff Protocol v1.0.0-draft). It does not cover failure modes or permissions, but the described behavior is more informative than typical create tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and purpose. Every clause adds value—no filler. It is efficient and well-structured for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (10 params, all described) and no output schema, the description sufficiently covers the protocol and guarantees. It could more clearly differentiate from sibling verification/validation tools, but the combination of schema coverage and description provides adequate context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with all parameters described, so baseline is 3. The description adds no parameter-specific details, but the overall theme of context transfer aligns with the context parameter. It does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a clear resource 'structured agent-to-agent task handoff'. It explains the purpose: transferring an in-progress task to another agent with complete context. This distinguishes it from sibling verification/validation tools like wwa_handoff_verify and wwa_handoff_validate_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: 'When one agent must transfer an in-progress task to another'. It also highlights key guarantees (no data loss, no silent drops, full attribution chain). However, it does not explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'Proves that an agent with a given public key signed a specific message' and mentions the protocol version, giving meaningful behavioral context. However, it does not disclose return values or error handling for invalid signatures, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action ('Verify an agent's Ed25519 cryptographic signature'). Each sentence contributes distinct information: the action, the proof semantics, and usage contexts with protocol version. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, usage contexts, and protocol implementation, and the schema covers all parameters. Given the simplicity of the tool (cryptographic verification), the missing return value description is a minor gap. With no output schema, stating whether it returns a boolean or a detailed result would improve completeness, but the description is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for all five parameters, and the tool description does not add any parameter-level detail beyond what the schema already provides. With 100% schema coverage, the baseline of 3 applies; the schema itself adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and a clear resource ('an agent's Ed25519 cryptographic signature'), immediately stating what the tool does. It also differentiates from sibling tools by naming concrete use cases (subagent output verification, capability attestation, agent-to-agent authentication) and the protocol version, making its role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by listing three specific scenarios where the tool should be used: subagent output verification, capability attestation, and agent-to-agent authentication. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to determine when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the data provenance ('real agent failures — not LLM hallucinations') and scope ('deployment, packaging, tooling, configuration'), giving agents confidence in what the search returns. It does not detail edge cases or result format, but for a read-only lookup this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly written sentences front-load the core purpose, then add source credibility, coverage scope, and a usage call-to-action. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 3-parameter search tool with no output schema. The description fully enables an agent to decide when and how to invoke it, covering purpose, data source, and scope. No additional return-value explanation is critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (query, limit, category all have descriptions). The description adds no parameter-specific syntax or semantics beyond schema, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search known failure patterns and verified fixes.' It clearly differentiates from sibling search tools like wwa_facts_query and wwa_bid_search by focusing on pitfalls and failure patterns, and adds credibility with 'real agent failures — not LLM hallucinations.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Before debugging something new, check here first — someone probably broke it already.' However, it does not mention alternatives or when-not-to-use, so it lacks full exclusion logic present in a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool 'Returns' a guide with specific sections, implying a read-only retrieval operation. It does not mention side effects, authentication, or rate limits, but for this simple informational tool, the description adequately conveys expected 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose, followed by specific content details. Every sentence contributes valuable information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool of low complexity, the description is complete. It covers the tool's purpose, what it returns, and when to use it, fully addressing the agent's needs without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter behavior. The baseline score of 4 for zero-parameter tools applies, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a full setup guide for the WWA SPFx Component Scaffolding (Dev-Loop). It specifies the verb 'Get' and lists exact contents (MCP server install instructions, available tools, dashboard features, architecture), which distinguishes it from sibling tools focused on bids, compliance, and other unrelated tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that 'Agents discovering WWA infrastructure call this to learn about the scaffolding tool,' providing clear when-to-use guidance. It does not mention when not to use it or alternatives, but given the uniqueness of this tool among siblings, the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. The verb 'list' implies a read-only operation, and mentioning 'counts' adds return-value detail. It could explicitly state non-mutating behavior, but for a simple list operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence front-loads the action and resource, and the second provides usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description fully covers purpose, output content (categories + counts), and usage context. It is complete and sufficient for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. The description adds meaningful context about the output (counts) and purpose, aligning with the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available fact categories and their counts, using a specific verb (list) and resource (fact categories). It distinguishes itself from sibling tools like wwa_skills_list_categories by explicitly focusing on 'facts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Use this to discover what knowledge domains are available before querying specifics.' This implies when to use it in a workflow, though it doesn't explicitly name alternatives or exclusions. The context is unambiguous for a discovery tool.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vystartasv/wwa-mcp'

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