Pharos MCP Server

Official

by PharosNetwork

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Every tool targets a distinct resource or action: code, storage, call, gas, logs, transaction, receipt, balance, nonce, gas price, block, chain info. No two tools have overlapping purposes; even similar ones like get_transaction and get_transaction_receipt are clearly separated by what they return.
Naming Consistency5/5
All tools follow a snake_case pattern, predominantly verb_get_* for reads and send_raw_transaction for the write operation. eth_call and estimate_gas are also snake_case and align with common EVM naming, preserving overall consistency.
Tool Count5/5
14 tools is well within the ideal 3-15 range for an EVM blockchain server. Each tool corresponds to a standard JSON-RPC method, and none are redundant or superfluous given the server's purpose.
Completeness5/5
The tool set covers the full spectrum of EVM node interactions: chain info, blocks, transactions, receipts, balances, storage, code, calls, gas estimation, logs, nonce, gas price, and raw transaction broadcast. This is a complete surface for typical dApp or chain interaction needs.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive nature. The description adds no additional behavioral context such as simulation semantics, revert behavior, or output format, simply restating the read-only aspect.
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 a single, efficient sentence with no wasted words, but the brevity compounds the lack of critical context.
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?
For a tool with a nested transaction object and no output schema, the description leaves out crucial information about parameters, return values, and usage context, making it incomplete for an agent to invoke correctly.
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 coverage is 0%, and the description offers no parameter-specific details. An agent must infer that 'to' is the contract address and 'data' contains calldata without any explicit guidance.
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?
Clearly states the tool executes a read-only EVM contract call, distinguishing it from transaction submission tools like send_raw_transaction. However, it doesn't explicitly mention the return value or how it relates to the eth_call RPC method.
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 guidance on when to use this tool vs alternatives like estimate_gas or send_raw_transaction, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. However, the description adds no additional behavioral context beyond what annotations provide—such as return format, encoding of 'position', or behavior with invalid inputs. It essentially restates the read-only nature already captured 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, well-structured sentence that is front-loaded with the core purpose. It contains no fluff or redundant details. While extremely brief, it conveys the essential action and object efficiently, fitting the conciseness criterion perfectly.
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?
For a tool of this complexity, the description lacks critical context: it does not mention the block parameter, the expected return value (e.g., raw storage data), or how 'position' is interpreted. There is no cross-referencing to related tools or caveats. The rich annotations mitigate some concerns, but the description alone is insufficient for an agent to confidently invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 does not explain any parameter: 'address', 'position', or 'block' are left undocumented. The meaning of 'position' (likely a storage slot key, often hex-encoded) is not clarified, and no hints about allowed formats or types are given. This is a complete failure to aid parameter understanding.
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 'Read a contract storage slot' clearly states the action (read) and the specific resource (contract storage slot), which distinguishes it from sibling tools like get_balance (reads balance) and get_code (reads code). The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as eth_call or get_balance. There is no mention of context, prerequisites, or exclusions. The single sentence gives the purpose but leaves usage entirely implied.
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?
The description aligns with the annotations (readOnlyHint, idempotentHint, non-destructive) but adds no behavioral context beyond that. It does not mention edge cases like addresses without code or the format of returned data. Since annotations are present, the bar is lower, but the description still 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is exactly as long as needed and contains no filler.
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 no output schema and incomplete parameter documentation, the description is insufficient for an agent to fully understand the tool's behavior. The block parameter is completely unexplained, and there is no indication of return values or edge cases. The purpose is clear, but the tool's full usage context is not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (address and block) with no descriptions. The description mentions 'at an address' but says nothing about the block parameter, leaving its purpose and usage ambiguous. Schema description coverage is 0%, and the description does not compensate.
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 gets contract bytecode at a given address. The verb 'get' specifies the action, and 'contract bytecode' distinguishes it from sibling tools like get_balance or get_storage_at.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with sibling tools. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no additional behavioral context, such as return formats, error conditions, or quirks like returning null for unknown hashes.
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, focused sentence with no filler. It is appropriately sized for the tool's simplicity.
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 no output schema and the presence of get_transaction_receipt, the description is incomplete. It does not explain what is returned, how it differs from related tools, or how it handles missing or invalid hashes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'hash' string parameter with no description (0% coverage). The description merely restates 'by hash' without explaining what the hash is (e.g., hex string, 0x-prefixed) or any constraints like required format.
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 'Get a transaction by hash' uses a specific verb and resource, clearly indicating it retrieves transaction data by hash. It implicitly distinguishes from siblings like get_transaction_receipt because it targets a transaction resource rather than a receipt.
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 usage guidance is provided. The description does not mention when to use this tool instead of alternatives like get_transaction_receipt, nor does it clarify scenarios such as pending vs confirmed transactions.
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 and destructiveHint=false, so safety is covered. The description adds the semantic clarification that the count is the nonce, but it does not disclose additional behavioral traits like changing values across calls or the effect of the optional block parameter.
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 with no redundant words. It earns its place efficiently, fully fitting the tool's simple nature.
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 read-only tool with two parameters and no output schema, the description is mostly complete. It implies a numeric return value (nonce) and the annotations cover safety. The only notable gap is not explicitly explaining the optional block parameter, though the schema partially covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the block parameter has a description ('Usually latest or pending'), but address lacks one. The description implies address is the target but adds no detail about the block parameter or the default behavior. It partially compensates but relies on the schema for block context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get an address transaction count (nonce)' with a specific verb and resource. It defines the operation precisely and adds the nonce clarification, but it does not explicitly differentiate from sibling tools like get_transaction or get_balance.
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 usage context is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions. It is a bare definition with no guidance on selecting this tool over siblings.
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, openWorldHint, and idempotentHint, so the agent knows this is a safe read operation. The description adds the behavioral requirement that the caller must supply a bounded block range, which is useful, but it does not mention return format or potential size/pagination issues. No contradictions 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 fronts the action and resource, with no redundant words. Every word earns its place.
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 optional parameters, no output schema, and no parameter descriptions in the schema, the description is too skeletal to fully guide invocation. It does not state what the tool returns (e.g., an array of log objects), nor does it clarify whether fromBlock/toBlock are effectively required despite the schema marking them optional. The annotations provide safety context, but the description lacks operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any of the four parameters. It only hints at block range via 'bounded block range,' leaving topics and address semantics entirely to the schema property names, which may be ambiguous for an AI agent. The description fails to compensate for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'EVM logs', and adds the qualifier 'with bounded block range supplied by the caller.' This clearly distinguishes it from sibling tools like get_transaction_receipt, which retrieves logs for a specific transaction, and get_block, which retrieves block data.
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 querying logs over a caller-specified block range, but it provides no explicit guidance on when to use it over alternatives like get_transaction_receipt or eth_call, and does not mention any exclusions. The context is clear but lacks alternative selection criteria.
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, openWorldHint, idempotentHint true and destructiveHint false, covering the safety profile. The description adds no additional behavioral context such as tag semantics (e.g., 'latest', 'pending') or response structure, but no contradictions exist.
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 directly states the tool's function without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover risk, but the description omits details about valid tag values (e.g., 'latest', 'earliest') and the exact return structure. Given no output schema, this is a minor gap for a basic read operation.
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 clarifies that the 'block' parameter accepts a tag or number, but the 'includeTransactions' parameter remains unexplained beyond its name and default value in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('Pharos block') and scoping ('by tag or number'). It distinguishes from sibling get_block_number, which retrieves the current block number, making the purpose unmistakable.
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 guidance is provided on when to use this tool versus alternatives like get_block_number or get_transaction. There are no exclusions or contextual suggestions, leaving the agent to infer its use from the name 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the non-mutating nature of the tool. The description adds the key behavioral insight 'without sending it', but it does not disclose return format, potential failure modes, or network-dependent behavior. This is acceptable but not thorough.
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 nine-word sentence that is direct, front-loaded, and contains no unnecessary wording. It efficiently communicates the tool's core purpose.
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?
There is no output schema, so the description should ideally clarify what the tool returns (e.g., the estimated gas amount and units), but it does not. Additionally, the transaction parameter is a nested object with nine fields and the description gives no guidance on required properties or defaults. The description is sufficient for selecting the tool but not for correctly invoking it without substantial prior domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description refers only to 'a transaction' and does not describe any of the fields in the nested transaction object. With schema description coverage at 0%, the agent gets no guidance on which properties are required or how they affect the estimate. The property names in the schema are somewhat self-explanatory, but the description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Estimate gas') and a specific resource ('for a transaction'). The qualifier 'without sending it' clearly distinguishes this from the sibling send_raw_transaction tool, and 'for a transaction' differentiates it from the network-level get_gas_price tool.
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 'without sending it' implies the tool should be used when a gas estimate is needed before an actual transaction is broadcast, and it excludes the send use case. However, it does not explicitly name alternatives like eth_call or get_gas_price, so it provides clear context but no explicit exclusions.
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 no extra behavioral context such as return format (e.g., hex string) or behavior for nonexistent addresses. Since annotations carry the burden, the description is acceptable 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.
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 contains no filler or redundant content, earning a perfect score for conciseness.
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 read-only balance query, the description plus schema and annotations are largely sufficient. However, no output schema is present, and the description does not mention the return value format, leaving a small gap. Despite this, the tool is straightforward, so it 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 100% with both parameters documented: 'Block tag or number; defaults to latest' and 'EVM address'. The description itself does not elaborate on parameters, but the schema already provides the necessary semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Get the native PROS balance of an EVM address.' It identifies the resource (native PROS balance) and the subject (EVM address), distinguishing it from sibling tools like get_code or get_storage_at. The verb 'Get' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading PROS balances but provides no explicit guidance on when to use it versus alternatives such as eth_call for token balances or get_transaction_count for nonce. There is no mention of exclusions or preferred use cases, so it only meets the 'implied usage' level.
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 the tool as readOnly, idempotent, and non-destructive. The description adds no additional behavioral context (e.g., return format, error conditions, or network implications). Since the annotations cover the safety profile, the minimal description does not create a conflict but also offers no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It states exactly what the tool does without unnecessary explanation.
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, and the annotations plus schema provide basic context. The description does not explain what a transaction receipt contains, but no output schema exists and the concept is well-known in blockchain contexts. Given the tool's simplicity and the presence of sibling tools that contrast with it, the description is reasonably 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?
With 0% schema description coverage, the description compensates by indicating that the 'hash' parameter is the transaction hash. This clarifies the parameter's purpose, though it does not specify details like hex format or length. Given there is only one parameter, the semantic role is sufficiently conveyed.
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 operation ('Get a transaction receipt') and the input key ('by hash'), distinguishing it from sibling tools like get_transaction, which retrieves transaction details rather than receipts. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as get_transaction or get_logs. It does not mention exclusions, prerequisites, or comparison with siblings, leaving the agent to infer usage from context.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no additional behavioral context beyond stating the get action. It does not mention any caching, rate limits, or return format, but with annotations covering the read-only nature, the bar is met.
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 concise sentence that is front-loaded with the action and resource. It contains no fluff or redundant information.
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?
Given the tool's simplicity (no parameters, no output schema), the description is fully sufficient to convey its purpose. The intended output (a block number) is implicitly clear from the name and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is complete with no properties. The description needs to explain nothing about parameters, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource: 'latest Pharos block number'. It clearly distinguishes from siblings like get_block (which likely returns block details) and get_chain_info (which returns chain metadata).
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?
There is no guidance on when to use this tool versus alternatives such as get_block or get_chain_info. The description simply states what it does, leaving the agent to infer appropriate usage from the name 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 and destructiveHint=false, so the safety profile is known. The description adds that it returns the 'current' price and includes 'priority fee', which is useful context. However, it does not disclose additional behavioral traits such as caching, latency, or response format, which is acceptable given the annotations but not exceptional.
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, concise sentence that front-loads the verb and resource. It contains no filler or redundant information, and every word earns its place.
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 zero-parameter read-only tool with no output schema, the description is complete. It clearly states what data the tool returns, and the sibling tools provide enough context for differentiation. No additional explanation of return values or behavior is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema imposes no burden. The description adds semantic meaning by specifying what is retrieved (gas price and priority fee), which goes beyond the empty parameter list. Per the rubric, a baseline of 4 is appropriate for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current Pharos gas price and priority fee' uses a specific verb ('Get') and clearly identifies the resource (gas price and priority fee). It is distinct from sibling tools like get_block or get_balance, and the scope ('current') adds precision.
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 does not explicitly state when to use this tool versus alternatives like estimate_gas. The usage is implied by the name and description, but no exclusions or alternative suggestions are provided. The context signal of zero parameters makes it straightforward, but guidance is still implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, destructiveHint=true), the description discloses that the server never receives a private key, a meaningful security behavior not present in annotations. The phrase 'already-signed' also clarifies that the tool does not sign transactions, adding behavioral context beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the primary action front-loaded in the first sentence. The second sentence adds a valuable security guarantee without any unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with strong annotations, the description is mostly sufficient. However, there is no output schema and the description does not mention what the tool returns (e.g., transaction hash) or potential error conditions, leaving a small gap in completeness for an agent that might need to confirm the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter 'rawTransaction' as '0x-prefixed signed transaction bytes' (100% coverage). The description's mention of 'already-signed' adds no new meaning beyond what the schema provides, so the baseline of 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 clearly states the action 'Broadcast' and the resource 'raw EVM transaction', distinguishing it from the sibling read-only tools. The added note about never receiving a private key reinforces the tool's unique role as a broadcast-only operation, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a key prerequisite: the transaction must already be signed, since it says 'already-signed'. It also signals that the server is not a signer by noting it never receives a private key. While it doesn't explicitly compare to alternatives, the sibling tools are all read-only, so this is clearly the only broadcast tool; no explicit exclusion is necessary.
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, establishing the safety profile. The description adds value by enumerating the exact return fields, giving the agent a clear expectation of the output without needing an output schema. It does not discuss error conditions or rate limits, but for a simple getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action verb and lists all four return items in a compact list. There is no filler, and every phrase adds information.
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?
With zero parameters, clear annotations, and a concise description listing all output fields, the tool is fully specified for the agent. The lack of an output schema is compensated by the description's enumeration of the returned data. Sibling tools suggest a read-only context, and this tool fits that pattern without needing additional caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description does not need to explain parameters, and it correctly lists the data items returned rather than any input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as Pharos chain info, listing four concrete data items (chain ID, client version, latest block, configured RPC endpoint). This clearly distinguishes it from sibling tools like get_block_number or get_transaction, which target different resources.
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 does not explicitly state when to use this tool over siblings such as get_block_number or eth_call. However, the purpose is self-explanatory and implies usage when chain-level metadata is needed, so it provides minimal contextual guidance.
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:

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

Score Badge

Copy to your README.md:

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

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