Wiremi Marketing MCP

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

With no annotations, the description carries full burden; it discloses that the question is logged for improvement purposes (no other personal data) but does not detail response format or underlying routing logic, which is acceptable for a simple Q&A tool.

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

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

The description is two clear sentences plus a note, front-loaded with purpose and usage, with no extraneous words. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature (single string parameter, no output schema) and the presence of specific sibling tools, the description fully covers purpose, usage, and behavioral context, making it complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description adds meaning by stating the question is in 'the user's own words' and explains the logging behavior, which goes beyond the bare schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it handles questions about ROSCAs, savings circles, Wiremi Passport, or how Wiremi works, clearly distinguishing it from sibling tools that cover specific topics like 'what_is_a_rosca' or 'how_a_rosca_works'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description directly states 'Use this when the other tools do not exactly match what the user asked,' providing clear guidance on when to use this tool versus alternatives, and mentions it points to next steps.

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

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

With no annotations, the description carries full burden. It honestly discloses that the answer is 'not yet directly to a credit bureau' but mentions a pilot, and explicitly states 'Never claims bureau reporting is live. No personal data.' This provides clear behavioral expectations.

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

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

Two sentences with no wasted words. The description is front-loaded with the purpose and immediately provides key caveats. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description explains what the tool does (answer a question) and provides the content of that answer. It could be slightly more explicit about the output format (textual explanation), but the overall completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (schema coverage 100%), so baseline 4 applies. The description does not need to add parameter info but adds context about the answer's nuance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool answers whether ROSCA payments build credit in Canada, with a specific verb 'answer' and resource 'credit history'. It distinguishes from sibling tools like 'how_a_rosca_works' or 'what_is_a_rosca' by focusing on credit building.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly tells when to use this tool (credit-building questions) but does not explicitly state when not to use or mention alternatives. However, the sibling tool list provides context and the tool name is self-explanatory.

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

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

With no annotations, description carries full burden. It transparently states the tool explains mechanics, uses a concrete example, and is interest-free with no personal data. Does not mention side effects, but for a read-only explanation tool, 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.

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

One concise sentence covering purpose, example, and constraints. Very efficient, but could be slightly more structured with a brief overview sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description fully covers what the tool does: a static explanation with a concrete example. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. Description adds no parameter info, but none is needed; the tool requires no input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it explains payout mechanics with a concrete example, using specific verb 'explain' and resource 'payout mechanics of a ROSCA'. It distinguishes itself from siblings like 'what_is_a_rosca' (general definition) and 'rosca_payout' (possibly more technical).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for understanding mechanics but lacks explicit when-to-use guidance or alternative comparisons. It mentions 'no personal data' as a safe context, but does not contrast with siblings like 'how_to_start_a_circle' or 'rosca_vs_loan'.

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

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

With no annotations provided, the description carries full burden. It mentions 'Includes app links' and 'No personal data', which disclose some behavioral traits. However, it does not detail the output format or other behaviors like whether the response is static or dynamic.

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

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

The description is one sentence covering all key points but is slightly run-on. It efficiently lists steps and key features without unnecessary words, though it could be broken into clearer segments.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given 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 is complete enough. It tells the user exactly what the tool does (instructions), what it includes (app links), and a notable behavior (no personal data).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so baseline is 4. The description adds context about what the tool does (provides instructions) beyond the empty schema, and it mentions key features (app links, no personal data).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides step-by-step instructions for starting or joining a savings circle on Wiremi. It uses a specific verb ('start or join') and resource ('savings circle on Wiremi'), distinguishing it from sibling tools like 'what_is_a_rosca' or 'how_a_rosca_works' which are more general explanations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (if user wants to start or join a circle, use this tool) but does not explicitly state when to use this tool vs. the sibling tools like 'how_a_rosca_works' or 'what_is_a_rosca'. No alternatives or exclusions are mentioned.

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

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

No annotations provided, so the description carries full weight. It explicitly states 'No personal data' and indicates it's a calculation port with no side effects, which is transparent. However, it doesn't discuss rate limits or authentication needs (implied none).

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

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

The description is very concise, using 4 sentences to convey purpose, inputs, outputs, and provenance without redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple calculator with no output schema; the description fully covers what it returns (pot, turn date, total contribute, per-round, schedule) and notes no personal data, making it complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, requiring the description to explain parameters. It describes members (2-60), contribution, frequency (weekly/biweekly/monthly), and turn (1..members), adding range and default context. However, it does not specify constraints like positive contribution or default values for turn and frequency.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates a ROSCA's payout and schedule, listing inputs and outputs. It distinguishes itself from sibling informational tools by being computational.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies when to use the tool (to compute payout and schedule) and enumerates required inputs, but does not explicitly state when not to use it or compare to alternatives like 'how_a_rosca_works'.

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

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

With no annotations, the description fully carries the burden. It discloses that data is public, includes specific sources, returns a URL and PDF, and emphasizes no personal data is included.

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

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

The description is a single paragraph that efficiently conveys purpose and key details. It could be slightly more concise, but it is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description comprehensively covers the tool's role, content, and output, including data sources and what it returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so baseline is 4. The description adds no parameter info, but none is needed as the tool takes no arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides headline findings from a specific public-data report, distinguishing it from sibling tools like 'what_is_a_rosca' or 'how_a_rosca_works' by focusing on a report summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the tool returns the report URL and PDF for citation purposes, implying usage for obtaining source data. However, it does not explicitly state when not to use it or mention alternative tools.

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

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

With no annotations available, the description discloses that the tool performs a comparison, returns specific financial figures, and mentions it is a faithful port of a known tool with no personal data. It could be more explicit about read-only nature but 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.

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

The description is concise (3 sentences) with no fluff. Purpose is front-loaded, and all content is necessary and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and no output schema, the description sufficiently explains what it returns and the tradeoff. No missing context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description adds crucial parameter constraints: goal >=100, months 2-60, APR 0-60. This provides meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares a ROSCA against a bank loan for the same goal, with specific input parameters and output values. It distinguishes itself from sibling tools like 'how_a_rosca_works' and 'what_is_a_rosca' by focusing on comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for comparing a ROSCA vs. loan but does not explicitly state when to use it over siblings or provide exclusion criteria. Usage context is implied via the comparison goal.

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

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

With no annotations, the description adds value by stating 'No personal data' and 'Pure public education', indicating safety and non-sensitive nature, though it doesn't detail other behaviors like rate limits or idempotency.

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

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

Two concise sentences with clear front-loading, no unnecessary words, and a logical flow from main function to parameter behavior to ethical note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple educational tool with one optional parameter and no output schema, the description fully covers purpose, parameter behavior, and behavioral context, leaving no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the optional 'term' parameter with concrete examples, adding meaning beyond the schema's default value and type, compensating for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool explains what a ROSCA is and can optionally provide cultural origins for given terms, distinguishing it from siblings like 'how_a_rosca_works' or 'rosca_vs_loan'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for general education ('Pure public education. No personal data.') but does not explicitly state when to use this tool versus alternatives like 'ask_wiremi' or 'how_a_rosca_works'.

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

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

No annotations exist, so the description carries full behavioral burden. It honestly discloses key traits: no personal data, not reporting to bureaus, not US payment rails. This transparency is sufficient for a zero-parameter informational tool.

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

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

The description is extremely concise, conveying essential information in one sentence with clear bullet points. Every phrase adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter informational tool with no output schema, the description is fully complete. It tells the agent exactly what to expect: a static explanation of Wiremi's identity and limitations, with no ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With no parameters, the baseline is 4. The description adds value by outlining the content domain, which aids understanding what the tool returns, even though no params are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 explain what Wiremi is and is not, including specific details about regulatory registrations, ROSCA-first nature, and limitations. It distinguishes itself from siblings like 'what_is_a_rosca' and 'ask_wiremi' by focusing on Wiremi's identity and boundaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when seeking an overview of Wiremi's scope and limitations. While it doesn't explicitly state when not to use it, the specificity (e.g., 'not primarily remittance') guides appropriate usage. Siblings cover other aspects, so 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.

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

With no annotations, the description transparently discloses the tool's behavior: it lists live corridors, states status of non-live rails, and notes no personal data. This covers safety and output scope, though it could mention if there are any side effects (none expected).

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

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

Three sentences front-load the key purpose, then detail operational scope and privacy. No wasted words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description adequately covers the return content (live corridors, non-live rails, user limitations). It could hint at output format (e.g., 'returns list'), but overall complete for a simple informational tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100%. The description adds context on what the tool returns (list of corridors, status updates) beyond the empty schema. Baseline 4 applies per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists where Wiremi operates, specifying 'seven live African funding corridors' and explicitly noting that CAD and US funding rails are not live yet. This distinguishes it from sibling tools about roscas and general inquiries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing operational regions, but lacks explicit guidance on when to use this tool versus alternatives like ask_wiremi or what_is_wiremi. No exclusions or prerequisites are mentioned.

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