Nine read-only tools for Chapa developer Impact Profiles, history, badge verification, dimension explanations, profile comparisons, and embed snippets.
Scored across 9 tools
Each tool addresses a distinct concern: profile receipt, history, comparison, dimension explanation, verification, embed snippet, handle resolution, and site capabilities. Despite some conceptual proximity, the descriptions clearly separate what each tool returns.
All tool names follow a consistent lowercase snake_case verb_noun pattern. The get_ prefix dominates, with explain_, compare_, find_, and verify_ as clear, predictable action verbs.
Nine tools is well-scoped for a focused public-profile and badge-reading service. Each tool earns its place, and there is no obvious redundancy or padding.
The toolkit covers the full read-only lifecycle: resolving a handle, fetching the current receipt, viewing history, comparing profiles, explaining dimensions and verification, verifying hashes, and getting embed snippets. No critical gap is apparent for the stated purpose.
Compare two public Chapa impact profiles by the headline each badge draws.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | ||
| other_handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is read-only and non-destructive, so the safety profile is covered. The description adds useful context by noting the profiles are 'public' and that the comparison focuses on badge headlines. It does not describe return format, ordering, or what happens when profiles are not found, but that is less critical given the read-only annotation.
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 concise sentence with no filler. The action and resource are front-loaded, and the comparison criterion is appended efficiently. Every word earns its place.
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 two-parameter read-only tool, the description is serviceable but leaves gaps. It does not explain what the returned comparison looks like, and since there is no output schema, some behavioral disclosure about return values would be helpful. The 'headline each badge draws' phrase hints at the output but does not fully specify it.
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%, so the description must compensate for the undocumented handle and other_handle parameters. The phrase 'two public Chapa impact profiles' weakly implies both parameters are profile identifiers, but it does not clarify handle format, whether order matters, or what valid values look like. This is a meaningful gap for a tool with no parameter documentation.
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 action ('Compare'), the resource ('two public Chapa impact profiles'), and the specific criterion ('by the headline each badge draws'). This distinguishes it from sibling tools like get_impact_profile or find_profile, which retrieve rather than compare. The phrase 'headline each badge draws' is a bit idiosyncratic but does not obscure the core purpose.
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 two profiles rather than retrieving one, which is a clear context. However, it does not explicitly state when to prefer this over alternatives such as get_impact_profile or verify_badge, nor does it mention any exclusions or prerequisites. 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.
Explain one impact dimension for a public profile's current v7.2 receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | ||
| dimension | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the word 'Explain'—it doesn't mention output format, level of detail, or any side effects. It is consistent with annotations but adds minimal value.
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?
A single sentence with zero filler, front-loaded with the action and resource. Every word earns its place, making it easy to parse quickly.
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?
With no output schema and two parameters, the description is incomplete. It doesn't clarify what 'current v7.2 receipt' implies (e.g., profile must have one) or what the explanation looks like. An agent lacks sufficient context to call this correctly without additional assumptions.
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%, so the description must clarify parameters. It names 'handle' and 'dimension' but doesn't explain what 'handle' refers to (e.g., a public profile handle) or define the dimension values beyond the enum in the schema. The agent must infer meaning, which is risky.
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 states a specific verb ('Explain'), a clear resource ('one impact dimension for a public profile's current v7.2 receipt'), and adds version specificity ('v7.2'), which distinguishes it from generic profile tools. While it doesn't explicitly name a sibling, the combination of verb and resource makes the purpose unambiguous and distinct.
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 provides no guidance on when to use this tool versus alternatives like get_impact_profile or explain_verification. It doesn't mention conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name alone. There is no explicit 'when-not' or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain Chapa badge verification guarantees and limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond annotations by clarifying that this tool provides an explanation rather than performing a verification action, which is a distinct behavioral trait.
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, well-structured sentence with no filler or redundant phrasing. The verb is front-loaded and every word contributes to understanding the tool's purpose.
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 read-only informational tool, the description sufficiently conveys what the tool does and its scope. It does not specify the exact response format, but the verb 'explain' strongly implies a natural-language output, which is acceptable given the absence of an output schema.
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?
This tool has zero parameters, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description does not add unnecessary parameter-related noise.
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 uses the specific verb 'Explain' and names the exact resource 'Chapa badge verification guarantees and limits', making the tool's function unambiguous. It distinguishes itself from sibling verify_badge, which would perform verification rather than describe it.
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 a usage context — use this when an explanation of verification guarantees and limits is needed, not actual verification. However, it does not explicitly state when to prefer this over siblings like verify_badge or explain_dimension, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a GitHub handle to its Chapa profile and badge URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with this. It adds the output scope (profile and badge URLs) but does not disclose return structure, error behavior, or any rate limits; not a contradiction.
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?
Single sentence, front-loads the action and input, with no filler. Every word 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?
For a one-parameter, read-only lookup the description conveys the essential workflow: input handle, output profile/badge URLs. It is adequate but lacks explicit differentiation from sibling tools and any details about output format or failure modes.
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 provides only 'handle' as a string with no description (0% coverage). The description compensates by identifying the handle as a GitHub handle and as the input to resolve, giving the parameter a meaningful semantic role.
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?
States a specific action 'Resolve' with a clear resource ('GitHub handle' to 'Chapa profile and badge URLs'). It is self-contained but does not explicitly distinguish itself from siblings like get_impact_profile or verify_badge.
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's use case—when you have a GitHub handle and need profile/badge URLs—but gives no explicit 'when to use' vs alternatives. No exclusions or comparison with sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return ready-to-paste Markdown and HTML for a live Chapa badge.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and non-destructive, so the description doesn't need to repeat that. It adds the output format (Markdown and HTML) but does not disclose other behavioral details such as required authentication, potential errors, or whether the badge status affects the snippet. No contradiction with annotations.
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, front-loaded sentence with no filler words. It states the action and the deliverable directly, making it easy to scan.
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 simple with one parameter and annotations cover side effects, so the description is mostly adequate. However, the lack of any parameter clarification and the absence of an output schema leave a notable gap for an agent trying to construct a correct call.
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% and the description does not explain what 'handle' means or how it should be supplied. The name suggests an identifier for the badge, but an agent would have to infer whether it's a username, badge ID, or slug, and no format or example is provided.
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 uses a specific verb ('Return') and identifies a concrete deliverable ('ready-to-paste Markdown and HTML for a live Chapa badge'), making the tool's function immediately clear. It is clearly distinct from sibling tools like verify_badge or get_impact_profile, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (need to embed a live Chapa badge) but does not explicitly state when to prefer this tool over alternatives or mention any exclusions. There is no direct comparison to sibling tools, though the specific phrasing gives some contextual signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current v7.2 observed history (daily winners and trend) for a GitHub handle.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds some useful context (v7.2, daily winners, trend), but it does not disclose output shape, error behavior, or any limitations. This is moderate transparency given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the action and resource. Every word contributes meaning, and there is no redundant or vague filler.
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 one-parameter read-only retrieval tool, the description covers the core context: what is returned and for whom. It does not fully describe the return structure since there is no output schema, but 'daily winners and trend' gives enough conceptual completeness for basic agent selection and 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?
Schema coverage is 0%, so the description carries the burden for parameter meaning. It does clarify that the single string parameter is a GitHub handle, which adds domain meaning beyond the raw schema. However, it gives no format, normalization, or validation details, so the compensation is only partial.
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 begins with a specific verb ('Return') and names a precise resource: 'current v7.2 observed history (daily winners and trend)' for a GitHub handle. It clearly distinguishes this tool from siblings like get_impact_profile by focusing on historical data rather than a profile snapshot.
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 when to use the tool—when you need a GitHub handle's daily winners and trend history—but it gives no explicit exclusions or comparisons to sibling tools. There is no guidance on when another tool, such as get_impact_profile or compare_profiles, would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current v7.2 receipt for a GitHub handle: displayScore and displayTier are the headline the badge draws. When there is no drawable current receipt yet, returns scoringStatus instead (collecting, action needed, unregistered, or ready-and-updating).
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description builds on that by adding the fallback behavior when no drawable receipt exists, and lists the possible scoringStatus values. It also specifies the version (v7.2) and the headline fields, which adds context beyond the annotations without contradicting them.
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 sentences, with the primary purpose and headline fields front-loaded, followed by the fallback behavior. Every phrase adds value, and 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, read-only annotation, no output schema), the description covers the essential return values (displayScore, displayTier) and the fallback (scoringStatus with its possible values). It lacks a detailed structure of the response object, but this is adequate for a tool with a single parameter and no complex schema.
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 schema description coverage at 0%, the description must clarify the handle parameter. It does mention 'GitHub handle', which adds minimal context, but does not specify format, pattern, or validation rules. For a single simple string parameter, this is a slight improvement over the schema but still limited.
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 states a specific verb 'Return' and resource 'current v7.2 receipt for a GitHub handle', making the tool's purpose clear. It mentions the headline fields (displayScore, displayTier) but does not explicitly differentiate from siblings like get_impact_history or find_profile, though the 'current receipt' phrasing implies a distinct temporal scope.
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 does not provide guidance on when to use this tool versus alternatives such as get_impact_history or find_profile. It only describes the tool's behavior and fallback condition (scoringStatus), but no explicit when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe Chapa and list its agent-facing tools and entry points.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true and destructiveHint=false. The description adds context about the output scope, namely a description of Chapa and a listing of agent-facing tools/entry points, but it provides no additional behavioral details such as auth requirements, response format, or any caveats. This is a modest but useful addition over the annotations.
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, tightly worded sentence that leads with the main verb and immediately conveys the purpose. There is no redundancy or filler, making it an efficient and well-structured description.
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, read-only discovery tool with safety annotations, the description adequately conveys what the call returns and why an agent would use it. It does not describe the exact structure of the returned list, but with no output schema that is not necessary, and the scope is sufficiently clear.
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 tool takes zero parameters, so the description has no parameter-level details to add. Per the baseline for zero-parameter tools, a score of 4 applies because the empty schema already fully documents the input contract.
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 names the resource (Chapa) and two explicit actions: describe and list agent-facing tools and entry points. This distinguishes it from sibling profile- and verification-focused tools, which operate on individual profiles rather than site-level capabilities.
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 does not explicitly state when to use this tool over siblings or mention alternatives. However, the name and phrasing imply it serves as an initial discovery/entry point for learning about Chapa's available tools and entry points, so usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the public verification result for a Chapa badge hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the context that the result is 'public', implying no authentication is needed, which is useful beyond the annotations. However, it does not disclose the output format or any additional behavior (e.g., error handling, network calls). Given the annotation coverage, the description adds a modest amount of context, warranting a 3.
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?
A single sentence with no filler or redundant phrasing. It is front-loaded with the action and resource, and every word contributes to the meaning. Ideal for quick parsing.
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 simple with one parameter and no output schema. The description explains the purpose but does not specify what the 'public verification result' contains (e.g., boolean, status string, detailed report). Since there is no output schema, the agent must infer the return shape from the name and description. This is a gap that could be filled with a brief mention of the response format. For a low-complexity tool, this is adequate but not complete.
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%, so the description must compensate for the hash parameter. It identifies the parameter as a 'Chapa badge hash', giving it semantic meaning beyond the raw 'hash' name. This helps an agent understand what value to provide. However, it does not explain the pattern constraints or the accepted formats (e.g., 8/16/32 hex chars or UUID-like v7 format), which the schema defines. The description adds some value but leaves room for clarification.
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 action ('look up'), the resource ('public verification result for a Chapa badge hash'), and the scope (public). This distinguishes it from siblings like explain_verification, which would explain the process rather than return a result. The purpose is unambiguous and specific.
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 when to use it (to retrieve a verification result) but does not explicitly contrast it with alternatives like explain_verification or compare_profiles. It gives context that this is a direct lookup, which suggests it should be used when the raw result is needed, but no exclusions or conditions are stated. This falls under 'implied usage' with room for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
verify_badge1 field changedInput schema / properties / hash / patternPrevious value: -"^(?:[0-9a-f]{8}|[0-9a-f]{16}|[0-9a-f]{32})$"New value: +"^(?:[0-9a-f]{8}|[0-9a-f]{16}|[0-9a-f]{32}|v7\\.[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}\\.[0-9a-f]{64})$"compare_profilesexplain_dimensionexplain_verificationfind_profileget_embed_snippetget_impact_historyget_impact_profileget_site_capabilitiesverify_badge
Add one secure layer between your agents and this server.