feode-mcp
Server Details
FEODE: offshore P&A, subsea wellhead (BV+CCS), + NOV Grant Prideco drill-pipe spec lookup
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Each tool targets a distinct resource or operation: certifications, company profile, drill pipe specs (by ID), product specs (by ID), drill pipe listing, product listing, keyword search for capabilities, keyword search for drill pipe. No overlapping functionality.
Tools follow a verb_noun pattern (get_, list_, search_), but 'get' is used inconsistently for both single-item retrieval (get_drill_pipe_specs) and aggregate retrieval (get_certifications, get_company_profile). Otherwise consistent.
8 tools is well-scoped for a company reference server covering company info, certifications, product lines, and a drill pipe database. Each tool serves a clear purpose without being too few or too many.
The tool set covers listing, searching, and getting details for both product lines and drill pipe items, plus company profile and certifications. Minor gap: no separate tool for searching certifications, but search_capabilities may cover it. Overall comprehensive for the stated domain.
Available Tools
9 toolsget_certificationsAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the specific certifications included. As a simple read tool, this is transparent enough. 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?
Single concise sentence listing all relevant certifications, front-loaded with 'FEODE certifications'. Every word earns its place.
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 no output schema, the description adequately details the return content. Could clarify format (list vs text) but sufficient for a simple tool.
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 in schema, so baseline 4 applies. Description adds no parameter detail as none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves FEODE certifications and lists specific types. Distinguishes from sibling tools like get_company_profile and get_drill_pipe_specs which cover different domains.
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 vs alternatives. Usage is implied: when certification information is needed. Lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_profileAInspect
FEODE company profile: legal name, founding year (1985), HQ, Huizhou manufacturing/test base, areas served, contact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what data is returned (e.g., legal name, founding year) but does not state whether the call is read-only, idempotent, or has side effects. The information is transparent about content but not behavior.
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 packs all relevant information without any filler. It is front-loaded with the company name and provides a lean list of data points, earning its place.
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 no output schema, the description covers the return values by listing key fields. However, it omits details like data types or structure (e.g., whether contact is a string or object). Still, it is sufficient for a simple profile retrieval.
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?
With zero parameters and 100% schema coverage, the description adds value by enumerating the data fields returned, such as legal name and founding year. This goes beyond the empty schema, justifying a baseline of 4.
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 the FEODE company profile, listing specific fields like legal name, founding year, HQ, manufacturing base, areas served, and contact. This is a specific verb+resource combination with no ambiguity.
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 when-to-use or when-not-to-use guidance. It implies usage for profile retrieval but offers no alternatives or exclusions. Sibling tools like get_certifications suggest context, but the description itself lacks direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drill_pipe_specsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While it lists the returned specs, it does not disclose whether the operation is read-only, what happens on invalid IDs, or any side effects. It is adequate but could be more explicit about safety and error behavior.
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 efficiently conveys the purpose, scoping, and usage hint. It is front-loaded with the key action and resource. Could be slightly improved by splitting into two sentences, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter and no output schema, the description compensates by listing the specific specs returned (pipe-body yield, collapse, tool-joint measurements, etc.). It also references a sibling tool for ID lookup. The description is sufficiently complete for the tool's 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?
The schema already provides an example for the 'id' parameter (dp-5-19.50-s135-nc50) and has 100% coverage. The description adds context by mentioning that the ID refers to a drill string item and referencing list_drill_pipe, but does not add new semantic 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 retrieves 'Full NOV Grant Prideco performance specs for one drill string item by id' and lists specific spec categories (pipe-body yield, collapse, tool-joint dimensions). The verb 'get' and resource 'drill_pipe_specs' are precise. Distinguishes from sibling 'list_drill_pipe' as a way to obtain IDs.
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 directs users to 'Use list_drill_pipe for ids,' providing clear guidance on how to use this tool in conjunction with a sibling. It implies when to use (when you have an ID) and suggests not using it without an ID. However, it does not explicitly state alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drill_string_guidanceAInspect
NOV Grant Prideco operating guidance for the drill string: make-up torque practice (incl. the 80% drilling-torque rule), handling/grip distance by connection, care & handling principles, and double-shoulder connection (DSC) notes. Optional topic filter.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: make_up_torque | handling | care_and_handling | double_shoulder_connections |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the optional topic filter and hints at the content areas, but it does not describe the return format, side effects, data freshness, or permissions. The behavioral transparency is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences, no redundant information. It front-loads the key purpose and lists the topics efficiently. The optional filter is mentioned in a separate sentence for clarity.
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 simplicity (1 optional parameter, no output schema), the description covers the tool's purpose and parameter adequately. However, it lacks information about the output format or behavior when no topic is provided, which would help the agent understand the full picture.
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 covers 100% of parameters with descriptions for the allowed topic values. The description adds slight nuance by mentioning the '80% drilling-torque rule' and providing a clearer list of topics, but it does not significantly surpass the schema's detail. Baseline 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?
The description clearly states that the tool retrieves operating guidance for drill strings, listing specific topics like make-up torque and handling. The verb 'get' is implied by the name, and the resource is well-defined. However, it does not explicitly differentiate from sibling tools like get_drill_pipe_specs or search_capabilities, though the topic list implies distinct usage.
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 implies usage scenarios by listing topics, but it does not explicitly state when to use this tool over alternatives or provide guidance on when not to use it. No sibling tool comparisons or exclusions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_specsCInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'detailed specs/highlights' without disclosing critical behavioral traits (e.g., read-only, authentication needs, return format).
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 is concise and front-loaded. Could benefit from slight expansion to cover usage context without becoming verbose.
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 low complexity (1 param, no output schema), description lacks usage exclusions and behavioral details, leaving gaps for proper tool selection.
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 clear enum values for 'id'. Description adds no new parameter meaning but confirms output nature ('detailed specs/highlights').
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 'get detailed specs/highlights for one product line by id', specifying action and resource. However, does not differentiate from sibling tool 'get_drill_pipe_specs' which may overlap.
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 list_products or get_drill_pipe_specs. Agent lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_drill_pipeAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it does not mention whether the tool is read-only, non-destructive, or if any side effects occur. Although listing is inherently safe, the description omits any behavioral traits beyond the action.
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 concise sentence that front-loads the main purpose ('List all...') and immediately provides the items and fields. Every word is necessary; no fluff or 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?
Given no parameters, no output schema, and no annotations, the description is fairly complete for a listing tool. It defines the scope (specific items and fields) but could be improved by noting any limitations or the nature of the 'reference DB'.
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, meeting the baseline of 4 for no-parameter tools. The description adds value by specifying the exact fields returned, which compensates for the lack of output schema and enriches the understanding beyond the empty input 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?
Description clearly states the tool lists specific NOV Grant Prideco drill string items (drill pipe, HWDP, drill collars) and explicitly mentions the returned fields (id, label, product_type, connection, grade). It distinguishes from siblings like search_drill_pipe by implying a comprehensive list versus filtered search.
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?
Description implies usage for obtaining a full list of drill string items but does not provide explicit guidance on when to use this tool versus alternatives like search_drill_pipe or get_drill_pipe_specs. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspect
List FEODE's 7 product/service lines (id, name, category).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It states the tool lists 7 product lines with specific fields, which is sufficient for a simple read operation. It does not mention side effects, rate limits, or additional behavior, but for a no-parameter list, this is acceptable.
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, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and output.
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 simplicity (no parameters, no output schema, no annotations), the description is complete. It tells the agent exactly what data is returned and the scope. No additional details are necessary.
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 schema coverage is 100% vacuously. The description adds value by specifying the fields returned (id, name, category), which complements the empty input schema. Baseline is 4 for no params.
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 lists FEODE's 7 product/service lines with specific fields (id, name, category). It uses a specific verb ('List') and resource, and it distinguishes from sibling tools which cover certifications, company profile, drill pipe specs, etc.
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 explicitly state when to use this tool vs alternatives. The context is clear enough that this is for product lines, but no exclusions or comparisons are provided. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_capabilitiesAInspect
Keyword search across FEODE products/specs. e.g. 'subsea wellhead 15000 psi', 'one trip abandonment', 'continuous circulation'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'keyword search'. It does not disclose pagination, result limits, authentication needs, or any side effects, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with examples, front-loaded with the purpose. Every word is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema or annotations, the description is fairly complete: it states the domain and provides examples. It could mention scope or limitations, but is adequate for the tool's 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 coverage is 0%, so the description must compensate. It explains that the 'query' parameter expects keywords related to FEODE products/specs and gives examples, adding substantial meaning beyond the schema's simple string type.
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 is a keyword search across FEODE products/specs, with concrete examples. It distinguishes itself from sibling tools like get_product_specs or search_drill_pipe by the general search scope.
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?
Examples imply usage for keyword queries, but no explicit guidance on when to use this versus siblings like search_drill_pipe or get_product_specs. No 'when not to use' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_drill_pipeBInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It correctly implies a read-only search operation, but does not disclose potential issues like authentication requirements, rate limits, or behavior on no matches.
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 concise and to the point, with most information in one sentence. The parenthetical examples are slightly messy but still effective.
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 required parameter and no output schema, the description is adequate. It explains the purpose and gives examples, but lacks details on return format or error responses.
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 a single 'query' parameter with no description (0% coverage). The description compensates somewhat with examples, but does not specify expected format, constraints, or allowed values formally.
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 ('keyword search') and the specific resource ('NOV Grant Prideco drill string reference'), and provides concrete examples. However, it does not explicitly differentiate from sibling tools like 'get_drill_pipe_specs' or 'list_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 guidance is given on when to use this tool versus alternatives. The description only provides example queries but lacks context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!