FEODE: AI-accessible precision machining & testing; offshore P&A, subsea wellhead, drill-pipe
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.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.3/5.
Tools are mostly distinct, but there is potential confusion between get_product_specs (product lines) and get_drill_pipe_specs (drill pipe items), as well as between list_drill_pipe and search_drill_pipe. However, descriptions clarify these differences.
All tool names follow a consistent verb_noun pattern in snake_case (get_, list_, search_, submit_), making it predictable for agents.
12 tools cover two main domains (FEODE company and drill string reference) without excess or deficiency, providing a well-scoped set.
The tool surface covers key operations for both domains: company info, product/service lifecycle, and drill string reference. Minor gaps like lack of company news or additional equipment categories, but core workflows are supported.
get_certificationsBFEODE 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, so the description does not need to restate safety. The description adds the specific certifications and standards included, which provides behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that front-loads the key content. It is concise and to the point, though it could be structured more clearly as a statement of function.
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 provides the list of certifications but does not explain the return format or structure. For a simple retrieval tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no parameter info, but with no parameters, the baseline is 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 tool name 'get_certifications' combined with the description listing specific certifications clearly indicates the tool retrieves certification information. However, it does not explicitly distinguish from sibling tools like 'get_company_profile', which might also include certifications.
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 no guidance on when to use this tool versus alternatives. There is no mention of scenarios where this is appropriate or when other tools like 'get_company_profile' might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_profileAFEODE 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 context beyond annotations by specifying the returned fields, but it does not disclose any potential staleness of data (e.g., founding year is fixed at 1985) or rate limits. Annotations already state readOnlyHint=true, so the description is adequate but not rich.
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 lists the contents of the profile. It is concise and front-loaded, though the list format could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema read tool with annotations, the description adequately covers what the tool returns. It does not mention data freshness or update frequency, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema description coverage is 100%. The description does not need to add parameter information, and it correctly omits it. Baseline score of 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 retrieves the FEODE company profile and explicitly lists the data fields included (legal name, founding year, HQ, manufacturing base, areas served, contact). This differentiates it from sibling tools like get_certifications 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?
The description implies the tool is for getting company profile information, but it does not explicitly state when to use it versus alternatives (e.g., get_certifications for certifications). No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drill_pipe_specsAFull 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 set readOnlyHint=true. The description adds valuable context by enumerating the exact specifications returned (pipe-body and tool-joint properties), which is beyond what annotations provide. 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 that efficiently lists the key specs and provides a cross-reference. No wasted words; all information 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?
No output schema, but the description fully lists the return fields (pipe-body and tool-joint specs), making the tool's output clear. The description is sufficient for an agent to understand what data it will receive.
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 has 100% coverage with a description for id and an example. The description reinforces the parameter's purpose and cross-references list_drill_pipe, adding value 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 performance specs for a single drill string item by ID, listing specific attributes (torsional yield, pressure, etc.). It also distinguishes from list_drill_pipe by indicating the latter provides IDs. The verb and resource are explicit.
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 advises using list_drill_pipe to obtain IDs, implying this tool is for looking up specs for known IDs. It does not explicitly exclude other sibling tools, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drill_string_guidanceANOV 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?
The description discloses behavioral traits such as returning reference image URLs for exact cell values instead of transcribing numbers. It aligns with the readOnlyHint annotation, indicating no destructive actions.
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 very long and dense, covering many details. It could be more structured (e.g., bullet points) but remains clear. Every sentence adds value, but brevity is lacking.
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 absence of an output schema, the description thoroughly explains the return content (text guidance and reference images). It covers all listed topics and provides usage instructions, making it complete for a reference 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?
The parameter 'topic' is fully described with a comprehensive list of allowed values and their meanings, adding significant value beyond the 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?
The description explicitly states it provides NOV Grant Prideco drill-string guidance and reference data, listing many specific topics. It clearly distinguishes from sibling tools by its focus on drill string guidance and reference tables.
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 explains usage: call without a topic for everything or specify one topic. It does not explicitly mention when not to use or alternatives, but the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_machining_servicesAFEODE 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 declare readOnlyHint=true, so the description's additional context about compliance-first, prepayment-based, and international shipping informs the agent about the nature of the service beyond a simple read operation.
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 paragraph that front-loads the main purpose. While packed with information, it is concise and avoids 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 no output schema and zero parameters, the description provides a comprehensive overview of capabilities, testing, materials, how-it-works, and policies, which is adequate for an information retrieval 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?
There are no parameters, so baseline is 4. The description adds context about what is returned, which is sufficient given trivial 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 returns precision contract machining & testing capabilities, differentiating it from siblings like get_machining_terms and submit_machining_rfq by listing specific content areas (CNC, boring, testing methods, materials, policies).
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 context (general capabilities overview) but does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tools exist but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_machining_termsAFull 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?
Annotations already include readOnlyHint=true, so the description's content focus adds no behavioral insights beyond confirming it's a read operation. No mention of rate limits, authentication, or side effects is needed given the read-only nature.
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 is concise, front-loaded with the core purpose, and every part is informative. No 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 no input parameters and no output schema, the description is fairly complete by listing the main content areas. However, it could mention the format or structure of the returned data for full completeness.
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 schema coverage 100%, the description adds value by detailing what the output covers (RFQ fields, KYB-lite, prohibited items, etc.), which compensates for the lack of parameter semantics.
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 for FEODE's machining/testing service', specifying the resource and scope. It distinguishes from siblings like get_certifications and get_company_profile by focusing on machining/testing service terms.
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 versus alternatives. While it implies use before submitting an RFQ (submit_machining_rfq is a sibling), no direct guidance or when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_specsBDetailed 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 read-only nature is established. The description adds that it returns 'detailed specs/highlights', but does not disclose other behavioral traits like rate limits, data freshness, or side effects. Minimal added value 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, front-loaded with 'Detailed specs/highlights'. No wasted words. Could be slightly more structured but achieves conciseness.
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, so description should cover return format. It only says 'detailed specs/highlights' without specifying fields, pagination, or structure. Somewhat complete given simplicity, but lacks detail for a rich result.
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 the id parameter fully described via an enum. The description mentions 'by id' but does not add meaning beyond the schema. 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 the verb ('get'), resource ('detailed specs/highlights for one product line'), and scope ('by id'). It distinguishes itself from sibling tools like list_drill_pipe which list items, not detailed 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 guidance on when to use this tool versus alternatives (e.g., get_drill_pipe_specs for drill pipe specs specifically). No context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_drill_pipeAList 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 context about the reference DB and specific fields returned, which is useful 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 wasted words, clearly communicates the tool's 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 read-only list with no parameters, the description is complete. Could mention ordering or count, but not essential.
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 schema coverage is 100%. Description adds meaning by listing output fields, which is useful but not required.
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 NOV Grant Prideco drill string items with specific types and fields. It distinguishes from search_drill_pipe which likely implies filtering.
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 purpose is clear and implies use when wanting all items. Sibling search_drill_pipe suggests alternative for searching. Some explicit guidance could improve, but current is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAList 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 declare readOnlyHint=true, assuring safe read-only operation. The description adds behavioral context: returns exactly 7 lines with specific fields. No mention of performance or auth, but the safety profile is clear from 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, concise sentence that conveys all necessary information without filler. Every word adds value.
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 list tool with no parameters and annotations providing safety, the description is complete. It specifies the return fields (id, name, category) even without an output schema, and the fixed number 7 sets clear expectations.
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 exist, and schema description coverage is 100% (empty schema). Per guidelines, 0 params baseline is 4. The description adds no parameter info because none exist, so score remains 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 the verb 'List' and the resource 'FEODE's 7 product/service lines' with specific fields (id, name, category). This distinguishes it from sibling tools like 'get_product_specs' which likely provide details for one product, and 'search_capabilities' which involves 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 implies use for obtaining an overview of all product lines but provides no explicit guidance on when to use vs alternatives. It does not exclude usage for filtering or detailed specs, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_capabilitiesAKeyword 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 indicate readOnlyHint=true and openWorldHint=false. The description adds that it is a keyword search but does not disclose additional behavioral traits such as result limits, pagination, or whether it returns full documents or snippets. 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 extremely concise: two sentences and examples. Every word adds value, front-loading the purpose and illustrating usage without waste.
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 lack of output schema, the description does not explain return values or structure. With only one parameter and simple annotations, the description is adequate but could be improved by noting what type of results (e.g., list of capabilities with IDs) are returned.
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 only defines 'query' as a string with 0% coverage. The description compensates by providing realistic query examples, which help the agent understand acceptable inputs and format.
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 keyword search across FEODE products/specs, with concrete examples ('subsea wellhead 15000 psi') that show the scope. This verb+resource definition distinguishes it from sibling tools that focus on specific domains like drill pipe or certifications.
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 examples but does not specify when to use this tool vs. alternatives like search_drill_pipe or get_product_specs. It lacks explicit guidance on when not to use it or the scope boundaries relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_drill_pipeAKeyword 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?
Annotations already declare readOnlyHint=true. The description adds that it returns full specs, which is beneficial but not extensive. No additional behavioral context (e.g., pagination, result limits) is provided.
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 sentences, each serving a clear purpose: first defines the action and domain, second describes the result. No extraneous 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 the single parameter and no output schema, the description sufficiently explains the tool's function. It could elaborate on result format or limitations, but the examples provide enough context for a simple search 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?
The schema has 0% description coverage for the 'query' parameter. The description compensates by providing example queries (e.g., 'NC50', '5 S-135'), adding meaning beyond the bare type string.
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 over the NOV Grant Prideco drill string reference, provides example queries, and specifies that it returns matching items with full specs. This distinguishes it from siblings like get_drill_pipe_specs and 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?
The description implies usage via example queries and the domain (drill string reference). However, it does not explicitly state when not to use or contrast with alternatives like get_drill_pipe_specs. The examples are helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_machining_rfqAInspectSubmit 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 readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds valuable context: the tool runs a compliance screen, registers for human follow-up, and does not take payment. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with clear purpose. Front-loaded with the core action, then compliance and non-contract clarifications. No 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 12 parameters (8 required) and no output schema, the description adequately explains the workflow, key steps, and a critical prerequisite. It provides enough context for an AI agent to determine when and how to use the 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?
Schema description coverage is 100%, so the schema already documents all 12 parameters. The description adds marginal value by emphasizing the need for a legal entity, which aligns with the 'company' parameter. No additional parameter details are provided beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Submit') and resource ('machining/testing RFQ'), and differentiates from sibling tools that are get/list/search operations. It clearly outlines the process: compliance screen and registration for human follow-up.
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 tells when to use (submitting an RFQ) and provides a clear prerequisite ('You must provide the legal entity behind the request'). It also clarifies what the tool does not do (not a contract/quotation, no payment). Explicit alternatives are not listed, but sibling tools imply different purposes.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.