Evidence-oriented REA + Ghidra static-analysis workflows, read-only PE32 and Delphi VMT tools.
Scored across 4 tools
The tools are mostly distinct: fetch_generic_url_content handles arbitrary URLs, fetch_rea_ghidra_docs retrieves the repo documentation, and search_rea_ghidra_code/docs search code or docs respectively. The only mild overlap is between fetching full documentation and semantically searching documentation, but the descriptions clarify the difference.
All names use snake_case with a clear verb_noun pattern: fetch_* and search_*. The generic URL tool uses a longer noun phrase than the repo-specific tools, but the convention remains readable and predictable.
Four tools is a reasonable minimal set for a documentation/code retrieval server. The generic URL fetch is broader than the repo-specific tools, but it supports the follow-up workflow described in the docs tools.
The surface covers fetching docs, searching docs, searching code, and fetching referenced URLs. A direct code-file content retrieval tool is not present, but search results can be followed by generic URL fetches, so the gap is minor.
Generic tool to fetch content from any absolute URL, respecting robots.txt rules. Use this to retrieve referenced urls (absolute urls) that were mentioned in previously fetched documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the document or page to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does disclose that the tool respects robots.txt rules. However, it omits other important behavior such as authentication needs, redirect handling, rate limits, or what content format is returned.
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 short and front-loads the main purpose. The parenthetical '(absolute urls)' in the second sentence is slightly redundant with the first sentence, but the overall structure is 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?
For a simple one-parameter fetch tool this is mostly adequate, and the schema fully documents the input. Since there is no output schema, the description should ideally say more about what is returned or how content is presented, which it currently does not.
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 100% for the single url parameter, so the schema already explains the parameter's meaning. The description adds the useful constraint that it must be an absolute URL, but provides no additional syntax or format details beyond that.
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 and resource: fetch content from an absolute URL. The word 'Generic' and the phrase 'any absolute URL' help distinguish it from the more specialized sibling fetch_rea_ghidra_docs, though no sibling is explicitly named.
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 clearly says to use this for referenced absolute URLs mentioned in previously fetched documentation. This gives an agent a concrete usage context, but it does not explicitly state when to prefer the sibling fetch_rea_ghidra_docs tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch entire documentation file from GitHub repository: ethanhunt1981/rea-ghidra-toolkit. Useful for general questions. Always call this tool first if asked about ethanhunt1981/rea-ghidra-toolkit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden; it does disclose that the entire file is returned rather than a filtered subset, and that it should be the first call. It says nothing about response size, truncation, or what the returned content looks like, which matters for a whole-file fetch.
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 short sentences, front-loaded with the action and source; no filler. The repository name is repeated in the second sentence, a minor 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-param, no-output-schema fetch tool the essential call information is present, but the agent is not told what the output contains or how to handle a large document, and the relationship to the search and generic-URL siblings is unstated.
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 baseline is 4. The description correctly implies the repository and file target are fixed, so the agent understands no arguments 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?
States a clear verb ('fetch'), resource ('entire documentation file') and the exact source repository, so the agent knows precisely what comes back. It does not explicitly contrast with the sibling search_rea_ghidra_docs, so the distinction between 'entire file' and 'search' is left implicit.
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?
'Always call this tool first if asked about ethanhunt1981/rea-ghidra-toolkit' is an explicit routing directive with a clear trigger condition. It stops short of saying when NOT to use it or naming search_rea_ghidra_docs as the follow-up alternative for narrow queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for code within the GitHub repository: "ethanhunt1981/rea-ghidra-toolkit" using the GitHub Search API (exact match). Returns matching files for you to query further if relevant.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number to retrieve (starting from 1). Each page contains 30 results. | |
| query | Yes | The search query to find relevant code files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It conveys exact-match behavior and that results are file references, but omits GitHub Search API's rate limits and any authentication expectations — material facts for a search endpoint that can be throttled.
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, front-loaded with the resource and scope, zero filler. The repository name consumes some space but is necessary disambiguation.
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 no annotations, the description must carry return-shape and constraint information; it says only 'returns matching files'. Adequate for a two-parameter read tool, but the absence of rate-limit and result-count context leaves real 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?
Schema coverage is 100%, so baseline is 3. The description's only added semantic is 'exact match' for the query, which is genuinely useful (query syntax is a common failure point), but paging and query format are otherwise left entirely to the 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?
States a specific verb+resource (search code) scoped to a named repository, plus the mechanism (GitHub Search API, exact match). Siblings differ by resource type (code vs. docs), but the description never names or contrasts them explicitly, so differentiation is left implicit.
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 trailing clause 'Returns matching files for you to query further if relevant' hints at the intended workflow (search then fetch), but there is no explicit statement of when to choose this over search_rea_ghidra_docs or fetch_rea_ghidra_docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantically search within the fetched documentation from GitHub repository: ethanhunt1981/rea-ghidra-toolkit. Useful for specific queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to find relevant documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions semantic search over fetched documentation, but does not clarify prerequisites, result count, ranking behavior, or whether an initial fetch is required, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action and source. The second sentence adds little beyond the first but is not harmful.
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 search tool with no annotations or output schema, the description covers the basic purpose but omits prerequisites and return behavior. It is minimally 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 coverage is 100% for the single query parameter, so the schema already defines its meaning. The description adds that search is semantic, but does not provide query syntax, expected format, or examples.
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 and resource: semantically search within fetched documentation from a named GitHub repository. It distinguishes itself from siblings like search_rea_ghidra_code by specifying documentation rather than code, though it does not explicitly name the alternative tools.
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 says 'Useful for specific queries,' which implies a usage context but gives no explicit when-to-use versus when-not-to-use guidance. It does not say whether the documentation must already be fetched, or how this differs from fetch_rea_ghidra_docs or search_rea_ghidra_code.
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.
fetch_generic_url_contentfetch_rea_ghidra_docssearch_rea_ghidra_codesearch_rea_ghidra_docsCrypto scam checks (tokens, sites, wallets), chain reads, web page to Markdown, email checks.
Crypto forensics with sources: deployer records, OFAC matches, exchange and bridge attribution.
Offline methodology engine for authorized penetration testing, CTF, and security research.
Read-only DERO blockchain MCP: 33 tools (12 composites) incl. TELA discovery + bundled docs.
Add one secure layer between your agents and this server.
