Structure-only reference for the vanilla Ross ERP 8.0 schema, UI menu tree, and program catalog.
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.1/5 across 21 of 21 tools scored. Lowest: 3.1/5.
Each tool has a clearly distinct purpose: list/lookup/search pairs are separated by summary vs full detail, exact match vs fuzzy search, and domain scope. Cross-reference tools are explicitly paired as reverse lookups (facility_programs/program_facilities, table_facilities/table_programs), eliminating ambiguity. Minor overlaps like find_column vs search_columns and get_ddl vs lookup_table are well-differentiated by their descriptions.
The naming is largely predictable with list_ for browsing, lookup_ for full detail, search_ for searching, and _stats for overviews. Cross-links follow a noun_noun pattern (facility_programs, table_facilities). Exceptions like find_column, get_ddl, graph_neighbors, and path_between are still intuitive and do not create confusion, though they deviate from the dominant verb-first pattern.
At 21 tools, the set sits in the 16-25 range that feels heavy. However, each tool serves a distinct function across schema, facilities, programs, columns, and graph traversal, so the count is justified for a comprehensive data dictionary. It is not as tightly scoped as a typical CRUD server, but the breadth is necessary for the domain.
The tool set provides complete coverage for a read-only data dictionary: browsing, searching, full details, and cross-references for every entity type (objects, columns, facilities, programs), plus graph utilities. There are no obvious dead ends or missing operations; stats and search-all tools further enhance orientation and cross-domain discovery.
facility_programsAInspectCross-link a UI facility to the vanilla program(s) that implement it — 'what code runs this screen?'. Each program carries a match label: declared (named by the facility's menu entry, authoritative) or titleId (TITLE id equals the facility code). Complements lookup_facility (which gives the facility's tables and call graph). Metadata only — no source body.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Facility code, e.g. AP_A_002 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool returns metadata only ('no source body'), and it explains the match label semantics ('declared' vs 'titleId'), both of which are non-obvious and add value beyond the schema.
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 compact and every sentence earns its place: core purpose, match label details, sibling complement, and metadata-only guarantee. There is no redundancy or irrelevant content, making it well-structured 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 one-parameter lookup with no output schema, the description sufficiently explains what the response contains (programs with match labels) and the relationship to lookup_facility. It could go slightly further by outlining the exact response shape, but the information provided is adequate for 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?
The schema already provides 100% coverage for the single 'code' parameter with a clear description and example. The tool description does not add additional parameter details, so the baseline score of 3 is appropriate given the schema's sufficient explanation.
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's function with a specific verb and resource: 'Cross-link a UI facility to the vanilla program(s) that implement it'. It also differentiates from a sibling by naming lookup_facility and explaining the differing output, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool as complementary to lookup_facility, clarifying that facility_programs provides program mappings while lookup_facility yields tables and call graph. This gives the agent clear context for selecting this tool over the named alternative, though no explicit 'when not to use' exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
facility_statsAInspectOverview of the Ross ERP 8.0 application layer — the client menu tree of UI facilities (screens, reports, inquiries, maintenance functions): total facilities, and their breakdown by system (e.g. ACCOUNTS_PAYABLE), database (FIN/MAN) and class (REPORT, MAINTENANCE, INQUIRY, ...). Use this first to orient before browsing facilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes the output as an overview with totals and breakdowns, making it clear this is a read-only, non-mutating operation. It does not mention potential limitations like performance or access restrictions, but for a simple stats tool, the information provided is adequate.
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 long, front-loaded with the core purpose, and every phrase adds value. It includes concrete examples (ACCOUNTS_PAYABLE, FIN/MAN, REPORT/MAINTENANCE) without unnecessary padding, making it efficient and well-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?
Given the tool has no parameters, no output schema, and no annotations, the description is complete. It explains what the overview contains, how it's grouped, and provides usage guidance. Nothing critical is missing for an agent to understand and invoke the tool 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 input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds meaningful context about what the tool returns and how it groups facilities (by system, database, class), which is more than just restating 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 what the tool does: it provides an overview of the Ross ERP 8.0 application layer with total facility counts and breakdowns by system, database, and class. This specific, detailed description distinguishes it from sibling tools like list_facilities or search_facilities, which focus on listing or searching rather than aggregate statistics.
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 says 'Use this first to orient before browsing facilities,' providing a clear when-to-use guideline. It does not explicitly name alternative tools or specify when not to use it, but the directive to use it first is sufficient guidance for a parameterless overview tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_columnAInspectLook up a single column by exact name across the whole Ross ERP 8.0 schema: its description, valid values, notes, every table that carries it, and any foreign-key roles it plays.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Column name, e.g. POSTING_DATE or GL_ACCOUNT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the matching behavior ('exact name'), scope ('whole schema'), and the return contents (description, valid values, notes, tables, foreign-key roles). However, it doesn't mention what happens if the column is not found, or whether matching is case-sensitive, which are minor gaps. Overall, it provides substantial behavioral context beyond a simple query.
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 one sentence, front-loaded with the verb 'Look up', and packs all essential information without redundancy. Every element earns its place: action, resource, scope, exactness, and the list of returned details. There is zero 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?
For a simple one-parameter lookup tool with no output schema, the description thoroughly explains the return values: 'description, valid values, notes, every table that carries it, and any foreign-key roles.' It is complete for typical use cases. It could be more complete by addressing not-found behavior, but given the tool's simplicity and the rich return description, it is nearly 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 schema already documents the single 'name' parameter with an example (100% coverage). The tool description adds the 'exact name' requirement, which clarifies matching semantics and excludes wildcard or partial matches. This adds meaning beyond the schema's bare example, so a 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 the tool's function: 'Look up a single column by exact name across the whole Ross ERP 8.0 schema.' It specifies the resource (column), the action (look up), the scope (whole schema), and the exactness criterion. This distinguishes it from sibling tools like search_columns (likely fuzzy) and lookup_table (table-level).
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 gives clear context: use this when you need a column by its exact name and want comprehensive information across all tables. It does not explicitly mention alternatives or when-not-to-use, but the 'exact name' wording implies a contrast with fuzzy search siblings. A 5 would require explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ddlBInspectReturn the CREATE TABLE (DDL) for a Ross ERP 8.0 table, with column descriptions as comments plus primary-key and foreign-key constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Table name, e.g. GL_ACCOUNTS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what the tool returns (DDL with comments and constraints) but does not state whether the operation is read-only, what permissions are required, or how it handles invalid or nonexistent table names. This is a significant gap for a tool that could be assumed to be safe by default.
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 core action: 'Return the CREATE TABLE (DDL)'. It includes relevant details about comments and constraints without any waste or unnecessary jargon.
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 tool with one parameter and no output schema, the description adequately explains the return value and the specific table type (Ross ERP 8.0). However, it could add context about error behavior or the fact that the table must exist, which are not covered. Overall, it is fairly complete for its complexity.
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 fully documents the single parameter 'name' with description and example, achieving 100% coverage. The description does not add additional semantic context, so the baseline of 3 is appropriate—the schema already carries the parameter information, and the description does not enhance it.
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's function: returning the CREATE TABLE DDL for a Ross ERP 8.0 table, including column descriptions as comments and primary/foreign key constraints. This specific action distinguishes it from sibling tools like lookup_table or search_columns, which are likely about metadata retrieval rather than DDL generation.
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, nor does it mention exclusions or prerequisites. While the purpose implies usage for obtaining DDL, there is no comparison to sibling tools such as lookup_table or schema_stats, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
graph_neighborsAInspectList the knowledge-graph neighbours of an object — the programs, tables, views and procedures directly connected to it, with relationship type and direction.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Object name, e.g. GL_ACCOUNTS | |
| limit | No | Max neighbours (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries the burden. It discloses that only direct neighbors are returned, not transitive ones, and that relationship type and direction are included. This is meaningful behavioral context beyond a simple 'list' but does not cover potential edge cases or performance implications.
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 the action, and zero waste. Every clause adds value—scope, object types, and output details.
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?
Without an output schema, the description appropriately mentions output aspects (relationship type and direction). It does not list all response fields but enough for a basic understanding. A tiny gap is lack of example usage or mention of the default limit, but the schema covers limit.
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%, so baseline is 3. The description adds no extra parameter meaning beyond the schema; it merely echoes that 'name' refers to an object. Limited role in parameter clarity is acceptable given schema completeness.
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?
Clear verb+resource: 'List the knowledge-graph neighbours of an object' with explicit object types (programs, tables, views, procedures) and relationship details. Distinguishes from siblings like lookup_* and path_between by focusing on direct neighbors.
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 conveys clear context: use this to discover directly connected objects. However, it does not explicitly state when not to use it or mention alternative tools (e.g., path_between for paths), missing the 'exclusions' that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_facilitiesAInspectBrowse and filter Ross ERP 8.0 UI facilities (menu screens/functions). Filter by system, database, class, a name/code substring, or withTables (only facilities whose table cluster is known); paginate with limit/offset. Returns summaries — use lookup_facility for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name or code substring, e.g. CHECK or AP_ | |
| class | No | Class filter: REPORT | MAINTENANCE | INQUIRY | UPDATE | TRANSACTION | ARCHIVE | CODES | |
| limit | No | Max facilities (default 100) | |
| offset | No | Pagination offset (default 0) | |
| system | No | System filter, e.g. ACCOUNTS_PAYABLE or GENERAL_LEDGER | |
| database | No | Database filter: FIN or MAN | |
| withTables | No | Only facilities with a known table cluster (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that results are summaries, supports pagination, and clarifies the withTables filter. It does not explicitly state that it is a read-only operation, but 'browse' strongly implies it, and the return-summaries note adds useful transparency.
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 three sentences, front-loaded with the core purpose, and contains no fluff. Every sentence adds value: the first defines scope, the second lists filter capabilities, and the third clarifies the return type and points to a complementary 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 the tool's complexity, the description covers the core purpose, filtering options, pagination, and return type. It does not specify what the summaries contain or how to handle ordering, and no output schema is provided, but the pointer to lookup_facility partially compensates. It is nearly complete for a listing 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 input schema already provides 100% coverage with clear descriptions for all seven parameters. The tool description names the filter dimensions but adds little beyond what the schema states, so it remains at the baseline for high schema coverage.
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 browses and filters Ross ERP 8.0 UI facilities, specifying the resource and the action. It also differentiates from lookup_facility by noting that this tool returns summaries while lookup_facility provides full detail.
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 gives clear context for when to use this tool (browsing/filtering summaries) and explicitly recommends lookup_facility for full detail. However, it does not mention when to prefer search_facilities or other sibling tools, so it is not fully explicit about all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_objectsAInspectBrowse and filter Ross ERP 8.0 objects (tables / views / procedures / functions). Filter by type, database, module, or a name substring; paginate with limit/offset. Returns object summaries — use lookup_table for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name substring filter, e.g. GL_ | |
| db | No | Database filter, e.g. FIN or MAN | |
| type | No | Object type filter: table | view | procedure | function | |
| limit | No | Max objects (default 100) | |
| module | No | Module filter, e.g. GL or PO | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose that the tool returns object summaries and supports pagination via limit/offset, which is useful. However, it omits details about read-only behavior, permissions, default sorting, or any edge cases, providing only basic behavioral transparency.
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 concise sentences that are front-loaded with the verb and resource. The first sentence states purpose, the second covers filters/pagination and output behavior. Every clause earns its place with no redundant or filler text.
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 straightforward list tool with 6 optional parameters and no output schema, the description covers the key aspects: purpose, filter types, pagination, and return summary type. It could more explicitly distinguish from search_all, but the overall context 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?
Schema description coverage is 100%, so the baseline is 3. The description adds a bit of semantic grouping by mentioning filters (type, database, module, name substring) and pagination (limit/offset), but it largely repeats what the schema already documents, so it does not significantly enhance parameter understanding.
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 uses specific verb 'browse and filter' and clearly identifies the resource as 'Ross ERP 8.0 objects' with an explicit list of object types. It distinguishes itself from lookup_table by stating that it returns summaries and directs users to lookup_table for full detail, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to 'use lookup_table for full detail,' providing a clear alternative and implying this tool is for browsing/filtering summaries. It explains the filter and pagination capabilities, but it does not explicitly discuss when not to use it relative to other siblings like search_all or find_column, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_programsAInspectBrowse and filter Ross ERP 8.0 vanilla programs (application source, metadata only). Filter by module (ap, gl, ic, sop, ...), type (a=archive, i=inquiry, m=maintenance, r=report, s=server, l=load, u=utility, ...), layer (base | vendor-core), titled (only programs that declare a TITLE id), or a substring of basename/title; paginate with limit/offset. Returns summaries — use lookup_program for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Substring of basename or title, e.g. check_register | |
| type | No | Program-type letter, e.g. r (report), m (maintenance), i (inquiry), s (server) | |
| layer | No | Source layer: base | vendor-core | |
| limit | No | Max programs (default 100) | |
| module | No | Module filter, e.g. ap, gl, ic, sop | |
| offset | No | Pagination offset (default 0) | |
| titled | No | Only programs that declare a TITLE program-id (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool deals with 'application source, metadata only' (read-only context), supports filtering and pagination, and returns summaries. This conveys the read-only listing behavior. It could mention potential rate limits or required permissions, but for a catalog query this level of disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the core purpose and then listing filters and return behavior. It is concise with no redundant phrases, and the mention of lookup_program is a useful pointer rather than filler.
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 tool has 7 optional parameters and no output schema, so the description must convey both filtering and return behavior. It covers filtering dimensions, pagination, and the fact that summaries are returned. It doesn't enumerate summary fields, but 'summaries' and the pointer to lookup_program are sufficient for a listing operation.
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 already provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds value by grouping filters (module, type, layer, titled, substring) and gives concrete examples for module and type, clarifying expected usage beyond the schema's one-line descriptions.
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 'browse and filter' Ross ERP 8.0 programs, naming the specific resource (programs) and the operation (list/filter). It distinguishes itself from lookup_program by noting it returns summaries, making the tool's purpose unambiguous.
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 explicit context: this is for browsing/filtering program metadata, returning summaries. It directs the user to lookup_program for full detail, indicating when to use the alternative. It does not explicitly list exclusions (e.g., when to avoid using this tool), but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_facilityAInspectFull detail for one Ross ERP 8.0 UI facility by code: its name, system, database, class, GEMBASE program, help text, menu paths, the physical table cluster it touches — core (the working set the screen is built on) and reference (control/lookup tables) — and its call graph: the facilities this one invokes (calls) and the facilities that invoke it (calledBy), parsed from the program source.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Facility code, e.g. AP_A_002 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the full scope of the return value, including fields, table clusters (core/reference), and call graph (calls/calledBy) parsed from program source. This goes beyond a generic lookup and gives agents a clear picture of what to expect, though it doesn't mention error conditions or explicitly state read-only 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 long sentence but well-structured with clear lists and parenthetical explanations. It packs substantial detail without wasted words, front-loading the core purpose. The length is justified by the need to enumerate the rich set of return fields, making it efficient despite its length.
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?
Since there is no output schema, the description must explain return values, and it does so thoroughly, listing every category of detail including name, system, database, class, GEMBASE program, help text, menu paths, table clusters, and call graph. This provides an agent with sufficient information to assess whether the result will meet a query's needs, making the description complete for its complexity.
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 parameter is already well-documented. The tool description adds only that it's 'by code', which isn't additional detail beyond the schema's 'Facility code, e.g. AP_A_002'. Baseline 3 is appropriate since 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 a specific verb ('lookup') and resource ('facility by code'), enumerating the detailed fields returned (name, system, database, class, etc.). It distinguishes itself from siblings like list_facilities and search_facilities by emphasizing 'Full detail for one ... facility by code' and listing unique aspects like call graph and table clusters.
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 conveys that this is for retrieving comprehensive details of a single facility when its exact code is known. It doesn't explicitly name alternatives or exclusions, but the contrast with list/search tools is implicit through the focus on one facility and 'by code'. This is clear context, though not exhaustive about 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.
lookup_programAInspectFull detail for one Ross ERP 8.0 vanilla program, by TITLE program-id (e.g. AP_A_002) or source basename (e.g. ap_a_check_register): its module, type, layer, declared title, internal PROCEDURE_FORM procedures, the Data Dictionary tables it references — each classified read vs read-write (a write is a FIND IN.../LOCK=WRITE update, an ADD, or a DELETE) with a writeCount — its call graph (the programs it invokes and the programs that invoke it, from PERFORM "GEM:"), the menu facilities it backs, and — for programs with no TITLE label — a display name carried from the menu facility's registry description. Metadata only — no source body.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Program id or basename, e.g. AP_A_002 or ap_a_check_register |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly. It discloses it is metadata-only ('no source body'), explains the read vs read-write classification logic for table references, and specifies the call graph extraction source (PERFORM "GEM<mod>:<prog>").
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 long sentence densely packed with details. While it is not wasteful, its length and continuous structure make it harder to parse quickly. It could benefit from briefer, more structured sentences, but every phrase contributes substantive 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?
Given there is no output schema, the description takes responsibility for explaining return values. It covers the main attribute groups (module, type, layer, procedures, tables, call graph, menu facilities) and edge cases (programs without a TITLE label), making it comprehensive for a lookup 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% and already explains that id is a 'Program id or basename, e.g. AP_A_002 or ap_a_check_register'. The tool description reinforces this with similar examples and adds the distinction between TITLE program-id and source basename, but adds minimal new 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?
Description clearly states it returns 'Full detail for one Ross ERP 8.0 vanilla program' and enumerates specific attributes (module, type, layer, procedures, tables, call graph, menu facilities). It distinguishes itself from sibling tools like lookup_table and lookup_facility by explicitly targeting programs.
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?
Provides clear context: use when you need comprehensive metadata for a known program, identified by TITLE program-id or source basename. It implies this is for a single known program, but does not explicitly name alternatives like search_programs for when the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_tableAInspectFull schema for a Ross ERP 8.0 object (table / view / procedure / function): columns with type, nullability, keys, descriptions and valid values, foreign keys in and out, related tables, and usage.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Object name, e.g. GL_ACCOUNTS or ACCOUNT_TYPES |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it does not explicitly state that the operation is read-only, nor does it mention error handling, permissions, or side effects. The name 'lookup_table' implies a read operation, but the description itself only lists return contents and offers no behavioral context beyond 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, well-structured sentence that front-loads the core purpose ('Full schema for a Ross ERP 8.0 object') and then lists what's included. Every word adds value, and there is no redundancy or extraneous detail.
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 does an excellent job of enumerating the return contents: columns with type/nullability/keys, valid values, foreign keys in/out, related tables, and usage. It covers all major aspects of a schema lookup. It falls short only by not mentioning error behavior (e.g., object not found), which is a minor gap for a well-scoped lookup 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 coverage is 100% with the 'name' parameter clearly described via an example ('GL_ACCOUNTS or ACCOUNT_TYPES'). The description adds no additional parameter semantics, but the schema already fully documents the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: 'Full schema for a Ross ERP 8.0 object' with a detailed enumeration of schema components (columns, types, keys, FKs, related tables, usage). It differentiates from siblings like find_column or get_ddl by emphasizing the comprehensive schema scope rather than a specific column search or DDL generation.
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 retrieving complete schema details for a named object, but it does not explicitly state when to use this over alternatives such as find_column or list_objects. There are no exclusions or situational guidance, leaving usage to be inferred from the 'full schema' wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
path_betweenAInspectFind the shortest path between two objects in the Ross ERP 8.0 knowledge graph (how A reaches B through calls / references / accesses).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination object name | |
| from | Yes | Start object name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the traversal semantics ('through calls / references / accesses') and implies a read-only operation via the verb 'Find'. However, it does not disclose details such as the exact return format, behavior when no path exists, or any limitations like depth or cycle handling. This is partial transparency, warranting a 3.
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 that directly states the action and clarifies the relationship types. Every word earns its place, with no filler or repetition.
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 tool has no output schema and no annotations, so the description must explain return values and edge cases. It explains the purpose and traversal edge types but does not specify what the output looks like (e.g., a list of nodes, a distance) or behavior when no path exists. This is a noticeable gap, making the description 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?
The input schema already provides descriptions for 'from' and 'to' as 'Start object name' and 'Destination object name' with 100% coverage. The description's phrase 'how A reaches B' reinforces the directional meaning (A=from, B=to) and adds context that the path traverses specific edge types, but it does not add parameter-specific details like case sensitivity or name format. Thus it stays at the baseline of 3.
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's function: 'Find the shortest path between two objects in the Ross ERP 8.0 knowledge graph.' It specifies the verb (find), the resource (knowledge graph), and the scope (shortest path between two objects). This distinguishes it from sibling tools like graph_neighbors, which likely return direct connections rather than full paths.
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 clear context: it is for finding how one object reaches another through calls, references, or accesses. It does not explicitly mention when not to use it or alternatives, but the phrasing 'how A reaches B' implies a pathfinding scenario, distinguishing it from neighbor-query or search tools. No exclusions are stated, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
program_facilitiesAInspectReverse of facility_programs: which UI facilities (menu screens / reports / inquiries) a vanilla program backs — 'what screens does this program run?'. One program often serves several facilities. Lookup by TITLE id (e.g. AP_I_001) or basename (e.g. ap_i_vendors); each facility carries the same declared / titleId match label.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Program id or basename, e.g. AP_I_001 or ap_i_vendors |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the tool is a read-only reverse lookup and that each facility carries the same declared/titleId match label. However, it does not state return format, error behavior, or whether an unknown id yields an empty result. This is adequate but leaves some 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?
The description is reasonably concise, using three sentences to convey purpose, usage context, and key lookup details. It front-loads the core idea ('Reverse of facility_programs') and avoids fluff. Slight redundancy with schema examples prevents a perfect score.
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 lookup tool with no output schema, the description provides enough context: it defines the input, the relationship to sibling tool, and the nature of the output (facilities with a match label). It lacks explicit return-structure details, but the simplicity of the tool mitigates this gap.
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 already documents the single parameter with examples (AP_I_001 or ap_i_vendors), giving 100% schema coverage. The description adds the phrase 'TITLE id' and reinforces the basename option, but does not meaningfully expand beyond the schema. Thus, 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 identifies the tool's purpose: it is the reverse of facility_programs, listing which UI facilities a program backs. It uses a specific verb ('backs', 'runs') and resource ('UI facilities'), and explicitly distinguishes it from the sibling tool facility_programs by labeling itself as the reverse.
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 when to use this tool: when you need to know what screens a program serves. It explains lookup by TITLE id or basename and notes that one program often serves several facilities, providing useful context. It does not explicitly state alternatives or when not to use it, but the 'Reverse of facility_programs' framing effectively guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
program_statsAInspectOverview of the Ross ERP 8.0 program catalog — every vanilla application-source program (metadata only, no source body): total programs, how many declare a TITLE id, how many carry Data Dictionary table links, total program→table edges, read/write counts (withWrites programs, writeEdges program→table write edges), base vs vendor-core split, program→program call-graph counts (programs with outbound calls, total call edges) and how many back a menu facility, plus the module and type breakdowns. Use this first to orient before browsing programs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It explicitly scopes to 'metadata only, no source body' and lists only read-only statistical aggregations, implying a non-mutating operation. It does not explicitly state 'read-only' or discuss authentication, but for a zero-parameter stats tool the described behavior is transparent enough.
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 long sentence but is front-loaded with 'Overview' and uses separators and lists to pack many relevant metrics. Every clause adds distinct information, though breaking it into shorter sentences would improve readability and scannability.
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 self-contained stats tool with no parameters and no output schema, the description enumerates all the categories of statistics returned (program counts, table links, read/write counts, splits, call-graph counts, module/type breakdowns). It also gives usage context. The only gap is the lack of a specific response format, but the metric list is sufficiently comprehensive.
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 accepts zero parameters and the schema is empty, so the baseline of 4 applies. The description appropriately focuses on what the statistics cover rather than adding parameter details, which is correct and 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 identifies the tool as an 'Overview of the Ross ERP 8.0 program catalog' and enumerates specific aggregate metrics (total programs, table edges, call-graph counts), which distinguishes it from sibling tools like list_programs or lookup_program. The verb and scope are explicit and unambiguous.
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 final sentence, 'Use this first to orient before browsing programs,' provides explicit usage context and positions it as a pre-navigation aggregate view. It does not name alternative tools or exclusions, but the 'first' instruction clearly implies when it is appropriate versus more detailed browsing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schema_statsAInspectOverview of the Ross ERP 8.0 schema in one call: object counts by type, module list, total/distinct columns, audit-twin pairs, and the top tables/columns/modules. Use this first to orient before drilling in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does a good job by enumerating what the tool returns, making the output expectations transparent. However, it does not explicitly state that it is a read-only operation or mention any potential performance limitations, which prevents a perfect score.
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 with a colon-led list of contents. It is front-loaded with the main purpose and includes the usage hint, with no wasted words. It is appropriately concise for the amount of information conveyed.
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 that this is a zero-parameter tool with no output schema, the description fully covers what the agent needs: the purpose, the exact contents of the result, and the contextual recommendation to use it first. No additional details seem necessary for effective 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?
The input schema has zero parameters, so there is nothing to document. The description's phrase 'in one call' reinforces that no arguments are needed, which is sufficient. The baseline for zero parameters is 4, and the description adds no unnecessary details.
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 identifies the action ('Overview ... in one call') and the specific resource (Ross ERP 8.0 schema), listing exactly what is included: object counts, module list, column totals, audit-twin pairs, and top tables/columns/modules. This distinguishes it from sibling tools like facility_stats or program_stats, which focus on specific subsets.
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 use it: 'Use this first to orient before drilling in.' This provides clear usage guidance and implies that other sibling tools are for deeper investigation, making it a proper entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_allAInspectCross-domain search in one call — spans schema objects, columns, UI facilities and vanilla programs at once. Use this when you don't yet know which layer a term lives in (e.g. 'check register' is a screen, a program and a table). Scope to one layer with type = object | column | facility | program (default all); limit is per domain.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one domain (default all). 'table' is accepted as an alias for object. | |
| limit | No | Max results per domain (default 25) | |
| query | Yes | Search text, e.g. check register or posting_date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful traits: it spans multiple domains in one call, the type parameter restricts to a single layer with default all, and the limit applies per domain. However, it does not describe the return format, pagination beyond the limit, or behavior with no results, which would make it richer.
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 three sentences with no wasted words. It front-loads the core purpose, then provides a concrete use case and parameter guidance. The example 'check register' is illustrative without being verbose, and every sentence contributes to either purpose, usage, or parameter semantics.
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 3-parameter tool with no output schema, the description covers the key invocation concerns: when to use, what the type and limit parameters do, and the cross-domain nature. It does not explain the response structure, which might be helpful, but the description is adequate for selecting and calling the tool 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?
Schema description coverage is 100%, so parameters are already well-documented. The description adds a clarifying example and restates that limit is per-domain, but it largely repeats what the schema already says (e.g., 'default all' for type, 'Max results per domain' for limit). The additive value for parameter understanding is marginal, which meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Cross-domain search in one call,' clearly stating a specific verb ('search') and resource ('schema objects, columns, UI facilities and vanilla programs'). It explicitly distinguishes itself from single-domain siblings like search_columns and search_programs by emphasizing the cross-domain scope, reinforced with a concrete example ('check register' is a screen, program, and table).
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?
It gives explicit guidance: 'Use this when you don't yet know which layer a term lives in,' which is a clear when-to-use signal. It also explains how to scope via the type parameter, but it does not explicitly name alternative specialized search tools or state when not to use this tool, leaving a small gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_columnsBInspectSearch the Ross ERP 8.0 schema by name (and column descriptions). Returns matching objects and columns.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per group (default 25) | |
| query | Yes | Search text, e.g. posting_date or GL_ACCOUNTS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it searches by name and column descriptions and returns matching objects and columns, which gives some insight into behavior. However, it does not specify whether the search is case-insensitive, if it supports wildcards, whether results are paginated, or any other behavioral traits. This is minimal disclosure for a search 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 a single, front-loaded sentence that covers the core purpose without any redundant phrasing. It is maximally concise and well-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 simple search tool with two well-documented parameters, the description is minimally viable. It states what is searched and the return type. However, given the abundance of sibling search tools and the lack of output schema, there are notable gaps in usage guidance and behavioral detail that prevent a higher score.
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 provides 100% parameter coverage with clear descriptions: 'query' has examples and 'limit' has a default and range. The tool description adds no additional parameter information, so the baseline score of 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's purpose: 'Search the Ross ERP 8.0 schema by name (and column descriptions). Returns matching objects and columns.' It has a specific verb and resource. However, it does not explicitly differentiate from siblings like find_column or search_all, relying on the tool name for distinction.
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. It does not mention search_all, find_column, or any specific scenario where search_columns is preferred. This is a significant gap given the number of sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_facilitiesAInspectSearch Ross ERP 8.0 UI facilities by code, name, help text, program or tag. Use this to find the screen/report for a task, e.g. 'check register' or 'purchase order receipts'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| query | Yes | Search text, e.g. check register or AP_A |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses that the search can be based on multiple fields, but does not describe return behavior (what a result looks like, whether matches are partial or exact, pagination beyond the limit parameter). This is a noticeable gap for a search tool without an output schema.
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 exactly two sentences, with the primary action and scope in the first sentence and a practical usage example in the second. No wasted words; every sentence serves a clear 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?
Given the moderate complexity of a search tool and the absence of an output schema, the description provides sufficient context for an agent to understand what to search and why. It does not describe the return format, but the tool's purpose is clear and the example use cases make it actionable.
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% and both parameters have descriptions. The description adds meaningful semantics by specifying that the query can match code, name, help text, program, or tag, which enriches the query parameter meaning beyond the schema's terse example.
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 searches Ross ERP 8.0 UI facilities, specifying the searchable attributes (code, name, help text, program, tag). It also differentiates from siblings like search_programs by focusing on facilities/screens/reports, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to find the screen/report for a task' with concrete examples ('check register', 'purchase order receipts'), providing clear when-to-use guidance. It does not mention when not to use it or alternatives, but the use case is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_programsAInspectSearch Ross ERP 8.0 vanilla programs by basename, TITLE program-id, title, module or type. Use this to find the program behind a task, e.g. 'check register' or 'ap_a'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| query | Yes | Search text, e.g. check register or AP_A_002 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It discloses the scope ('vanilla programs') and search fields, but omits details like case sensitivity, match type (substring/fuzzy), limit application, or output format. This adds some context but leaves ambiguity.
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, front-loading the core function and following with a practical example. 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?
For a simple search tool with two parameters and no annotations or output schema, the description covers purpose and usage, but does not explain what the search results contain or any default behaviors. It is mostly complete but lacks return-value 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?
Schema coverage is 100%: both parameters have descriptions. The tool description does not add significant meaning beyond the schema's parameter descriptions; it only includes a usage example already present in 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 specifies a clear action ('Search'), a target resource ('Ross ERP 8.0 vanilla programs'), and searchable attributes (basename, program-id, title, module, type). It differentiates from sibling tools like list_programs (list all) and lookup_program (exact lookup) by indicating it finds programs from task-oriented 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?
The description explicitly states a use case: 'Use this to find the program behind a task, e.g. check register or ap_a.' This provides clear contextual guidance for when to invoke the tool, though it does not explicitly mention alternatives 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.
table_facilitiesAInspectReverse lookup: which UI facilities (screens/reports/programs) touch a given Ross ERP 8.0 table — split into core (facilities whose working set includes it) and reference (facilities that use it as a control/lookup), each with how many times the program source accesses it. Answers 'what screens read or write this table?'.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name, e.g. GL_ACCOUNTS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the output structure (core vs. reference, access counts) and clarifies what 'touch' means. It does not explicitly state read-only behavior, but the nature of a reverse lookup and the wording 'accesses' imply a safe query 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 two sentences with no wasted words. It efficiently packs the reverse lookup purpose, the core/reference split, and the access count detail in a structured dash clause. The final question reinforces the tool's intent without 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?
For a single-parameter lookup tool with no output schema, the description is adequately complete. It tells the user exactly what the tool returns (facilities split by core/reference with counts) and answers the primary use case. No significant behavioral detail is missing.
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 full coverage for the single 'table' parameter with an example (GL_ACCOUNTS). The description only adds the Ross ERP domain context and does not introduce new parameter-level semantics beyond the schema, matching the baseline of 3.
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 a reverse lookup from a given Ross ERP 8.0 table to UI facilities, and further specifies the split into core and reference with access counts. The 'Reverse lookup' phrase and the question 'what screens read or write this table?' effectively distinguish it from forward lookup tools like lookup_table and table_programs.
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: when you have a table and want to know which facilities (screens/reports/programs) use it, with a clear breakdown. It does not explicitly name alternatives, but the 'reverse lookup' framing and the answerable question provide clear context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
table_programsAInspectReverse lookup: which vanilla Ross ERP 8.0 programs reference a given table (validated against the Data Dictionary). Answers 'what code touches this table?' — complements table_facilities (which answers 'what screens touch it?'). Metadata only — no source body.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name, e.g. GL_ACCOUNTS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses two key behaviors: validation ('validated against the Data Dictionary') and output scope ('Metadata only — no source body'). These go beyond the basic lookup and help set expectations, though it doesn't mention rate limits or auth (less critical for a read-only lookup).
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 sentences, front-loaded with the core action ('Reverse lookup'), and every phrase earns its place. It includes purpose, scope, validation, sibling distinction, and output type without fluff.
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 lookup with no output schema, the description sufficiently covers the tool's role, scope, validation, and limitations. It doesn't describe the return format (e.g., list of program names), but given the straightforward nature and lack of an output schema, this is acceptable. Sibling context and the complement note round out the context.
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% (the 'table' param is described with an example), so baseline is 3. The description adds semantic value by indicating the table must be a valid Data Dictionary table ('validated against the Data Dictionary'), which informs the user about expected input validation. It also implicitly ties the parameter to the 'given table' in the lookup.
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 begins with 'Reverse lookup: which vanilla Ross ERP 8.0 programs reference a given table' – a specific verb ('reverse lookup') and resource ('programs referencing a table'), clearly distinguishing it from the sibling table_facilities (screens vs. code). The phrase 'Answers what code touches this table?' reinforces the purpose and differentiates it from related 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?
It explicitly identifies a complementary tool: 'complements table_facilities (which answers what screens touch it?)', guiding users when to choose this tool over that one. However, it does not explicitly state when not to use other sibling tools or exhaustively cover alternatives, so it stops short of a full 5.
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!