Philidor MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the DeFi vault domain, with no overlap that could cause confusion. For example, 'get_vault' retrieves detailed vault information, while 'get_vault_risk_breakdown' focuses specifically on risk metrics, and 'search_vaults' handles filtering and listing.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as 'compare_vaults', 'explain_risk_score', and 'get_vault_risk_breakdown'. This predictable naming convention makes the tool set easy to navigate and understand.
Tool Count5/5
With 9 tools, the server is well-scoped for analyzing DeFi vaults, covering key aspects like risk assessment, market overview, and vault details. Each tool serves a unique function without redundancy, making the count appropriate for the domain.
Completeness5/5
The tool set provides comprehensive coverage for DeFi vault analysis, including CRUD-like operations (e.g., get, search, compare), risk explanation, market insights, and curator/protocol details. There are no obvious gaps that would hinder an agent from performing essential tasks in this domain.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 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
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't address important behavioral aspects like whether this requires authentication, rate limits, error conditions, or what format the detailed information returns. The description mentions what information is included but not how it's structured or delivered.
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 that packs substantial information about what the tool returns. It's appropriately sized for a simple lookup tool with one parameter, though it could potentially be more front-loaded with the core purpose before listing specific data points.
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 simple lookup tool with one parameter and no output schema, the description provides reasonable coverage of what information is returned. However, without annotations or output schema, it lacks important context about behavioral characteristics, error handling, and response format that would be needed for optimal agent usage.
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 description coverage is 100% with the single parameter 'curatorId' documented as 'Curator ID'. The description adds no additional parameter semantics beyond what's already in the schema. The baseline score of 3 reflects adequate but minimal value added by the description regarding parameters.
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 action ('Get detailed information') and resource ('vault curator'), with specific details about what information is included (managed vaults, TVL, chain distribution, performance). However, it doesn't explicitly differentiate from sibling tools like 'get_vault' or 'get_protocol_info' which might provide related but different information.
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. With sibling tools like 'get_vault', 'get_protocol_info', and 'search_vaults' available, there's no indication of when this specific curator-focused tool is appropriate versus those other options.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a 'detailed breakdown' with three score types, but doesn't specify output format (e.g., structured data, text summary), potential errors (e.g., invalid address handling), rate limits, or authentication needs. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
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 that front-loads the core action ('Get a detailed breakdown') and lists key components. There's no wasted text, and it directly communicates the tool's function. However, it could be slightly more structured (e.g., bullet points for clarity) but remains highly concise.
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?
Given the tool's moderate complexity (risk analysis with multiple score types), no annotations, and no output schema, the description is minimally adequate. It covers what the tool does but lacks details on output format, error handling, or integration with siblings. Without annotations or output schema, more context on behavioral aspects would improve completeness for safe agent use.
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 ('network', 'address') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples of valid network slugs beyond 'ethereum', no clarification on address format). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose with specific verbs ('Get a detailed breakdown') and resources ('vault's risk vectors'), listing the three main components (Asset Composition, Platform Code, Governance scores). It distinguishes itself from siblings like 'get_vault' or 'explain_risk_score' by focusing on risk breakdown rather than general vault data or score explanations. However, it doesn't explicitly contrast with all siblings (e.g., 'compare_vaults' also involves risk analysis).
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. It doesn't mention prerequisites (e.g., needing a specific vault address), exclusions (e.g., not for comparing multiple vaults), or direct comparisons to sibling tools like 'explain_risk_score' (for detailed score explanations) or 'compare_vaults' (for multi-vault analysis). Usage is implied only through the tool name and description context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation ('Get'), it does not specify whether it requires authentication, has rate limits, returns structured or raw data, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the purpose and lists key details without unnecessary words. Every element (action, resource, examples of information) earns its place, making it highly concise and well-structured.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and output details but lacks behavioral context (e.g., authentication, error handling) and usage guidelines. For a simple read tool, this is minimally viable but has clear gaps.
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 input schema has 100% description coverage, with the single parameter 'protocolId' documented in the schema. The description does not add any additional meaning or examples beyond what the schema provides (e.g., it does not clarify the format of protocol IDs or list all possible values). Baseline score of 3 is appropriate as the schema handles the parameter documentation.
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 ('Get detailed information') and the resource ('a DeFi protocol'), with specific examples of the information returned (TVL, vault count, versions, auditors, security incidents). It distinguishes itself from sibling tools like 'get_vault' or 'get_market_overview' by focusing on protocol-level details rather than vaults or markets.
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 like 'get_vault' or 'get_market_overview'. It does not mention prerequisites, such as needing a protocol ID, or exclusions, such as not being suitable for comparing multiple protocols. Usage is implied but not explicitly stated.
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?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, or what happens with invalid inputs. The phrase 'and more' is vague about additional metrics.
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?
Single sentence efficiently conveys purpose and key comparison metrics. No wasted words, and the structure is front-loaded with the core action ('compare 2-3 DeFi vaults').
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 comparison tool with no annotations and no output schema, the description adequately covers what metrics are compared but lacks details about return format, error handling, or behavioral constraints. The schema provides good parameter coverage, but overall completeness is moderate given the missing behavioral context.
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%, so the schema fully documents the 'vaults' parameter structure. The description adds no parameter-specific information beyond implying 2-3 vaults, which is already in the schema's minItems/maxItems. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('compare') and resources ('2-3 DeFi vaults'), listing the exact comparison metrics (TVL, APR, risk score, etc.). It distinguishes from siblings like 'get_vault' (single vault) or 'find_safest_vaults' (different objective).
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 side-by-side comparison of specific metrics, but doesn't explicitly state when to use this tool versus alternatives like 'search_vaults' for broader discovery or 'get_vault_risk_breakdown' for detailed risk analysis. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes what the tool explains but lacks details on behavioral traits such as response format, potential errors (e.g., for invalid scores), or performance characteristics. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently lists all key aspects (tier, calculation, thresholds) without unnecessary words. It is front-loaded with the core purpose and appropriately sized for the tool's complexity.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It covers what the tool explains but does not address behavioral aspects or output expectations, which are needed for full contextual understanding despite the simple schema.
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 the parameter 'score' documented as a number (0-10) to explain. The description does not add meaning beyond the schema, as it does not specify parameter usage or constraints. Baseline 3 is appropriate since the schema adequately covers parameter semantics.
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's purpose: to explain a Philidor risk score, including tier classification, calculation methodology, and thresholds. It specifies the verb 'explain' and the resource 'risk score,' distinguishing it from sibling tools that focus on vault operations, comparisons, or searches rather than score interpretation.
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 usage when a user needs to understand a risk score's meaning, tiers, calculation, and thresholds. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_vault_risk_breakdown for detailed risk components) or provide exclusions, leaving some ambiguity in sibling tool differentiation.
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?
No annotations are provided, so the description carries full burden. It states what data is returned but does not disclose behavioral traits like data freshness (real-time vs. cached), rate limits, authentication needs, or error conditions. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key metrics. Every word contributes to understanding the tool's function without redundancy or fluff.
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?
Given no annotations and no output schema, the description provides basic purpose but lacks behavioral context (e.g., data sources, update frequency) and output details (e.g., format of risk distribution). It is minimally adequate but has clear gaps for a tool returning complex market data.
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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 specific action ('Get a high-level overview') and resource ('DeFi vault market'), listing concrete metrics (total TVL, vault count, risk distribution, TVL by protocol). It distinguishes from siblings like get_vault (single vault) or get_protocol_info (protocol-specific) by focusing on aggregate market 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 usage for high-level market analysis, but does not explicitly state when to use this tool versus alternatives like get_vault_risk_breakdown (detailed risk) or search_vaults (filtered vaults). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds that the tool returns a 'paginated list with risk scores and APR', which goes beyond the input schema. However, it does not cover important aspects like rate limits, authentication needs, error conditions, or whether the search is real-time or cached, leaving gaps for a tool with 9 parameters.
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 front-loaded and efficiently structured in a single sentence, clearly stating the action, filterable attributes, and return format. Every word earns its place without redundancy, making it easy to parse quickly.
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?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description is moderately complete. It covers the core purpose and return format but lacks details on behavioral traits (e.g., rate limits, auth), error handling, and output structure beyond 'paginated list with risk scores and APR'. For a search tool with rich filtering, more context would be beneficial.
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 description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds marginal value by listing some filter criteria ('chain, protocol, asset, risk tier, TVL') and mentioning 'and more', but does not provide additional syntax, format details, or constraints beyond what the schema specifies. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose with specific verbs ('search and filter') and resources ('DeFi vaults'), listing multiple filter criteria. It distinguishes itself from siblings like 'get_vault' (single vault) and 'find_safest_vaults' (specific risk focus) by emphasizing comprehensive search capabilities.
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 context through the listed filter criteria (e.g., 'by chain, protocol, asset, risk tier'), suggesting when to use it for multi-criteria searches. However, it lacks explicit guidance on when to choose this tool over alternatives like 'find_safest_vaults' or 'get_market_overview', and does not mention exclusions or prerequisites.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool returns a limited set ('top 10'), includes quality criteria ('audited, high-confidence'), and sorts by 'risk score'. However, it does not cover aspects like rate limits, authentication needs, error handling, or whether the operation is read-only or has side effects, leaving gaps for a tool with no annotation support.
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 front-loaded with the core purpose and efficiently lists optional filters and output details in a single, well-structured sentence. Every element (e.g., 'top 10', 'audited', 'sorted by risk score') serves a clear purpose without redundancy, making it concise and easy to parse.
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?
Given no annotations and no output schema, the description partially compensates by specifying the return format ('top 10 audited, high-confidence vaults sorted by risk score'). However, it lacks details on output structure, error cases, or behavioral constraints like pagination or rate limits. For a tool with 3 parameters and no structured support, it is adequate but has clear gaps in completeness.
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%, so the schema already documents all parameters (asset, chain, minTvl) with descriptions. The description adds minimal value by mentioning these filters as optional but does not provide additional semantics, syntax, or format details beyond what the schema provides. Baseline 3 is appropriate when the schema handles parameter documentation.
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 specific action ('Find'), resource ('safest DeFi vaults'), and scope ('highest risk-scored'), distinguishing it from siblings like 'search_vaults' or 'get_vault' by emphasizing risk-based filtering and ranking. It explicitly mentions the output criteria ('top 10 audited, high-confidence vaults sorted by risk score'), making the 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 provides clear context for usage by specifying optional filters (asset, chain, minTvl) and the focus on risk-scored vaults, but it does not explicitly state when to use this tool versus alternatives like 'search_vaults' or 'compare_vaults'. It implies usage for finding high-risk-scored vaults but lacks explicit exclusions or named alternatives.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'Get' and 'Lookup', which is appropriate, but lacks details on permissions, rate limits, error handling, or response format. It adds some context about the data scope (risk, events, snapshots), but more behavioral traits would improve transparency for this unannotated tool.
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 front-loaded with the core purpose in the first sentence, followed by a concise second sentence on lookup methods. Both sentences earn their place by adding distinct value—no wasted words or redundancy. It is appropriately sized for a tool with three parameters and no annotations.
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?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and lookup methods well, but lacks details on behavioral aspects like response structure, error cases, or prerequisites. Without annotations or output schema, more context would help the agent use this tool effectively, though it's not critically inadequate.
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%, so the schema already documents all three parameters (id, network, address) with descriptions. The description adds marginal value by clarifying that these are alternative lookup methods ('by ID or by network + address'), but does not provide additional syntax, format, or usage details beyond what the schema specifies. This meets the baseline for high schema coverage.
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 ('Get detailed information') and resource ('specific DeFi vault'), specifying the type of information returned ('risk breakdown, recent events, and historical snapshots'). It distinguishes from siblings like 'get_vault_risk_breakdown' by offering broader details beyond just risk, and from 'search_vaults' by focusing on a single vault lookup rather than multiple results.
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 provides clear context for when to use this tool: to retrieve comprehensive data on a single vault, using either an ID or network+address combination. However, it does not explicitly state when not to use it (e.g., vs. 'search_vaults' for multiple vaults or 'get_vault_risk_breakdown' for risk-only info), nor does it name alternatives, leaving some ambiguity in sibling tool selection.
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:

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

Score Badge

Copy to your README.md:

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

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