Machine-queryable capabilities, certifications, and a NOV Grant Prideco drill-string engineering reference for FEODE — Shenzhen Far East Oil Drilling Engineering Ltd.
A remote Model Context Protocol (MCP) server that lets AI agents and MCP clients query FEODE's offshore oilfield equipment & services and a curated drill-string specification & operating-guidance reference — machine to machine.
Endpoint (streamable-http): https://www.feode.com/mcp
npm (stdio bridge): feode-mcp — npx -y feode-mcp
Official MCP Registry: com.feode/feode-mcp
Server card: https://www.feode.com/.well-known/mcp.json
Website: https://www.feode.com · Contact: enquiry@feode.com
Precision machining & testing
get_machining_services — AI-accessible contract machining & testing capabilities (large-envelope CNC, pressure testing).
get_machining_terms — intake terms & compliance requirements for machining/testing RFQs.
submit_machining_rfq — submit a structured machining/testing RFQ (with lightweight compliance screen).
Company
get_company_profile — profile (founded 1985, HQ, Huizhou manufacturing/test base, areas served).
list_products — FEODE's 7 product/service lines.
get_product_specs — detailed specs for one product line.
get_certifications — BV + CCS classification, 8 API monogram licenses, PSL 4S, ISO 9001/14001/45001, awards.
search_capabilities — keyword search across products/specs.
NOV Grant Prideco drill-string reference
list_drill_pipe — 16 drill pipe / HWDP / drill collar items.
get_drill_pipe_specs — full performance specs for one item (pipe body new/premium torsional & tensile yield, internal pressure, collapse; tool joint OD/ID, make-up torque max/min, drift).
search_drill_pipe — keyword search (e.g. "NC50", "5 S-135", "HT55").
get_drill_string_guidance — operating guidance: make-up torque rules, grip/handling, care & handling, double-shoulder connections, sour-service grades, field-use practice.
Related MCP server: Handaas Qualification MCP Server
Add to an MCP client (streamable-http):
{
"mcpServers": {
"feode": { "type": "streamable-http", "url": "https://www.feode.com/mcp" }
}
}Stdio-only client (Claude Desktop etc.)? Use the npm package — no config beyond this:
{
"mcpServers": {
"feode": { "command": "npx", "args": ["-y", "feode-mcp"] }
}
}Or query directly via JSON-RPC:
curl -s https://www.feode.com/mcp -X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'src/worker.js — the MCP server (dependency-free; runs as a Cloudflare Pages function at /mcp).
server.json — official MCP Registry metadata.
data/drill-pipe-data.json — 16 NOV Grant Prideco spec sheets (human-readable source).
data/drill-guidance.json — operating-guidance reference (6 topics).
.well-known/mcp.json — server discovery card.
Shenzhen Far East Oil Drilling Engineering Ltd. (FEODE, est. 1985) — offshore well plug & abandonment, deepwater subsea wellhead systems (BV + CCS classed), continuous circulation drilling, completion, drill pipe & tool rental, fishing, and supervision. 8 API monogram licenses; in-house pressure testing to 30,000 psi.
The NOV Grant Prideco drill-string data is reference material transcribed from manufacturer performance sheets (FOR REFERENCE ONLY; per API RP7G / API 7G), curated by FEODE. Always verify against the controlling NOV document before field use.
Code: MIT (see LICENSE). Reference data: see "Note on reference data".
FEODE certifications: BV + CCS classification of the subsea wellhead system (incl. references), 8 API monogram licenses, PSL 4S, ISO 9001/14001/45001, national awards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds the specific list of certifications returned, but does not disclose any additional behavioral traits such as authentication requirements or data freshness. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('FEODE certifications') and enumerates key items. It is concise, though could benefit from a brief note on return format.
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?
Despite lacking an output schema, the description sufficiently lists what is returned. For a simple read-only tool with no parameters, this covers the essential information needed by the agent.
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 has no parameters, so the schema provides full coverage. The description adds no parameter information, but none is needed. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves FEODE certifications, listing specific types (BV, CCS, API, etc.). It is specific about the resource, distinguishing it from sibling tools by focus on certifications, though no explicit contrast is provided.
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?
No guidance is given on when to use this tool versus siblings like get_company_profile or get_product_specs. The agent must infer 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.
FEODE company profile: legal name, founding year (1985), HQ, Huizhou manufacturing/test base, areas served, contact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by listing the specific fields returned, complementing the readOnlyHint and openWorldHint annotations. No behavioral pitfalls or additional side effects are relevant for this simple read-only tool.
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 extremely concise, providing all necessary information in a single sentence. It is well-structured and front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides a clear list of the fields included in the profile, which is complete for understanding what the tool returns. It could be improved by mentioning the return format, but the list of fields is adequate.
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 has no parameters, so the description does not need to add parameter semantics. The schema coverage is 100% as there are no properties. The description appropriately focuses on the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the FEODE company profile with specific fields (legal name, founding year, HQ, etc.). It is easily distinguishable from sibling tools like get_certifications or get_drill_pipe_specs as it focuses on the company overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. However, given its self-contained nature (no parameters) and distinct purpose, the need for such guidance is minimal. Still, it lacks explicit 'when to use' or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full NOV Grant Prideco performance specs for one drill string item by id: pipe-body new/premium torsional & tensile yield, internal pressure, collapse; tool-joint OD/ID, make-up torque max/min, drift, torsional yield. Use list_drill_pipe for ids.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item id, e.g. dp-5-19.50-s135-nc50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing what specs are returned (pipe-body, tool-joint properties). No contradictions. Adds beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence listing all returned specs and a usage tip. No fluff, front-loaded with essential info.
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 spec retrieval with one parameter, the description explains output and references sibling for input. Could mention error handling or return format, but not critical given simplicity.
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 covers 100% of parameters, with description and example for 'id'. The tool description does not add extra semantics beyond the schema's parameter description. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full performance specs for a drill string item by id, listing specific attributes (torsional yield, internal pressure, etc.). It distinguishes from siblings by mentioning 'Use list_drill_pipe for ids', implying this tool is for specs retrieval.
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?
Explicitly says to use this tool when you have an id and need specs, and directs users to list_drill_pipe for obtaining ids. Provides clear when-to-use and alternative reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NOV Grant Prideco drill-string guidance & reference data (from the Grant Prideco 钻具技术手册, excerpted from API Spec 7 / API RP 7G): make-up torque practice (incl. the 80% drilling-torque rule), handling/grip distance, care & handling, sour service; double-shoulder connection families HT/XT/XT-M/GPDS with recommended make-up torque & thread forms; drill-pipe steel grades & API tool joints; heavy-weight drill pipe (3 types + dimensional data); drill collars (material, bending-strength-ratio, weight, connection selection, ideal size by hole); rotary-shouldered connection interchangeability; kelly (square/hex weights & connections); crossover/service subs; well control (kill/pressure formulas, pump output, capacity & displacement, buoyancy factor); and imperial-to-SI unit conversions. ALSO includes reference_tables: the manual's dense spec/torque/weight/capacity/inspection matrices and BSR charts as reference IMAGE URLs (including the wide cross-page drill-collar make-up-torque & weight tables assembled whole from the facing-page scan) — for exact cell values, return the matching image_url to the user instead of transcribing the numbers. Call without a topic to get everything, or pass one topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: make_up_torque | handling | care_and_handling | double_shoulder_connections | sour_service | field_usage | premium_connections | pipe_grades_and_body | heavy_weight_drill_pipe | drill_collars | connection_interchange | kelly | crossover_subs | well_control | unit_conversion | reference_tables (dense spec/torque/weight/capacity/inspection matrices & BSR charts as reference image URLs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (which indicates safe read), the description adds key behavioral context: it returns reference data including image URLs and instructs to return the matching image_url instead of transcribing numbers. This goes beyond what annotations provide.
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 extremely long, running as a single complex sentence with many semicolons and lists. While front-loaded with the main purpose, the structure is poor and contains excessive detail that could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many subtopics) and lack of output schema, the description covers most aspects: what data is included, how to use the topic parameter, and how images should be handled. It is fairly complete for an agent to understand usage.
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 input schema only names the 'topic' parameter, but the description enumerates all 16 valid values (e.g., make_up_torque, handling, etc.) and briefly explains each. With 100% schema coverage, the description adds substantial meaning beyond 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?
The description clearly states the tool provides drill-string guidance from a specific source (NOV Grant Prideco manual) and lists many content areas. However, it is verbose and lacks a concise summary, but the verb 'get' plus resource 'drill_string_guidance' makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call with or without a topic: 'Call without a topic to get everything, or pass one topic.' This provides clear invocation guidance, though it does not discuss alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FEODE AI-accessible precision contract machining & testing: capabilities (large-envelope CNC, deep-hole boring up to 7m, non-magnetic drill collar repair, welding/cladding), test capacity (30k psi hydraulic, 20k psi N2, MPI/UT/PT), materials, how-it-works, payment & compliance policy. FEODE machines to the client's drawing/spec and ships internationally. Compliance-first, prepayment-based.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, making this a safe read operation. The description adds context about the content (capabilities, test capacity, policies) but does not disclose behavioral traits such as output format, data freshness, or any restrictions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that packs significant information but lacks paragraph breaks or bullet points. It is functional but not optimally concise; a structured list could improve readability without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key content areas (capabilities, test capacity, materials, policies) but fails to specify the output structure (e.g., whether it returns a document, list, or free text). Given the absence of an output schema, this is a gap. The tool's simplicity partly mitigates the lack, but completeness is only partial.
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 has zero parameters, and schema coverage is 100%. Per guidelines, 0 parameters earns a baseline of 4. The description adds no parameter details, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides precision contract machining and testing capabilities, including specific details like CNC, deep-hole boring, test capacities, and policies. It distinguishes itself from siblings like get_machining_terms and search_capabilities by offering a comprehensive overview rather than focusing on a single aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives such as get_machining_terms, get_company_profile, or search_capabilities. It does not mention situations where this tool is preferred or when another tool would be more appropriate, leaving the AI to infer usage from content alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full intake terms & compliance requirements for FEODE's machining/testing service: required RFQ fields, KYB-lite (legal entity / country / real contact), end-use declaration, prohibited items, IP & liability terms, prepayment & accepted payment methods (bank wire / T/T).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it details what information is included (required fields, prohibited items, payment methods). Annotations already mark it as read-only and closed-world, and the description aligns with and expands on that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, front-loaded with the core purpose. It is efficient but could be slightly restructured for readability. Still, it earns its place without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the main categories of returned information. It is sufficient for understanding what the tool provides, though it omits output format details.
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?
There are no parameters, so schema coverage is 100% by default. The description does not need to add parameter info, meeting the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Full intake terms & compliance requirements' and lists specific categories like RFQ fields, KYB-lite, end-use declaration, etc. This distinguishes it from siblings like get_machining_services or submit_machining_rfq.
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?
Usage is implied rather than explicit. The description suggests it is a prerequisite for submitting an RFQ but does not directly state when to use it or when to use alternatives like get_machining_services. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detailed specs/highlights for one product line by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | One of: well-abandonment, subsea-wellhead, feccs, completion, drill-pipe, fishing, supervision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds only 'Detailed specs/highlights', which is minimal additional behavioral context. With annotations covering the core trait, the description does not provide new insights such as response format or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential purpose. It is appropriately sized with no unnecessary words. Could potentially include more detail without becoming verbose, but as is it 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?
Given the tool has one parameter and no output schema, the description is minimal but functional. However, considering the number of sibling tools (11), more context about what kind of specs are returned would help an agent select correctly. Not a 4 because it lacks completeness for decision-making.
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%, listing acceptable values for the 'id' parameter. The description mentions 'by id' but adds no new meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'detailed specs/highlights for one product line by id'. The verb 'get' and resource 'specs/highlights' are specific, and the scope is clear. However, it does not differentiate from the sibling tool 'get_drill_pipe_specs', which might be a subset, so not a 5.
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?
No guidance on when to use this tool versus alternatives like 'get_drill_pipe_specs' or 'list_products'. The description lacks any context about prerequisites or preferred use cases, making it hard for an agent to decide among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all NOV Grant Prideco drill string items in the reference DB (drill pipe, heavy-weight drill pipe HWDP, drill collars) with id, label, product_type, connection, grade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds specifics on what fields are returned, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with key action and scope.
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?
No output schema, but description adequately explains return fields; lacks mention of pagination but is acceptable for simple list.
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?
No parameters, so description does not need to add parameter details; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all NOV Grant Prideco drill string items with specific attributes, distinguishing it from search and get sibling 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?
No explicit guidance on when to use vs search_drill_pipe or other siblings, but the description implies it's for bulk listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List FEODE's 7 product/service lines (id, name, category).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by specifying the exact count (7) and the fields included, without repeating the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Perfect for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the agent needs to know: what it returns and how many items.
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 input schema has no parameters, so there is no need for parameter descriptions. The description adds value by listing the output fields, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (FEODE's product/service lines), and output fields (id, name, category), and specifies there are exactly 7 items. This distinguishes it from sibling tools like search_capabilities or get_product_specs.
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?
No explicit usage guidelines or when-not-to-use instructions are provided. The tool is simple, and its use is implied for obtaining a list of product lines, but compared to the 11 sibling tools, some context on when to choose this over others would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across FEODE products/specs. e.g. 'subsea wellhead 15000 psi', 'one trip abandonment', 'continuous circulation'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds no further behavioral details (e.g., pagination, result format), which is acceptable but doesn't exceed the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with examples, no wasted words. Highly efficient and front-loaded with the key action.
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 search tool with annotations, the description covers the essential purpose and parameter usage. It could mention the output type (e.g., list of results) but is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds concrete example queries that clarify the 'query' parameter's usage. This provides useful context beyond the raw 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?
The description clearly states the tool does 'Keyword search across FEODE products/specs' and provides specific examples. This clearly distinguishes it from more specific sibling tools like 'search_drill_pipe'.
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?
No explicit guidance on when to use this tool versus alternatives like search_drill_pipe or get_product_specs. The description implies general keyword search but doesn't clarify scope or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search the NOV Grant Prideco drill string reference (e.g. 'NC50', '5 S-135', 'HT55 make-up torque', '8 drill collar', 'XT57'). Returns matching items with full specs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by confirming the tool returns data without mutation. It adds context about the data source (NOV Grant Prideco) but does not disclose additional behaviors like result limits, error handling, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences: first states the action and source, second provides examples and what is returned. No unnecessary words, and the key information is front-loaded.
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 search tool with one parameter and no output schema, the description covers the data source, search type, and return value. It lacks details on pagination, max results, or empty result behavior, but the provided information is adequate for an AI agent to invoke correctly.
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 description enriches the single 'query' string parameter by providing concrete examples (e.g., 'NC50', '5 S-135'), which the schema lacks. Given 0% schema description coverage, this compensates well, though it could further specify query format or case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a keyword search over a specific database (NOV Grant Prideco drill string reference), with examples of valid queries, distinguishing it from siblings like get_drill_pipe_specs that fetch by known identifiers rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries but does not explicitly state when to use this tool versus sibling tools like get_drill_pipe_specs or list_drill_pipe, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a structured machining/testing RFQ. Runs a lightweight compliance screen (prohibited-use + sanctions) and, if cleared, registers the enquiry for human follow-up from enquiry@feode.com. Not a contract or quotation; no payment is taken here. You must provide the legal entity behind the request.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Contact email | ||
| notes | No | Any other details (optional) | |
| company | Yes | Legal entity name placing the order | |
| country | Yes | Country of registration of the legal entity | |
| end_use | Yes | Declared end-use of the part | |
| industry | No | Industry sector | |
| material | Yes | Material / grade | |
| quantity | Yes | Quantity | |
| tolerance | No | Key tolerances (optional) | |
| drawing_url | No | Link to drawing/spec if available (optional) | |
| contact_name | Yes | Real human contact name | |
| part_description | Yes | Part/component description or drawing reference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and no destruction. Description adds valuable context: lightweight compliance screen, human follow-up, and clarification that it's not a binding contract. No contradictions.
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?
Four sentences, each providing distinct value: purpose, compliance step, legal disclaimer, and requirement. No 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?
Covers the workflow and non-contract nature well for a submission tool. Lacks mention of expected response or confirmation, but overall adequate given complexity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. The tool description adds emphasis on 'legal entity' but does not elaborate on parameter format or constraints beyond schema. Baseline of 3 is appropriate.
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?
Clearly states the verb 'submit', the resource 'machining/testing RFQ', and includes distinctive details like compliance screening and human follow-up. Differentiates from sibling tools which are all read-only queries.
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?
Specifies when to use (submitting an RFQ) and important caveats (not a contract/quote, no payment, must provide legal entity). Does not explicitly list alternatives, but siblings are all read-only so context is clear.
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. Dates show when Glama detected each change.
v0.1.0get_certificationsget_company_profileget_drill_pipe_specsget_drill_string_guidanceget_machining_servicesget_machining_termsget_product_specslist_drill_pipelist_productssearch_capabilitiessearch_drill_pipesubmit_machining_rfqMost tools have distinct purposes (e.g., company info vs. drill pipe specs), but some overlap exists between search_drill_pipe and get_drill_pipe_specs, though descriptions clarify the difference.
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_, list_, search_, submit_), with no mixed conventions.
With 12 tools, the set is well-scoped for a company capability server covering products, services, and a drill pipe reference. No excessive or trivial tools.
The tool surface covers the main functions: company info, product listings/specs/search, machining services/terms/RFQ, and a comprehensive drill pipe reference. No obvious gaps for informational and enquiry needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cross-model evidence pipeline for financial filings & contracts. x402 pay-per-call.
Ocean shipping intelligence: D&D, freight rates, vessel schedules, port data. 24 tools, 6 carriers.
Bounded data, document, web-quality, and operations services purchased with USDC through x402.
8.1M+ US gov and science data via x402 USDC. 21 tools, $0.001 sample tier, sanctions, SEC, CVEs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FarEastAI/feode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
