canforge-mcp

Official

by canforge

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct operation on DBC or log files. Even the multiple log-analysis tools (probe_log, log_stats, read_frames, decode_log) have clearly defined differences in scope and output.
Naming Consistency4/5
Most tools follow verb_noun pattern (validate_dbc, list_messages, decode_log), but a few are noun-led (dbc_info, log_stats) or compound nouns (signal_timeseries), creating minor inconsistency.
Tool Count5/5
13 tools is well within the ideal range, each covering a unique aspect of DBC and CAN log processing without redundancy.
Completeness5/5
The set comprehensively covers DBC validation, informational retrieval, message/signal access, comparison, and log probing, scanning, decoding, and timeseries extraction. No obvious missing operations for this domain.
Average 3.9/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a safe read-only profile. The description adds the behavioral detail of a 'one full, one-pass scan,' which implies a resource-intensive operation, and clarifies that it observes signals rather than modifying anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the verb and concisely states the tool's purpose. Every word contributes to understanding the operation.
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?
With four parameters and zero schema coverage, the description is too sparse. It doesn't explain the meaning of match_mode or include_values, nor the nature of the inventory output. The presence of an output schema helps, but the description alone is insufficient for an agent to invoke this tool correctly with confidence.
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?
Schema description coverage is 0%, so the description must compensate for parameter semantics. The description only hints at dbc_path and log_path via 'DBC signals' and 'CAN log,' but leaves match_mode and include_values entirely unexplained. No details on acceptable formats, defaults, or effect on output are provided.
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 the specific verb 'Inventory' and names the resource 'DBC signals observed in one full, one-pass scan of a local CAN log,' making the tool's purpose clear. It distinguishes from siblings like search_signals and signal_timeseries by emphasizing the one-pass full scan, though it does not explicitly reference an alternative.
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 alternatives or exclusions are mentioned. The description implies usage when a complete inventory of signals in a log is needed, but it does not state when to prefer this over sibling tools like signal_timeseries or search_signals.
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?
The description adds meaningful behavioral context beyond the annotations: it mentions 'bounded sample' with a 'limit is capped at 500' and explains that 'Filters combine by intersection'. These details are not present in the annotations and help set expectations about the tool's behavior and constraints.
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 word contributes. It efficiently combines purpose and key constraints without wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 0% schema coverage, and no parameter explanations in the description, the agent cannot correctly construct invocations. Required parameters like dbc_path and log_path are not mentioned, and filter semantics are only vaguely referenced. The presence of an output schema helps for return values, but the description lacks essential operational context.
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?
Schema description coverage is 0%, so the description must compensate. It barely does: it mentions 'limit is capped at 500' (referencing the limit parameter) and notes that filters combine by intersection, but it does not explain the key parameters (dbc_path, log_path, time_start, time_end, messages, id_filter) or how they should be formatted. This leaves the agent with significant ambiguity.
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 'Decode a bounded sample of local log frames through a local DBC', specifying the action (decode), resource (local log frames), and scope (bounded sample). This distinguishes it from siblings like decode_frame (which likely decodes a single frame) and read_frames (which may not decode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description does not mention alternatives or provide exclusions. It only implies usage through the filters and limit semantics, but offers no clear when-to-use instructions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read nature is covered. The description adds a useful behavioral constraint: the server caps limit at 200. This is beyond the annotations but not rich in other behavioral details.
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 short sentences with no filler. The core purpose is front-loaded, and the limit cap is a concise added detail. Every sentence earns its place.
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 search tool, the description covers the essential scope and a key constraint. Annotations provide safety context, and an output schema exists, so missing return details are not critical. It could add alternative tool references, but given its simplicity, this is nearly complete.
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 0%, so the description must carry parameter meaning. It explains that query searches signal names and comments, and mentions the limit cap. However, it does not explicitly describe the dbc_path parameter or provide details about the limit's default/range beyond the cap. The parameter names are self-explanatory, giving partial credit.
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 action ('Search') and the resource ('signal names and comments across a DBC'). This distinguishes it from sibling tools like list_messages or get_message, which are retrieval-oriented rather than search-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or contrast with sibling tools such as list_messages or signal_timeseries. The description implies a search use case but lacks direct 'when to use' or 'when not to use' advice.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the server-side cap at limit 200, which is useful behavioral context beyond annotations. It does not mention pagination or return format, but with the output schema present and safety annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and then the key constraint. It is concise and directly useful, with no wasted words. The only slight deduction is that the mention of 'name, ID, or sender' might be overly specific if 'search' is a generic filter, but it stays within a reasonable length.
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 tool's simplicity (3 params, output schema present, read-only annotations), the description covers the essential behavior: listing messages with optional filters and a limit cap. It doesn't explain output structure but the output schema covers that. The main gap is lack of explicit distinction from siblings, but overall the description is adequate for a read-only list 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 0%, so the description must compensate. It mentions narrowing by name, ID, or sender, which maps loosely to the 'search' parameter, but it doesn't explicitly explain the 'limit' or 'dbc_path' semantics beyond what the schema names imply. The description adds some meaning but not enough to fully compensate for zero schema coverage, hence a 3.
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 states it lists DBC messages and mentions optional narrowing by name, ID, or sender, which clearly identifies the verb+resource and scope. It does not explicitly distinguish from siblings like 'get_message' but the resource is clear. The sibling tool 'get_message' is presumably for a single message, so the plural list is implied but not explicitly differentiated.
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 listing messages with optional filters, but it does not explicitly state when to use this versus alternatives like 'get_message' or 'search_signals'. No exclusions or alternatives are mentioned, so while context is clear, there is no direct comparison to 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the notion of 'bounded' output, which suggests a limit on results, but this is not elaborated (e.g., what bound applies). There is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It avoids unnecessary detail while covering the core purpose and output type, making it highly efficient.
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 tool has only two required string parameters and an output schema, so the description covers the core functionality adequately. However, the term 'bounded' is vague and could benefit from clarification, and the description does not mention any potential failure modes (e.g., file access errors), though this is a minor gap for a read-only diff 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 0%, but the parameter names (dbc_a_path, dbc_b_path) are self-explanatory. The description mentions 'two local DBC files' but does not explicitly clarify the order or format of the paths, leaving some ambiguity. Given the simple, self-descriptive parameter names, the description provides minimal additional value.
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 ('Compare') and resource ('two local DBC files') and clearly states the type of output (bounded added, removed, and changed message/signal details). This clearly distinguishes it from sibling tools like validate_dbc or dbc_info, 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.
Usage Guidelines3/5
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 DBC files, but it does not explicitly state when to use it over alternatives or mention exclusions. Sibling tools like validate_dbc and dbc_info are not referenced, so the user must infer usage from the purpose alone.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool summarizes a local file and returns size and node names, but it does not disclose further behavioral details like error handling or file access specifics. This is acceptable given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the purpose, key outputs, and a usage hint without any wasted words. The description is front-loaded with the core action and followed by usage guidance.
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 one-parameter tool with an output schema present, the description adequately covers what the tool does and when to use it. It does not explicitly mention alternatives, but the sibling list and 'use this first' hint provide enough context. A slightly richer description might note that validation is elsewhere, but it is not essential.
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 has one parameter with no description (coverage 0%), but the parameter name 'dbc_path' and the phrase 'local DBC file' make the meaning clear. The description does not explicitly explain the parameter format or constraints, but the path semantics are self-evident, so a baseline-3 is appropriate.
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 ('Summarize'), a clear resource ('local DBC file'), and specific outcomes ('size and node names'). This distinguishes it from siblings like validate_dbc (validation) and list_messages (listing messages).
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 says 'Use this first', providing clear context for when to use the tool before others. It does not mention alternatives or when not to use it, so it falls short of an explicit exclusion or alternative list.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds 'no file is modified' which reinforces non-destructiveness and clarifies it uses a local DBC, providing useful context beyond the annotation flags.
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 primary action, and no redundant phrasing or filler. Every word contributes to understanding.
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 tool is simple with an output schema present, so return values need not be described. Missing an explicit usage guideline is a minor gap, but overall it covers the essentials for a single-frame decoder.
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 0%, so the description must compensate. It explains data_hex as a 'hexadecimal byte string', which adds meaning. However, dbc_path and arbitration_id are left to their self-explanatory names, which is adequate but not fully developed.
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 action ('Decode one CAN payload using a local DBC') with a clear resource (CAN payload) and scope (one frame). This distinguishes it from siblings like decode_log, which handles multiple frames.
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 phrase 'one CAN payload' implies single-frame use, but there is no explicit 'when to use vs alternatives' or exclusion guidance. Siblings like decode_log are not mentioned, leaving usage context implied rather than stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the concrete behavioral constraint that 'limit is capped at 500' and notes the sample is 'bounded', which is useful. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every phrase adds value. It avoids redundant details and is appropriately concise for a simple read tool.
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 5 parameters, an output schema, and annotations covering safety, the description is sufficient. It explains the return type ('raw-frame sample'), key filters, and the limit cap. It doesn't elaborate on return formatting (covered by output schema) or prerequisites, but that is acceptable for a read-only 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?
Schema coverage is 0%, so the description must compensate. It maps log_path via 'local log', limit via 'bounded' and 'capped at 500', and id_filter/time_start/time_end via 'optional ID and timestamp filters'. This covers all parameters, though it doesn't specify filter inclusivity or time formats explicitly.
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 ('Read') and clearly identifies the resource: a bounded raw-frame sample from a local log, with optional ID and timestamp filters. It also mentions 'bounded' and 'limit capped at 500', which distinguishes it from sibling tools like decode_frame or get_message.
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 raw-frame sampling tasks but does not explicitly name alternatives, exclusion criteria, or when to prefer this tool over siblings like search_signals or decode_frame. The 'raw-frame' wording gives context, but no direct guidance on tool selection is provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by specifying the accepted input forms (name, decimal ID, or 0x-prefixed hex ID) and the nature of the return ('signal layout'). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action, no redundant words. Every sentence earns its place.
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 simple read-only nature, the presence of an output schema, and strong annotations, the description is largely complete. It could mention what happens when a message isn't found, but that is not essential for this straightforward lookup 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?
With 0% schema description coverage, the description must compensate. It meaningfully explains the 'message' parameter by listing accepted formats, but says nothing about 'dbc_path' beyond its self-evident name. This is partial compensation for the schema gap.
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 ('Return one message and its signal layout') and clearly identifies the resource (a single message from a DBC). It is well differentiated from siblings like list_messages by emphasizing the singular target.
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 conveys clear context: use this to retrieve one message and its signal layout. It doesn't explicitly name alternative tools or exclusion scenarios, but the 'one message' scoping makes the intended use obvious given the sibling list_messages tool.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context: it operates on a local log and caps the 'top' parameter at 200. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action 'Scan a local CAN log.' Every phrase is informative, with no filler or redundancy.
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 two-parameter stats tool with an output schema available, the description adequately covers what the tool computes and a key constraint (top cap). It doesn't need to describe return values since an output schema exists. It could add usage guidance relative to siblings, but overall it is contextually complete.
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?
Schema description coverage is 0%, so the description must carry parameter semantics. It clarifies that log_path refers to a local CAN log and that 'top' is capped at 200, implying it controls the number of top IDs returned. It does not explicitly explain the default value (20) or the exact format of log_path, but it provides meaningful context 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 clearly states a specific action ('Scan a local CAN log') and lists concrete outputs (counts, span, top IDs, median per-ID cycle times). This distinguishes it from sibling tools like decode_log or signal_timeseries, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (computing aggregate statistics on a CAN log) but does not explicitly state when to choose this over alternatives like probe_log or list_messages. There are no exclusions or alternative tool mentions, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds valuable behavioral context by stating 'without scanning all frames' and 'cheap header metadata', which are performance characteristics not conveyed by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the verb, target, and key differentiator in 15 words. Every word earns its place with no repetition 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?
With a single parameter, an output schema, and strong annotations, the description covers the essential context. It doesn't detail what 'format' or 'header metadata' includes, but the output schema likely handles that. The performance characteristic is highlighted, making this sufficiently complete for a tool of this simplicity.
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 has only one parameter, log_path, with no description (0% coverage). The tool description mentions 'local CAN log', which hints at the parameter's purpose, but it does not explicitly explain the parameter format or requirements. The name is self-explanatory, so this is adequate but not exemplary.
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 'Detect' and specifies the resource 'local CAN log' and the exact output: 'format and cheap header metadata'. It distinguishes from sibling tools like read_frames by emphasizing 'without scanning all frames', making its unique purpose clear.
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 implies a use case: when you need quick, cheap metadata about a log without full scanning. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select it over frame-reading tools.
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?
Beyond annotations (readOnly, idempotent), it adds key behavioral details: the series is bounded, evenly downsampled, and max_points is capped at 2,000. This gives practical constraints not present in 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?
A single, concise sentence that front-loads the core purpose and key constraint. No wasted words.
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 output schema exists and annotations are strong, the description covers critical constraints (downsampling, max_points cap) but does not explicitly state the role of time bounds or other parameters. Still, it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only adds semantics for max_points (capped at 2,000), but schema coverage is 0%. Parameter names like dbc_path, log_path, message, signal are self-explanatory, yet the description does not explain their roles or time_start/time_end semantics, leaving a gap.
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?
Clearly states it returns a bounded, evenly downsampled [timestamp, value] series for one DBC signal, distinguishing it from sibling tools by its focus on a single signal's time series.
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?
Implies usage for extracting a downsampled time series of one signal, but does not explicitly mention when to use this instead of siblings like decode_frame or read_frames. Provides context without direct exclusions.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context: the server caps limit at 200, which is beyond the schema and annotations. It also notes the output is 'structured issues', consistent with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no unnecessary words. Every phrase adds value.
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 validation tool with only two parameters, an output schema, and clear annotations, the description covers the purpose, output type, and a key server limit. No critical information is missing for an agent to decide to invoke this 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 0%, so the description must compensate. It adds meaning to the 'limit' parameter by mentioning the server cap of 200, but it does not explain 'dbc_path' beyond its obvious name. This partial compensation is adequate for a simple two-parameter tool.
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 ('DBC') and states the output ('structured issues'). This clearly distinguishes it from sibling tools like dbc_info or diff_dbcs.
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 'Validate a DBC' provides clear context for when to use the tool, implying it’s for checking correctness. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident given the sibling set.
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:

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

Score Badge

Copy to your README.md:

[![canforge-mcp MCP server](https://glama.ai/mcp/servers/canforge/canforge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/canforge/canforge-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/canforge/canforge-mcp'

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